Re: [DNSOP] Possible slower response with minimization
Paul Vixie wrote: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. i disagree with this. broken implementations who emit NXDOMAIN for empty non-terminals cannot be used as an excuse not to develop and deploy correct protocol and software enhancements. My suggestion is just for robust minimization without sacrificing the correctness as NXDOMAIN for full domain name is interpreted as is. the internet has hundreds of years to run yet, and these broken implementations are (a) shrinking not growing, and (b) subject to rapid replacement when they start to encounter problems with correct enhancements to their habitat. How widely is EDNS deployed? IIRC, about 20 years ago, you said 2KB DNS message of DNSSEC was not a problem because EDNS takes care of it. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Paul Vixie wrote: the internet has hundreds of years to run yet, and these broken implementations are (a) shrinking not growing, and (b) subject to rapid replacement when they start to encounter problems with correct enhancements to their habitat. Hh. Hahahah. HAHAHA. MUHAAHHAHAHAHAHAHAHA. Sorry, where was I. Oh yeah. There is far too much bad undergrowth on the Internet, of old code and old systems that it still works and is never upgraded. For example, we see plenty of instances of dnsmasq which are so old that the version date is before the developer started keeping a changelog. Short of setting deliberate viral brush fires designed to brick old devices, we're stuck with them and need to plan around them. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Nicholas Weaver mailto:nwea...@icsi.berkeley.edu Thursday, November 06, 2014 7:55 AM ... Short of setting deliberate viral brush fires designed to brick old devices, we're stuck with them and need to plan around them. BIND once had a 100% market share, and did a number of things wrong, which Win/NT's DNS implementation had to work around. rather than documenting the current behaviour and telling others to plan around it, we fixed BIND. similarly, many DNS servers are behind low-grade IP firewalls who pass udp/53 but not frags, thus keeping EDNS from working. so, every EDNS implementation has complicated fallback, and DNSSEC won't work on many data paths. nevertheless we call those firewalls wrong and keep trying to get DNSSEC (and therefore EDNS) working. so, there are cases where you have to plan for an extremely long tail, and other cases where you plan for a rapid transition. implementations who think NXDOMAIN is valid for empty-nonterminal nodes are known-broken, and they are on our short list to fix, and we're going to ignore them and let their operators feel the pain. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
In message 545b54d3.50...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Paul Vixie wrote: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. i disagree with this. broken implementations who emit NXDOMAIN for empty non-terminals cannot be used as an excuse not to develop and deploy correct protocol and software enhancements. My suggestion is just for robust minimization without sacrificing the correctness as NXDOMAIN for full domain name is interpreted as is. the internet has hundreds of years to run yet, and these broken implementations are (a) shrinking not growing, and (b) subject to rapid replacement when they start to encounter problems with correct enhancements to their habitat. How widely is EDNS deployed? http://users.isc.org/~marka/ts.html IIRC, about 20 years ago, you said 2KB DNS message of DNSSEC was not a problem because EDNS takes care of it. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Mon, Oct 27, 2014 at 06:09:49PM -0400, Warren Kumari war...@kumari.net wrote a message of 69 lines which said: wkumari@vimes:~$ dig ns +noall +comments com.akadns.net [Example of a nameservcer replying NXDOMAIN for an ENT.] Er... wouldn't this break with qnm? Depending on how it is implemented, yes, may be, or no. Remember that QNAME m12n is not a protocol but a general principle, that different resolvers may implement slightly differently. It has been a long day, so perhaps I'm missing something as well... The issue is described in draft-vixie-dnsext-resimprove-00 (section 3) and partially in draft-ietf-dnsop-qname-minimisation-00 (section 3). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Wed, Oct 29, 2014 at 10:53 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Oct 27, 2014 at 06:09:49PM -0400, Warren Kumari war...@kumari.net wrote a message of 69 lines which said: wkumari@vimes:~$ dig ns +noall +comments com.akadns.net [Example of a nameservcer replying NXDOMAIN for an ENT.] Yes, I'm just surprised that Akamai suffers from it. Er... wouldn't this break with qnm? Depending on how it is implemented, yes, may be, or no. Remember that QNAME m12n is not a protocol but a general principle, that different resolvers may implement slightly differently. It has been a long day, so perhaps I'm missing something as well... The issue is described in draft-vixie-dnsext-resimprove-00 (section 3) and partially in draft-ietf-dnsop-qname-minimisation-00 (section 3). Yup. Just expected better from akamai. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Mon, Oct 27, 2014 at 03:44:12PM -0700, Doug Barton do...@dougbarton.us wrote a message of 86 lines which said: We already have projects that have bravely gone into these details ... https://wiki.mozilla.org/Public_Suffix_List comes to mind of course. [See also the DBOUND effort https://www.ietf.org/mailman/listinfo/dbound, which seems currently dead.] Using that kind of intelligence would go a long way towards reducing the complaints about qnm adding inefficiency. My personal feeling is that it is not worth the extra complication (and dependance towards a far-from-perfect external list). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Warren Kumari: Stephane Bortzmeyer bortzme...@nic.fr: Warren Kumari war...@kumari.net wrote wkumari@vimes:~$ dig ns +noall +comments com.akadns.net [Example of a nameservcer replying NXDOMAIN for an ENT.] Yes, I'm just surprised that Akamai suffers from it. It is definitely considered a bug and has had a CR open for it for almost 10 years, but since there has been no noticeable, practical operational impact it has never had any time spent on addressing it. qname-minimisation would change that of course, and personally I don't mind. It's nice to finally close out CRs from the long long ago. Incidentally, the logic of how a name is resolved by Akamai's nameservers varies depending on the type of service the zone is providing. This bug is particular to only one type of service. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Warren Kumari war...@kumari.net wrote: Outside this list how common are hierarchies more than 4 levels deep in practice? Surprisingly enough, not an insignificant number -- but this is mitigated by what the queries are (see below) Large organizations in countries with special-purpose 2LDs easily get quite long, e.g. www.pubs.sp.phy.cam.ac.uk, and that involves only four zones so it's a good example of a situation where qname minimization would do badly. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Sat, Oct 25, 2014 at 2:08 PM, Paul Vixie p...@redbarn.org wrote: Stephane Bortzmeyer bortzme...@nic.fr Saturday, October 25, 2014 9:05 AM On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp mo...@necom830.hpcl.titech.ac.jp wrote a message of 27 lines which said: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. i disagree with this. broken implementations who emit NXDOMAIN for empty non-terminals cannot be used as an excuse not to develop and deploy correct protocol and software enhancements. the internet has hundreds of years to run yet, and these broken implementations are (a) shrinking not growing, and (b) subject to rapid replacement when they start to encounter problems with correct enhancements to their habitat. I agree with the sentiment. But there is a way to get the implementations to converge and that is to build something on top that consumes DNS Authoritative date and makes particular assumptions that is widely enough used to create an incentive. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
In message CAMm+Lwh=75oXwbubuB19rYhhMbfO=geapes_wes8xbyvdjn...@mail.gmail.com, Phillip Hallam-Baker writes: On Sat, Oct 25, 2014 at 2:08 PM, Paul Vixie p...@redbarn.org wrote: Stephane Bortzmeyer bortzme...@nic.fr Saturday, October 25, 2014 9:05 AM On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp mo...@necom830.hpcl.titech.ac.jp wrote a message of 27 lines which said: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. i disagree with this. broken implementations who emit NXDOMAIN for empty non-terminals cannot be used as an excuse not to develop and deploy correct protocol and software enhancements. the internet has hundreds of years to run yet, and these broken implementations are (a) shrinking not growing, and (b) subject to rapid replacement when they start to encounter problems with correct enhancements to their habitat. I agree with the sentiment. But there is a way to get the implementations to converge and that is to build something on top that consumes DNS Authoritative date and makes particular assumptions that is widely enough used to create an incentive. People will learn. There were nameservers that returned NXDOMAIN to queries. These have basically gone as they caused operational problems There are nameservers that return NXDOMAIN to unknown EDNS options. See the bind-users archives. These will go as people report them. There are nameservers that return NXDOMAIN to empty non terminals. These too will go as soon as that start causing operational problems. At the moment NXDOMAIN and NODATA don't cause a issue for most applications. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Sat, Oct 25, 2014 at 11:57 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Oct 20, 2014 at 05:26:29PM -0400, Phillip Hallam-Baker hal...@gmail.com wrote a message of 74 lines which said: If we are going there, I would want to know how common the configurations are. Yes, actual numbers seen from a real resolver would be useful. Outside this list how common are hierarchies more than 4 levels deep in practice? Surprisingly enough, not an insignificant number -- but this is mitigated by what the queries are (see below) ip6.arpa, and other infrastructure domains? There is a long tail, but: ~51% of lookups are of length 3 (www.example.com) ~23% of lookups are of length 5 (this was surprising to me, but is largely dominated by Akamai - www.example.com.akadns.net) ~15% of lookups are of length 4 (usually service.something.largecompany.com) This means that lengths 3, 4, 5 account for ~89% of lookups. If you include lengths of 1 and 2 you get 96% Many of these (like the akamai ones, .com, etc) look like they would cache every well... In the long tail there are the ip6.arpa, in-addr.arpa, some dnsbls and then a bunch of anti-virus / web-filter stuff (things like really long b64(?) encoded string.sophosxl.com or some opaque string.avts.mcafee.com), and some obviously broken queries www.www.www.www.www.www.www.www.www.cnn.com) So, while looking at this I stumbled across something, um, odd... wkumari@vimes:~$ dig ns +noall +comments apple.com.akadns.net ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 27395 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 'kay... wkumari@vimes:~$ dig ns +noall +comments com.akadns.net ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 3341 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 Er... wouldn't this break with qnm? (obviously fixable, but an interesting data point). It has been a long day, so perhaps I'm missing something as well... W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On 10/27/14 3:09 PM, Warren Kumari wrote: On Sat, Oct 25, 2014 at 11:57 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Oct 20, 2014 at 05:26:29PM -0400, Phillip Hallam-Baker hal...@gmail.com wrote a message of 74 lines which said: If we are going there, I would want to know how common the configurations are. Yes, actual numbers seen from a real resolver would be useful. Outside this list how common are hierarchies more than 4 levels deep in practice? Surprisingly enough, not an insignificant number -- but this is mitigated by what the queries are (see below) ip6.arpa, and other infrastructure domains? There is a long tail, but: ~51% of lookups are of length 3 (www.example.com) ~23% of lookups are of length 5 (this was surprising to me, but is largely dominated by Akamai - www.example.com.akadns.net) ~15% of lookups are of length 4 (usually service.something.largecompany.com) This means that lengths 3, 4, 5 account for ~89% of lookups. If you include lengths of 1 and 2 you get 96% Many of these (like the akamai ones, .com, etc) look like they would cache every well... In the long tail there are the ip6.arpa, in-addr.arpa, some dnsbls and then a bunch of anti-virus / web-filter stuff (things like really long b64(?) encoded string.sophosxl.com or some opaque string.avts.mcafee.com), and some obviously broken queries www.www.www.www.www.www.www.www.www.cnn.com) So, while looking at this I stumbled across something, um, odd... wkumari@vimes:~$ dig ns +noall +comments apple.com.akadns.net ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 27395 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 'kay... wkumari@vimes:~$ dig ns +noall +comments com.akadns.net ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 3341 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 Er... wouldn't this break with qnm? (obviously fixable, but an interesting data point). It has been a long day, so perhaps I'm missing something as well... Yeah, I was thinking about this same concept over the weekend. Minimalization is definitely a privacy benefit when dealing at the root and TLD levels, and fortunately those are the easiest cases to detect. :) I think it's less useful when you've navigated into the domain-holder's space. As y'all know that border is harder to determine in the ccTLD space. We already have projects that have bravely gone into these details ... https://wiki.mozilla.org/Public_Suffix_List comes to mind of course. It shouldn't be too difficult to code using that information as a third alternative to on or off for qnm. Using that kind of intelligence would go a long way towards reducing the complaints about qnm adding inefficiency. In fact unless I'm missing something it would largely eliminate them. There is no benefit to sending the whole query to the root or TLD servers, and lots of privacy benefits for not doing so. OTOH, there is a lot of benefit to sending the whole query to the domain holder's servers, and minimal privacy negatives. Sounds like a win-win to me. Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
In message CAHw9_iLzKsqSWLV+BdcG_R-d9Jd-=1sc+srzhv8iwd_5tdo...@mail.gmail.com, Warren K umari writes: On Sat, Oct 25, 2014 at 11:57 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Oct 20, 2014 at 05:26:29PM -0400, Phillip Hallam-Baker hal...@gmail.com wrote a message of 74 lines which said: If we are going there, I would want to know how common the configurations are. Yes, actual numbers seen from a real resolver would be useful. Outside this list how common are hierarchies more than 4 levels deep in practice? Surprisingly enough, not an insignificant number -- but this is mitigated by what the queries are (see below) ip6.arpa, and other infrastructure domains? There is a long tail, but: ~51% of lookups are of length 3 (www.example.com) ~23% of lookups are of length 5 (this was surprising to me, but is largely dominated by Akamai - www.example.com.akadns.net) ~15% of lookups are of length 4 (usually service.something.largecompany.com) This means that lengths 3, 4, 5 account for ~89% of lookups. If you include lengths of 1 and 2 you get 96% Many of these (like the akamai ones, .com, etc) look like they would cache every well... In the long tail there are the ip6.arpa, in-addr.arpa, some dnsbls and then a bunch of anti-virus / web-filter stuff (things like really long b64(?) encoded string.sophosxl.com or some opaque string.avts.mcafee.com), and some obviously broken queries www.www.www.www.www.www.www.www.www.cnn.com) So, while looking at this I stumbled across something, um, odd... wkumari@vimes:~$ dig ns +noall +comments apple.com.akadns.net ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 27395 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 'kay... wkumari@vimes:~$ dig ns +noall +comments com.akadns.net ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 3341 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 Er... wouldn't this break with qnm? (obviously fixable, but an interesting data point). It has been a long day, so perhaps I'm missing something as well... Yes, there are lots of broken nameservers out there. This doesn't have to remain the case. Audit all the servers for the zone delegated from TLD and SLD infrastructure zones and with and without www prepended. Report the errors found and request that they contact their nameserver / firewall vendor for a fix. Repeat 3 months later with a warning that the delegation will be removed if the issue is not fixed for those contacted on the previous run. Repeat 3 months late and remove all delegations which have had the 2 previous message. Repeat at 3 monthly interval to catch new instances. Unlike bad delegations. You don't get many regressions. Once a nameserver is fixed it tends to stay fixed. This gives them 6 months to deploy a fix. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Mon, Oct 20, 2014 at 05:26:29PM -0400, Phillip Hallam-Baker hal...@gmail.com wrote a message of 74 lines which said: If we are going there, I would want to know how common the configurations are. Yes, actual numbers seen from a real resolver would be useful. Outside this list how common are hierarchies more than 4 levels deep in practice? ip6.arpa, and other infrastructure domains? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Mon, Oct 20, 2014 at 05:03:19PM -0400, Bob Harold rharo...@umich.edu wrote a message of 135 lines which said: With minimization: Besides the fact that it is true only for a cold cache (as mentioned by others in this thread), it depends on how minimisation is implemented. One possible way is aggressive minimisation (the algorithm you describe), but another one is lazy minimisation (sending the full qname at the beginning and learning the zone cuts, then switching to minimisation). If it is realistic (I did not analyze the idea in detail), lazy minimisation will bring less privacy but will improve performances. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote a message of 27 lines which said: As the choice between privacy and latency is on resolver side, moderate latency is not harmful. I fully agree. Qname minimisation is an _unilateral_ decision. Any resolver can make its own trade-off, depending on its administrator's choices. dataminimisation: on|off (programmers, pick the best default value) Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. Full agreement again and I suggest everyone to consider draft-vixie-dnsext-resimprove-00, section 3 (an useful thing for qname minimisation but also against current random qnames attacks https://indico.dns-oarc.net//contributionDisplay.py?contribId=37sessionId=3confId=20). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Stephane Bortzmeyer mailto:bortzme...@nic.fr Saturday, October 25, 2014 9:05 AM On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote a message of 27 lines which said: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. i disagree with this. broken implementations who emit NXDOMAIN for empty non-terminals cannot be used as an excuse not to develop and deploy correct protocol and software enhancements. the internet has hundreds of years to run yet, and these broken implementations are (a) shrinking not growing, and (b) subject to rapid replacement when they start to encounter problems with correct enhancements to their habitat. Full agreement again and I suggest everyone to consider draft-vixie-dnsext-resimprove-00, section 3 (an useful thing for qname minimisation but also against current random qnames attacks https://indico.dns-oarc.net//contributionDisplay.py?contribId=37sessionId=3confId=20). stephane, i believe you misunderstood the sense of ohta-san's remarks. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Sat, Oct 25, 2014 at 06:05:16PM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 24 lines which said: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. Full agreement again Paul Vixie was right, I've read your sentence too fast. I focused on the broken implementation part (on which we agree, these implementations are awfully broken) and missed the meaning of the double negation. So, to rephrase it, my opinion is: NXDOMAIN returned by some broken implementation to empty non-terminals is a bug. A NXDOMAIN MUST be interpreted as the node in the domain tree, AND ALL ITS SUBNODES, do not exist. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Ray Bellis wrote: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. Can we name and shame these broken implementations? I don't know about a specific example. But, considering that people here was having lengthy debates on how should the response to empty non-terminals until I pointed out relevant part of rfc1034 means there should have been, and, more importantly, will again be, some. It would be a massive shame if this important and useful clarification to DNS semantics couldn't be used just because of a few broken implementations. It is clearly specified in rfc1034: The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On 21 Oct 2014, at 11:11, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: It is clearly specified in rfc1034: The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). That’s a matter of interpretation. To me, that _clearly_ indicates that the name exists (given that the “label” is a property of the node, which clearly does exists) and therefore that NXDOMAIN is inappropriate. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Adopt it. Then argue about it. I think it is worthwhile to talk about. IMHO it isn’t a protocol change, but a change to how a recursive element looks for an answer in the existing protocol. On Oct 20, 2014, at 17:30, Paul Vixie p...@redbarn.org wrote: there's a cart/horse proble in this thread. right now we're arguing whether to adopt it. if we adopt it then its goods and bads will become relevant. that said: Bob Harold Monday, October 20, 2014 2:03 PM I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle. i argue that caching will equalize these logic paths over a very short stretch of wall time. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Ray Bellis wrote: To me, that _clearly_ indicates that the name exists (given that the “label” is a property of the node, which clearly does exists) and therefore that NXDOMAIN is inappropriate. Yes, it is, even for those who debated a lot here without reading rfc1034 or those who read the rfc so long ago that they don't remember its content, but only after the text is presented to them. The problem is that, for those who don't fully understand/remember DNS, empty non terminals can be a pitfall with high probability, against which new proposals should be protected. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Possible slower response with minimization
I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle. Consider “www.host.group.department.example.com” where the company’s servers are authoritative for the zones: example.com department.example.com group.department.example.com Without minimization (typical today): 1. Query root for “www.host.group.department.example.com”, get list of “com” servers. 2. Query a com server for “www.host.group.department.example.com”, get list of “example.com” servers. 3. Query an example.com server for “www.host.group.department.example.com”, get answer. With minimization: 1. Query root for “com”, get list of “com” servers. 2. Query a com server for “example.com”, get list of “example.com” servers. 3. Query an example.com server for “department.example.com”, get list of “ department.example.com” servers (which happens to be the same as the list of “example.com” servers). 4. Query a “department.example.com” server (likely the same server as step 3) for “group.department.example.com”, get list of “ group.department.example.com” servers. 5. Query a “group.department.example.com” server for “host.group.example.com”, get probably just an A and/or record, indicating there is no zone cut at that level. 6. Query a “group.department.example.com” server for “ www.host.group.department.example.com”, get answer. Note that it takes twice as many queries, and each depends on the previous, so it is twice as many round trips. I realize that caching will reduce the extra queries in many cases, but can we estimate the impact of this somehow, to determine if it is significant? -- Bob Harold DNS hostmaster, University of Michigan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
I think part of the work on qname-minimization will spend some time studying performance, as well as operational issues as Peter brought up. It could very well be that what Peter pointed out will be true and there are operational issues that could cause acceptance. But part of this work will be to understand and document these effects, correct? tim (finally back home and catching up) On 10/20/14 5:03 PM, Bob Harold wrote: I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle. Consider “www.host.group.department.example.com http://www.host.group.department.example.com” where the company’s servers are authoritative for the zones: example.com http://example.com department.example.com http://department.example.com group.department.example.com http://group.department.example.com Without minimization (typical today): 1. Query root for “www.host.group.department.example.com http://www.host.group.department.example.com”, get list of “com” servers. 2. Query a com server for “www.host.group.department.example.com http://www.host.group.department.example.com”, get list of “example.com http://example.com” servers. 3. Query an example.com http://example.com server for “www.host.group.department.example.com http://www.host.group.department.example.com”, get answer. With minimization: 1. Query root for “com”, get list of “com” servers. 2. Query a com server for “example.com http://example.com”, get list of “example.com http://example.com” servers. 3. Query an example.com http://example.com server for “department.example.com http://department.example.com”, get list of “department.example.com http://department.example.com” servers (which happens to be the same as the list of “example.com http://example.com” servers). 4. Query a “department.example.com http://department.example.com” server (likely the same server as step 3) for “group.department.example.com http://group.department.example.com”, get list of “group.department.example.com http://group.department.example.com” servers. 5. Query a “group.department.example.com http://group.department.example.com” server for “host.group.example.com http://host.group.example.com”, get probably just an A and/or record, indicating there is no zone cut at that level. 6. Query a “group.department.example.com http://group.department.example.com” server for “www.host.group.department.example.com http://www.host.group.department.example.com”, get answer. Note that it takes twice as many queries, and each depends on the previous, so it is twice as many round trips. I realize that caching will reduce the extra queries in many cases, but can we estimate the impact of this somehow, to determine if it is significant? -- Bob Harold DNS hostmaster, University of Michigan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
If we are going there, I would want to know how common the configurations are. There is zero additional overhead for www.example.com Outside this list how common are hierarchies more than 4 levels deep in practice? This isn't a functionality issue, it's purely performance. So I suggest a 5% minimum occurrence threshold for considering any corner cases. And made up examples don't count Sent from my difference engine On Oct 20, 2014, at 5:06 PM, Tim Wicinski tjw.i...@gmail.com wrote: I think part of the work on qname-minimization will spend some time studying performance, as well as operational issues as Peter brought up. It could very well be that what Peter pointed out will be true and there are operational issues that could cause acceptance. But part of this work will be to understand and document these effects, correct? tim (finally back home and catching up) On 10/20/14 5:03 PM, Bob Harold wrote: I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle. Consider “www.host.group.department.example.com http://www.host.group.department.example.com” where the company’s servers are authoritative for the zones: example.com http://example.com department.example.com http://department.example.com group.department.example.com http://group.department.example.com Without minimization (typical today): 1. Query root for “www.host.group.department.example.com http://www.host.group.department.example.com”, get list of “com” servers. 2. Query a com server for “www.host.group.department.example.com http://www.host.group.department.example.com”, get list of “example.com http://example.com” servers. 3. Query an example.com http://example.com server for “www.host.group.department.example.com http://www.host.group.department.example.com”, get answer. With minimization: 1. Query root for “com”, get list of “com” servers. 2. Query a com server for “example.com http://example.com”, get list of “example.com http://example.com” servers. 3. Query an example.com http://example.com server for “department.example.com http://department.example.com”, get list of “department.example.com http://department.example.com” servers (which happens to be the same as the list of “example.com http://example.com” servers). 4. Query a “department.example.com http://department.example.com” server (likely the same server as step 3) for “group.department.example.com http://group.department.example.com”, get list of “group.department.example.com http://group.department.example.com” servers. 5. Query a “group.department.example.com http://group.department.example.com” server for “host.group.example.com http://host.group.example.com”, get probably just an A and/or record, indicating there is no zone cut at that level. 6. Query a “group.department.example.com http://group.department.example.com” server for “www.host.group.department.example.com http://www.host.group.department.example.com”, get answer. Note that it takes twice as many queries, and each depends on the previous, so it is twice as many round trips. I realize that caching will reduce the extra queries in many cases, but can we estimate the impact of this somehow, to determine if it is significant? -- Bob Harold DNS hostmaster, University of Michigan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
there's a cart/horse proble in this thread. right now we're arguing whether to adopt it. if we adopt it then its goods and bads will become relevant. that said: Bob Harold mailto:rharo...@umich.edu Monday, October 20, 2014 2:03 PM I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle. i argue that caching will equalize these logic paths over a very short stretch of wall time. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On 10/20/14 2:03 PM, Bob Harold wrote: I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle. Consider “www.host.group.department.example.com Your analysis is correct, but only for a cold cache. Once the resolver has cached the NS records for group.department.example.com the penalty no longer applies. One thing that may be a worthwhile consideration though is a way to cache that host.group is not a zone cut. That would further reduce the penalty. FWIW, I also have some concerns about empty non-terminals, but none of that slows me down in terms of supporting WG adoption. I think it's a worthy idea, and I'll do what I can to help. Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
