This post originally appeared on the Packet Pushers’ Ignition site on October 1, 2019.
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. (Usually. There are apps, notably browsers, that might do their own thing. But let’s go with traditional behavior for now.)
What if that DNS server doesn’t know what the IP address of the requested hostname is, either? That DNS server will ask a root server. The DNS root server will point the querying server to a top level domain (TLD) server, who will finally direct the querying DNS server to the authoritative name server for the domain.
This process is known as DNS recursion, and it works fine. In conjunction with record caching, the DNS system even works quite fast, which matters. Name resolution is a crucial part of practically all IP transactions. If DNS resolution is slow, users are likely to notice, sparking help desk tickets complaining that “the network is slow.”
The Privacy Problem
As privacy is increasingly in the news, the familiar DNS recursion process has come under scrutiny. Why? Queriers ask for the entire record, which reveals more information to the intermediate DNS servers in the recursion chain than necessary.
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?
The argument is to keep your query scope to a minimum at each step of the recursion process, and minimize the amount of information that any DNS server along the way might be able to glean about you.
If you don’t think that’s a big deal, read Packet Pushers’ IPv6 Buzz co-host Scott Hogg’s DNS Privacy in the Face of Pervasive Monitoring over on the Infoblox blog. Scott points out the following in the opening paragraph.
“Pervasive Monitoring (PM) of data networking traffic is not only performed by governments, but corporations wanting to inspect the behavior of employees or customers. The goal of network traffic monitoring can be benevolent. Organizations may want to detect malicious behavior to combat malware, identify insider threats, and prevent against criminal behavior. Unfortunately, the goal of monitoring can also be malevolent. Examples of this can include invading a user’s privacy or gathering data to be used in a subsequent attack. In fact, the IETF feels that ‘Pervasive Monitoring Is an Attack’ (RFC 7258).”
Minimizing DNS Query Scope
To improve privacy in the DNS recursion process, experimental RFC7816 was published in March 2016. 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 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 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.
QNAME minimization’s value proposition is simple in the RFC’s abstract quoted above. The resolver (the DNS server asking an upstream DNS server to help perform name resolution) won’t ask for the entire FQDN–just the parts that the upstream server in the recursion chain is authoritative for. In this way, privacy is preserved–non-authoritative DNS servers won’t know the exact hostname you’re looking for.
Doesn’t DNS Over HTTPS Solve This Problem Better?
DNS over HTTPS (DoH) specified in RFC8484 isn’t solving the problem tackled by query minimization. Rather, DoH is about encrypting (interceptors can’t see the query) and authenticating (I’m really talking to who I think I’m talking to) the query itself.
Yes, DoH can improve privacy in that snoopers observing traffic between the client and the recursive DNS server running DoH can’t see what’s being asked. However, that’s simply last-mile privacy that doesn’t impact whether or not the DNS servers in the chain can see the FQDN or not.
Therefore, while DoH certainly helps with privacy concerns, it’s solving a different problem. QNAME minimization prevents mid-tier DNS servers from harvesting information about endpoints.
Problems With QNAME Minimization
The Zone Cut Problem
The biggest challenge with QNAME minimization is knowing where the zone portion of an FQDN ends and the hostname portion begins.
For example, let’s say I’ve got a domain called packetpushers.net. An FQDN inside of that domain is ignition.packetpushers.net.
What if I had another hostname called dev.ignition.packetpushers.net? In this case, the zone cut happens at packetpushers.net. The dev.ignition is the hostname portion of the FQDN.
How does an RFC7816 compliant server know exactly where the zone cut happens? The short answer is that it doesn’t. The resolver has to deduce the location of the zone cut based on the answers it gets back from various DNS servers in the resolver chain.
Following a QNAME-minimized algorithm, a name server recursively resolving dev.ignition.packetpushers.net would…
- Ask a root server for the list of authoritative TLD servers for .net.
- Ask a TLD server for the list of authoritative servers for packetpushers.net.
- Ask an authoritative packetpushers.net name server for the list of authoritative name servers for ignition.packetpushers.net.
- Whoops. There isn’t one. We aren’t running a zone for ignition.packetpushers.net. The packetpushers.net name servers will respond with NODATA, that is, no name servers for ignition.packetpushers.net.
- Now, the resolver knows where the zone cut is–at packetpushers.net–and can proceed to ask the FQDN dev.ignition.packetpushers.net of an authoritative packetpushers.net name server.
Appendix A of RFC7816 describes a more elaborate QNAME algorithm that, among other things, handles this “I don’t know where the zone cut is” scenario.
The Broken Name Server Problem
RFC7816 highlights another possible challenge with QNAME minimization–badly behaving name servers that don’t honor requests for NS records. NS records are name server records–what’s requested to find out the authoritative name servers for a domain.
This is a critical part of QNAME minimization, since the recursion process works by finding out which server authoritatively holds the answer to the client’s hostname query via NS queries, and then asking only an authoritative name server for the answer.
RFC7816 describes a scenario where some name servers might not honor an NS request, instead only honoring A record requests. Middleboxes such as load balancers were cited as common offenders. The RFC points out that middlebox name servers behaving in this way are technically broken, but suggest this workaround.
“…try with QTYPE=A requests (A being chosen because it is the most common and hence a QTYPE that will always be accepted, while a QTYPE NS may ruffle the feathers of some middleboxes). Instead of querying name servers with a query ‘NS example.com’, we could use ‘A _.example.com’ and see if we get a referral.”
That’s sort of a lousy workaround, but likely to work.
There are other potential corner-case issues with QNAME minimization that all revolve around non-compliance issues–either the zone doesn’t have the records it should or the name server doesn’t respond as it should. Both scenarios result in situations where QNAME minimization gets stuck, or needs to leak the FQDN in order to complete the primary job of name resolution.
However, those potential issues reveal an important assumption built-in to RFC7816. From Section 4…
“QNAME minimisation is compatible with the current DNS system and therefore can easily be deployed; since it is a unilateral change to the resolver, it does not change the protocol.”
Right. So if there’s a name server in the recursion path that did screw with the protocol, QNAME minimization might not work as expected, resulting in a leak of the FQDN or a re-stating of the query just to get a response from the broken name servers that allows name resolution to proceed.
All of which begs the question…
Does QNAME Minimization Increase Transaction Latency?
For the most part, no, QNAME minimization does not increase transaction latency. There are a couple of big reasons for this.
- Caching still works. Your local name server will still cache the answers it gets in accordance with DNS record TTL, just like always.
- Minimizing the QNAME doesn’t change the number of steps involved in recursion, assuming compliant name servers and well-configured zones.
That said, the corner case problems described in RFC7816 could indeed result in an extra query or three to get the FQDN resolved, depending on the scenario. That could result in some sub-second increases for resolution of non-cached queries.
But on the whole, my seat-of-my-pant opinion is that QNAME minimization should have almost no negative impact on web transaction times.
Industry Support For RFC7816 QNAME Minimization
Is QNAME minimization widely available? I spent some time exercising my Internet search-fu, and came up with the following. (Note: This list was compiled in 2019 and may be out of date.)
Cisco Umbrella – YES
CloudFlare – YES
F5 – Nothing I can find.
Google – Nothing I can find.
Infoblox – Nothing I can find.
Microsoft – Nothing I can find.
Quad9 – Nothing I can find.
Open Source Software
- BIND – YES, as of stable branch 9.14, first released in developmental branch 9.13.2.
- TinyDNS – Nothing I can find.
- Unbound – YES, first appeared in 1.5.7, I believe.
In summary, QNAME minimization is somewhat available. It could be that some of the DNS services I mention support RFC7816, but aren’t talking about it. That said, support from BIND and Unbound makes it easy to implement if you run your own DNS server. That code has been around for a while now, and is presumably robust.
If you have more information on any of these entries, let me know, and I’ll update this post.
For More Information
The DNS Privacy Project (because there’s always a project or a consortium or…)