Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
On Thu, Oct 30, 2014 at 07:42:02PM +, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote a message of 1087 lines which said: 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). I really do not understand you. With Qname minimisation, the Qname *will* be shorter. If we're stuck on the term minimization, make it clear that it's not the QNAME itself that's being minimized, -1 but the actual number of query transactions being minimized. -1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
On Thu, Oct 30, 2014 at 08:46:37PM +, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote a message of 19 lines which said: Isn't doing the minimum necessary to get the job done pretty much the definition of optimization (or, for that matter, efficiency)? Minimize means, basically, only to make small; whereas optimization or efficiency means to reduce something, relative to something else, for a particular purpose or to achieve a particular end. Minimisation did not came out of the blue. It is a very common term in privacy work and it is used in RFC 6973 (normative reference for draft-ietf-dnsop-qname-minimisation-00), section 6.1. Let's not reinvent terminology. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
On Thu, Oct 30, 2014 at 05:02:21PM -0400, Andrew Sullivan a...@anvilwalrusden.com wrote a message of 21 lines which said: Ed's point is not wrong, however -- in one fairly natural meaning, the technique is actually query maximization. If one called it query disclosure minimization or something like that it'd be closer to describing what happens. As I said to Paul Vixie, the Internet-Draft says qname minimisation, not query minimisation. (There is one - just one - unfortunate occurrence of query minimisation in section 4, which will disappear in the next version.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
To clear up a few points. On Oct 31, 2014, at 7:08, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Thu, Oct 30, 2014 at 03:29:21PM -0400, Edward Lewis edlewis.subscri...@cox.net wrote a message of 526 lines which said: This sounds like something related to work attempted in the DBound mail list, Doug Barton suggested here to use Dbound-like techniques to optimize the work of a qname-minimising resolver. I personally don't think this small improvment would be worth the added complication and risks of staleness. I had in mind what Doug suggested. You say that not sending a SOA (when requested) is legal? A server may, at any time, return REFUSED. If you want to argue based on the RFCs: See RFC 1035, section 4.1.1. (Header section format), under RCODE, value 5 As far as not returning at all, that isn’t considered an option by the RFCs and protocol designers but is justified in my eyes under the reality of operations. 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. I disagree. When you want to resolve www.example.com with Qname m12n, knowing that example.com and com are on different sides of a zone cut is necessary. Knowing that the .com name servers also serve .net is useless. In this case the point was not made well. What I mean is for a name like this: www.localschool.K-12.city.county.province.ccTLD. : one name server might serve these zones: localschool.K-12.city.county.province.ccTLD. K-12.city.county.province.ccTLD. county.province.ccTLD. It’s not the zones that matter, but the set of zones on the server because if you ask this server the full name you will get to the result much faster than targeting the NS records of the zones. The DNS does not convey the zones on a server - it does report the servers a zone is to be found on (although we know that it might be inaccurate). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[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, 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 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
Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
the term query minimization appeals to me since each server, during iteration, sees the minimum substring of the qname needed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
Isn't doing the minimum necessary to get the job done pretty much the definition of optimization (or, for that matter, efficiency)? Minimize means, basically, only to make small; whereas optimization or efficiency means to reduce something, relative to something else, for a particular purpose or to achieve a particular end. _De_gustabis_. I don't have any strong preferences one way or the other, I just think shortening QNAMEs is an odd way to _introduce_ what the proposal purports to do. Once one comprehends the gist of the proposal, then it makes sense, but for historical reference and information retrieval, one wants to choose a title that most intuitively yet concisely describes what is/was proposed. - Kevin -Original Message- From: Paul Vixie [mailto:p...@redbarn.org] Sent: Thursday, October 30, 2014 4:35 PM To: Darcy Kevin (FCA) Cc: dnsop Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt the term query minimization appeals to me since each server, during iteration, sees the minimum substring of the qname needed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
On Thu, Oct 30, 2014 at 01:35:28PM -0700, Paul Vixie wrote: the term query minimization appeals to me since each server, during iteration, sees the minimum substring of the qname needed. Ed's point is not wrong, however -- in one fairly natural meaning, the technique is actually query maximization. If one called it query disclosure minimization or something like that it'd be closer to describing what happens. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
