Edwards Snowden’s revelations about the NSA’s widespread surveillance and pervasive monitoring started a large number of initiatives to advance security and privacy of standards. For the Domain Name System (DNS) this resulted in DNS over Transport Layer Security (DoT): a specification for eliminating opportunities for eavesdropping and on-path tampering with DNS queries.
As more products include support for DoT (Quad9 and Cloudflare to name two), its use increases; as do questions regarding the value and relevance of Domain Name System Security Extensions (DNSSEC) in this setting. After all, the connection to your DNS provider that you trust with your queries is secure and authenticated, so no one can interfere, right? Well… yes, but also not quite.
Currently, DoT and DNSSEC are complementary: they serve two different purposes (privacy and origin authenticity respectively), and thereby overcome each other’s limitations and weaknesses. This said, DoT could realistically become a viable replacement for DNSSEC. It would entail a fundamentally different — more indirect — security and trust model though, that relies on (authorized and authenticated) operators to convey data correctly, instead of validating the correctness of the data itself.
Key Points:
- DNSSEC and DNS over Transport Layer Security (DoT) are two different, yet complementary things.
- The exempt nature of DNS practice at the edges gives DNSSEC a poor chance of being delivered properly.
- DoT brings reliable delivery of DNS, which might make DNSSEC and DANE finally happen after all.
Why did we need DNSSEC again?
Traditionally, DNS has been running on the User Datagram Protocol (UDP). A UDP DNS transaction is a very brief affair — the client sends the DNS question in a single UDP message, and the server responds also with a single UDP message.
Because of this stateless mode of operation, an attacker capable of spoofing source IP addresses is able to impersonate a DNS server and forge fake DNS responses. DNSSEC is designed as the definite countermeasure against these kinds of attacks.
At the time DNSSEC was designed, using a different transport for DNS, like TCP, would have dealt with the issue just fine. However, for various reasons — like the low cost of scaling up UDP and, perhaps also, the desire to address the matter conclusively at a more fundamental level — that choice was not made. Instead of changing the transport, the choice was made to protect the zone data itself by letting the holders (owners) of the zone digitally sign for their own zones.
Data/origin authenticity versus authenticated TLS
There is a fundamental difference in the trust models used by DNSSEC and the Transport Layer Security (TLS). It is important to understand this difference for the discussion and case below.
DNSSEC validating resolvers can verify that the DNS answer is from the actual owners of the data, by verifying the signatures they created for their own data. This property is known as origin authenticity.
It is not at all important how the DNSSEC validator obtained the data. It does not even have to come via the DNS network protocol. Either way, the data integrity can be verified to be the same as that created by the source of the data. The ability to verify DNSSEC data is transitive.
The trust model provided by the TLS is quite different. With TLS, the remote end is authenticated, but the data received over the transport channel is not. One has to trust the remote end of the channel to have acquired and to serve you the correct unmodified data.
The first mile of the DNSSEC problem: DoT to the rescue
Despite the fact that the ability to verify DNSSEC data is transitive, it is — for end users — very hard to get by. Non-standards compliant Customer Premise Equipment (CPE) (modems and such) and enterprise middleware severely hamper delivery of DNSSEC data over conventional UDP DNS network protocol.
The first mile, from the stub resolver on the end-user’s machine to the recursive resolver is, more often than not, not protected by DNSSEC with the traditional UDP/DNS protocol.
DoT can jump to the rescue. Authenticated TLS provides a private and protected path, not susceptible to tampering by middleboxes. Sure, it can be actively blocked, but it won’t be broken by amateurish protocol forwarding implementations, which are so commonly seen with CPE DNS infrastructure [1, 2, 3].
Is DNSSEC still needed?
With authenticated TLS, a client can be certain it is connected to the intended other end. With this certainty, there is no added value in DNSSEC validating that the address for the service belonged to the domain name. That domain name is verified after connection establishment anyway.
Also, DNSSEC protects the mapping from a domain name to an IP address, but routing to the IP address is not protected. The IP address itself is still vulnerable to hijacking. This uncovered gap does not exist with authenticated TLS, although…
Too many Certificate Authorities: DNSSEC to the rescue
Authentication with TLS means verifying that a Certificate Authority (CA) vouched for the domain name at the service endpoint. For this, a TLS-verifying client maintains a CA repository. Any CA in the repository can vouch for any domain name. There are at least 1,500 CAs that can vouch for any name.
It does not matter which CA you picked; all the other ones have the ability to hijack a TLS session for your name. This is quite different from DNSSEC, where the zone owner is in control of its own names instead of having to rely on 1,500 third parties.
The DNS-Based Authentication of Named Entities (DANE) can address this weakest link problem by pinning either the CA or the key used at a TLS service, with a DNSSEC-signed DNS entry.
DoT and DNSSEC, two different things
DoT makes sure your DNS requests are known only to you and the DoT server. The answers given by the DoT server, however, do not necessarily need to be correct. The cache of a security ignorant DoT server that does not DNSSEC-validate may get poisoned. For an end-entity to be absolutely sure that it receives correct unmodified answers, it needs to DNSSEC-validate the requests itself.
Luckily, DoT helps out greatly in covering that first-mile hurdle (remember, the broken CPEs) and getting DNSSEC to the end-entities. Vice versa, DNSSEC can strengthen the certainty that you’re talking to the intended DoT server with DANE. But, …
What if?
What if — in an imaginary future world — all DNS traffic in the whole world is over TLS; not only from the stub to resolver but also from the resolver to the authoritative server?
In this model, instead of the zone owners vouching for the zone data, they trust the authoritative servers (which might be run by an appointed DNS operator) to serve the zone content properly. Resolvers can be certain the data is from a zone owner authorized authoritative server, by authenticating them.
Many of DNSSEC’s current features would work just as well in this setting. For example, when an authoritative nameserver would return a delegation it could provide a DANE (TLSA) record alongside each NS record, effectively eliminating the ‘too many CAs’ problem in this setting too.
The CA store of a recursive resolver would contain the CAs needed to authenticate the 13 root servers. The resolver then learns the keys in use by authoritative servers for the Top Level Domain (TLD) alongside the delegation from the root server, and subsequently, the key in use by the authoritative servers for the Second Level Domain alongside the delegation from the TLDs’ authoritative server, and so forth.
NSEC records would also still be useful for aggressive NSEC to effectively reduce DNS traffic at authoritative name servers (traffic generated by broken software or DDoS attacks).
All this without the non-trivial administrative burden of zone signing, key rollovers, and algorithm rollovers, which currently torment the zone owners. Zone owners simply appoint DNS operators they trust, and resolvers know they contact those trusted operators because they are authenticated.
Of course, this is a highly speculative future. Completely replacing DNS over UDP with DoT would require a completely different approach to DNS infrastructure, with higher operational costs and higher resource demands: TCP/TLS doesn’t come for free! But there is another development that might demotivate and reduce the need for clients to do DNSSEC validation: DNS over HTTPS (DoH).
What if, in a slightly less imaginary future…
Currently, operators of web servers have full control over the content (the web pages) they serve. A client has no other choice than to rely on that operator to serve the correct web page. When following a link on the page, it is essential to DNSSEC-validate the lookup for the link, to prevent the link from being hijacked via the DNS.
But, what if browsers would send queries surrounding a webpage in-band to the server serving that page; or the webpage would push along with the web page all DNS answers for all links on the page? Since we have to rely on the operator to provide the right references already, should we then not just go with the provided IP address too?
With out-of-band DNS we had to rely on one party (web operator) and could validate the other party (DNS operator). With in-band DoH, we eliminate the DNS operator and are left with the web operator, which we have to trust to provide the correct data to begin with.
Note, it is important that those resolutions are not used in another context than the webpage. Otherwise, the operator of the webpage will be able to control resolution outside the context of the webpage.
Also note, it is important to only use pushed addresses. Currently, web operators cannot (without a redirection or javascript mechanism) track what link is clicked on a page because the resolution is done with a third party. In-band DNS resolution, by request, would reveal that information. Information the web operator would not have access to so easily before.
DNSSEC (and DANE) might actually finally happen thanks to DoT
The trust model of DNSSEC and TLS are fundamentally different.
- With TLS, a third party CA vouches for a key in use by an operator. The operator could be yourself, or someone you trust to provide your service properly and truthfully. The operator is authenticated, and therefore auditable, and can be held accountable for the quality of the delivered service. It is in the interest of operators to provide top quality service to obtain a top reputation (and the clientele alongside).
- With DNSSEC, you vouch for your own data. Unfortunately, in current DNS infrastructure, that data needs to be delivered over a gallimaufry of anonymous, unaccountable UDP-based proxies and resolvers, quite often part of cheap CPEs. DNSSEC is the victim of this cobbled-together practice and has a very poor chance of being delivered properly. DNSSEC availability is very unreliable at endpoints, and this is a pity because DNSSEC can help out greatly with the flawed trust model of TLS (that is as strong as the weakest CA), with DANE.
Like nature, the Internet is constantly evolving. Changes in the environment can turn out favourable for already existing beings (giving them a chance to develop and flourish). DNSSEC had to live in the harsh and hostile environment of untrustworthy ‘best effort’ UDP-based DNS. Although DoT’s primary goal is adding privacy, it also brings the reliable untampered delivery of DNS as a side effect, which is excellent news for DNSSEC. In a DoT environment, DNSSEC could actually become available at endpoints!
Service operators and ISPs have made the Internet the success it is. Giving them full (accountable and auditable) responsibility of correct delivery of DNS (in the DoT-only world) could be a viable alternative for verifying the integrity of DNS responses with DNSSEC.
However, DNSSEC is a little more than just integrity verification. With DANE, owners of a zone can vouch for their own services instead of having to purchase authentication from a ‘1 of >1500’ third party. If the world finds this worth addressing, then — with DoT finally making DNSSEC available at endpoints — there might be a bright future for DNSSEC after all.
Willem Toorop is a researcher and developer at NLnet Labs, a non-profit Research and Development lab dedicated to the development of Open Source software and open standards for the benefit of the Internet.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.