Line # https://tools.ietf.org/id/draft-ietf-dnsop-qname-minimisation-00.txt
1 ##Network Working Group S.
Bortzmeyer
Should be DNSOP WG
7 ## DNS query name minimisation to improve privacy
I suggest shortening the name to "DNS Query Name Minimi[s|z]ation" but I have
a feeling that there is a more appropriate word to use. Because, as described
this proposal would increase the number of queries sent in search of a name.
Perhaps "DNS Query Localization". A query is issued mindful of its data space
location.
12 ## This document describes one of the techniques that could be used to
13 ## improve DNS privacy (see [I-D.bortzmeyer-dnsop-dns-privacy]), a
14 ## technique called "qname minimisation".
This isn't a topic to discuss here, but my concern with privacy is that
acheiving
that goal tends to make network management and operations that much harder. I
mention this misgiving in the sense that perhaps there is no need to make this
proposal only about privacy.
What is proposed is that an interating client asks only what it thinks the
server
will know. I don't know if that is a benefit to any client other than those
trying to hide their tracks.
89 ## It follows the principle explained in section 6.1 of [RFC6973]: the
90 ## less data you send out, the less privacy problems you'll get.
I don't know that the amount of "privacy problems" is something DNSOP is suited
to address. One of my concerns of using privacy to set up the use case.
92 ##2. Qname minimisation
113 ## To do such minimisation, the resolver needs to know the zone cut
114 ## [RFC2181]. There is not a zone cut at every label boundary. If we
115 ## take the name www.foo.bar.example, it is possible that there is a
116 ## zone cut between "foo" and "bar" but not between "bar" and
"example".
117 ## So, assuming the resolver already knows the name servers of
.example,
118 ## when it receives the query "What is the AAAA record of
119 ## www.foo.bar.example", it does not always know if the request should
120 ## be sent to the name servers of bar.example or to those of example.
121 ## [RFC2181] suggests a method to find the zone cut (section 6), so
122 ## resolvers may try it.
This sounds like something related to work attempted in the DBound mail list,
work which hasn't crystalized into anything (yet). If a client could know a
priori where the zone, err, server cuts were in the "path" of a domain name,
localizing the query and minimizing the number of queries could be plausible.
128 ## It can be noted that minimising the amount of data sent also
129 ## partially addresses the case of a wire sniffer, not just the case
of
130 ## privacy invasion by the servers.
Before using arguments like this, terms such as "privacy invasion" need to be
defined.
132 ## One should note that the behaviour suggested here (minimising the
133 ## amount of data sent in qnames) is NOT forbidden by the [RFC1034]
134 ## (section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname
135 ## to the authoritative name server is a tradition, not a protocol
136 ## requirment.
I tend to disagree with that. While "requirement" is a strong word, in the days
before the global public DNS settled on a top-level domain/second-level domain
data model and in some places still today, the need for the full qname was to
be as opportunistic as possible. And I don't mean "opporunistic security", I
mean to be as efficient in finding an answer.
In particular, during the days when COM and NET would perform a "hybrid"
response
to a query for an address of a server that was in the glue - the hybird being
a partially cache answer (no AA bit) and partially a referral (authority
section indicated the more authoritative location), the full qname was needed.
This hybrid wasn't a registry just being "nice" it was related to old code not
being able to handle some referral chains (specifically into the in-addr.arpa
subtree). Not only is the buggy code (largely gone), signing COM and NET forced
the end of the hybrid responses.
Effectively, yes, not a requirement, but more than a tradition.
138 ##3. Operational considerations
139 ##
143 ## qtypes). On the other hand, it will decrease their legal
144 ## responsability, in many cases.
How any statement be made about "legal responsibility" if it is never defined?
149 ## queries but send REFUSED to queries "NS www.ratp.fr". This
behaviour
150 ## is a gross protocol violation and there is no need to stop
improving
This ignores that local policy trumps all others in the DNS. The recipient of a
query has no duty to respond to it. There's an expectation on the sender side
and if the recipient decides to follow the protocol they will respond. But
following a tradition of "there's no protocol police" we can't say there is
a violation, much less a "gross" one.
I will say that once I was enraged by servers that did not respond to every
query.
It was explained to me that some implementers feel out of target responses are
threats. Eventually I became convinced that it was thier perogative to answer
as they see fit and adjusted my operational probes accordingly (looking for lame
servers). And then RRL came about ... ;) A server has the right to withhold
answers - and a duty when you consider that we live with a network where people
shout for BCP 38 deployment.
153 ## need to send them NS requests). Anyway, such setup breaks many
154 ## things (besides qname minimisation), it breaks negative answers as
155 ## the servers don't return the correct SOA. It also breaks anything
156 ## that depends on NS and SOA records existing at the top of the zone.
The SOA is "just a convention" too (in negative answers) and if the zone does
not make use of NOTIFY/AXFR/IXFR, the SOA serial number doesn't matter either.
172 ## Other strange and illegal practice may pose a problem: for
instance,
At this point the current proposal seems more and more like a bad idea.
(Once again - illegal practice?)
This is getting into hacking at one part of the architecture to spite another
hack at the architecture.
210 ##4. Other advantages
211 ##
228 ## priori that neither B.CORP or C.CORP could exist. Thus in this
229 ## common case the total number of upstream queries under query
230 ## minimisation would be counter-intuitively less than the number of
231 ## queries under the traditional iteration (as described in the DNS
232 ## standard).
With DNSSEC, we'd get that anyway. Let's face it, worrying about queries just
doesn't matter. We know that in practice.
239 ##6. Acknowledgments
240 ##
241 ## Thanks to Olaf Kolkman for the original idea.
No need to throw him under the bus first.
292 ##Appendix A. An algorithm to find the zone cut
It's not the zone cut that matters, it's what zones the server answers that
matters._______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
