1 Internet Engineering Task Force (IETF)                     S. Bortzmeyer   
    2 Request for Comments: 9156                                         AFNIC   
    3 Obsoletes: 7816                                               R. Dolmans   
    4 Category: Standards Track                                     NLnet Labs   
    5 ISSN: 2070-1721                                               P. Hoffman   
    6                                                                    ICANN   
    7                                                            November 2021   
   10              DNS Query Name Minimisation to Improve Privacy                
   12 Abstract                                                                   
   14    This document describes a technique called "QNAME minimisation" to      
   15    improve DNS privacy, where the DNS resolver no longer always sends      
   16    the full original QNAME and original QTYPE to the upstream name         
   17    server.  This document obsoletes RFC 7816.                              
   19 Status of This Memo                                                        
   21    This is an Internet Standards Track document.                           
   23    This document is a product of the Internet Engineering Task Force       
   24    (IETF).  It represents the consensus of the IETF community.  It has     
   25    received public review and has been approved for publication by the     
   26    Internet Engineering Steering Group (IESG).  Further information on     
   27    Internet Standards is available in Section 2 of RFC 7841.               
   29    Information about the current status of this document, any errata,      
   30    and how to provide feedback on it may be obtained at                    
   31    https://www.rfc-editor.org/info/rfc9156.                                
   33 Copyright Notice                                                           
   35    Copyright (c) 2021 IETF Trust and the persons identified as the         
   36    document authors.  All rights reserved.                                 
   38    This document is subject to BCP 78 and the IETF Trust's Legal           
   39    Provisions Relating to IETF Documents                                   
   40    (https://trustee.ietf.org/license-info) in effect on the date of        
   41    publication of this document.  Please review these documents            
   42    carefully, as they describe your rights and restrictions with respect   
   43    to this document.  Code Components extracted from this document must    
   44    include Revised BSD License text as described in Section 4.e of the     
   45    Trust Legal Provisions and are provided without warranty as described   
   46    in the Revised BSD License.                                             
   48 Table of Contents                                                          
   50    1.  Introduction and Background                                         
   51      1.1.  Experience from RFC 7816                                        
   52      1.2.  Terminology                                                     
   53    2.  Description of QNAME Minimisation                                   
   54      2.1.  QTYPE Selection                                                 
   55      2.2.  QNAME Selection                                                 
   56      2.3.  Limitation of the Number of Queries                             
   57      2.4.  Implementation by Stub and Forwarding Resolvers                 
   58    3.  Algorithm to Perform QNAME Minimisation                             
   59    4.  QNAME Minimisation Examples                                         
   60    5.  Performance Considerations                                          
   61    6.  Security Considerations                                             
   62    7.  References                                                          
   63      7.1.  Normative References                                            
   64      7.2.  Informative References                                          
   65    Acknowledgments                                                         
   66    Authors' Addresses                                                      
   68 1.  Introduction and Background                                            
   70    The problem statement for this document is described in [RFC9076].      
   71    This specific solution is not intended to fully solve the DNS privacy   
   72    problem; instead, it should be viewed as one tool amongst many.         
   74    QNAME minimisation follows the principle explained in Section 6.1 of    
   75    [RFC6973]: the less data you send out, the fewer privacy problems you   
   76    have.                                                                   
   78    Before QNAME minimisation, when a resolver received the query "What     
   79    is the AAAA record for www.example.com?", it sent to the root           
   80    (assuming a resolver, whose cache is empty) the very same question.     
   81    Sending the full QNAME to the authoritative name server was a           
   82    tradition, not a protocol requirement.  In a conversation with one of   
   83    the authors in January 2015, Paul Mockapetris explained that this       
   84    tradition comes from a desire to optimise the number of requests,       
   85    when the same name server is authoritative for many zones in a given    
   86    name (something that was more common in the old days, where the same    
   87    name servers served .com and the root) or when the same name server     
   88    is both recursive and authoritative (something that is strongly         
   89    discouraged now).  Whatever the merits of this choice at this time,     
   90    the DNS is quite different now.                                         
   92    QNAME minimisation is compatible with the current DNS system and        
   93    therefore can easily be deployed.  Because it is only a change to the   
   94    way that the resolver operates, it does not change the DNS protocol     
   95    itself.  The behaviour suggested here (minimising the amount of data    
   96    sent in QNAMEs from the resolver) is allowed by Section 5.3.3 of        
   97    [RFC1034] and Section 7.2 of [RFC1035].                                 
   99 1.1.  Experience from RFC 7816                                             
  101    This document obsoletes [RFC7816].  [RFC7816] was categorised           
  102    "Experimental", but ideas from it were widely deployed since its        
  103    publication.  Many resolver implementations now support QNAME           
  104    minimisation.  The lessons learned from implementing QNAME              
  105    minimisation were used to create this new revision.                     
  107    Data from DNSThought [dnsthought-qnamemin], Verisign                    
  108    [verisign-qnamemin], and APNIC [apnic-qnamemin] shows that a large      
  109    percentage of the resolvers deployed on the Internet already support    
  110    QNAME minimisation in some way.                                         
  112    Academic research has been performed on QNAME minimisation              
  113    [devries-qnamemin].  This work shows that QNAME minimisation in         
  114    relaxed mode causes almost no problems.  The paper recommends using     
  115    the A QTYPE and limiting the number of queries in some way.  Some of    
  116    the issues that the paper found are covered in Section 5.               
  118 1.2.  Terminology                                                          
  120    The terminology used in this document is defined in [RFC8499].          
  122    In this document, a "cold" cache is one that is empty, having           
  123    literally no entries in it.  A "warm" cache is one that has some        
  124    entries in it.                                                          
  126    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  128    "OPTIONAL" in this document are to be interpreted as described in       
  129    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  130    capitals, as shown here.                                                
  132 2.  Description of QNAME Minimisation                                      
  134    The idea behind QNAME minimisation is to minimise the amount of         
  135    privacy-sensitive data sent from the DNS resolver to the                
  136    authoritative name server.  This section describes how to do QNAME      
  137    minimisation.  The algorithm is summarised in Section 3.                
  139    When a resolver is not able to answer a query from cache, it has to     
  140    send a query to an authoritative name server.  Traditionally, these     
  141    queries would contain the full QNAME and the original QTYPE as          
  142    received in the client query.                                           
  144    The full QNAME and original QTYPE are only needed at the name server    
  145    that is authoritative for the record requested by the client.  All      
  146    other name servers queried while resolving the query only need to       
  147    receive enough of the QNAME to be able to answer with a delegation.     
  148    The QTYPE in these queries is not relevant, as the name server is not   
  149    able to authoritatively answer the records the client is looking for.   
  150    Sending the full QNAME and original QTYPE to these name servers         
  151    therefore exposes more privacy-sensitive data than necessary to         
  152    resolve the client's request.                                           
  154    A resolver that implements QNAME minimisation obscures the QNAME and    
  155    QTYPE in queries directed to an authoritative name server that is not   
  156    known to be responsible for the original QNAME.  These queries          
  157    contain:                                                                
  159    *  a QTYPE selected by the resolver to possibly obscure the original    
  160       QTYPE                                                                
  162    *  the QNAME that is the original QNAME, stripped to just one label     
  163       more than the longest matching domain name for which the name        
  164       server is known to be authoritative                                  
  166 2.1.  QTYPE Selection                                                      
  168    Note that this document relaxes the recommendation in [RFC7816] to      
  169    use the NS QTYPE to hide the original QTYPE.  Using the NS QTYPE is     
  170    still allowed.  The authority of NS records lies at the child side.     
  171    The parent side of the delegation will answer using a referral, like    
  172    it will do for queries with other QTYPEs.  Using the NS QTYPE           
  173    therefore has no added value over other QTYPEs.                         
  175    The QTYPE to use while minimising queries can be any possible data      
  176    type (as defined in Section 3.1 of [RFC6895]) for which the authority   
  177    always lies below the zone cut (i.e., not DS, NSEC, NSEC3, OPT, TSIG,   
  178    TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no        
  179    relation between the incoming QTYPE and the selection of the QTYPE to   
  180    use while minimising.  The A or AAAA QTYPEs are always good             
  181    candidates to use because these are the least likely to raise issues    
  182    in DNS software and middleboxes that do not properly support all        
  183    QTYPEs.  QTYPE=A or QTYPE=AAAA queries will also blend into traffic     
  184    from nonminimising resolvers, making it in some cases harder to         
  185    observe that the resolver is using QNAME minimisation.  Using a QTYPE   
  186    that occurs most in incoming queries will slightly reduce the number    
  187    of queries, as there is no extra check needed for delegations on non-   
  188    apex records.                                                           
  190 2.2.  QNAME Selection                                                      
  192    The minimising resolver works perfectly when it knows the zone cut      
  193    (zone cuts are described in Section 6 of [RFC2181]).  But zone cuts     
  194    do not necessarily exist at every label boundary.  In the name          
  195    www.foo.bar.example, it is possible that there is a zone cut between    
  196    "foo" and "bar" but not between "bar" and "example".  So, assuming      
  197    that the resolver already knows the name servers of example, when it    
  198    receives the query "What is the AAAA record of www.foo.bar.example?",   
  199    it does not always know where the zone cut will be.  To find the zone   
  200    cut, it will query the example name servers for a record for            
  201    bar.example.  It will get a non-referral answer, so it has to query     
  202    the example name servers again with one more label, and so on.          
  203    (Section 3 describes this algorithm in deeper detail.)                  
  205 2.3.  Limitation of the Number of Queries                                  
  207    When using QNAME minimisation, the number of labels in the received     
  208    QNAME can influence the number of queries sent from the resolver.       
  209    This opens an attack vector and can decrease performance.  Resolvers    
  210    supporting QNAME minimisation MUST implement a mechanism to limit the   
  211    number of outgoing queries per user request.                            
  213    Take for example an incoming QNAME with many labels, like               
  214    www.host.group.department.example.com, where                            
  215    host.group.department.example.com is hosted on example.com's name       
  216    servers.  (Such deep domains are especially common under ip6.arpa.)     
  217    Assume a resolver that knows only the name servers of example.com.      
  218    Without QNAME minimisation, it would send these example.com name        
  219    servers a query for www.host.group.department.example.com and           
  220    immediately get a specific referral or an answer, without the need      
  221    for more queries to probe for the zone cut.  For such a name, a cold    
  222    resolver with QNAME minimisation will send more queries, one per        
  223    label.  Once the cache is warm, there will be less difference with a    
  224    traditional resolver.  Testing of this is described in                  
  225    [Huque-QNAME-Min].                                                      
  227    The behaviour of sending multiple queries can be exploited by sending   
  228    queries with a large number of labels in the QNAME that will be         
  229    answered using a wildcard record.  Take for example a record for        
  230    *.example.com, hosted on example.com's name servers.  An incoming       
  231    query containing a QNAME with more than 100 labels, ending in           
  232    example.com, will result in a query per label.  By using random         
  233    labels, the attacker can bypass the cache and always require the        
  234    resolver to send many queries upstream.  Note that [RFC8198] can        
  235    limit this attack in some cases.                                        
  237    One mechanism that MAY be used to reduce this attack vector is by       
  238    appending more than one label per iteration for QNAMEs with a large     
  239    number of labels.  To do this, a maximum number of QNAME minimisation   
  240    iterations MUST be selected (MAX_MINIMISE_COUNT); a RECOMMENDED value   
  241    is 10.  Optionally, a value for the number of queries that should       
  242    only have one label appended MAY be selected (MINIMISE_ONE_LAB); a      
  243    good value is 4.  The assumption here is that the number of labels on   
  244    delegations higher in the hierarchy are rather small; therefore, not    
  245    exposing too many labels early on has the most privacy benefit.         
  247    Another potential, optional mechanism for limiting the number of        
  248    queries is to assume that labels that begin with an underscore (_)      
  249    character do not represent privacy-relevant administrative              
  250    boundaries.  For example, if the QNAME is "_25._tcp.mail.example.org"   
  251    and the algorithm has already searched for "mail.example.org", the      
  252    next query can be for all the underscore-prefixed names together,       
  253    namely "_25._tcp.mail.example.org".                                     
  255    When a resolver needs to send out a query, it will look for the         
  256    closest-known delegation point in its cache.  The number of not-yet-    
  257    exposed labels is the difference between this closest name server and   
  258    the incoming QNAME.  The first MINIMISE_ONE_LAB labels will be          
  259    handled as described in Section 2.  The number of labels that are       
  260    still not exposed now need to be divided proportionally over the        
  261    remaining iterations (MAX_MINIMISE_COUNT - MINIMISE_ONE_LAB).  If the   
  262    not-yet-exposed labels cannot be equally divided over the remaining     
  263    iterations, the remainder of the division should be added to the last   
  264    iterations.  For example, when resolving a QNAME with 18 labels with    
  265    MAX_MINIMISE_COUNT set to 10 and MINIMISE_ONE_LAB set to 4, the         
  266    number of labels added per iteration are: 1,1,1,1,2,2,2,2,3,3.          
  268 2.4.  Implementation by Stub and Forwarding Resolvers                      
  270    Stub and forwarding resolvers MAY implement QNAME minimisation.         
  271    Minimising queries that will be sent to an upstream resolver does not   
  272    help in hiding data from the upstream resolver because all              
  273    information will end up there anyway.  It might however limit the       
  274    data exposure between the upstream resolver and the authoritative       
  275    name server in the situation where the upstream resolver does not       
  276    support QNAME minimisation.  Using QNAME minimisation in a stub or      
  277    forwarding resolver that does not have a mechanism to find and cache    
  278    zone cuts will drastically increase the number of outgoing queries.     
  280 3.  Algorithm to Perform QNAME Minimisation                                
  282    This algorithm performs name resolution with QNAME minimisation in      
  283    the presence of zone cuts that are not yet known.                       
  285    Although a validating resolver already has the logic to find the zone   
  286    cuts, implementers of resolvers may want to use this algorithm to       
  287    locate the zone cuts.                                                   
  289    (0)  If the query can be answered from the cache, do so; otherwise,     
  290         iterate as follows:                                                
  292    (1)  Get the closest delegation point that can be used for the          
  293         original QNAME from the cache.                                     
  295         (1a)  For queries with a QTYPE for which the authority only lies   
  296               at the parent side (like QTYPE=DS), this is the NS RRset     
  297               with the owner matching the most labels with QNAME           
  298               stripped by one label.  QNAME will be a subdomain of (but    
  299               not equal to) this NS RRset.  Call this ANCESTOR.            
  301         (1b)  For queries with other original QTYPEs, this is the NS       
  302               RRset with the owner matching the most labels with QNAME.    
  303               QNAME will be equal to or a subdomain of this NS RRset.      
  304               Call this ANCESTOR.                                          
  306    (2)  Initialise CHILD to the same as ANCESTOR.                          
  308    (3)  If CHILD is the same as QNAME, or if CHILD is one label shorter    
  309         than QNAME and the original QTYPE can only be at the parent side   
  310         (like QTYPE=DS), resolve the original query as normal, starting    
  311         from ANCESTOR's name servers.  Start over from step 0 if new       
  312         names need to be resolved as a result of this answer, for          
  313         example, when the answer contains a CNAME or DNAME [RFC6672]       
  314         record.                                                            
  316    (4)  Otherwise, update the value of CHILD by adding the next relevant   
  317         label or labels from QNAME to the start of CHILD.  The number of   
  318         labels to add is discussed in Section 2.3.                         
  320    (5)  Look for a cache entry for the RRset at CHILD with the original    
  321         QTYPE.  If the cached response code is NXDOMAIN and the resolver   
  322         has support for [RFC8020], the NXDOMAIN can be used in response    
  323         to the original query, and stop.  If the cached response code is   
  324         NOERROR (including NODATA), go back to step 3.  If the cached      
  325         response code is NXDOMAIN and the resolver does not support        
  326         [RFC8020], go back to step 3.                                      
  328    (6)  Query for CHILD with the selected QTYPE using one of ANCESTOR's    
  329         name servers.  The response can be:                                
  331         (6a)  A referral.  Cache the NS RRset from the authority           
  332               section, and go back to step 1.                              
  334         (6b)  A DNAME response.  Proceed as if a DNAME is received for     
  335               the original query.  Start over from step 0 to resolve the   
  336               new name based on the DNAME target.                          
  338         (6c)  All other NOERROR answers (including NODATA).  Cache this    
  339               answer.  Regardless of the answered RRset type, including    
  340               CNAMEs, continue with the algorithm from step 3 by           
  341               building the original QNAME.                                 
  343         (6d)  An NXDOMAIN response.  If the resolver supports [RFC8020],   
  344               return an NXDOMAIN response to the original query, and       
  345               stop.  If the resolver does not support [RFC8020], go to     
  346               step 3.                                                      
  348         (6e)  A timeout or response with another RCODE.  The               
  349               implementation may choose to retry step 6 with a different   
  350               ANCESTOR name server.                                        
  352 4.  QNAME Minimisation Examples                                            
  354    As a first example, assume that a resolver receives a request to        
  355    resolve foo.bar.baz.example.  Assume that the resolver already knows    
  356    that ns1.nic.example is authoritative for .example and that the         
  357    resolver does not know a more specific authoritative name server.  It   
  358    will send the query with QNAME=baz.example and the QTYPE selected to    
  359    hide the original QTYPE to ns1.nic.example.                             
  361    +=======+=================+=========================+======+            
  362    | QTYPE | QNAME           | TARGET                  | NOTE |            
  363    +=======+=================+=========================+======+            
  364    | MX    | a.b.example.org | root name server        |      |            
  365    +-------+-----------------+-------------------------+------+            
  366    | MX    | a.b.example.org | org name server         |      |            
  367    +-------+-----------------+-------------------------+------+            
  368    | MX    | a.b.example.org | example.org name server |      |            
  369    +-------+-----------------+-------------------------+------+            
  371       Table 1: Cold Cache, Traditional Resolution Algorithm                
  372        without QNAME Minimisation, Request for MX Record of                
  373                          a.b.example.org                                   
  375    The following are more detailed examples of requests for an MX record   
  376    of a.b.example.org with QNAME minimisation, using A QTYPE to hide the   
  377    original QTYPE and using other names and authoritative servers:         
  379    +=======+=================+=========================+============+      
  380    | QTYPE | QNAME           | TARGET                  | NOTE       |      
  381    +=======+=================+=========================+============+      
  382    | A     | org             | root name server        |            |      
  383    +-------+-----------------+-------------------------+------------+      
  384    | A     | example.org     | org name server         |            |      
  385    +-------+-----------------+-------------------------+------------+      
  386    | A     | b.example.org   | example.org name server |            |      
  387    +-------+-----------------+-------------------------+------------+      
  388    | A     | a.b.example.org | example.org name server | "a" may be |      
  389    |       |                 |                         | delegated  |      
  390    +-------+-----------------+-------------------------+------------+      
  391    | MX    | a.b.example.org | example.org name server |            |      
  392    +-------+-----------------+-------------------------+------------+      
  394               Table 2: Cold Cache with QNAME Minimisation                  
  396    Note that, in the above example, one query would have been saved if     
  397    the incoming QTYPE was the same as the QTYPE selected by the resolver   
  398    to hide the original QTYPE.  Only one query for a.b.example.org would   
  399    have been needed if the original QTYPE would have been A.  Using the    
  400    most-used QTYPE to hide the original QTYPE therefore slightly reduces   
  401    the number of outgoing queries compared to using any other QTYPE to     
  402    hide the original QTYPE.                                                
  404    +=======+=================+=========================+============+      
  405    | QTYPE | QNAME           | TARGET                  | NOTE       |      
  406    +=======+=================+=========================+============+      
  407    | A     | example.org     | org name server         |            |      
  408    +-------+-----------------+-------------------------+------------+      
  409    | A     | b.example.org   | example.org name server |            |      
  410    +-------+-----------------+-------------------------+------------+      
  411    | A     | a.b.example.org | example.org name server | "a" may be |      
  412    |       |                 |                         | delegated  |      
  413    +-------+-----------------+-------------------------+------------+      
  414    | MX    | a.b.example.org | example.org name server |            |      
  415    +-------+-----------------+-------------------------+------------+      
  417               Table 3: Warm Cache with QNAME Minimisation                  
  419 5.  Performance Considerations                                             
  421    The main goal of QNAME minimisation is to improve privacy by sending    
  422    less data.  However, it may have other advantages.  For instance, if    
  423    a resolver sends a root name server queries for A.example followed by   
  424    B.example followed by C.example, the result will be three NXDOMAINs,    
  425    since .example does not exist in the root zone.  When using QNAME       
  426    minimisation, the resolver would send only one question (for .example   
  427    itself) to which they could answer NXDOMAIN.  The resolver can cache    
  428    this answer and use it to prove that nothing below .example exists      
  429    [RFC8020].  A resolver now knows a priori that neither B.example nor    
  430    C.example exist.  Thus, in this common case, the total number of        
  431    upstream queries under QNAME minimisation could be counterintuitively   
  432    less than the number of queries under the traditional iteration (as     
  433    described in the DNS standard).                                         
  435    QNAME minimisation can increase the number of queries based on the      
  436    incoming QNAME.  This is described in Section 2.3.  As described in     
  437    [devries-qnamemin], QNAME minimisation both increases the number of     
  438    DNS lookups by up to 26% and leads to up to 5% more failed lookups.     
  439    Filling the cache in a production resolver will soften that overhead.   
  441 6.  Security Considerations                                                
  443    QNAME minimisation's benefits are clear in the case where you want to   
  444    decrease exposure of the queried name to the authoritative name         
  445    server.  But minimising the amount of data sent also, in part,          
  446    addresses the case of a wire sniffer as well as the case of privacy     
  447    invasion by the authoritative name servers.  Encryption is of course    
  448    a better defense against wire sniffers, but, unlike QNAME               
  449    minimisation, it changes the protocol and cannot be deployed            
  450    unilaterally.  Also, the effect of QNAME minimisation on wire           
  451    sniffers depends on whether the sniffer is on the DNS path.             
  453    QNAME minimisation offers no protection against the recursive           
  454    resolver, which still sees the full request coming from the stub        
  455    resolver.                                                               
  457    A resolver using QNAME minimisation can possibly be used to cause a     
  458    query storm to be sent to servers when resolving queries containing a   
  459    QNAME with a large number of labels, as described in Section 2.3.       
  460    That section proposes methods to significantly dampen the effects of    
  461    such attacks.                                                           
  463 7.  References                                                             
  465 7.1.  Normative References                                                 
  467    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
  468               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,       
  469               <https://www.rfc-editor.org/info/rfc1034>.                   
  471    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  472               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  473               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
  475    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  476               Requirement Levels", BCP 14, RFC 2119,                       
  477               DOI 10.17487/RFC2119, March 1997,                            
  478               <https://www.rfc-editor.org/info/rfc2119>.                   
  480    [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,         
  481               Morris, J., Hansen, M., and R. Smith, "Privacy               
  482               Considerations for Internet Protocols", RFC 6973,            
  483               DOI 10.17487/RFC6973, July 2013,                             
  484               <https://www.rfc-editor.org/info/rfc6973>.                   
  486    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  487               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  488               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  490    [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS             
  491               Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,       
  492               January 2019, <https://www.rfc-editor.org/info/rfc8499>.     
  494 7.2.  Informative References                                               
  496    [apnic-qnamemin]                                                        
  497               Huston, G. and J. Damas, "Measuring Query Name               
  498               Minimization", September 2020, <https://indico.dns-          
  499               oarc.net/event/34/contributions/787/                         
  500               attachments/777/1326/2020-09-28-oarc33-qname-                
  501               minimisation.pdf>.                                           
  503    [devries-qnamemin]                                                      
  504               de Vries, W., Scheitle, Q., Müller, M., Toorop, W.,          
  505               Dolmans, R., and R. van Rijswijk-Deij, "A First Look at      
  506               QNAME Minimization in the Domain Name System", March 2019,   
  507               <https://nlnetlabs.nl/downloads/publications/                
  508               devries2019.pdf>.                                            
  510    [dnsthought-qnamemin]                                                   
  511               "Qname Minimisation", October 2021,                          
  512               <https://dnsthought.nlnetlabs.nl/#qnamemin>.                 
  514    [Huque-QNAME-Min]                                                       
  515               Huque, S., "Query name minimization and authoritative        
  516               server behavior", May 2015,                                  
  517               <https://indico.dns-oarc.net/event/21/contribution/9>.       
  519    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
  520               Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,   
  521               <https://www.rfc-editor.org/info/rfc2181>.                   
  523    [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the        
  524               DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,             
  525               <https://www.rfc-editor.org/info/rfc6672>.                   
  527    [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA             
  528               Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,     
  529               April 2013, <https://www.rfc-editor.org/info/rfc6895>.       
  531    [RFC7816]  Bortzmeyer, S., "DNS Query Name Minimisation to Improve      
  532               Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,        
  533               <https://www.rfc-editor.org/info/rfc7816>.                   
  535    [RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is      
  536               Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,         
  537               November 2016, <https://www.rfc-editor.org/info/rfc8020>.    
  539    [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of    
  540               DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,     
  541               July 2017, <https://www.rfc-editor.org/info/rfc8198>.        
  543    [RFC9076]  Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,   
  544               DOI 10.17487/RFC9076, July 2021,                             
  545               <https://www.rfc-editor.org/info/rfc9076>.                   
  547    [verisign-qnamemin]                                                     
  548               Thomas, M., "Maximizing Qname Minimization: A New Chapter    
  549               in DNS Protocol Evolution", September 2020,                  
  550               <https://blog.verisign.com/security/maximizing-qname-        
  551               minimization-a-new-chapter-in-dns-protocol-evolution/>.      
  553 Acknowledgments                                                            
  555    The acknowledgments from RFC 7816 apply here.  In addition, many        
  556    participants from the DNSOP Working Group helped with proposals for     
  557    simplification, clarification, and general editorial help.              
  559 Authors' Addresses                                                         
  561    Stephane Bortzmeyer                                                     
  562    AFNIC                                                                   
  563    1, rue Stephenson                                                       
  564    78180 Montigny-le-Bretonneux                                            
  565    France                                                                  
  567    Phone: +33 1 39 30 83 46                                                
  568    Email: bortzmeyer+ietf@nic.fr                                           
  569    URI:   https://www.afnic.fr/                                            
  572    Ralph Dolmans                                                           
  573    NLnet Labs                                                              
  575    Email: ralph@nlnetlabs.nl                                               
  578    Paul Hoffman                                                            
  579    ICANN                                                                   
  581    Email: paul.hoffman@icann.org                                           

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

During an NDSSS DNS privacy workshop, I showed that the only true protection from privacy is to https://www.isi.edu/~hardaker/papers/2018-02-ndss-analyzing-root-privacy.pdf after comparing multiple DNS privacy preserving mechanisms, such as those described in RFC9156.