When a host doesn’t know the IP address for a hostname, what does it do? It asks its configured DNS server to resolve the hostname.

We all know what the DNS server is and how it basically works. Whenever a user types a domain name (such as ‘duckduckgo.com’) into their browser window, this triggers a DNS lookup. A series of remote computers known as DNS servers then find the IP address for that domain and return it to the user’s computer so that they can access the correct website.

The DNS was originally designed without security and privacy considerations in mind. In the early days of the DNS, it was assumed that clients would only interact with name servers that they trusted. DNS messages were standardized to be primarily sent over an unencrypted transport without any mechanism to verify the validity of their contents that have left clients vulnerable to attacks on their security and privacy.

In short, the DNS as originally designed lacked three key design principles for secure technology: origin authenticity, integrity, and confidentiality.

The lack of these principles discovers attacks on user security and privacy in the DNS. One attack is cache poisoning, in which network adversaries inject false answers into various caches in the DNS hierarchy At a high level, this attack occurs when an on-path host between a recursive resolver and a name server intercepts queries to the name server, creates a false response with a query ID that matches the query, and sends it back to the recursive resolver. The recursive resolver then caches the false answers before sending them back to the client. This attack works because the DNS as originally designed has no built-in mechanism for verifying origin authenticity and integrity.

Another attack is eavesdropping, in which plaintext DNS queries and responses are observed by network adversaries. As implied by its name, a simple form of this attack occurs when a network observer sitting anywhere on the DNS hierarchy reads plaintext queries and responds” off the wire.”

Generally, DNS servers fall into four categories:

Recursive resolvers, root nameservers, TLD nameservers, and authoritative nameservers. 

DNS recursion (AKA recursive DNS):

A recursive DNS lookup is where one DNS server communicates with several other DNS servers to hunt down an IP address and return it to the client. This is in contrast to an iterative DNS query, where the client communicates directly with each DNS server involved in the lookup.

A recursive resolver (also known as a DNS recursor) is the first stop in a DNS query. The recursive resolver acts as a middleman between a client and a DNS nameserver. After receiving a DNS query from a web client, a recursive resolver will either respond with cached data, or send a request to a root nameserver, followed by another request to a TLD nameserver, and then one last request to an authoritative nameserver. After receiving a response from the authoritative nameserver containing the requested IP address, the recursive resolver then sends a response to the client.

During this process, the recursive resolver will cache information received from authoritative name servers. When a client requests the IP address of a domain name that was recently requested by another client, the resolver can circumvent the process of communicating with the nameservers, and just deliver the client the requested record from its cache.

Later, As improvement in DNS, changes happened in order to include a set of extensions to bring origin authenticity and integrity to the DNS. they are called DNS Security Extensions (DNSSEC).

 At a high level, each domain name is associated with a cryptographic key that signs the records associated with that domain. The “root” key is embedded in resolvers and used to sign top-level domains such as .com. Those domains have their own keys which can be used to sign subdomains, and so on. DNSSEC introduces some new records, most importantly DNSKEY which contains a public key, and RRSIG which contains the signature over a set of records. In order to verify a given record, a resolver must know the DNSKEY corresponding to that domain and the RRSIG corresponding to the relevant RRs; it can then verify the signature over the records.

DNSSEC has more to do with how your DNS resolver communicates with authoritative DNS servers when completing a request. DNSSEC offers a way for servers involved in the DNS hierarchy to validate that the answer to their queries came from the appropriate "source." This is completed using cryptography signed and authenticated keys for validation.

In fact, DNSSEC operates much like HTTPS does in a browser in the sense that an SSL certificate is a way for a website to "prove" that it is whom it says it is. With DNSSEC, the keys help validate that an authority is whom it says it is.

DNSSEC helps prevent a response from a rogue DNS server from hijacking and/or modifying a query to point to an unintended (and frequently malicious) connection. As described above, DNSSEC helps prevent DNS Poisoning and Spoofing by malicious actors.

The Privacy Problem

Deploying DNSSEC and encrypted DNS protocols will not solve all security and privacy issues with the DNS. As privacy is increasingly in the news, the familiar DNS recursion process has come under scrutiny. Queriers ask for the entire record, which reveals more information to the intermediate DNS servers in the recursion chain than necessary.

Look again at Fig. 1(DNS Flow) and notice that when the resolver sends the query to the root server it sends the entire query name, not just a query for the .com servers. It sends the same full query to every authoritative server in the recursion path. That means that every authoritative server in the recursion path (and any eavesdroppers on that part of the network) can see the full set of query names that the clients of each resolver send, unnecessarily leaking data.

Why ask the root server for the FQDN, when all you really need to know from it is the current list of TLD servers? Why ask a TLD server for the FQDN, when all you really need to know from it is the current list of authoritative servers for the domain you’re curious about?

Minimizing DNS Query Scope

To improve privacy in the DNS recursion process, experimental RFC7816 was published. In IETF parlance, “experimental” means that the RFC is not binding as an official standard. Rather, the document “is published for examination, experimental implementation, and evaluation.” Therefore, scope minimization might or might not be available in the DNS implementations you’re using.

What, exactly, is RFC7816 trying to accomplish?

“This document describes a technique to improve DNS privacy, a technique called ‘QNAME minimisation’, where the DNS resolver no longer sends the full original QNAME to the upstream name server.”

What’s a QNAME? A QNAME (AKA Query Name Minimisation) is what you’re trying to resolve. If you’re resolving a typical A record, then the QNAME has traditionally been the fully qualified domain name (FQDN) of the host.

A simple example is to consider a case where a resolver needs to resolve www.foo.bar.example for the first time Now, it is possible that there is a zone cut (an explicit delegation point) between foo and bar but not between bar and example, however, a resolver cannot know this in advance. After obtaining the name servers for .example it will query those servers for the NS records for the bar.example. However, it will get a NODATA response, indicating that there is no zone cut at that point, so it has to query the .example name servers again with one more label (foo.bar.example), and so on until it resolves the name if possible. Without QNAME minimization the required response would be returned immediately to the full query for www.foo.bar.example.

QNAME minimization can also increase problems querying authoritative servers that are not fully compliant with all the DNS specifications, especially regarding corner cases with empty non-terminals, like the example described above. At the same time, enabling QNAME minimization is becoming the default setting for most popular open-source recursive resolver implementations and is increasingly deployed.

Essentially, QNAME minimization trades an occasional small latency increase in these corner cases for privacy, protecting the users behind the recursive resolver where DoT/DoH protects the privacy between the client and resolver.

What are the potential technical side effects of QNAME minimization?

1. Some implementations of DNS authorities can be confused by minimized queries, and will either not respond, return an error code, or return garbage data. In that case, BIND’s implementation, with the “relaxed” qname-minimization setting which currently is the default, will “fall-back” to normal querying, and will re-send the query with the full QNAME. A 2015 research study on QNAME minimization  found that 12% of minimized queries failed, almost all due to a few large CDNs. These problems have largely been addressed, but there still are operators that fail to properly answer for minimized queries. The current “relaxed” setting might change in the future to “strict”, which will fail to resolve a name for which authoritative servers don’t answer properly for minimized queries.
2. Query loops are more common when using QNAME minimization.

Example query loop:

domain1. IN NS ns.domain1.
domain2. IN NS ns.domain2.        

We have added query-loop detection in BIND’s QNAME minimization logic so we won’t get hung up in this situation.

1. A single authoritative server may be serving both parent and child for a domain: isc.org and .org, for example. In this case, the records for .org should properly include a DS record for isc.org, and isc.org should include an NS record for .org. However, because traditionally the query contained the full path, servers that lacked the pointers from parent to the child were able to verify that the DNSSEC chain was valid. With QNAME minimization, if there is no explicit link between parent and child, DNSSEC validation should fail.
2. In the case of zones that contain labels that are multiple levels deep (reverse PTR lookups for IPv6 is the classic example), QNAME minimization can require more queries than previously necessary. There are limits on how deep BIND will go with qname-minimization, and BIND will “jump over” some labels when querying for IPv6 PTR records. This difference will diminish as the cache is primed with answers.

What are the potential technical side-benefits of QNAME minimization?

When a resolver gets a response of NXDOMAIN, meaning the domain does not exist, the resolver will stop querying. BIND 9 caches and reuses negative responses to avoid superfluous queries.

QNAME minimization makes each negative answer more useful. For example, when querying for “department.school.university.edu” with QNAME minimization, a negative response from .edu would apply only to the question university.edu and would be cached as a negative response for that higher-level query.

The demand for online privacy is increasing

The Pew Research Center has done extensive surveys on end-user attitudes toward online privacy. Unsurprisingly, they are finding consumer concern has increased substantially over the last few years.

“Pew Research Center studies have shown that people are anxious about all the personal information that is collected and shared and the security of their data. Overall, a 2014 survey found that 91% of Americans ‘agree’ or ‘strongly agree’ that people have lost control over how personal information is collected and used by all kinds of entities.”

Source: http://www.pewresearch.org/fact-tank/2018/03/27/americans-complicated-feelings-about-social-media-in-an-era-of-privacy-concerns/

Some of this concern about social media and data sharing has already carried over into concern about DNS privacy.

79% of respondents to a 2017 ISC survey on DNS privacy believed that products and services that improve end-user privacy will get marketing benefits from the improved privacy.

Multiple new DNS services that promise to protect end-user privacy have emerged in the past two years and are seeing tremendous adoption. Quad9 (which operates a DNS resolver service at 9.9.9.9) reports that they are seeing growth in their user base of 5 - 10%  EACH WEEK. Cloudflare, which operates 1.1.1.1 , has also implemented QNAME minimization on its service.

QNAME minimization is only one element in an overall privacy protection plan. It does not encrypt your communications, nor does it ensure the integrity of the data received. However, QNAME minimization is important to minimize passive data leakage, and it is one end-user privacy step that requires absolutely no effort or retraining of the end user. It is also easy for the service provider to deploy and does not add any cost or performance penalties. We hope that in 2019, QNAME minimization will spread on the Internet so that it will become the new default standard for a well-run DNS service.

References:

1] https://www.cloudflare.com/learning/dns/dns-server-types/#recursive-resolver

2] https://www.isc.org/blogs/qname-minimization-and-privacy/

3] https://www.sciencedirect.com/science/article/pii/S1574013722000132#fig6

4] https://www.netmeister.org/blog/doh-dot-dnssec.html