There is a lot of confusion about security in the DNS – what it does and does not do and how it might affect choices that you make in deploying DNS. With DNS and its role in security garnering more and more attention, it seems timely to review what the various pieces are and how they can affect your business. There are three related topics: DNSSEC, Query Minimization and DNS over TLS.
Before we begin, it’s important to keep in mind some technical distinctions. There are broadly speaking three kinds of participants that send DNS messages: authoritative DNS servers, recursive DNS servers, and stub resolvers. The authoritative servers are the ones that make your domain name work, so you can offer your services at that domain name. Dyn’s Managed DNS services are authoritative: you put your information into a zone, and Dyn serves it up. Recursive servers, on the other hand, do not have the zone data. Instead, when a recursive server is asked about a domain name, it goes out onto the internet, gets all the relevant data from all the various servers, and serves up the final answer in response to the original query.
Dyn’s Internet Guide service is a recursive service. Recursive servers usually get those original queries from stub resolvers. These are the basic pieces of functionality that live in every computer — including your smartphone, your laptop, and so on — that allows the whole DNS train to get started. There are some additional complications in the system, but for this discussion these are the pieces we need to think about.
The DNS Security Extensions — widely known as DNSSEC — were intended to solve a particular problem in the DNS. When a stub resolver asks a recursive server for an answer, it has no way to be sure that the answer it gets really is the legitimate one. Because of the way DNS works, there is a technical possibility that an attacker can hand back the answer faster than the real recursive server can. Suppose that I am an attacker and I want to get all of the banking information for customers of a hypothetical bank, “LargeBankXX”. I can get an account in HomeISP’s network. I send a flurry of spam mail to other HomeISP customers, pretending to be LargeBankXX. If one of those customers clicks on the link, I work fast and respond to the HomeISP query, giving it a fake answer. That fake answer takes the customer away to a site controlled by me. Now the customer enters a bank login and password, and I have their information. Later, I log in as them and empty their bank account.
This kind of attack is one that was well-known for some time, but it received a lot of attention in 2008 due to researcher Dan Kaminsky. In order to counteract the problem, DNSSEC gives everyone on the Internet a way to authenticate data from the DNS: if one has an answer from the DNS, it contains all and only the data that it should according to the authoritative server. In short, it works by adding digital signatures to the data in the DNS. If you receive DNSSEC-signed data, you can check the data against the accompanying signature, and make sure that it is signed with the official keys for that domain. Yet it does this without needing to consult the authoritative servers for every answer, which means that the DNS can continue to grow sustainably, just as it always has. This “record signing” trick is basically the same one used by software vendors to check that the software updates you download are the right ones, and that an encrypted website is really the one it says it is, so it is a well-proven approach to ensuring data integrity.
DNSSEC does not encrypt data in transit, so it is not like https. It does not make the transaction private, but simply allows you to be sure that, if you get the data, it is the data you are supposed to get. Every answer from a signed zone must be signed, or it will be evaluated as “bogus” — that is, it will look as though it has been tampered with.
To deploy DNSSEC, servers and stub resolvers all over the internet need to be upgraded. Also, zones need to be signed and maintenance procedures updated. It has taken some time to get all of that work done, but today we are seeing increased use of and demand for DNSSEC.
In the wake of revelations that were borne from Edward Snowden, the Internet Engineering Task Force (IETF) has become increasingly concerned about the privacy of data on the Internet. One part of this privacy involves what sites someone connects to. Each time you visit a website like www.dyn.com, you need to find the address of that site. Historically, your computer’s stub resolver asked your local recursive server for the answer – so when you ask to go to “www.dyn.com”, anyone who is logging the queries at that recursive server will now know that you want to go to the Dyn web site. But the data leak is worse than that, because historically recursive servers also asked for everything. Suppose your recursive server wanted to send you to www.dyn.com but didn’t know where it was yet, and had to start at the top-post point in the DNS, the root. Under the original DNS design, your recursive (which might be operated by your ISP, or might be a service like Internet Guide) asked the root for the way to www.dyn.com. The root provided a redirection to com, then your recursive server would ask the com nameservers for www.dyn.com. They also would provide a redirection, to the nameservers for dyn.com. Finally you would get the answer for www.dyn.com. This meant that both the root and com nameservers would know that somebody using your recursive name server wanted to go to the Dyn web site. In the era of big data, collecting all of this together can turn into a privacy problem.
In order to reduce this problem, the IETF came up with Query Minimization. Instead of asking the biggest question possible, DNS systems ask the smallest one. So, in the above scenario, for instance, the recursive server would ask the root just for the location of the com name servers. It would ask the com nameservers just for the location of the dyn.com nameservers. And finally, it would ask for the answer it wanted (www.dyn.com) just from the dyn nameservers. This reduces the number of servers in the world that know what website is being contacted, so it increases privacy.
DNS over TLS
I noted above that DNSSEC offers no privacy, only data integrity. This leaves the problem that all the DNS queries you ever send from your computer to a recursive server can be monitored by someone else. Since every web page can require dozens of DNS queries, monitoring those queries passively provides a convenient way to make a profile of a user.
This is where privacy becomes an issue. The IETF has created two mechanisms for encrypting queries while they are being sent. The first, adopted for standardization, is DNS over TLS, which works approximately the same way that https does: it uses transport-layer security (TLS) to create a secure channel between the source of a DNS query and the server that answers it. Instead of using the traditional DNS arrangement of the User Datagram Protocol on port 53, it uses Transport Control Protocol on a different well-known port (853). Because it uses TCP and needs to deal with some overhead to get started, it is perhaps best suited for the link between a stub resolver and a recursive server.
The second mechanism is DNS over DTLS, which is an experiment to use datagram transport-layer security (DTLS) instead of TLS. It has the advantage that it does not require TCP. It uses the same port as DNS over TLS (853). There is some additional overhead in DNS over DTLS also, so it is again specified mostly for communication between stub resolvers and recursive servers. In principle, both techniques will work for other cases too; but if Query Minimization is broadly deployed it may be that protecting the communications beyond the stub-to-recursive will not yield significant benefits for the required cost.
Protecting the Infrastructure
None of these developments are aimed at the secure and stable operation of the DNS infrastructure. DNSSEC makes DNS response sizes bigger, so for that reason it may inadvertently create more opportunities for Denial of Service attacks. Both TLS and DTLS can be computationally expensive for servers, and that means that attackers can cause denial of service that way, too. But protecting the DNS from pervasive surveillance and fraudsters is just as important as making sure that it can always answer: a system that provides a good but dangerous service is still dangerous. What it does mean is that scaling DNS services to do what is needed on the Internet today requires more DNS expertise than ever.
To learn about Dyn DNS, please visit http://dyn.com/traffic-management/.