draft-ietf-dnsop-qname-minimisation-07.txt   draft-ietf-dnsop-qname-minimisation-08.txt 
Domain Name System Operations (dnsop) Working Group S. Bortzmeyer Domain Name System Operations (dnsop) Working Group S. Bortzmeyer
Internet-Draft AFNIC Internet-Draft AFNIC
Intended status: Experimental October 12, 2015 Intended status: Experimental November 29, 2015
Expires: April 14, 2016 Expires: June 1, 2016
DNS query name minimisation to improve privacy DNS query name minimisation to improve privacy
draft-ietf-dnsop-qname-minimisation-07 draft-ietf-dnsop-qname-minimisation-08
Abstract Abstract
This document describes one of the techniques that could be used to This document describes a technique to improve DNS privacy, a
improve DNS privacy, a technique called "QNAME minimisation", where technique called "QNAME minimisation", where the DNS resolver no
the DNS resolver no longer sends the full original QNAME to the longer sends the full original QNAME to the upstream name server.
upstream name server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2016. This Internet-Draft will expire on June 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
2. QNAME minimisation . . . . . . . . . . . . . . . . . . . . . 3 2. QNAME minimisation . . . . . . . . . . . . . . . . . . . . . 3
3. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 4 3. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol and compatibility discussion . . . . . . . . . . . . 5 4. Protocol and compatibility discussion . . . . . . . . . . . . 5
5. Operational considerations . . . . . . . . . . . . . . . . . 5 5. Operational considerations . . . . . . . . . . . . . . . . . 5
6. Performance considerations . . . . . . . . . . . . . . . . . 5 6. Performance considerations . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 8
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. An algorithm to find the zone cut . . . . . . . . . 9 Appendix A. An algorithm to perform QNAME minimisation in
presence of zone cuts . . . . . . . . . . . . . . . 10
Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background 1. Introduction and background
The problem statement is exposed in [RFC7626]. The terminology The problem statement is exposed in [RFC7626]. The terminology
("QNAME", "resolver", etc) is also defined in this companion ("QNAME", "resolver", etc) is also defined in this companion
document. This specific solution is not intended to fully solve the document. This specific solution is not intended to fully solve the
DNS privacy problem; instead, it should be viewed as one tool amongst DNS privacy problem; instead, it should be viewed as one tool amongst
many. many.
It follows the principle explained in section 6.1 of [RFC6973]: the It follows the principle explained in section 6.1 of [RFC6973]: the
less data you send out, the fewer privacy problems you'll get. less data you send out, the fewer privacy problems you have.
Under current practice, when a resolver receives the query "What is Currently, when a resolver receives the query "What is the AAAA
the AAAA record for www.example.com?", it sends to the root (assuming record for www.example.com?", it sends to the root (assuming a cold
a cold resolver, whose cache is empty) the very same question. resolver, whose cache is empty) the very same question. Sending the
Sending the full QNAME to the authoritative name server is a full QNAME to the authoritative name server is a tradition, not a
tradition, not a protocol requirement. This tradition comes protocol requirement. This tradition comes [mockapetris-history]
[mockapetris-history] from a desire to optimize the number of from a desire to optimize the number of requests, when the same name
requests, when the same name server is authoritative for many zones server is authoritative for many zones in a given name (something
in a given name (something which was more common in the old days, which was more common in the old days, where the same name servers
where the same name servers served .com and the root) or when the served .com and the root) or when the same name server is both
same name server is both recursive and authoritative (something which recursive and authoritative (something which is strongly discouraged
is strongly discouraged now). Whatever the merits of this choice at now). Whatever the merits of this choice at this time, the DNS is
this time, the DNS is quite different now. quite different now.
2. QNAME minimisation 2. QNAME minimisation
The idea is to minimise the amount of data sent from the DNS resolver The idea is to minimise the amount of data sent from the DNS resolver
to the authoritative name server. In the example in the previous to the authoritative name server. In the example in the previous
section, sending "What are the NS records for .com?" would have been section, sending "What are the NS records for .com?" would have been
sufficient (since it will be the answer from the root anyway). The sufficient (since it will be the answer from the root anyway). The
rest of this section describes the recommended way to do QNAME rest of this section describes the recommended way to do QNAME
minimisation, the one which maximimes privacy benefits (other minimisation, the one which maximimes privacy benefits (other
alternatives are discussed in appendixes). alternatives are discussed in appendixes).
A resolver which implements QNAME minimisation, and which does not A resolver which implements QNAME minimisation, and which does not
have already the answer in its cache, instead of sending the full have already the answer in its cache, instead of sending the full
QNAME and the original QTYPE upstream, sends a request to the name QNAME and the original QTYPE upstream, sends a request to the name
server authoritative for the closest known parent of the original server authoritative for the closest known ancestor of the original
QNAME. The request is done with: QNAME. The request is done with:
the QTYPE NS, the QTYPE NS,
the QNAME which is the original QNAME, stripped to just one label the QNAME which is the original QNAME, stripped to just one label
more than the zone for which the server is authoritative. more than the zone for which the server is authoritative.
For example, a resolver receives a request to resolve For example, a resolver receives a request to resolve
foo.bar.baz.example. Let's assume it already knows that foo.bar.baz.example. Let's assume it already knows that
ns1.nic.example is authoritative for .example and the resolver does ns1.nic.example is authoritative for .example and 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 QTYPE=NS,QNAME=baz.example to ns1.nic.example. query QTYPE=NS,QNAME=baz.example to ns1.nic.example.
The minimising resolver works perfectly when it knows the zone cut The minimising resolver works perfectly when it knows the zone cut
[RFC2181] (section 6). But zone cuts do not necessarily exist at (zone cuts are described in section 6 of [RFC2181]). But zone cuts
every label boundary. If we take the name www.foo.bar.example, it is do not necessarily exist at every label boundary. If we take the
possible that there is a zone cut between "foo" and "bar" but not name www.foo.bar.example, it is possible that there is a zone cut
between "bar" and "example". So, assuming the resolver already knows between "foo" and "bar" but not between "bar" and "example". So,
the name servers of .example, when it receives the query "What is the assuming the resolver already knows the name servers of .example,
AAAA record of www.foo.bar.example", it does not always know where when it receives the query "What is the AAAA record of
the zone cut will be. To find it out, it will query the .example www.foo.bar.example", it does not always know where the zone cut will
name servers for the NS records for bar.example. It will get a be. To find it out, it will query the .example name servers for the
NODATA response, indicating there is no zone cut at that point, so it NS records for bar.example. It will get a NODATA response,
has to to query the .example name servers again with one more label, indicating there is no zone cut at that point, so it has to to query
and so on. (Appendix A describes this algorithm in deeper details.) the .example name servers again with one more label, and so on.
(Appendix A describes this algorithm in deeper details.)
Since the information about the zone cuts will be stored in the Since the information about the zone cuts will be stored in the
resolver's cache, the performance cost is probably reasonable. resolver's cache, the performance cost is probably reasonable.
Section 6 discusses this performance discrepancy further. Section 6 discusses this performance discrepancy further.
Note that DNSSEC-validating resolvers already have access to this Note that DNSSEC-validating resolvers already have access to this
information, since they have to know the zone cut (the DNSKEY record information, since they have to know the zone cut (the DNSKEY record
set is just below, the DS record set just above). set is just below, the DS record set just above).
3. Possible issues 3. Possible issues
skipping to change at page 4, line 42 skipping to change at page 4, line 42
to ENT (Empty Non-Terminals). If ent.example.com has no resource to ENT (Empty Non-Terminals). If ent.example.com has no resource
records but foobar.ent.example.com does, then ent.example.com is an records but foobar.ent.example.com does, then ent.example.com is an
ENT. A query, whatever the qtype, for ent.example.com must return ENT. A query, whatever the qtype, for ent.example.com must return
NODATA (NOERROR / ANSWER: 0). However, some broken name servers NODATA (NOERROR / ANSWER: 0). However, some broken name servers
return NXDOMAIN for ENTs. If a resolver queries only return NXDOMAIN for ENTs. If a resolver queries only
foobar.ent.example.com, everything will be OK but, if it implements foobar.ent.example.com, everything will be OK but, if it implements
QNAME minimisation, it may query ent.example.com and get a NXDOMAIN. QNAME minimisation, it may query ent.example.com and get a NXDOMAIN.
See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad
consequences of this brokenness. consequences of this brokenness.
A possible solution, currently implemented in Knot, is to retry with
the full query when you receive a NXDOMAIN. It works but it is not
ideal for privacy.
Other strange and non-conformant practices may pose a problem: there Other strange and non-conformant practices may pose a problem: there
is a common DNS anti-pattern used by low-end web hosters that also do is a common DNS anti-pattern used by low-end web hosters that also do
DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC) DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC)
allows certain serious misconfigurations, such as parent and child allows certain serious misconfigurations, such as parent and child
zones disagreeing on the location of a zone cut. Basically, they zones disagreeing on the location of a zone cut. Basically, they
have a single zone with wildcards for each TLD like: have a single zone with wildcards for each TLD like:
*.example. 60 IN A 192.0.2.6 *.example. 60 IN A 192.0.2.6
(It is not known why they don't just wildcard all of "*." and be done (It is not known why they don't just wildcard all of "*." and be done
skipping to change at page 5, line 4 skipping to change at page 5, line 9
is a common DNS anti-pattern used by low-end web hosters that also do is a common DNS anti-pattern used by low-end web hosters that also do
DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC) DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC)
allows certain serious misconfigurations, such as parent and child allows certain serious misconfigurations, such as parent and child
zones disagreeing on the location of a zone cut. Basically, they zones disagreeing on the location of a zone cut. Basically, they
have a single zone with wildcards for each TLD like: have a single zone with wildcards for each TLD like:
*.example. 60 IN A 192.0.2.6 *.example. 60 IN A 192.0.2.6
(It is not known why they don't just wildcard all of "*." and be done (It is not known why they don't just wildcard all of "*." and be done
with it.) with it.)
This lets them turn up many web hosting customers without having to This lets them turn up many web hosting customers without having to
configure thousands of individual zones on their nameservers. They configure thousands of individual zones on their nameservers. They
just tell the prospective customer to point their NS records at the just tell the prospective customer to point their NS records at the
hoster's nameservers, and the Web hoster doesn't have to provision hoster's nameservers, and the Web hoster doesn't have to provision
anything in order to make the customer's domain resolve. NS queries anything in order to make the customer's domain resolve. NS queries
to the hoster will therefore do not give the right result, which may to the hoster will therefore not give the right result, which may
endanger QNAME minimisation (it will be a problem for DNSSEC, too). endanger QNAME minimisation (it will be a problem for DNSSEC, too).
4. Protocol and compatibility discussion 4. Protocol and compatibility discussion
QNAME minimisation is compatible with the current DNS system and QNAME minimisation is compatible with the current DNS system and
therefore can easily be deployed; since it is a unilateral change to therefore can easily be deployed; since it is a unilateral change to
the resolver, it does not change the protocol. (Because it is an the resolver, it does not change the protocol. (Because it is an
unilateral change, resolver implementers may do QNAME minimisation in unilateral change, resolver implementers may do QNAME minimisation in
slightly different ways, see the appendices for examples.) slightly different ways, see the appendices for examples.)
skipping to change at page 6, line 41 skipping to change at page 6, line 51
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security Considerations 8. Security Considerations
QNAME minimisation's benefits are clear in the case where you want to QNAME minimisation's benefits are clear in the case where you want to
decrease exposure to the authoritative name server. But minimising decrease exposure to the authoritative name server. But minimising
the amount of data sent also, in part, addresses the case of a wire the amount of data sent also, in part, addresses the case of a wire
sniffer as well the case of privacy invasion by the servers. sniffer as well as the case of privacy invasion by the servers.
(Encryption is of course a better defense against wire sniffers but, (Encryption is of course a better defense against wire sniffers but,
unlike QNAME minimisation, it changes the protocol and cannot be unlike QNAME minimisation, it changes the protocol and cannot be
deployed unilaterally. Also, the effect of QNAME minimisation on deployed unilaterally. Also, the effect of QNAME minimisation on
wire sniffers depend on whether the sniffer is, on the DNS path.) wire sniffers depends on whether the sniffer is, on the DNS path.)
QNAME minimisation offers zero protection against the recursive QNAME minimisation offers zero protection against the recursive
resolver, which still sees the full request coming from the stub resolver, which still sees the full request coming from the stub
resolver. resolver.
All the alternatives mentioned in Appendix B decrease privacy in the All the alternatives mentioned in Appendix B decrease privacy in the
hope of improving performances. They must not be used if you want hope of improving performance. They must not be used if you want the
the maximum privacy. maximum privacy.
9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
skipping to change at page 7, line 32 skipping to change at page 7, line 39
exist. exist.
According to [RFC6982], "this will allow reviewers and working groups According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
As of today, no production resolver implements QNAME minimisation but As of today, no production resolver implements QNAME minimisation but
it has been publically announced for the future Knot DNS resolver it has been publically announced for the future Knot DNS resolver [1]
[1]. For Unbound, see ticket 648 [2] and for PowerDNS which is now in beta mode [2] (with QNAME minimisation actually
<https://github.com/PowerDNS/pdns/issues/2311>. working). For Unbound, see ticket 648 [3] and for PowerDNS [4].
The algorithm to find the zone cuts described in Appendix A is The algorithm to find the zone cuts described in Appendix A is
implemented with QNAME minimisation in the sample code zonecut.go implemented with QNAME minimisation in the sample code zonecut.go
[3]. It is also implemented, for a much longer time, in an option of [5]. It is also implemented, for a much longer time, in an option of
dig, "dig +trace", but without QNAME minimisation. dig, "dig +trace", but without QNAME minimisation.
Another implementation was done by Shumon Huque for testing, and is Another implementation was done by Shumon Huque for testing, and is
described in [huque-qnamemin]. described in [huque-qnamemin].
10. Acknowledgments 10. Acknowledgments
Thanks to Olaf Kolkman for the original idea during a KLM flight from Thanks to Olaf Kolkman for the original idea during a KLM flight from
Amsterdam to Vancouver, although the concept is probably much older Amsterdam to Vancouver, although the concept is probably much older
[4]. Thanks for Shumon Huque and Marek Vavrusa for implementation [6]. Thanks for Shumon Huque and Marek Vavrusa for implementation
and testing. Thanks to Mark Andrews and Francis Dupont for the and testing. Thanks to Mark Andrews and Francis Dupont for the
interesting discussions. Thanks to Brian Dickson, Warren Kumari, interesting discussions. Thanks to Brian Dickson, Warren Kumari,
Evan Hunt and David Conrad for remarks and suggestions. Thanks to Evan Hunt and David Conrad for remarks and suggestions. Thanks to
Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone
cut algorithm in Appendix A and for discussion of the algorithm. cut algorithm in Appendix A and for discussion of the algorithm.
Thanks to Paul Vixie for pointing out that there are practical Thanks to Paul Vixie for pointing out that there are practical
advantages (besides privacy) to QNAME minimisation. Thanks to advantages (besides privacy) to QNAME minimisation. Thanks to
Phillip Hallam-Baker for the fallback on A queries, to deal with Phillip Hallam-Baker for the fallback on A queries, to deal with
broken servers. Thanks to Robert Edmonds for an interesting anti- broken servers. Thanks to Robert Edmonds for an interesting anti-
pattern. pattern.
skipping to change at page 9, line 34 skipping to change at page 9, line 39
[huque-qnamestorify] [huque-qnamestorify]
Huque, S., "Qname Minimization @ DNS-OARC", May 2015, Huque, S., "Qname Minimization @ DNS-OARC", May 2015,
<https://storify.com/shuque/qname-minimization-dns-oarc>. <https://storify.com/shuque/qname-minimization-dns-oarc>.
11.3. URIs 11.3. URIs
[1] https://ripe70.ripe.net/presentations/121-knot-resolver- [1] https://ripe70.ripe.net/presentations/121-knot-resolver-
ripe70.pdf ripe70.pdf
[2] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=648 [2] https://storify.com/KnotDNS/knot-dns-recursive-beta
[3] https://github.com/bortzmeyer/my-IETF-work/blob/master/draft- [3] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=648
[4] https://github.com/PowerDNS/pdns/issues/2311
[5] https://github.com/bortzmeyer/my-IETF-work/blob/master/draft-
ietf-dnsop-QNAME-minimisation/zonecut.go ietf-dnsop-QNAME-minimisation/zonecut.go
[4] https://lists.dns-oarc.net/pipermail/dns- [6] https://lists.dns-oarc.net/pipermail/dns-
operations/2010-February/005003.html operations/2010-February/005003.html
Appendix A. An algorithm to find the zone cut Appendix A. An algorithm to perform QNAME minimisation in presence of
zone cuts
Although a validating resolver already has the logic to find the zone Although a validating resolver already has the logic to find the zone
cut, other resolvers may be interested by this algorithm to follow in cut, other resolvers may be interested by this algorithm to follow in
order to locate this cut: order to locate this cut:
(0) If the query can be answered from the cache, do so, otherwise (0) If the query can be answered from the cache, do so, otherwise
iterate as follows: iterate as follows:
(1) Find closest enclosing NS RRset in your cache. The owner of (1) Find closest enclosing NS RRset in your cache. The owner of
this NS RRset will be a suffix of the QNAME - the longest suffix this NS RRset will be a suffix of the QNAME - the longest suffix
of any NS RRset in the cache. Call this PARENT. of any NS RRset in the cache. Call this ANCESTOR.
(2) Initialize CHILD to the same as PARENT. (2) Initialize CHILD to the same as ANCESTOR.
(3) If CHILD is the same as the QNAME, resolve the original query (3) If CHILD is the same as the QNAME, resolve the original query
using PARENT's name servers, and finish. using ANCESTOR's name servers, and finish.
(4) Otherwise, add a label from the QNAME to the start of CHILD. (4) Otherwise, add a label from the QNAME to the start of CHILD.
(5) If you have a negative cache entry for the NS RRset at CHILD, (5) If you have a negative cache entry for the NS RRset at CHILD,
go back to step 3. go back to step 3.
(6) Query for CHILD IN NS using PARENT's name servers. The (6) Query for CHILD IN NS using ANCESTOR's name servers. The
response can be: response can be:
(6a) A referral. Cache the NS RRset from the authority section (6a) A referral. Cache the NS RRset from the authority section
and go back to step 1. and go back to step 1.
(6b) An authoritative answer. Cache the NS RRset from the (6b) An authoritative answer. Cache the NS RRset from the
answer section and go back to step 1. answer section and go back to step 1.
(6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response (6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response
to the original query and stop. to the original query and stop.
skipping to change at page 11, line 16 skipping to change at page 11, line 26
IPv6 deployment by counting the percentage of AAAA vs. A queries). A IPv6 deployment by counting the percentage of AAAA vs. A queries). A
variant of QNAME minimisation would be to keep the original QTYPE. variant of QNAME minimisation would be to keep the original QTYPE.
Another useful optimisation may be, in the spirit of the HAMMER idea Another useful optimisation may be, in the spirit of the HAMMER idea
[I-D.wkumari-dnsop-hammer] to probe in advance for the introduction [I-D.wkumari-dnsop-hammer] to probe in advance for the introduction
of zone cuts where none previously existed (i.e. confirm their of zone cuts where none previously existed (i.e. confirm their
continued absence, or discover them.) continued absence, or discover them.)
To address the "number of queries" issue, described in Section 6, a To address the "number of queries" issue, described in Section 6, a
possible solution is to always use the traditional algorithm when the possible solution is to always use the traditional algorithm when the
cache is cold and then to move to QNAME minimisation. This will cache is cold and then to move to QNAME minimisation (precisely
decrease the privacy but will guarantee no degradation of defining what is "hot" or "cold" is left to the implementer). This
will decrease the privacy but will guarantee no degradation of
performance. performance.
Author's Address Author's Address
Stephane Bortzmeyer Stephane Bortzmeyer
AFNIC AFNIC
1, rue Stephenson 1, rue Stephenson
Montigny-le-Bretonneux 78180 Montigny-le-Bretonneux 78180
France France
 End of changes. 29 change blocks. 
56 lines changed or deleted 68 lines changed or added

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