The core protocols of the internet weren’t set up with data privacy in mind. For the most part, privacy controls and protections have been bolted onto protocols like DNS over time.

This hodgepodge approach was taken primarily to minimize disruption to how the internet functions while addressing the changing needs of enterprises and users. At the same time, there have been some unintended consequences to addressing privacy in this way.

Since these privacy-enhancing technologies are voluntary add-ons, a basic lack of standardization has led to inconsistent application across the internet. That in-turn has led to some negative technical side effects.

QNAME minimization

In 2016 the IETF published RFC 7816, which introduced an optional addition to the DNS protocol called QNAME minimization. QNAME minimization was designed to enhance privacy by applying the “need to know” principle to DNS queries. Since its introduction, adoption of QNAME minimization has become widespread, most often due to default settings on recursive resolvers and open source (BIND and Unbound) DNS software releases.

Traditionally, DNS queries sent the entire query name QNAME (e.g., my.subzone.example.com) to authoritative nameservers, even though it wasn’t required by the protocol. The architecture of most networks in the early days of the internet made that desirable, but over time network setups have changed to the point that sending the full QNAME is now considered a privacy threat.

To keep data flows between DNS resolvers and authoritative name servers as small as possible, QNAME minimization essentially breaks up DNS queries into smaller chunks, asking each nameserver in the DNS lookup chain only about the piece for which they are likely to have knowledge.

Senders of queries get the information they need, and responders make connections without revealing too much of how their network operates. Everyone’s happy. Right?

The _ problem

Unfortunately, not all nameservers implement QNAME minimization correctly. The RFC gives the example of load balancers which reply properly to A queries but send REFUSED responses to NS queries. Rather than ditch QNAME minimization to satisfy these improperly configured nameservers, the RFC suggests a workaround.

The workaround is to try a QTYPE=A request. If you attach an underscore to an A record like A_.example.com it effectively limits the request to that part of the DNS chain. Since underscores are almost never used in domain names, it’s the equivalent of saying “look no further than this.”

For example, when given the task of finding the IP address of my.subzone.example.com, the resolver would query the root zone name server for “_.com”. The root zone resolver will return the authoritative nameserver for “.com”. It doesn’t need to know the rest of the domain name. The resolver next will ask the .com nameserver about “_.example.com”. That’s all the .com server needs to know to return the authoritative nameserver for example.com. This continues until the resolver finds the authoritative nameserver for subzone.example.com and is finally able to ask the full question -- what is the IP address for my.subzone.example.com.

Since the addition of this underscore is buried deep in a highly technical RFC document, we’ve found that many DNS administrators don’t know why it exists and what it means for their DNS configurations. They see an uptick in NXDOMAIN and/or REFUSED traffic, but can’t understand why it’s happening. They see A records with an underscore, but don’t know what that means. Most admins aren’t aware of the potential connection between these two phenomena.

What you can do about it

Is there anything you can do to reduce the volume of NXDOMAIN or REFUSED responses that appear as a result of QNAME minimization? Not really.

What you can do is eliminate QNAME minimization as the root cause of other DNS misconfigurations that might result in increased error traffic. Since QNAME minimization queries are scattered across traffic from servers that happen to implement QNAME minimization, they will probably appear as part of the standard background “noise” for most enterprises. That being said, if a subset of users happens to rely more heavily on a privacy-enhanced resolver, QNAME minimization-related errors could also appear as part of a sudden spike in NXDOMAIN or REFUSED queries.

Of course, you’ll only know that this is a problem if you’re paying attention to DNS traffic patterns in the first place. At NS1, we strongly suggest that all of our customers perform regular audits and analysis of their DNS data. This is the best way to pick up on unusual traffic patterns(like those related to QNAME minimization) that can impact DNS performance metrics.

NS1 users have access to some of the best DNS data analytics tools in the business. NS1’s DNS Insights feature provides deep observability into what’s happening on your network. With 100+ unique data points and built-in analysis, DNS Insights gives administrators the information they need to be proactive. For the QNAME minimization issue, DNS Insights will tell you which resolvers are responding with A record traffic that contains the infamous underscore, and help triangulate that intelligence against other relevant data points.

Need to dive into a QNAME minimization issue? See how DNS Insights can provide the observability you need.