Some form of "optimization", perhaps? I too have been tempted to comment on the fact that there is no QNAME that is being "minimized" here (which would imply making it shorter; not the gist of the proposal at all).
If we're stuck on the term "minimization", make it clear that it's not the QNAME itself that's being "minimized", but the actual number of query transactions being minimized. Although "query-transaction volume minimization" is a bit of a mouthful... - Kevin From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Edward Lewis Sent: Thursday, October 30, 2014 3:29 PM To: dnsop Cc: edlewis.subscri...@cox.net Subject: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt 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<http://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<http://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<http://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