Re: [DNSOP] DNS privacy : now at least two drafts
In message 87y50auqqf@mid.deneb.enyo.de, Florian Weimer writes: * Mark Andrews: Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has probably no practical consequences. Most resolvers do not make NS queries, and some authoritative servers do not return useful data (or any data at all). So using NS queries for zone cut discovery does not work reliably. Any resolver that is DNSSEC aware will make NS queries (whether validating or not). Really? Where is this mentioned in the protocol RFCs? RFC 3658 2.2.1.2. Special processing when child and an ancestor share nameserver Nameservers that fail to handle NS queries are broken. More NS queries would be good for the overall health of the DNS as it would flush out the broken servers. Sure, but in practice, no one wants to be the person who exerts this perssure on zone publishers. -- 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] DNS privacy : now at least two drafts
* Mark Andrews: In message 87y50auqqf@mid.deneb.enyo.de, Florian Weimer writes: * Mark Andrews: Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has probably no practical consequences. Most resolvers do not make NS queries, and some authoritative servers do not return useful data (or any data at all). So using NS queries for zone cut discovery does not work reliably. Any resolver that is DNSSEC aware will make NS queries (whether validating or not). Really? Where is this mentioned in the protocol RFCs? RFC 3658 2.2.1.2. Special processing when child and an ancestor share nameserver I think this section is about DS queries, not NS queries. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
In message 87a9coiyqc@mid.deneb.enyo.de, Florian Weimer writes: * Mark Andrews: In message 87y50auqqf@mid.deneb.enyo.de, Florian Weimer writes: * Mark Andrews: Another note is that the answer to the NS query, unlike the referra l sent when the question is a full qname, is in the Answer section, n ot in the Authoritative section. It has probably no practical consequences. Most resolvers do not make NS queries, and some authoritative servers do not return useful data (or any data at all). So using NS queries for zone cut discovery does not work reliably. Any resolver that is DNSSEC aware will make NS queries (whether validating or not). Really? Where is this mentioned in the protocol RFCs? RFC 3658 2.2.1.2. Special processing when child and an ancestor share nameserver I think this section is about DS queries, not NS queries. You need to discover where to send the DS queries. That means discovering the immediate parent zone cut. The usual and suggested way is to make NS queries with the left most label stripped. 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] DNS privacy : now at least two drafts
* Florian Weimer: There is another privacy-enhancing approach that is not mentioned in the draft: defensive delegations. For example, with current resolver behavior, the lack of a delegation for 1.E164.ARPA means that queries under that tree are sent to the E164.ARPA servers, which are scattered around the globe. With a delegation, the delegation would be cached and queries could be kept locally in the region. And another one: If you make your queries against a local copy of the DNS tree (which has been made irrespective of future demand), then nobody else will now which DNS records you are intersted in. This approach obviously weighs query privacy over database protection (whether as someone's intellectual property or with regards to domain owner privacy). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Mark Andrews: Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has probably no practical consequences. Most resolvers do not make NS queries, and some authoritative servers do not return useful data (or any data at all). So using NS queries for zone cut discovery does not work reliably. Any resolver that is DNSSEC aware will make NS queries (whether validating or not). Really? Where is this mentioned in the protocol RFCs? Nameservers that fail to handle NS queries are broken. More NS queries would be good for the overall health of the DNS as it would flush out the broken servers. Sure, but in practice, no one wants to be the person who exerts this perssure on zone publishers. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
In message 87fvmsd0nk@mid.deneb.enyo.de, Florian Weimer writes: * Stephane Bortzmeyer: On Sat, Mar 08, 2014 at 06:07:48PM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 17 lines which said: It is. Section 2.2.2 Can you quote it here? 2.2.2. In the authoritative name servers Ahhh, this section heading is wrong, the section is actually discussing resolver. The text doesn't explicitly mention minimization, either. :) A possible solution would be to minimize the amount of data sent from the resolver. When a resolver receives the query What is the record for www.example.com?, it sends to the root (assuming a cold resolver, whose cache is empty) the very same question. Sending What are the NS records for .com? would be sufficient (since it will be the answer from the root anyway). To do so would be compatible with the current DNS system and therefore could be deployable, since it is an unilateral change to the resolvers. There are some odd configurations out there where a query for www.foo.bar.example/IN/A returns data, but a query for foo.bar.example/IN/A returns NXDOMAIN. So it is backwards-compatible per specification, but a bit thorny to implement in practice. RFC 2535 said there were no names between NXT owner and the next name leading to a change in behaviour from RFC 103[45] for empty non terminals in the range (NXDOMAIN rather than NODATA). RFC 4034 corrected this to say the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset which handles empty non terminal as NODATA and is consistent with RFC 103[45]. [RFC2181] suggests an algorithm to find the zone cut, so resolvers may try it. Do you refer to explicit NS queries? Note that DNSSEC-validating resolvers already have access to this information, since they have to find the zone cut (the DNSKEY record set is just below, the DS record set just above). But they don't obtain this information in a privacy-enhancing way. One should note that the behaviour suggested here (minimizing the amount of data sent in qnames) is NOT forbidden by the [RFC1034] (section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname to the authoritative name server is a tradition, not a protocol requirment. ^ Typo. Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has probably no practical consequences. Most resolvers do not make NS queries, and some authoritative servers do not return useful data (or any data at all). So using NS queries for zone cut discovery does not work reliably. Any resolver that is DNSSEC aware will make NS queries (whether validating or not). They do not do so very often as the configurations that require them to be made are rare. The majority of recursive servers in the world are DNSSEC aware. Nameservers that fail to handle NS queries are broken. More NS queries would be good for the overall health of the DNS as it would flush out the broken servers. ___ 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] DNS privacy : now at least two drafts
* Stephane Bortzmeyer: I just posted a new version of the DNS privacy draft, draft-bortzmeyer-dnsop-dns-privacy-01. The most important difference is that it is now split in two, one pure problem statement, draft-bortzmeyer-dnsop-dns-privacy and an exploration of possible solutions, draft-bortzmeyer-dnsop-privacy-sol. The first one seems to me (and to the AD) well adapted to dnsop. The second one mixes solutions that may be in the realm of dnsop (such as qname minimization) and solutions that would require a new WG (such as encryption of DNS traffic). The -sol draft mentions QNAME minimization without defining the term. Is this about sending only as many labels as required to obtain a delegation from an authoritative server? There is another privacy-enhancing approach that is not mentioned in the draft: defensive delegations. For example, with current resolver behavior, the lack of a delegation for 1.E164.ARPA means that queries under that tree are sent to the E164.ARPA servers, which are scattered around the globe. With a delegation, the delegation would be cached and queries could be kept locally in the region. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
On Sat, Mar 08, 2014 at 05:50:55PM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 22 lines which said: The -sol draft mentions QNAME minimization without defining the term. It is. Section 2.2.2 I'll add some more cross-references to make it easier to find it. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Stephane Bortzmeyer: On Sat, Mar 08, 2014 at 05:50:55PM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 22 lines which said: The -sol draft mentions QNAME minimization without defining the term. It is. Section 2.2.2 Can you quote it here? It seems to be missing from the 00 version, or I'm horribly confused. I'll add some more cross-references to make it easier to find it. Thanks. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
On Sat, Mar 08, 2014 at 06:07:48PM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 17 lines which said: It is. Section 2.2.2 Can you quote it here? 2.2.2. In the authoritative name servers A possible solution would be to minimize the amount of data sent from the resolver. When a resolver receives the query What is the record for www.example.com?, it sends to the root (assuming a cold resolver, whose cache is empty) the very same question. Sending What are the NS records for .com? would be sufficient (since it will be the answer from the root anyway). To do so would be compatible with the current DNS system and therefore could be deployable, since it is an unilateral change to the resolvers. To do so, the resolver needs to know the zone cut [RFC2181]. There is not a zone cut at every label boundary. If we take the name www.foo.bar.example, it is possible that there is a zone cut between foo and bar but not between bar and example. So, assuming the resolver already knows the name servers of .example, when it receives the query What is the record of www.foo.bar.example, it does not always know if the request should be sent to the name servers of bar.example or to those of example. [RFC2181] suggests an algorithm to find the zone cut, so resolvers may try it. Note that DNSSEC-validating resolvers already have access to this information, since they have to find the zone cut (the DNSKEY record set is just below, the DS record set just above). It can be noted that minimizing the amount of data sent also partially addresses the case of a wire sniffer. One should note that the behaviour suggested here (minimizing the amount of data sent in qnames) is NOT forbidden by the [RFC1034] (section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname to the authoritative name server is a tradition, not a protocol requirment. Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has probably no practical consequences. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Stephane Bortzmeyer: On Sat, Mar 08, 2014 at 06:07:48PM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 17 lines which said: It is. Section 2.2.2 Can you quote it here? 2.2.2. In the authoritative name servers Ahhh, this section heading is wrong, the section is actually discussing resolver. The text doesn't explicitly mention minimization, either. :) A possible solution would be to minimize the amount of data sent from the resolver. When a resolver receives the query What is the record for www.example.com?, it sends to the root (assuming a cold resolver, whose cache is empty) the very same question. Sending What are the NS records for .com? would be sufficient (since it will be the answer from the root anyway). To do so would be compatible with the current DNS system and therefore could be deployable, since it is an unilateral change to the resolvers. There are some odd configurations out there where a query for www.foo.bar.example/IN/A returns data, but a query for foo.bar.example/IN/A returns NXDOMAIN. So it is backwards-compatible per specification, but a bit thorny to implement in practice. [RFC2181] suggests an algorithm to find the zone cut, so resolvers may try it. Do you refer to explicit NS queries? Note that DNSSEC-validating resolvers already have access to this information, since they have to find the zone cut (the DNSKEY record set is just below, the DS record set just above). But they don't obtain this information in a privacy-enhancing way. One should note that the behaviour suggested here (minimizing the amount of data sent in qnames) is NOT forbidden by the [RFC1034] (section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname to the authoritative name server is a tradition, not a protocol requirment. ^ Typo. Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has probably no practical consequences. Most resolvers do not make NS queries, and some authoritative servers do not return useful data (or any data at all). So using NS queries for zone cut discovery does not work reliably. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
