Data privacy and security experts tell us that applying the “need to know” principle enhances privacy and security, because it reduces the amount of information potentially disclosed to a service provider — or to other parties — to the minimum the service provider requires to perform a service. This principle is at the heart of qname minimization, a technique described in RFC 7816 that has now achieved significant adoption in the DNS.
Qname minimization alters the process of DNS resolution by limiting the content of DNS queries to the minimum that a name server needs to do its “first job” of referring requesters to the next name server during an iterative resolution process.
For instance, if the resolver is looking for the Internet Protocol (IP) address of the web server “www.example.TLD” — a three-label domain name — the resolver would send a request for a referral to the authoritative name server for “.TLD” — just one label — to the root server. The name server would return the referral: “ask TLD”.
The resolver would then send a request for information about the name server for “example.TLD” — just two labels — to the TLD name server. The TLD name server would again return the appropriate referral: “ask SLD”.
Finally, the resolver would send the full domain name — all three labels, in this case — to the SLD name server. The SLD name server, as in ‘ordinary’ DNS resolution, would return the DNS record of interest.
This minimized approach, illustrated in the figure below, is a simple but innovative step in the evolution of DNS protocol implementation. It’s a fundamental way to reduce the sensitivity of DNS data exchanged between resolvers and root and TLD servers (as well as any other name servers prior to the final one in the chain).
Resolver-to-authoritative DNS traffic represents the aggregate DNS lookup requirements of all clients of the resolver and is therefore less sensitive in its particulars than client-to-resolver DNS traffic. This inherent property of DNS recursive resolution, when coupled with qname minimization, enhances privacy and security as responses to minimized queries meld into the resolver’s cache. Ultimately it reduces the number of DNS queries sent “across the wire” while also removing visibility of the full domain name at various levels of the DNS hierarchy.
The risk / benefit tradeoff for qname minimization is therefore very attractive: a simple change to the resolver side yields a significant reduction in DNS data disclosed to the authoritative, which in turn yields enhanced privacy and security benefits at the root and TLD levels that some techniques, including DNS encryption, do not.
Qname-minimized DNS traffic from resolvers is inherently less sensitive, particularly at the root and TLD levels. Proposals to add DNS encryption at these levels of the ecosystem, meanwhile, would require a complex change and add operational risk to both resolvers and authoritative name servers. While encryption would yield a relatively modest benefit against outside observers, without qname minimization the full domain name would still be sent to each name server in the chain — more than the minimum required, and more than the “need to know.”
(Note that while there are clear privacy and security benefits from qname minimization, the DNS community will have to also consider the operational tradeoffs that arise as result of the wide-scale adoption of the technique, as the reduction in traffic content may impair root and TLD servers’ ability to do their traditional “second job” of providing visibility into name collisions and other security threats to the DNS.)
The Internet Engineering Task Force began specifying qname minimization in 2014 and published RFC 7816 as an Experimental RFC in 2016. To further support these efforts, in 2015, Verisign announced a royalty-free license to its qname minimization intellectual property rights. The progress since that time has been encouraging, particularly with implementation support and operational deployment.
Open source resolvers such as BIND, Knot and Unbound have all implemented, tested, and enabled by default qname minimization functionality.
A 2019 paper at the Passive and Active Measurement (PAM) conference reported on an initial study of qname minimization deployment. The researchers’ measurements via RIPE Atlas showed the adoption of qname minimization by resolvers quickly growing from 0.7% in May 2017 to 16.8% in April 2018. Their investigation of DNS traffic at the K Root and .NL name servers also confirmed that qname minimization has had an observable impact on traffic seen at authoritative name servers. For instance, the fraction of queries to the .NL name servers for names with no more than two labels increased from 33% to 44% over the same time span.
More recent measurements reported at an IETF meeting in April 2020 via the RIPE Atlas platform show that 47% of probes were utilizing qname-minimizing resolvers. As of August 2020, the fraction had increased to 55%, according to latest statistics in the same data collection hosted by NLnet Labs.
How has qname minimization impacted DNS traffic at Verisign’s authoritative name servers? The figures below show the overall trend of label size distributions observed at Verisign’s A and J Root servers as well as the .COM and .NET name servers.
These observations demonstrate a shift in the statistical distribution of the number of labels that is consistent with the increased deployment of qname minimization for queries sent to the root and TLD levels of the DNS hierarchy.
In January 2018, 32% of queries received at the A and J Root servers contained only one label, while 30% of queries received at the .COM and .NET name servers consisted of only two labels.
As of August 2020, those measures have increased to an impressive 53% and 49%, respectively – in just a few short years nearly half of all queries received at .COM and .NET are utilizing this easy and effective security and privacy enhancement!*
We look forward to several next steps including further adoption, additional research results on the impact of qname minimization, and the evolution of RFC 7816 from an experimental track document to a standard (rfc7816bis) that reflects this new chapter in DNS protocol deployment.
*October 2020: This sentence has been updated to clarify the relative amount of qname minimization received at .COM and .NET.
