Skip to main content

DNS security still an issue

DNS security is a decades-old issue that shows no signs of being fully resolved. Here's a quick overview of some of the problems with proposed solutions and the best way to move forward.

Like almost all of the original and fundamental Internet protocols, DNS transactions are designed to be transported in plain text on the wire. Other network users can see the domains to which users are resolving by sniffing their DNS requests on TCP or UDP port 53. Though it has taken too long to fix, as is usually the case, the industry is finally getting around to it. But it won't be pretty. We can look forward to a variety of DNS security standards that aim to address a variety of problems in a variety of ways. 

The current standard for securing DNS

The first proposed standard for DNSSEC (RFC 4033 and many others) is almost 20 years old, but it solves a different problem: validating the provenance of DNS results, by using public and private keys and signatures in the DNS to prove that an authorized party actually created the DNS entry. This protects the client against certain attacks, such as DNS cache poisoning.

After many years of availability, DNSSEC has yet to attain significant adoption, even though any security expert you might ask recognizes its value. As with any public key infrastructure, DNSSEC is complicated. You must follow a lot of rules carefully, although some network services providers are trying to make things easier.

But DNSSEC does not encrypt the communications between the DNS client and server. Using the information in your DNS requests, an attacker between you and your DNS server could determine which sites you are attempting to communicate with just by reading packets on the network.

So despite best efforts of various Internet groups, DNS remains insecure. Too many roadblocks exist that prevent the Internet-wide adoption of a DNS security solution. But it is time to revisit the concerns.

The next generation of DNS security models has arrived

Enter DNS over TLS (RFC 7858 and RFC 8310), a new standard that uses Transport Level Security (the successor standard for SSL) to strongly encrypt DNS communications between the client and server. DNS over TLS builds on existing, proven Internet technologies to provide strong protection. Will DNS over TLS adoption move more quickly than DNSSEC? Perhaps. It uses the existing TLS infrastructure rather than creating a whole new one, as with DNSSEC. And it solves a problem that everyone agrees is worth solving.

On the other hand, there are at least two big reasons why organizations would put off adoption. The first, comparatively minor, issue is the need to obtain and maintain certificates for DNS servers. The other, more serious, consideration is that existing software probably needs modification to work smoothly with TLS over DNS.

This latter problem is probably the main one holding back genuine adoption of DNSSEC as well. The world is full of software that uses standard library calls like gethostbyname() and getaddrinfo() that query the DNS in ways that make it difficult to simply swap in DNSSEC. If your software works at a lower level with DNS, there is even more work to do. Conventional DNS queries are simple, but working with DNSSEC queries involves validating digital signatures and confirming them all the way along the “global chain of trust” to the root of the DNS to ensure the results have not been modified from those created by the authorized entity.

Even if everyone agrees that using DNSSEC would be good, comparatively few IT shops are willing to go to the significant extra effort to make software that works correctly with DNSSEC and with plain-old insecure DNS. DNS over TLS has the same problem to a lesser degree.

How to handle error reporting

With respect to error reporting, TLS validation errors for a DNS connection could probably be hidden, at least initially, behind more general “connection error” handlers and messages. The real problem is behind the scenes a bit, as described by RFC 7858 (DNS over TLS, section 3.4):

For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()", current implementations are known to open and close TCP connections for each DNS query. To avoid excess TCP connections, each with a single query, clients SHOULD reuse a single TCP connection to the recursive resolver. Alternatively, they may prefer to use UDP to a DNS-over-TLS-enabled caching resolver on the same machine that then uses a system-wide TCP connection to the recursive resolver.

In other words, conventional DNS programming practices used on DNS over TLS will probably noticeably impact network performance. Getting around this problem could be a lot of work and would add moving parts to the network stack.

The suggestion to employ UDP raises another point about DNS over TLS that is probably academic in the short term. Because TLS is a TCP-only protocol, so is DNS over TLS. This is a problem for the many implementations of DNS that use UDP for transport.

Performance problems require workarounds

In general, DNS doesn’t have a reputation for high performance. That leads to ubiquitous caching and other tricks, such as UDP, for getting any advantage possible. For this reason, there is a separate Datagram Transport Layer Security (DTLS – RFC 6347) specification and the DNS over TLS spec makes references to UDP use. But don’t assume that TCP implementations of DNS over TLS also support DNS over DTLS; Cloudflare’s early implementation does not.

Beyond issues of network performance and proper TLS operations, once the secure connection is set up, the workings of the actual DNS transaction are the same with DNS over TLS as with conventional DNS. TCP port 53 is the standard, “well-known” port for DNS; the IANA has reserved port 853 for DNS over TLS.

Innovation in your inbox. Sign up for our weekly newsletter.

It helps that DNS over TLS has some support from large, important companies. I already mentioned Cloudflare, which is always on the cutting edge of new Internet security standards. Several DNS server vendors support DNS over TLS—for example, PowerDNS, Bind, Technitium, and Unbound. Cloudflare, Quad9, and Tenta all provide free public DNS resolvers that support both DNS over TLS and DNSSEC.

Web browsers lack support for new technologies

It doesn’t help that no major web browsers support DNS over TLS yet. (Tenta’s Private VPN Browser + Ad Blocker (Beta) supports it on Android.) The latest version of Android (9, a.k.a. Pie) supports it, but not the Chrome browser. And we have no word yet from Mozilla, Microsoft, or Apple about support in their browsers for the standard.

DNS over TLS solves the problem of sniffing the wire, but it doesn’t solve all theoretical problems, most obviously the problems DNSSEC addresses. If the DNS response sent by the server over TLS is manipulated or otherwise false, the fact that the data is encrypted on the wire won’t help.

It’s also important to understand that the DNS server itself still has your DNS requests—it has to, in order to service them. Those requests will be in a log file, for how long depending on the policy set for the server. Administrators, potentially hackers, and with proper authorization, law enforcement can still get access to those records. This problem, if you view it as a problem, is a more general one that applies to almost all network services.

But DNS service providers and browser ISVs are working on this problem, too. According to this Mozilla article, a Trusted Recursive Resolver (TRR) appears to be a DNS resolver with a rigid privacy policy. The administrators “have committed to throwing away all personally identifiable data after 24 hours, and to never pass that data along to third parties. And there will be regular audits to ensure that data is being cleared as expected.” It’s basically a trust system and not yet an accepted standard. TRR is the term Mozilla coined for its resolvers that meet their privacy criteria and provide encrypted transport of DNS answers to the Firefox browser. At the moment, Cloudflare is the only one in the world supporting this technology.

D'oh!

If DNS over TLS doesn’t catch on, Google, Mozilla, and others are working on DNS over HTTPS (DoH—yes, really, they use that acronym), which should accomplish the same level of security but present fewer issues with firewalls. It allows DNS to be implemented over content delivery networks. In fact, Mozilla has already rolled this out in its browser, and Cloudflare supports it as a resolver.

DoH also moves DNS programming into the more modern realm of REST APIs and JSON, and in fact, this is the way it becomes usable over HTTPS, getting security almost for free.

DoH is probably the most straightforward of the proposals, which is how it reached actual deployment inside of a year since the formation of the working group. The proposed specification is very short, and it uses a programming model that is as hot as a vinyl car seat in summer. Rather than try to make minimal changes to an insecure architecture in order to make it secure, DoH uses new, better, and increasingly familiar ways of programming to take advantage of existing, proven security systems. All this makes it better than DNS over TLS, but DoH doesn’t solve the authenticity problem addressed by DNSSEC.

The usual gang of security proliferators—Google, Cloudflare, and Mozilla all work hard at this—seem to be throwing every DNS security idea they have at the wall to see what sticks. At some point, the proliferation of standards could produce more confusion than opportunity. We may already be there.

DNS security: Lessons for leaders

  • The current DNS security model is insecure, and earlier attempts to resolve that issue have little traction.
  • Multiple new solutions are being proposed, but each has some gotchas.
  • Whatever the solution is, it will require industrywide adoption to be effective. 

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.