<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2181 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY rfc4033 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc5246 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5936 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5936.xml">
<!ENTITY rfc6347 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY rfc6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
<!ENTITY I-D.koch-perpass-dns-confidentiality SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.koch-perpass-dns-confidentiality.xml">
<!ENTITY I-D.vandergaast-edns-client-subnet SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vandergaast-edns-client-subnet">
<!ENTITY I-D.wijngaards-dnsop-confidentialdns SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijngaards-dnsop-confidentialdns">
<!ENTITY I-D.bortzmeyer-dnsop-dns-privacy SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bortzmeyer-dnsop-dns-privacy.xml">
]>

<rfc docName="draft-bortzmeyer-dns-qname-minimisation-00" category="info" ipr="trust200902">
<?rfc toc="yes"?>
<?rfc strict="yes"?> 
<front>
<title abbrev="Qname minimisation">DNS query name minimisation to improve privacy</title>
<author fullname="Stephane Bortzmeyer" initials="S." surname="Bortzmeyer">
<organization>AFNIC</organization>
<address><postal><street>Immeuble International</street><code>78181</code><city>Saint-Quentin-en-Yvelines</city><country>France</country></postal> <phone>+33 1 39 30 83 46</phone><email>bortzmeyer+ietf@nic.fr</email><uri>http://www.afnic.fr/</uri></address>
</author>
<date month="March" year="2014"/>
<abstract>
<t>This document describes one of the techniques that could be used to
improve DNS privacy (see <xref
target="I-D.bortzmeyer-dnsop-dns-privacy"/>), a technique called "qname
minimisation".</t>
<t>Discussions of the document should currently take place on the <xref target="dns-privacy">dns-privacy
mailing list</xref>.</t>
</abstract>
</front>

<middle>
<section title="Introduction and background">
<t>The problem statement is exposed in <xref
target="I-D.bortzmeyer-dnsop-dns-privacy"/>. The terminology ("qname",
"resolver", etc)
is also defined in this companion document. This specific solution is
not intended to completely solve the problem, far from it. It is
better to see it as one tool among a toolbox. </t>
<t>It follows the principle explained in section 6.1 of <xref
target="RFC6973"/>: the less data you send out, the less privacy
problems you'll get.</t>
</section>

<section title="Qname minimisation">
<t>The idea is to minimise the amount of data sent
from the DNS resolver. When a resolver receives the query "What is the
AAAA record for www.example.com?", it sends to the root (assuming a
cold resolver, whose cache is empty) the very same question. Sending
"What are the NS records for .com?" would be sufficient (since
it will be the answer from the root anyway). To do so would be
compatible with the current DNS system and therefore could be
easily deployable, since it is an unilateral change to the resolvers.</t>
<t>To do such minimisation, the resolver needs to know the zone cut <xref
target="RFC2181"/>. There is not a zone cut at every label
boundary. If we take the name www.foo.bar.example, it is possible that
there is a zone cut between "foo" and "bar" but not between "bar" and
"example"<!-- A real example is www.economie.gouv.fr -->. So, assuming the resolver already knows
the name servers of .example, when it receives the query "What is the
AAAA record of www.foo.bar.example", it does not always know if the
request should be sent to the name servers of bar.example or to those
of example. <xref
target="RFC2181"/> suggests an algorithm to find the zone cut, so
resolvers may try it.</t>
<t>Note that DNSSEC-validating resolvers already have access to this information, since they
have to find the zone cut (the DNSKEY record set is just below, the DS
record set just above).</t>
<t>It can be noted that minimising the amount of data sent also
partially addresses the case of a wire sniffer, not just the case of
privacy invasion by the servers.</t>
<t>One should note that the behaviour suggested here
(minimising the amount of data sent in qnames) is NOT forbidden by the <xref
target="RFC1034"/> (section 5.3.3) or <xref target="RFC1035"/>
(section 7.2). Sending the full qname to the authoritative name server
is a tradition, not a protocol requirment.</t>
<t>Another note is that the answer to the
NS query, unlike the referral sent when the question is a full qname,
is in the Answer section, not in the Authoritative section. It has
probably no practical consequences.</t>
</section>

<section title="Operational considerations">
<t>The administrators of the forwarders, and of the authoritative name
servers, will get less data, which will reduce the utility of the
statistics they can produce (such as the percentage of the various
qtypes). On the other hand, it will decrease their legal
responsability, in many cases.</t>
</section>

<section title="Security considerations">
<t>Some broken name servers do not react properly to qtype=NS
requests. 
As an example, look at www.ratp.fr (not ratp.fr), which
is delegated to two name servers that reply properly to "A
www.ratp.fr" queries but send REFUSED to queries "NS
www.ratp.fr". This behaviour is a gross protocol violation and there
is no need to stop improving the DNS because of such
brokenness. However, qname minimisation may still work with such
domains since they are only leaf domains (no need to send them NS requests).</t>
</section>

<section title="Acknowledgments">
<t>Thanks to Olaf Kolkman, Mark Andrews and Francis Dupont for the
interesting discussions on this qname minimisation. Thanks to Mohsen Souissi for proofreading.</t>
</section>

</middle>

<back>

<references title='Normative References'>
&rfc1034;
&rfc1035;
&rfc2119;
&rfc6973;
&I-D.bortzmeyer-dnsop-dns-privacy;
</references>

<references title='Informative References'>
&rfc2181;

<reference anchor="dns-privacy">
<front>
<title>The dns-privacy mailing list</title>
<author fullname="IETF" surname="IETF"/>
<date month="March" year="2014"/>
<abstract>
<t>This (non-WG) IETF list is for the discussion of the problem statement 
surrounding the addition of privacy to the DNS protocol.<eref target="http://www.ietf.org/mail-archive/web/dns-privacy/"/></t>
</abstract>
</front>
</reference>

</references>

</back>

</rfc>



