In the previous blog on DNS privacy, we covered how the current DNS does not provide for any confidentiality of queries or responses. Pervasive Monitoring (PM) of clear-text DNS messages can reveal a great deal about a client. With a heightened awareness of Pervasive Monitoring, there is a sincere desire to preserve user’s personal privacy when using DNS over the Internet. In this blog we will cover the work being done within the IETF to help mitigate the DNS privacy issues.
IETF Work on DNS Privacy
The IETF is actively working on DNS privacy and confidentiality solutions. The IETF has formed a DNS PRIVate Exchange (dprive) working group. DNS privacy topics are also covered by the DNS Operations (dnsop) working group. There is also an IETF mailing list specifically for discussions about DNS Privacy (dns-privacy@ietf.org). You can subscribe to the mailing list here. The archives for this mailing list can be found here.
One of the primary IETF RFCs on this topic is DNS Privacy Considerations (RFC 7626). This RFC originally started as a draft authored by Stéphane Bortzmeyer (AFNIC) which came out of the dnsop working group (but then it changed into a problem statement, which then became an RFC). This DNS Privacy RFC offers a good overview of the issues at hand and hints at some of the possible solutions. Another draft, albeit expired, that covered some of these same topics of monitoring DNS traffic is titled “Confidentiality Aspects of DNS Data, Publication, and Resolution”.
Client Subnet in DNS Queries
Most DNS queries use UDP, but sometimes TCP can be used, when the query response is large for example. This choice is also influenced by the availability of EDNS0. Thus, another IETF draft germane to the discussion about DNS privacy is “Client Subnet in DNS Queries”. This draft proposal intends to include a masked IP address of the originating DNS client within the DNS query and place it into the EDNS0 OPT resource record. When a client uses a public recursive DNS server, a GSLB system may incorrectly assume that they are near each other. The aim of this technique is that it helps aid the resolution based on network topology geographical proximity information. The DNS servers will more precisely know about the client’s location and be able to return resolutions that direct the connection to the nearest content to reduce latency and maximize end-user experience. The disadvantage of this technique is that it reveals information about the client’s network location that could be pervasively monitored by recursive DNS servers or authoritative name servers.
DNS Cookies
In recent years, we have witnessed an increase in DNS message amplification attacks due to open DNS servers. The attacker will send spoofed queries to a set of DNS servers that do not restrict queries. The DNS servers respond to those spoofed queries’ fake source addresses with a large amount of response data. The result is a high-volume stream of DNS response packets destined for the spoofed IP address which leads to the victim’s network. One proposed method to help thwart these types of attacks is to use DNS cookies. This draft proposes creation of a cookie OPT resource record (EDNS0 RFC 6891) response data for either a client cookie or a server cookie to provide a lightweight DNS transaction security measure. This paper also further explains how DNS cookies would work between the client and the recursive name server and between the recursive name server and other DNS servers. This DNS cookie technique has been implemented by ISC in BIND 9.10.0b1 as the Source Identity Token (SIT) feature. The benefit of this technique is that DNS cookies would provide a method of protecting against DNS packet amplification attacks. Unfortunately, this technique does not provide any privacy protection.
DNS Minimization
A central issue in DNS privacy is that DNS queries contain the full Query Name (QNAME) on each recursive query. Therefore, each DNS server queried along the tree traversal would know the full question being asked by the client. This can contain more information than is required. For example, queries to TLD or root name servers should only be a query for a Name Server (NS) record for the authoritative DNS server for that queried domain. The concept is similar to only asking the specific question required at the moment without giving away the complete intent of the questioner. In this way, the answer is not provided too much information and provides for a “separation of duties” security measure.
The IETF dnsop working group has created a draft, again authored by Stéphane Bortzmeyer (AFNIC), titled “DNS query name minimisation to improve privacy”. With this solution, the queries to the root name servers only contain a query for the Top Level Domain (TLD) that contains the domain name being looked up. The query to the TLD name server only contains a query for the NS record for the next-level down the zone tree structure for the organization’s authoritative DNS server. Each subsequent query contains more specific information and only the authoritative name server observes the complete QNAME query.
Encryption of DNS Requests
Other solutions to solving the DNS privacy conundrum involves performing encryption of the DNS packets to prevent traffic inspection and protecting against eavesdropping. At the 2014 IETF 89 meeting in London there was an “Encryption of DNS requests for confidentiality” (DNSE) Birds of a Feather (BOF) session where several options were discussed.
Confidential DNS
One draft proposal is titled “Confidential DNS”. This proposal defines the creation of a new ENCRYPT resource record type (RRType). The DNS server publishes encryption keys and the ENCRYPT RRType is used for each segment of the DNS query path.
TLS for DNS
Transport Layer Security (TLS) (and its predecessor Secure Sockets Layer (SSL)) is a popular technique for providing confidentiality to many types of communications applications. TLS is best known as the secure form of HTTP that uses public key cryptography to validate the authenticity of the site (but then uses symmetric cryptography for the encryption of the transmitted data). TLS can also be applied for collaboration applications and it is also possible to use TLS over TCP to provide security for DNS queries.
There are several benefits to using TCP for DNS queries. UDP DNS queries are often spoofed and used for large-scale DDoS attacks. TCP avoids the problems of DDoS attacks using open recursive DNS servers and allows for TLS encryption. These are all great benefits, but most DNS queries use UDP and so this TLS method of encryption with TCP may not apply to all DNS queries. Besides, TCP can end up being used anyway for larger DNS responses such as those containing more data (e.g. DNSSEC, DANE, TLSA, etc.).
This IETF draft proposal titled “TLS for DNS: Initiation and Performance Considerations” describes how TLS can be applied to protect the confidentially of DNS query payload data.
DNS over DTLS
Since most DNS queries utilize UDP, then using TLS for encryption may not be the best applicable for all situations. Thankfully, there may be an option of adding encryption to the typical UDP DNS queries. The Datagram Transport Layer Security (DTLS) protocol is a method of encrypting application payload data transported over UDP.
The IETF draft proposal titled “DNS over DTLS (DNSoD)” describes how this might work. You might recognize the name Dan Wing, one of the authors of this draft. Dan Wing (along with Andrew Yourtchenko, both with Cisco) is an author of the Happy Eyeballs RFC (RFC 6555) that describes a technique to improve end-user experience for dual-protocol communications.
More DNS Privacy Activity Expected in 2016
Judging from the activity in the area of DNS privacy, this will likely be a popular topic of discussion and action in 2016. There are many different solutions, some competing with each other. Many of these solutions are just early IETF drafts of concepts but a few of these ideas may make their way into the Internet Systems Consortium’s (ISCs) BIND software and appear on their list of features. In the meantime, we should consider how monitoring of our DNS traffic can leave us vulnerable to a loss of privacy.
