RFC 7816

DNS Query Name Minimisation to Improve Privacy

📅 published March 2016, from ietf

RFC 7816: DNS Query Name Minimisation to Improve Privacy ✨

okay bestie, this one is from the IETF, which is the crew that writes the rulebook for how the Internet talks to itself 🌐💅 It's an Experimental doc (so not a Standards Track thing), written by S. Bortzmeyer from AFNIC, dated March 2016, with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a standalone experiment. 🧚

Abstract 💖

This doc describes a trick to make DNS more private, called "QNAME minimisation," where the DNS resolver stops sending the full original QNAME to the upstream name server. 🫶

Status of This Memo 📜

So this document is not an Internet Standards Track spec. It's being published so people can look at it, try it out in real code, and evaluate it. 🔍

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF), it reflects the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is up for any level of Internet Standard, so see Section 2 of RFC 5741 for that. 🌸

If you want the latest status, errata, or a way to send feedback, check http://www.rfc-editor.org/info/rfc7816. ✨

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect when it was published. Please actually read these, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License. 🧾

Table of Contents 🗂️

   1. Introduction and Background .....................................2
   2. QNAME Minimisation ..............................................3
   3. Possible Issues .................................................4
   4. Protocol and Compatibility Discussion ...........................5
   5. Operational Considerations ......................................5
   6. Performance Considerations ......................................6
   7. On the Experimentation ..........................................6
   8. Security Considerations .........................................7
   9. References ......................................................7
      9.1. Normative References .......................................7
      9.2. Informative References .....................................8
   Appendix A. An Algorithm to Perform QNAME Minimisation .............9
   Appendix B. Alternatives  .........................................10
   Acknowledgments ...................................................11
   Author's Address ..................................................11

1. Introduction and Background 🌸

The problem statement lives in [RFC7626]. That doc also defines the terminology (things like "QNAME" and "resolver") that this one uses. This specific fix is not meant to fully solve the DNS privacy problem. It's better to think of it as one tool in a big toolbox. 🧰

QNAME minimisation follows the principle explained in Section 6.1 of [RFC6973]: the less data you send out, the fewer privacy problems you have. 🔒

Here's the tea ☕ Right now, when a resolver gets the query "What is the AAAA record for www.example.com?", it sends the very same question to the root (assuming a cold resolver, whose cache is empty). Sending the full QNAME to the authoritative name server is a tradition, not a protocol requirement. In a conversation with the author in January 2015, Paul Mockapetris explained where the tradition came from. It was about wanting to optimise the number of requests, when the same name server was authoritative for many zones in a given name. That was more common back in the old days, when the same name servers served .com and the root. It also came up when the same name server was both recursive and authoritative, which is strongly discouraged now. Whatever the merits of that choice were at the time, the DNS is quite different now. 💅

2. QNAME Minimisation 🦋

The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. In the example from the previous section, sending "What are the NS records for .com?" would have been enough, since that's what the root would answer anyway. The rest of this section describes the recommended way to do QNAME minimisation, the way that gets the most privacy benefit. Other alternatives are discussed in the appendices. 🍓

Instead of sending the full QNAME and the original QTYPE upstream, a resolver that implements QNAME minimisation and doesn't already have the answer in its cache sends a request to the name server that's authoritative for the closest known ancestor of the original QNAME. The request is done with:

  • the QTYPE NS
  • the QNAME that is the original QNAME, stripped to just one label more than the zone for which the server is authoritative

For example, say a resolver gets a request to resolve foo.bar.baz.example. Let's assume it already knows that ns1.nic.example is authoritative for .example, and the resolver doesn't know a more specific authoritative name server. It'll send the query QTYPE=NS,QNAME=baz.example to ns1.nic.example. 👀

The minimising resolver works perfectly when it knows the zone cut (zone cuts are described in Section 6 of [RFC2181]). But zone cuts don't always exist at every label boundary. Take the name www.foo.bar.example. It's possible there's a zone cut between "foo" and "bar" but not between "bar" and "example". So, assuming the resolver already knows the name servers of .example, when it gets the query "What is the AAAA record of www.foo.bar.example?", it doesn't always know where the zone cut will be. To find it, the resolver queries the .example name servers for the NS records for bar.example. It gets a NODATA response, which means there's no zone cut at that point, so it has to ask the .example name servers again with one more label, and so on. (Appendix A describes this algorithm in much more detail.) 🔍

Since the info about zone cuts gets stored in the resolver's cache, the performance cost is probably reasonable. Section 6 digs further into this performance discrepancy. ⚡

Also, DNSSEC-validating resolvers already have access to this info, since they have to know the zone cut anyway (the DNSKEY record set sits just below it, and the DS record set sits just above). 🔐

3. Possible Issues 🙈

QNAME minimisation is legal, since the original DNS RFCs don't mandate sending the full QNAME. So in theory it should work without any problems. In practice though, some problems may pop up (see [Huque-QNAME-Min] for an analysis, and [Huque-QNAME-storify] for an interesting discussion on the topic). 😬

Some broken name servers don't react properly to QTYPE=NS requests. For instance, some authoritative name servers embedded in load balancers reply properly to A queries but send REFUSED to NS queries. This behaviour is a protocol violation, and there's no need to stop improving the DNS because of it. Still, QNAME minimisation may keep working with such domains, since they're only leaf domains (so there's no need to send them NS requests). A setup like that breaks more than just QNAME minimisation, though. It breaks negative answers, since the servers don't return the correct SOA, and it also breaks anything that depends on NS and SOA records existing at the top of the zone. 💀

Another way to deal with such incorrect name servers would be to try QTYPE=A requests. A is picked because it's the most common, so it's a QTYPE that will basically 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. 🪽

A problem can also show up when a name server doesn't react properly to ENTs (Empty Non-Terminals). If ent.example.com has no resource records but foobar.ent.example.com does, then ent.example.com is an ENT. Whatever the QTYPE, a query for ent.example.com must return NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly return NXDOMAIN for ENTs. If a resolver only queries foobar.ent.example.com, everything's fine. But if it implements QNAME minimisation, it may query ent.example.com and get an NXDOMAIN back. See also Section 3 of [DNS-Res-Improve] for the other bad consequences of this bad behaviour. 😤

A possible fix, currently implemented in Knot, is to retry with the full query when you get an NXDOMAIN. It works, but it's not ideal for privacy. 🤷‍♀️

Other practices that don't conform to the DNS protocol standards may cause problems too. There's a common DNS trick used by some web hosters who also do DNS hosting. It exploits the fact that the DNS protocol (pre-DNSSEC) allows certain serious misconfigurations, such as parent and child zones disagreeing on where a zone cut is. Basically, they have a single zone with wildcards for each TLD, like:

*.example.          60  IN  A   192.0.2.6

(They could just wildcard all of *., which would be enough. We don't know why they don't do it.) 🤔

This lets them host lots of web customers without configuring thousands of individual zones on their name servers. They just tell the prospective customer to point their NS records at the hoster's name servers, and the hoster doesn't have to provision anything to make the customer's domain resolve. NS queries to the hoster therefore won't give the right result, which may endanger QNAME minimisation (and it'll be a problem for DNSSEC too). 🚨

4. Protocol and Compatibility Discussion 🎀

QNAME minimisation is compatible with the current DNS system, so it can be deployed easily. Since it's a unilateral change to the resolver, it doesn't change the protocol. (Because it's unilateral, resolver implementers may do QNAME minimisation in slightly different ways. See the appendices for examples.) 🧩

One thing to note: the behaviour suggested here (minimising the amount of data sent in QNAMEs from the resolver) is NOT forbidden by Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035]. As stated in Section 1, the current method of sending the full QNAME isn't mandated by the DNS protocol either. 📖

Also, lots of DNS explainer docs aimed at a wide audience incorrectly describe the resolution process as already using QNAME minimisation. For example, they show a request going to the root with just the TLD in the query. Those docs can confuse readers who use them for privacy analysis. 🫠

5. Operational Considerations 🛠️

The admins of the forwarders and the authoritative name servers will get less data. That reduces the usefulness of the statistics they can produce, such as the percentage of the various QTYPEs [Kaliski-Minimum]. 📊

DNS admins are reminded that the data on DNS requests they store may have legal consequences, depending on your jurisdiction (check with your local lawyer). ⚖️💜

6. Performance Considerations ✨

okay so the main goal of QNAME minimisation is privacy, right? sending less data 🔒 but it's giving bonus perks too 💅 like, say a root name server gets a query from some resolver for A.example, then B.example, then C.example. 😭 that's three NXDOMAINs, because .example doesn't exist in the root zone. but with query name minimisation, the root servers only hear ONE question, for .example itself, and they can answer NXDOMAIN 🎀 which opens up a negative caching opportunity. the full resolver can now know a priori that neither B.example nor C.example could exist. 🧚 so in this very common case, the total number of upstream queries under QNAME minimisation is counterintuitively LESS than under traditional iteration (the way the DNS standard describes it). iykyk, the best outcomes are the unhinged ones 🙈

QNAME minimisation may also improve lookup performance for TLD operators 🍓 for a typical TLD that's delegation-only, with delegations sitting just under the TLD, a two-label QNAME query is optimal for finding the delegation owner name. ✨ literally the perfect length 💖

okay but the tea ☕ QNAME minimisation can DECREASE performance in some cases. 💀 for instance, a deep domain name like www.host.group.department.example.com, where host.group.department.example.com is hosted on example.com's name servers. 😭 let's assume a resolver that only knows the name servers of .example. without QNAME minimisation, it would send these .example name servers a query for www.host.group.department.example.com and immediately get a specific referral or an answer, no extra probing for the zone cut needed. 🫶 but for a name like this, a cold resolver with QNAME minimisation will, depending on how it's implemented, send more queries, one per label. 🌸 once the cache is warm, though, there's no difference with a traditional resolver. ✨ actual testing is described in [Huque-QNAME-Min]. and these deep domains are especially common under ip6.arpa. 🦋

7. On the Experimentation 🧪

this document has status "Experimental". 💅 since the beginning of time (or DNS), the fully qualified host name was always sent to the authoritative name servers. 👑 there was a concern that changing this behaviour may engage the Law of Unintended Consequences 💀 so that's why it's marked this way. 🙈

the idea behind the experiment is to observe QNAME minimisation in action with multiple resolvers, various authoritative name servers, etc. 🔥 basically, let's see how it actually plays out in the wild 🌈

8. Security Considerations 🔐

okay this section is serious, bestie 😤 QNAME minimisation's benefits are clear when you want to decrease exposure to the authoritative name server. 🎀 but minimising the amount of data sent also, in part, addresses the case of a wire sniffer, as well as privacy invasion by the servers. 👀 (encryption is of course a better defense against wire sniffers, but unlike QNAME minimisation, it changes the protocol and can't be deployed unilaterally. 🙅‍♀️ also, the effect of QNAME minimisation on wire sniffers depends on whether the sniffer is on the DNS path.)

QNAME minimisation offers ZERO protection against the recursive resolver, which still sees the full request coming from the stub resolver. 💀 not me being dramatic, this is just the facts 🫠

all the alternatives mentioned in Appendix B decrease privacy in the hope of improving performance. 😤 they must not be used if you want maximum privacy. 🚫 no cap, don't go there if privacy is the vibe 🔒

9. References 📚

9.1. Normative References 🌟

9.2. Informative References 📖

Appendix A. An Algorithm to Perform QNAME Minimisation 🧩

this algorithm performs name resolution with QNAME minimisation in the presence of zone cuts that aren't known yet. 🫶

although a validating resolver already has the logic to find the zone cuts, implementers of other resolvers may want to use this algorithm to locate the cuts. 💖 this is just a possible aid for implementers; it is not intended to be normative:

(0) If the query can be answered from the cache, do so; otherwise,
    iterate as follows:

(1) Find the closest enclosing NS RRset in your cache.  The owner of
    this NS RRset will be a suffix of the QNAME -- the longest suffix
    of any NS RRset in the cache.  Call this ANCESTOR.

(2) Initialise CHILD to the same as ANCESTOR.

(3) If CHILD is the same as the QNAME, resolve the original query
    using ANCESTOR's name servers, and finish.

(4) Otherwise, add a label from the QNAME to the start of CHILD.

(5) If you have a negative cache entry for the NS RRset at CHILD, go
    back to step 3.

(6) Query for CHILD IN NS using ANCESTOR's name servers.  The
    response can be:

    (6a) A referral.  Cache the NS RRset from the authority section,
         and go back to step 1.

    (6b) An authoritative answer.  Cache the NS RRset from the
         answer section, and go back to step 1.

    (6c) An NXDOMAIN answer.  Return an NXDOMAIN answer in response
         to the original query, and stop.

    (6d) A NOERROR/NODATA answer.  Cache this negative answer, and
         go back to step 3.

Appendix B. Alternatives 🎭

remember that QNAME minimisation is unilateral, so a resolver is not forced to implement it exactly as described here. 💅

there are several ways to perform QNAME minimisation. 🌈 see Section 2 for the suggested way. it can be called the aggressive algorithm, since the resolver only sends NS queries as long as it doesn't know the zone cuts. ✨ this is the safest, from a privacy point of view. 🔒 another possible algorithm, not fully studied at this time, could be to "piggyback" on the traditional resolution code. 🧁 at startup, it sends traditional full QNAMEs and learns the zone cuts from the referrals received, then switches to NS queries asking only for the minimum domain name. 😬 this leaks more data, but could require fewer changes in the existing resolver codebase. 🛠️

in the above specification, the original QTYPE is replaced by NS (or may be A, if too many servers react incorrectly to NS requests); this is the best approach to preserve privacy. 🫶 but this erases information about the relative use of the various QTYPEs, which may be interesting for researchers (for instance, if they try to follow IPv6 deployment by counting the percentage of AAAA vs. A queries). 📊 a variant of QNAME minimisation would be to keep the original QTYPE. 🦋

another useful optimisation may be, in the spirit of the HAMMER idea [HAMMER], to probe in advance for the introduction of zone cuts where none previously existed (i.e., confirm their continued absence, or discover them). 🔍

to address the "number of queries" issue described in Section 6, a possible solution is to always use the traditional algorithm when the cache is cold, and then move to QNAME minimisation (precisely defining what is "hot" or "cold" is left to the implementer). 🌡️ this will decrease the privacy but will guarantee no degradation of performance. 💜

Acknowledgments 🫶

thanks to Olaf Kolkman for the original idea during a KLM flight from Amsterdam to Vancouver, although the concept is probably much older (e.g., <https://lists.dns-oarc.net/pipermail/dns-operations/2010-February/005003.html>). ✈️ thanks to Shumon Huque and Marek Vavrusa for implementation and testing. 🙌 thanks to Mark Andrews and Francis Dupont for the interesting discussions. 💬 thanks to Brian Dickson, Warren Kumari, Evan Hunt, and David Conrad for remarks and suggestions. 🎀 thanks to Mohsen Souissi for proofreading. 📝 thanks to Tony Finch for the zone cut algorithm in Appendix A and for discussion of the algorithm. 🧠 thanks to Paul Vixie for pointing out that there are practical advantages (besides privacy) to QNAME minimisation. 💫 thanks to Phillip Hallam-Baker for the fallback on A queries, to deal with broken servers. 🛟 thanks to Robert Edmonds for an interesting anti-pattern. 🍭

Author's Address 📮

Stephane Bortzmeyer AFNIC 1, rue Stephenson Montigny-le-Bretonneux 78180 France

Phone: +33 1 39 30 83 46 Email: bortzmeyer+ietf@nic.fr URI: http://www.afnic.fr/

📦 where this page comes from