rfc9156xml2.original.xml   rfc9156.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!ENTITY rfc1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY zwsp "&#8203;">
nce.RFC.1034.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY rfc1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY wj "&#8288;">
nce.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY rfc2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2181.xml">
<!ENTITY rfc4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4033.xml">
<!ENTITY rfc5246 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5246.xml">
<!ENTITY rfc5936 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5936.xml">
<!ENTITY rfc6347 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6347.xml">
<!ENTITY rfc6672 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6672.xml">
<!ENTITY rfc6895 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6895.xml">
<!ENTITY rfc6973 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6973.xml">
<!ENTITY rfc7816 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7816.xml">
<!ENTITY rfc8020 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8020.xml">
<!ENTITY rfc8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY rfc8198 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8198.xml">
<!ENTITY rfc8499 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8499.xml">
<!ENTITY rfc9076 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.9076.xml">
]> ]>
<rfc docName="draft-ietf-dnsop-rfc7816bis-11" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dnsop-rfc781
category="std" ipr="trust200902" obsoletes="7816" consensus="yes"> 6bis-11" number="9156" ipr="trust200902" obsoletes="7816" updates="" submissionT
ype="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortR
<?rfc toc="yes"?> efs="true" symRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="QNAME Minimisation">DNS Query Name Minimisation to Improve Privac
y</title>
<author fullname="Stephane Bortzmeyer" initials="S." surname="Bortzmeyer">
<organization>AFNIC</organization>
<address>
<postal>
<street>1, rue Stephenson</street>
<code>78180</code>
<city>Montigny-le-Bretonneux</city>
<country>France</country>
</postal>
<phone>+33 1 39 30 83 46</phone>
<email>bortzmeyer+ietf@nic.fr</email>
<uri>https://www.afnic.fr/</uri>
</address>
</author>
<author fullname="Ralph Dolmans" initials="R." surname="Dolmans">
<organization>NLnet Labs</organization>
<address>
<email>ralph@nlnetlabs.nl</email>
</address>
</author>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>ICANN</organization>
<address>
<email>paul.hoffman@icann.org</email>
</address>
</author>
<date />
<abstract> <!-- xml2rfc v2v3 conversion 3.9.1 -->
<front>
<title abbrev="QNAME Minimisation">DNS Query Name Minimisation to Improve Pr
ivacy</title>
<seriesInfo name="RFC" value="9156"/>
<author fullname="Stephane Bortzmeyer" initials="S." surname="Bortzmeyer">
<organization>AFNIC</organization>
<address>
<postal>
<street>1, rue Stephenson</street>
<code>78180</code>
<city>Montigny-le-Bretonneux</city>
<country>France</country>
</postal>
<phone>+33 1 39 30 83 46</phone>
<email>bortzmeyer+ietf@nic.fr</email>
<uri>https://www.afnic.fr/</uri>
</address>
</author>
<author fullname="Ralph Dolmans" initials="R." surname="Dolmans">
<organization>NLnet Labs</organization>
<address>
<email>ralph@nlnetlabs.nl</email>
</address>
</author>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>ICANN</organization>
<address>
<email>paul.hoffman@icann.org</email>
</address>
</author>
<date year="2021" month="November"/>
<keyword>QNAME</keyword>
<t>This document describes a technique called "QNAME minimisation" to improve <abstract>
<t>This document describes a technique called "QNAME minimisation" to impr
ove
DNS privacy, where the DNS resolver no longer always sends the full DNS privacy, where the DNS resolver no longer always sends the full
original QNAME and original QTYPE to the upstream name server. This document original QNAME and original QTYPE to the upstream name server. This document
obsoletes RFC 7816.</t> obsoletes RFC 7816.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="intro" numbered="true" toc="default">
<middle> <name>Introduction and Background</name>
<t>The problem statement for this document is described in <xref target="R
<section anchor="intro" title="Introduction and Background"> FC9076" format="default"/>.
<t>The problem statement for this document is described in <xref target="RFC9076
"/>.
This specific solution is not This specific solution is not
intended to fully solve the DNS privacy problem; instead, it intended to fully solve the DNS privacy problem; instead, it
should be viewed as one tool amongst many.</t> should be viewed as one tool amongst many.</t>
<t>QNAME minimisation follows the principle explained in
<t>QNAME minimisation follows the principle explained in <xref target="RFC6973" sectionFormat="of" section="6.1"/>: the less data y
Section 6.1 of <xref target="RFC6973"/>: the less data you send out, ou send out,
the fewer privacy problems you have.</t> the fewer privacy problems you have.</t>
<t>Before QNAME minimisation, when a resolver received the query "What is
<t>Before QNAME minimisation, when a resolver received the query "What is
the AAAA record for www.example.com?", it sent to the root (assuming the AAAA record for www.example.com?", it sent to the root (assuming
a resolver whose cache is empty) the very same question. Sending a resolver, whose cache is empty) the very same question. Sending
the full QNAME to the authoritative name server was a tradition, the full QNAME to the authoritative name server was a tradition,
not a protocol requirement. In a conversation with one of the authors in not a protocol requirement. In a conversation with one of the authors in
January 2015, Paul Mockapetris explained that this tradition comes January 2015, Paul Mockapetris explained that this tradition comes
from a desire to optimise the number of requests, when the same from a desire to optimise the number of requests, when the same
name server is authoritative for many zones in a given name name server is authoritative for many zones in a given name
(something that was more common in the old days, where the same (something that was more common in the old days, where the same
name servers served .com and the root) or when the same name servers served .com and the root) or when the same
name server is both recursive and authoritative (something that is name server is both recursive and authoritative (something that is
strongly discouraged now). Whatever the merits of this choice at this strongly discouraged now). Whatever the merits of this choice at this
time, the DNS is quite different now.</t> time, the DNS is quite different now.</t>
<t>QNAME minimisation is compatible with the current DNS system and
<t>QNAME minimisation is compatible with the current DNS system and therefore can easily be deployed. Because it is only a change to
therefore can easily be deployed. Because it is only a change to the way that the resolver operates, it does not change the DNS protocol it
the way that the resolver operates, it does not change the DNS protocol itself. self.
The behaviour suggested here (minimising the The behaviour suggested here (minimising the
amount of data sent in QNAMEs from the resolver) is allowed by amount of data sent in QNAMEs from the resolver) is allowed by
Section 5.3.3 of <xref target="RFC1034"/> and <xref target="RFC1034" sectionFormat="of" section="5.3.3"/> and
Section 7.2 of <xref target="RFC1035"/>.</t> <xref target="RFC1035" sectionFormat="of" section="7.2"/>.</t>
<section numbered="true" toc="default">
<section title="Experience From RFC 7816"> <name>Experience from RFC 7816</name>
<t>This document obsoletes <xref target="RFC7816" format="default"/>.
<t>This document obsoletes <xref target="RFC7816" />. <xref target="RFC7816" format="default"/> was categorised "Experimental",
RFC 7816 was labelled "experimental", but ideas from it were widely but ideas
deployed since its publication. from it were widely deployed since its publication.
Many resolver implementations now support QNAME minimisation. The lessons Many resolver implementations now support QNAME minimisation. The lessons
learned from implementing QNAME minimisation were used to create this new learned from implementing QNAME minimisation were used to create this new
revision.</t> revision.</t>
<t>Data from DNSThought <xref target="dnsthought-qnamemin" format="defau
<t>Data from DNSThought <xref target="dnsthought-qnamemin" />, lt"/>,
Verisign <xref target="verisign-qnamemin" /> and APNIC <xref target="apnic-qname Verisign <xref target="verisign-qnamemin" format="default"/>, and APNIC <
min"/> xref
shows that a large percentage of the resolvers deployed on the Internet already target="apnic-qnamemin" format="default"/>
support shows that a large percentage of the resolvers deployed on the Internet a
QNAME minimisation in some way.</t> lready support
QNAME minimisation in some way.</t>
<t>Academic research has been performed on QNAME minimisation <t>Academic research has been performed on QNAME minimisation
<xref target="devries-qnamemin"/>. This <xref target="devries-qnamemin" format="default"/>. This
work shows that QNAME minimisation in relaxed mode causes almost no problems. work shows that QNAME minimisation in relaxed mode causes almost no probl
The paper recommends using the A QTYPE, and limiting the number of queries in ems.
some way. The paper recommends using the A QTYPE and limiting the number of queries
Some of the issues that the paper found are covered in <xref target="perf_cons"/ in
>.</t> some way. Some of the issues that the paper found are covered in <xref
target="perf_cons" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>The terminology used in this document is defined in <xref target="RF
<t>The terminology used in this document is defined in <xref target="RFC8499"/> C8499"
.</t> format="default"/>.</t>
<t>In this document, a "cold" cache is one that is empty, having literal
<t>In this document, a "cold" cache is one that is empty, having literally no en ly no
tries entries in it. A "warm" cache is one that has some entries in it.</t>
in it. A "warm" cache is one that has some entries in it.</t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
and “OPTIONAL” in this document are to be interpreted as described in RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
ey be interpreted as
appear in all capitals, as shown here.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</section> </t>
</section>
</section> </section>
<section anchor="qname-main" numbered="true" toc="default">
<section anchor="qname-main" title="Description of QNAME Minimisation"> <name>Description of QNAME Minimisation</name>
<t>The idea behind QNAME minimisation is to minimise the amount of
<t>The idea behind QNAME minimisation is to minimise the amount of
privacy-sensitive data sent from the DNS resolver to the authoritative privacy-sensitive data sent from the DNS resolver to the authoritative
name server. This section describes how to do QNAME minimisation. The algorithm name server. This section describes how to do QNAME minimisation. The algorithm
is summarised in <xref target="zonecutalgo"/>.</t> is summarised in <xref target="zonecutalgo" format="default"/>.</t>
<t>When a resolver is not able to answer a query from cache, it has
<t>When a resolver is not able to answer a query from cache it has to send a query to an authoritative name server. Traditionally, these
to send a query to an authoritative nameserver. Traditionally these
queries would contain the full QNAME and the original QTYPE as received queries would contain the full QNAME and the original QTYPE as received
in the client query.</t> in the client query.</t>
<t>The full QNAME and original QTYPE are only needed at the name server th
<t>The full QNAME and original QTYPE are only needed at the nameserver that at
is authoritative for the record requested by the client. All other nameservers is authoritative for the record requested by the client. All other name servers
queried while resolving the query only need to receive enough of the QNAME to queried while resolving the query only need to receive enough of the QNAME to
be able to answer with a delegation. The QTYPE in these queries is not be able to answer with a delegation. The QTYPE in these queries is not
relevant, as the nameserver is not able to authoritatively answer the records relevant, as the name server is not able to authoritatively answer the records
the client is looking for. Sending the full QNAME and original QTYPE to the client is looking for. Sending the full QNAME and original QTYPE to
these nameservers therefore exposes more privacy-sensitive data than these name servers therefore exposes more privacy-sensitive data than
necessary to resolve the client's request.</t> necessary to resolve the client's request.</t>
<t>A resolver that implements QNAME minimisation obscures the QNAME and QT
<t>A resolver that implements QNAME minimisation obscures the QNAME and QTYPE in YPE in
queries directed to an authoritative nameserver that is not known to be queries directed to an authoritative name server that is not known to be
responsible for the original QNAME. These queries contain: responsible for the original QNAME. These queries contain:</t>
<ul spacing="normal">
<list style="symbols"> <li>a QTYPE selected by the resolver to possibly obscure the original QT
YPE</li>
<t>a QTYPE selected by the resolver to possibly obscure the original QTYPE</t> <li>the QNAME that is the original QNAME, stripped to just one
label more than the longest matching domain name for which the
<t>the QNAME that is the original QNAME, stripped to just one name server is known to be authoritative</li>
label more than the longest matching domain name for which the </ul>
nameserver is known to be authoritative</t> <section numbered="true" toc="default">
<name>QTYPE Selection</name>
</list></t> <t>Note that this document relaxes the recommendation in <xref target="R
FC7816"
<section title="QTYPE Selection"> format="default"/> to use the NS
<t>Note that this document relaxes the recommendation in RFC 7816 to use the NS QTYPE to hide the original QTYPE. Using the NS QTYPE is
QTYPE to still allowed. The authority of NS records lies at the child side. The pa
hide the original QTYPE. Using the NS QTYPE is rent
still allowed. The authority of NS records lies at the child side. The parent side of the delegation will answer using a referral, like it will do for
side of the delegation will answer using a referral, like it will do for queries queries
with other QTYPEs. Using the NS QTYPE therefore has no added value over other with other QTYPEs. Using the NS QTYPE therefore has no added value over o
QTYPEs.</t> ther
QTYPEs.</t>
<t>The QTYPE to use while minimising queries can be any possible data type <t>The QTYPE to use while minimising queries can be any possible data ty
(as defined in <xref target="RFC6895"/> Section 3.1) for which the authority alw pe
ays lies below the zone cut (as defined in <xref target="RFC6895" section="3.1" sectionFormat="of"
(i.e. not DS, NSEC, NSEC3, OPT, TSIG, TKEY, ANY, MAILA, MAILB, format="default"/>) for which the authority always lies below the zone cu
AXFR, and IXFR), as long as there is no relation between the incoming QTYPE and t
the selection of the QTYPE to use while minimising. (i.e., not DS, NSEC, NSEC3, OPT, TSIG, TKEY, ANY, MAILA, MAILB,
Good candidates are to always use the "A" or "AAAA" AXFR, and IXFR), as long as there is no relation between the incoming QTY
QTYPE because these are the least likely to raise issues in DNS PE and
software and middleboxes that do not properly support all QTYPEs. the selection of the QTYPE to use while minimising.
QTYPE=A or QTYPE=AAAA queries will also blend into traffic from non-minimising The A or AAAA QTYPEs are always good candidates to use because these
resolvers, making it in some cases harder to observe that the are the least likely to raise issues in DNS software and middleboxes
resolver is using QNAME minimisation. Using a QTYPE that occurs that do not properly support all QTYPEs.
most in incoming queries will slightly reduce the number of queries, QTYPE=A or QTYPE=AAAA queries will also blend into traffic from nonminimi
as there is no extra check needed for delegations on non-apex sing
records. resolvers, making it in some cases harder to observe that the
</t> resolver is using QNAME minimisation. Using a QTYPE that occurs
</section> most in incoming queries will slightly reduce the number of queries,
as there is no extra check needed for delegations on non-apex
<section title="QNAME Selection"> records.</t>
<t>The minimising resolver works perfectly when it knows the zone cut </section>
(zone cuts are described in Section 6 of <section numbered="true" toc="default">
<xref target="RFC2181"/>). But zone cuts do not <name>QNAME Selection</name>
necessarily exist at every label boundary. In the name <t>The minimising resolver works perfectly when it knows the zone cut
www.foo.bar.example, it is possible that there is a zone cut between (zone cuts are described in
"foo" and "bar" but not between "bar" and "example". So, assuming <xref target="RFC2181" sectionFormat="of" section="6"/>). But zone cuts
that the resolver already knows the name servers of example, when it do not
receives the query "What is the AAAA record of www.foo.bar.example?", necessarily exist at every label boundary. In the name
it does not always know where the zone cut will be. To find the www.foo.bar.example, it is possible that there is a zone cut between
zone cut, it will query the example name servers for a record for "foo" and "bar" but not between "bar" and "example". So, assuming
bar.example. It will get a non-referral answer, it has to query the that the resolver already knows the name servers of example, when it
example name servers again with one more label, and so on. receives the query "What is the AAAA record of www.foo.bar.example?",
(<xref target="zonecutalgo"/> describes this algorithm in deeper it does not always know where the zone cut will be. To find the
detail.)</t> zone cut, it will query the example name servers for a record for
</section> bar.example. It will get a non-referral answer, so it has to query the
example name servers again with one more label, and so on.
<section anchor="number-of-queries" title="Limit Number of Queries"> (<xref target="zonecutalgo" format="default"/> describes this algorithm i
n deeper
<t>When using QNAME minimisation, the number of labels in the received QNAME can detail.)</t>
</section>
<section anchor="number-of-queries" numbered="true" toc="default">
<name>Limitation of the Number of Queries</name>
<t>When using QNAME minimisation, the number of labels in the received Q
NAME can
influence the number of queries sent from the resolver. This opens an attack influence the number of queries sent from the resolver. This opens an attack
vector and can decrease performance. Resolvers supporting QNAME minimisation vector and can decrease performance. Resolvers supporting QNAME minimisation
MUST implement a mechanism to limit the number of outgoing queries per user <bcp14>MUST</bcp14> implement a mechanism to limit the number of outgoing querie s per user
request.</t> request.</t>
<t>Take for example an incoming QNAME with many labels, like
<t>Take for example an incoming QNAME with many labels, like
www.host.group.department.example.com, where www.host.group.department.example.com, where
host.group.department.example.com is hosted on example.com's host.group.department.example.com is hosted on example.com's
name servers. name servers.
(Such deep domains are especially common under ip6.arpa.) (Such deep domains are especially common under ip6.arpa.)
Assume a resolver that knows only the Assume a resolver that knows only the
name servers of example.com. Without QNAME minimisation, it would name servers of example.com. Without QNAME minimisation, it would
send these example.com name servers a query for send these example.com name servers a query for
www.host.group.department.example.com and immediately get a www.host.group.department.example.com and immediately get a
specific referral or an answer, without the need for more queries specific referral or an answer, without the need for more queries
to probe for the zone cut. For such a name, a cold resolver with to probe for the zone cut. For such a name, a cold resolver with
QNAME minimisation will send more queries, one per label. Once the cache is QNAME minimisation will send more queries, one per label. Once the cache is
warm, there will be less difference with a traditional resolver. warm, there will be less difference with a traditional resolver.
Testing of this is described in <xref target="Huque-QNAME-Min"/>. Testing of this is described in <xref target="Huque-QNAME-Min" format="default"/ >.
</t> </t>
<t>The behaviour of sending multiple queries can be exploited by sending
<t>The behaviour of sending multiple queries can be exploited by sending queries queries with a large number of
with a large number of
labels in the QNAME that will be answered using a wildcard record. Take for labels in the QNAME that will be answered using a wildcard record. Take for
example a record for *.example.com, hosted on example.com's name servers. An example a record for *.example.com, hosted on example.com's name servers. An
incoming query containing a QNAME with more than 100 labels, ending in incoming query containing a QNAME with more than 100 labels, ending in
example.com, will result in a query per label. By using random labels, the example.com, will result in a query per label. By using random labels, the
attacker can bypass the cache and always require the resolver to send many attacker can bypass the cache and always require the resolver to send many
queries upstream. Note that <xref target="RFC8198"/> can limit this attack in queries upstream. Note that <xref target="RFC8198" format="default"/> can limit this attack in
some cases.</t> some cases.</t>
<t>One mechanism that <bcp14>MAY</bcp14> be used to reduce this attack v
<t>One mechanism that MAY be used to reduce this attack vector is by appending ector is by
more than one appending more than one label per iteration for QNAMEs with a large numb
label per iteration for QNAMEs with a large number of labels. To do this, a er of labels.
maximum number of QNAME minimisation iterations MUST be selected To do this, a maximum number of QNAME minimisation iterations <bcp14>MUST
(MAX_MINIMISE_COUNT); a RECOMMENDED value is 10. Optionally, a value for the num </bcp14> be
ber of selected (MAX_MINIMISE_COUNT); a <bcp14>RECOMMENDED</bcp14> value is 10.
queries that should only have one label appended MAY be selected Optionally, a
(MINIMISE_ONE_LAB), a good value is 4. The assumption here is that the number value for the number of
of labels on delegations higher in the hierarchy are rather small, therefore queries that should only have one label appended <bcp14>MAY</bcp14> be se
not exposing too many labels early on has the most privacy benefit.</t> lected
(MINIMISE_ONE_LAB); a good value is 4. The assumption here is that the nu
<t>Another potential, optional mechanism for limiting the number of queries is t mber
o assume that labels that begin with of labels on delegations higher in the hierarchy are rather small; theref
an underscore (_) character do not represent privacy-relevant administrative bou ore,
ndaries. not exposing too many labels early on has the most privacy benefit.</t>
For example, if the QNAME is "_25._tcp.mail.example.org" and the algorithm has <t>Another potential, optional mechanism for limiting the number of quer
already searched for "mail.example.org", the next query can be for all the under ies is to
score-prefixed assume that labels that begin with
names together, namely "_25._tcp.mail.example.org".</t> an underscore (_) character do not represent privacy-relevant administrat
ive
<t>When a resolver needs to send out a query, it will look for the closest known boundaries. For example, if the QNAME is "_25._tcp.mail.example.org" and
delegation point in its cache. The number of not yet exposed labels is the algorithm
the difference between this closest nameserver and the incoming QNAME. The has already searched for "mail.example.org", the next query can be for al
first MINIMISE_ONE_LAB labels will be handled as described in l the
<xref target="qname-main"/>. The number of labels that are still not exposed now underscore-prefixed names together, namely "_25._tcp.mail.example.org".</
need to be divided proportionally over the remaining iterations t>
(MAX_MINIMISE_COUNT - MINIMISE_ONE_LAB). If the not yet exposed labels can not b <t>When a resolver needs to send out a query, it will look for the close
e equally divided over the remaining iterations, the remainder of the division s st-known
hould delegation point in its cache. The number of not-yet-exposed labels is
be added to the last iterations. For example, when resolving a QNAME with 18 the difference between this closest name server and the incoming QNAME. T
labels with MAX_MINIMISE_COUNT set to 10 and MINIMISE_ONE_LAB set to 4, the numb he
er of labels added per iteration are: 1,1,1,1,2,2,2,2,3,3.</t> first MINIMISE_ONE_LAB labels will be handled as described in
<xref target="qname-main" format="default"/>. The number of labels that a
</section> re still not
exposed now need to be divided proportionally over the remaining iteratio
<section title="Stub and Forwarding Resolvers"> ns
<t>Stub and forwarding resolvers MAY implement QNAME minimisation. Minimising (MAX_MINIMISE_COUNT - MINIMISE_ONE_LAB). If the not-yet-exposed labels ca
queries that will be sent to an upstream resolver does not help in hiding data nnot be
from the upstream resolver because all information will end up there anyway. It equally divided over the remaining iterations, the remainder of the divis
might, however, limit the data exposure between the upstream resolver and the ion should
authoritative nameserver in the situation where the upstream resolver does not be added to the last iterations. For example, when resolving a QNAME with
support QNAME minimisation. Using QNAME minimisation in a stub or forwarding 18
resolvers that does not have a mechanism to find and cache zone cuts will drasti labels with MAX_MINIMISE_COUNT set to 10 and MINIMISE_ONE_LAB set to 4, t
cally increase he number of
the number of outgoing queries.</t> labels added per iteration are: 1,1,1,1,2,2,2,2,3,3.</t>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Implementation by Stub and Forwarding Resolvers</name>
<t>Stub and forwarding resolvers <bcp14>MAY</bcp14> implement QNAME mini
<section anchor="zonecutalgo" title="Algorithm to Perform QNAME Minimisation"> misation.
Minimising queries that will be sent to an upstream resolver does not hel
<t>This algorithm performs name resolution with QNAME minimisation in p in
the presence of zone cuts that are not yet known.</t> hiding data from the upstream resolver because all information will end u
p there
<t>Although a validating resolver already has the logic to find the anyway. It might however limit the data exposure between the upstream res
zone cuts, implementers of resolvers may want to use olver
this algorithm to locate the zone cuts. and the authoritative name server in the situation where the upstream res
olver does
<list style="hanging" hangIndent="4"> not support QNAME minimisation. Using QNAME minimisation in a stub or for
warding
<t hangText="(0)">If the query can be answered from the cache, do so; resolver that does not have a mechanism to find and cache zone cuts will
otherwise, iterate as follows:</t> drastically increase the number of outgoing queries.</t>
</section>
<t hangText="(1)">Get the closest delegation point that can be used for </section>
the original QNAME from the cache. <section anchor="zonecutalgo" numbered="true" toc="default">
<list style="hanging" hangIndent="5"> <name>Algorithm to Perform QNAME Minimisation</name>
<t>This algorithm performs name resolution with QNAME minimisation in
<t hangText="(1a)"> the presence of zone cuts that are not yet known.</t>
For queries with a QTYPE for which the authority only lies at the parent side (l <t>Although a validating resolver already has the logic to find the
ike QTYPE=DS) this is the NS RRset with the owner matching the most zone cuts, implementers of resolvers may want to use
labels with QNAME stripped by one label. QNAME will be a subdomain of this algorithm to locate the zone cuts.</t>
(but not equal to) this NS RRset. Call this ANCESTOR.</t> <ol type="(%d)" start="0">
<li>If the query can be answered from the cache, do so;
<t hangText="(1b)"> otherwise, iterate as follows:</li>
For queries with other original QTYPEs this is the NS RRset with the owner <li>
matching the most labels with QNAME. QNAME will be equal to or a <t>Get the closest delegation point that can be used for
subdomain of this NS RRset. Call this ANCESTOR.</t> the original QNAME from the cache.</t>
</list></t> <ol type="(1%c)">
<li>For queries with a QTYPE for which the authority only lies at the
<t hangText="(2)">Initialise CHILD to the same as ANCESTOR.</t> parent side (like QTYPE=DS), this is the NS RRset with the owner matc
hing the
<t hangText="(3)">If CHILD is the same as QNAME, or if CHILD is one most labels with QNAME stripped by one label. QNAME will be a subdoma
label shorter than QNAME and the original QTYPE can only be at the parent side ( in of
like QTYPE=DS), resolve the (but not equal to) this NS RRset. Call this ANCESTOR.</li>
original query as normal starting from ANCESTOR's name servers. Start over from <li>For queries with other original QTYPEs, this is the NS RRset with
step 0 if new names need to be resolved as result of this answer, for example wh the
en the answer contains a CNAME or DNAME <xref target="RFC6672"/> record.</t> owner matching the most labels with QNAME. QNAME will be equal to or
a
<t hangText="(4)">Otherwise, update the value of CHILD by adding the next releva subdomain of this NS RRset. Call this ANCESTOR.</li>
nt label or labels from QNAME to the start </ol>
of CHILD. The number of labels to add is discussed in <xref target="number-of-qu </li>
eries"/>.</t> <li>Initialise CHILD to the same as ANCESTOR.</li>
<li>If CHILD is the same as QNAME, or if CHILD is one
<t hangText="(5)">Look for a cache entry for the RRset at CHILD with the origina label shorter than QNAME and the original QTYPE can only be at the parent
l side
QTYPE. If the cached response code is NXDOMAIN and the resolver has support for (like QTYPE=DS), resolve the original query as normal, starting from ANCE
<xref target="RFC8020"/>, STOR's
the NXDOMAIN can be used in response to the original query, and stop. If the name servers. Start over from step 0 if new names need to be resolved as
cached response code is NOERROR (including NODATA), go back to step 3. a
If the cached response code is NXDOMAIN and the resolver does not support result of this answer, for example, when the answer contains a CNAME or D
RFC 8020, go back to step 3.</t> NAME <xref
target="RFC6672" format="default"/> record.</li>
<t hangText="(6)">Query for CHILD with the selected QTYPE using one of ANCESTOR' <li>Otherwise, update the value of CHILD by adding the next relevant labe
s l or
name servers. The response can be: labels from QNAME to the start
of CHILD. The number of labels to add is discussed in <xref
<list style="hanging" hangIndent="5"> target="number-of-queries" format="default"/>.</li>
<li>Look for a cache entry for the RRset at CHILD with the original
<t hangText="(6a)">A referral. Cache the NS RRset from the authority QTYPE. If the cached response code is NXDOMAIN and the resolver has suppo
section, and go back to step 1.</t> rt for
<xref target="RFC8020" format="default"/>,
<t hangText="(6b)">A DNAME response. Proceed as if a DNAME is received for the the NXDOMAIN can be used in response to the original query, and stop. If
original query. Start over from step 0 to resolve the new name based on the the
DNAME target.</t> cached response code is NOERROR (including NODATA), go back to step 3.
If the cached response code is NXDOMAIN and the resolver does not support
<t hangText="(6c)">All other NOERROR answers (including NODATA). <xref target="RFC8020" format="default"/>, go back to step 3.</li>
Cache this answer. Regardless of the answered RRset type, including CNAMEs, <li><t>Query for CHILD with the selected QTYPE using one of ANCESTOR's
continue with the algorithm from step 3 by building the original QNAME.</t> name servers. The response can be:</t>
<ol type="(6%c)">
<t hangText="(6d)">An NXDOMAIN response. <li>A referral. Cache the NS RRset from the authority
If the resolver supports RFC8020, return an NXDOMAIN response to the original qu section, and go back to step 1.</li>
ery and stop. <li>A DNAME response. Proceed as if a DNAME is received for the
If the resolver does not support RFC8020, go to step 3.</t> original query. Start over from step 0 to resolve the new name based
on the
<t hangText="(6e)"> A timeout or response with another RCODE. The implementation DNAME target.</li>
may choose to retry step (6) with a different ANCESTOR name server.</t> <li>All other NOERROR answers (including NODATA).
Cache this answer. Regardless of the answered RRset type, including C
</list></t> NAMEs,
continue with the algorithm from step 3 by building the original QNAM
</list></t> E.</li>
<li>An NXDOMAIN response.
</section> If the resolver supports <xref target="RFC8020" format="default"/>, r
eturn an
<section title="QNAME Minimisation Examples"> NXDOMAIN response to the original
query, and stop. If the resolver does not support <xref target="RFC80
<t>As a first example, assume that a resolver receives a request to resolve 20"
format="default"/>, go to step 3.</li>
<li>A timeout or response with another RCODE. The implementation
may choose to retry step 6 with a different ANCESTOR name server.</li
>
</ol>
</li>
</ol>
</section>
<section numbered="true" toc="default">
<name>QNAME Minimisation Examples</name>
<t>As a first example, assume that a resolver receives a request to resolv
e
foo.bar.baz.example. Assume that the resolver already knows that foo.bar.baz.example. Assume that the resolver already knows that
ns1.nic.example is authoritative for .example, and that the resolver does ns1.nic.example is authoritative for .example and that the resolver does
not know a more specific authoritative name server. It will send the not know a more specific authoritative name server. It will send the
query with QNAME=baz.example and the QTYPE selected to hide the original query with QNAME=baz.example and the QTYPE selected to hide the original
QTYPE to ns1.nic.example.</t> QTYPE to ns1.nic.example.</t>
<table align="left">
<t>The following are more detailed examples of other queries with QNAME <name>Cold Cache, Traditional Resolution Algorithm without QNAME Minimisation,
minimisation, using other names and authoritative servers:</t> Request for MX Record of a.b.example.org</name>
<thead>
<t>Cold cache, traditional resolution algorithm without QNAME minimisation, <tr>
request for MX record of a.b.example.org: <th>QTYPE</th>
<th>QNAME</th>
<figure><artwork> <th>TARGET</th>
QTYPE QNAME TARGET NOTE <th>NOTE</th>
MX a.b.example.org root nameserver </tr>
MX a.b.example.org org nameserver </thead>
MX a.b.example.org example.org nameserver <tbody>
</artwork></figure></t> <tr>
<td>MX</td>
<t>Cold cache, with QNAME minimisation, request for MX record of <td>a.b.example.org</td>
a.b.example.org, using the A QTYPE to hide the original QTYPE: <td>root name server</td>
<td></td>
<figure><artwork> </tr>
QTYPE QNAME TARGET NOTE <tr>
A org root nameserver <td>MX</td>
A example.org org nameserver <td>a.b.example.org</td>
A b.example.org example.org nameserver <td>org name server</td>
A a.b.example.org example.org nameserver "a" may be delegated <td></td>
MX a.b.example.org example.org nameserver </tr>
</artwork></figure> <tr>
<td>MX</td>
Note that in above example one query would have been saved if the incoming QTYPE <td>a.b.example.org</td>
was the same as the QTYPE selected by the resolver to hide the <td>example.org name server</td>
original QTYPE. Only one query for a.b.example.org would have been needed if <td></td>
the original QTYPE would have been A. Using the most used QTYPE to hide the </tr>
original QTYPE therefore slightly reduces the number of outgoing queries compare </tbody>
d to using any other QTYPE to hide the original QTYPE. </table>
</t> <t>The following are more detailed examples of requests for an MX record of
a.b.example.org with QNAME minimisation, using A QTYPE to hide the original
<t> QTYPE and using other names and authoritative servers:</t>
Warm cache with only org delegation known, (example.org's NS RRset is <table align="left">
not known), request for MX record of <name>Cold Cache with QNAME Minimisation</name>
a.b.example.org, using A QTYPE to hide the original QTYPE: <thead>
<tr>
<figure><artwork> <th>QTYPE</th>
QTYPE QNAME TARGET NOTE <th>QNAME</th>
A example.org org nameserver <th>TARGET</th>
A b.example.org example.org nameserver <th>NOTE</th>
A a.b.example.org example.org nameserver "a" may be delegated </tr>
MX a.b.example.org example.org nameserver </thead>
</artwork></figure></t> <tbody>
<tr>
</section> <td>A</td>
<td>org</td>
<section title="Performance Considerations" anchor="perf_cons"> <td>root name server</td>
<td></td>
<t>The main goal of QNAME minimisation is to improve privacy by </tr>
sending less data. However, it may have other advantages. For <tr>
instance, if a resolver sends a root name server queries <td>A</td>
for A.example followed by B.example followed by C.example, the result <td>example.org</td>
will be three NXDOMAINs, since .example does not exist in the root <td>org name server</td>
zone. When using QNAME minimisation, the resolver would send <td></td>
only one question (for .example itself) to which they could answer </tr>
NXDOMAIN. The resolver can cache this answer and use it as to prove that <tr>
nothing below .example exists (<xref target="RFC8020"/>). A resolver now knows <td>A</td>
a priori that neither B.example nor C.example exist. Thus, in this common case, <td>b.example.org</td>
the total number of upstream <td>example.org name server</td>
queries under QNAME minimisation could counterintuitively be less <td></td>
than the number of queries under the traditional iteration (as </tr>
described in the DNS standard). <tr>
</t> <td>A</td>
<td>a.b.example.org</td>
<t>QNAME minimisation can increase the number of queries based on the incoming <td>example.org name server</td>
QNAME. This is described in <xref target="number-of-queries"/>. <td>"a" may be delegated</td>
As described in <xref target="devries-qnamemin"/>, QNAME minimisation </tr>
both increases the number of DNS lookups by up to 26% and leads to up to 5% more <tr>
failed lookups. <td>MX</td>
Filling the cache in a production resolver will soften that overhead.</t> <td>a.b.example.org</td>
<td>example.org name server</td>
</section> <td></td>
</tr>
<section title="Security Considerations"> </tbody>
</table>
<t>QNAME minimisation's benefits are clear in the case where you want <t>Note that, in the above example, one query would have been saved if the
to decrease exposure of the queried name to the authoritative name server. But m incoming QTYPE
inimising was the same as the QTYPE selected by the resolver to hide the
the amount of data sent also, in part, addresses the case of a wire original QTYPE. Only one query for a.b.example.org would have been needed
sniffer as well as the case of privacy invasion by the authoritative name if
servers. (Encryption is of course a better defense against wire the original QTYPE would have been A. Using the most-used QTYPE to hide th
sniffers, but, unlike QNAME minimisation, it changes the protocol and e
cannot be deployed unilaterally. Also, the effect of QNAME original QTYPE therefore slightly reduces the number of outgoing queries c
minimisation on wire sniffers depends on whether the sniffer is on ompared to
the DNS path.)</t> using any other QTYPE to hide the original QTYPE.</t>
<table align="left">
<t>QNAME minimisation offers no protection against the recursive <name>Warm Cache with QNAME Minimisation</name>
resolver, which still sees the full request coming from the stub <thead>
resolver.</t> <tr>
<th>QTYPE</th>
<t>A resolver using QNAME minimisation can possibly be used to cause <th>QNAME</th>
<th>TARGET</th>
<th>NOTE</th>
</tr>
</thead>
<tbody>
<tr>
<td>A</td>
<td>example.org</td>
<td>org name server</td>
<td></td>
</tr>
<tr>
<td>A</td>
<td>b.example.org</td>
<td>example.org name server</td>
<td></td>
</tr>
<tr>
<td>A</td>
<td>a.b.example.org</td>
<td>example.org name server</td>
<td>"a" may be delegated</td>
</tr>
<tr>
<td>MX</td>
<td>a.b.example.org</td>
<td>example.org name server</td>
<td></td>
</tr>
</tbody>
</table>
</section>
<section anchor="perf_cons" numbered="true" toc="default">
<name>Performance Considerations</name>
<t>The main goal of QNAME minimisation is to improve privacy by
sending less data. However, it may have other advantages. For
instance, if a resolver sends a root name server queries
for A.example followed by B.example followed by C.example, the result
will be three NXDOMAINs, since .example does not exist in the root
zone. When using QNAME minimisation, the resolver would send
only one question (for .example itself) to which they could answer
NXDOMAIN. The resolver can cache this answer and use it to prove that
nothing below .example exists <xref target="RFC8020" format="default"/>. A
resolver now
knows a priori that neither B.example nor C.example exist. Thus, in this c
ommon case,
the total number of upstream
queries under QNAME minimisation could be counterintuitively less
than the number of queries under the traditional iteration (as
described in the DNS standard).</t>
<t>QNAME minimisation can increase the number of queries based on the inco
ming
QNAME. This is described in <xref target="number-of-queries" format="defau
lt"/>.
As described in <xref target="devries-qnamemin" format="default"/>, QNAME
minimisation
both increases the number of DNS lookups by up to 26% and leads to up to 5
% more failed
lookups. Filling the cache in a production resolver will soften that overh
ead.</t>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>QNAME minimisation's benefits are clear in the case where you want
to decrease exposure of the queried name 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 the case of privacy invasion by the authoritative name
servers. Encryption is of course a better defense against wire
sniffers, but, unlike QNAME minimisation, it changes the protocol and
cannot be deployed unilaterally. Also, the effect of QNAME
minimisation on wire sniffers depends on whether the sniffer is on
the DNS path.</t>
<t>QNAME minimisation offers no protection against the recursive
resolver, which still sees the full request coming from the stub
resolver.</t>
<t>A resolver using QNAME minimisation can possibly be used to cause
a query storm to be sent to servers when resolving queries containing a QNAME a query storm to be sent to servers when resolving queries containing a QNAME
with a large number of labels, as described in with a large number of labels, as described in
<xref target="number-of-queries"/>. That section proposes methods to <xref target="number-of-queries" format="default"/>. That section proposes metho ds to
significantly dampen the effects of such attacks.</t> significantly dampen the effects of such attacks.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8499.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2181.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6672.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6895.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7816.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8198.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9076.xml"/>
</section> <reference anchor="Huque-QNAME-Min" target="https://indico.dns-oarc.net/
event/21/contribution/9">
</middle> <front>
<title>Query name minimization and authoritative server behavior</ti
<back> tle>
<author fullname="Shumon Huque" initials="S." surname="Huque"/>
<references title='Normative References'> <date month="May" year="2015"/>
&rfc1034; </front>
&rfc1035; </reference>
&rfc2119; <reference anchor="dnsthought-qnamemin" target="https://dnsthought.nlnet
&rfc6973; labs.nl/#qnamemin">
&rfc8174; <front>
&rfc8499; <title>Qname Minimisation</title>
</references> <author fullname="" initials="" surname=""/>
<date month="October" year="2021"/>
<references title='Informative References'> </front>
&rfc2181; </reference>
&rfc6672;
&rfc6895;
&rfc7816;
&rfc8020;
&rfc8198;
&rfc9076;
<reference anchor="Huque-QNAME-Min" target="https://indico.dns-oarc.net/event/21
/contribution/9">
<front>
<title>Query name minimization and authoritative server behavior</title>
<author fullname="Shumon Huque" initials="S." surname="Huque"/>
<date month="May" year="2015"/>
</front>
</reference>
<reference anchor="dnsthought-qnamemin"
target="https://dnsthought.nlnetlabs.nl/#qnamemin">
<front>
<title>DNSThought QNAME minimisation results. Using Atlas probes</title>
<author fullname="" initials=""
surname=""/>
<date month="March" year="2020"/>
</front>
</reference>
<reference anchor="devries-qnamemin"
target="https://nlnetlabs.nl/downloads/publications/devries2019.pdf">
<front>
<title>A First Look at QNAME Minimization in the Domain Name System</ti
tle>
<author fullname="de Vries et al." initials=""
surname=""/>
<date month="March" year="2019"/>
</front>
</reference>
<reference anchor="verisign-qnamemin"
target="https://blog.verisign.com/security/maximizing-qname-minimization
-a-new-chapter-in-dns-protocol-evolution/">
<front>
<title>Maximizing Qname Minimization: A New Chapter in DNS Protocol Evolutio
n</title>
<author fullname="Matt Thomas" initials="M."
surname="Thomas"/>
<date month="September" year="2020"/>
</front>
</reference>
<reference anchor="apnic-qnamemin"
target="https://indico.dns-oarc.net/event/34/contributions/787/attachmen
ts/777/1326/2020-09-28-oarc33-qname-minimisation.pdf">
<front>
<title>Measuring Query Name Minimization</title>
<author fullname="Geoff Huston" initials="G."
surname="Huston"/>
<author fullname="Joao Damas" initials="J."
surname="Damas"/>
<date month="September" year="2020"/>
</front>
</reference>
</references>
<section title="Acknowledgments" numbered="no">
<t>The acknowledgements from RFC 7816 apply here.
In addition, many participants from the DNSOP Working Group helped
with proposals for simplification, clarification, and general
editorial help.
</t>
</section>
<section title="Changes from RFC 7816" numbered="no">
<t>Changed in -07<list style="symbols">
<t>Stopped using the term "aggressive" for the method described</t>
<t>Clarified some terminology</t>
<t>More reorganization</t>
</list></t>
<t>Changed in -06<list style="symbols">
<t>Removed lots of text from when this was experimental</t>
<t>Lots of reorganization</t>
</list></t>
<t>Changed in -04<list style="symbols">
<t>Start structure for implementation section</t>
<t>Add clarification why the used QTYPE does not matter</t>
<t>Make algorithm DS QTYPE compatible</t>
</list></t>
<t>Changed in -03<list style="symbols">
<t>Drop recommendation to use the NS QTYPE to hide the incoming QTYPE</t>
<t>Describe DoS attach vector for QNAME with large number of labels, and propose
a mitigation.</t>
<t>Simplify examples and change qname to a.b.example.com to show the change in
number of queries.</t>
</list></t>
<t>Changed in -00, -01, and -02<list style="symbols">
<t>Made changes to deal with errata #4644</t>
<t>Changed status to be on standards track</t>
<t>Major reorganization</t>
</list></t> <reference anchor="devries-qnamemin" target="https://nlnetlabs.nl/downlo
</section> ads/publications/devries2019.pdf">
<front>
<title>A First Look at QNAME Minimization in the Domain Name System<
/title>
<author fullname="Wouter B. de Vries" initials="W" surname="de Vries
"/>
<author fullname="Quirin Scheitle" initials="Q" surname="Scheitle"/>
<author fullname="Moritz Müller" initials="M" surname="Müller"/>
<author fullname="Willem Toorop" initials="W" surname="Toorop"/>
<author fullname="Ralph Dolmans" initials="R" surname="Dolmans"/>
<author fullname="Roland van Rijswijk-Deij" initials="R" surname="van
Ri
jswijk-Deij"/>
<date month="March" year="2019"/>
</front>
</reference>
</back> <reference anchor="verisign-qnamemin" target="https://blog.verisign.com/
security/maximizing-qname-minimization-a-new-chapter-in-dns-protocol-evolution/"
>
<front>
<title>Maximizing Qname Minimization: A New Chapter in DNS Protocol
Evolution</title>
<author fullname="Matt Thomas" initials="M." surname="Thomas"/>
<date month="September" year="2020"/>
</front>
</reference>
<reference anchor="apnic-qnamemin" target="https://indico.dns-oarc.net/e
vent/34/contributions/787/attachments/777/1326/2020-09-28-oarc33-qname-minimisat
ion.pdf">
<front>
<title>Measuring Query Name Minimization</title>
<author fullname="Geoff Huston" initials="G." surname="Huston"/>
<author fullname="Joao Damas" initials="J." surname="Damas"/>
<date month="September" year="2020"/>
</front>
</reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The acknowledgments from RFC 7816 apply here.
In addition, many participants from the DNSOP Working Group helped
with proposals for simplification, clarification, and general
editorial help.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 33 change blocks. 
609 lines changed or deleted 631 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/