Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
sanity check, someone? i believe that in dnssec, an empty non-terminal has a proof that the name exists, and a proof that there are no RR's. thus, vastly different from the signaling for NXDOMAIN. Yes, it does. With NSEC3 it is an explicit proof. With NSEC you have to read between the lines. NSEC3: see RFC5155 sections 7.1 and B.2.1. NSEC: if foo.example is an empty non-terminal, then there will exist an NSEC record such as "echo.example NSEC alpha.foo.example ..." - the ENT's name is part of the "next domain name". -- Sam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Mon, Oct 26, 2015 at 10:03 PM, Paul Vixie wrote: > On Monday, October 26, 2015 10:15:37 AM Ray Bellis wrote: > > On 26/10/2015 09:52, I wrote: > > > That's clear - what isn't perhaps, is what the RCODE should be, given > > > that this text is in a section with "Name Error" in its title. > > > > For what it's worth, I expect the answer to be NOERROR, but I think the > > text that lumps empty-non-terminals in with "name error" causes > > sufficient ambiguity and confusion that an errata may be in order. > > strong +1. > > names that don't exist can't have children. I agree, however I'm slightly amused that we are having this discussion in 2015. Is there anyone that is claiming that the response code for empty non-terminals should not be NOERROR. Yes, there are some CDNs and hosting providers that currently issue Name Error for empty non-terminals, but every one of them I've spoken to has positively acknowledged that this is a defect that they are planning to fix. If we need to provide a reference, RFC 4592, Section 2.2.2 has a pretty good treatment of empty non-terminals (updating 1034), that pretty definitively states that they exist, and thus their response code cannot be Name Error. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Monday, October 26, 2015 10:15:37 AM Ray Bellis wrote: > On 26/10/2015 09:52, I wrote: > > That's clear - what isn't perhaps, is what the RCODE should be, given > > that this text is in a section with "Name Error" in its title. > > For what it's worth, I expect the answer to be NOERROR, but I think the > text that lumps empty-non-terminals in with "name error" causes > sufficient ambiguity and confusion that an errata may be in order. strong +1. names that don't exist can't have children. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
In message <562ded9e.40...@bellis.me.uk>, Ray Bellis writes: > On 26/10/2015 06:39, Paul Vixie wrote: > > sanity check, someone? > > = > > > i believe that in dnssec, an empty non-terminal has a proof that the = > > > name exists, and a proof that there are no RR's. thus, vastly = > > > different from the signaling for NXDOMAIN. > > RFC 4035 =A73.1.3.2 appears to say differently :( > > The subject of that section is "Including NSEC RRs: Name Error > Response", and it says: > > "Note that this form of response includes cases in which SNAME > corresponds to an empty non-terminal name within the zone (a name > that is not the owner name for any RRset but that is the parent name > of one or more RRsets)." It's a heads up to say you need to be very careful here. The NSEC record provides both noexistance and potentially existance proofs for names in the range on the NSEC. It's not saying the ENT get Name Error. > Paul and I already exchange mail off-list - I think we're both equally > surprised at the above. > > Clarification from the authors of the rationale for this would be useful > here! > > Ray > > ___ > 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] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Sun, Oct 25, 2015 at 11:39:25PM -0700, Paul Vixie wrote: > sanity check, someone? Yes, you're quite sane. :-) > I believe that in dnssec, an empty non-terminal has a proof that the name > exists, and a proof that there are no RR's. thus, vastly different from the > signaling for NXDOMAIN. Definitely. In my surveys of DANE adoption for SMTP, I'm exercising the "authenticated denial of existence" support of a fairly large number of nameservers (my scans cover ~5 million domains). My validating recursor is unbound, and it rejects NXDOMAIN replies in which the NSEC/NSEC3 records demonstrate that the qname is an empty non-terminal. Conversely it rejects NODATA replies where the NSEC/NSEC3 records prove the non-existence of the qname. When I've reported either issue to the responsible operators, excepting cases where the guilty party has simply buried their head in the sand and not responded, upgrades of the DNS software to a more recent supported version (of say PowerDNS) have resolved the problem. > this ought to end, for all time, the debate about whether empty nonterminals > exist or not. (there are some authority servers who return NXDOMAIN for them, > and we need to know whether those servers are wrong, before we advance query > minimization.) The servers that return NXDOMAIN for empty non-terminals are wrong. Example: @nszero1.axc.nl. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13022 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;_25._tcp.mail.maartenburie.nl. IN TLSA maartenburie.nl.SOA nszero1.axc.nl. hostmaster.maartenburie.nl. 2015013000 14400 3600 1209600 86400 maartenburie.nl.RRSIG SOA 8 2 14400 2015110500 2015101500 56271 maartenburie.nl. ... maartenburie.nl.NSECmaartenburie.nl. A NS SOA MX TXT RRSIG NSEC DNSKEY maartenburie.nl.RRSIG NSEC 8 2 86400 2015110500 2015101500 56271 maartenburie.nl. ... $ unbound-host -t tlsa -v _25._tcp.mail.maartenburie.nl _25._tcp.mail.maartenburie.nl has no TLSA record (BOGUS (security failure)) validation failure <_25._tcp.mail.maartenburie.nl. TLSA IN>: nodata proof failed from 159.253.2.101 The "proof" above is valid for NXDOMAIN, but not NODATA. In this case the problem is a bit more subtle, in addition to the zone apex, this domain has a wildcard A record, but seems to leave it out of the NSEC chain. So NODATA is actually correct, but the NSEC records are wrong. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Mon, Oct 26, 2015 at 11:59 AM, Ray Bellis wrote: > > > On 26/10/2015 15:32, Evan Hunt wrote: > > > But RFC 5155 is clear on the subject; empty non-terminal nodes are > > mentioned under "no data" rather than "name error". > > Ah, thanks, that's useful to know, and further it specifically says that > the NSEC3 ETN response is different to an NSEC ETN response. > > I still thinks that RFC 4035 merits an errata, with perhaps all that's > required is for the "Name Error" title to be expanded to say "Name Error > Response or Empty Non-Terminal Response" (thus avoiding any implication > that an ETN Response is a subset of a "Name Error Response"). > I agree with Ray. An errata should be filed. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
As a Chair, I'm actually very happy were' having deeper discussions around this draft. I think there is some good work inside here, and it appears that the WG feels the same. tim On 10/26/15 11:59 AM, Ray Bellis wrote: On 26/10/2015 15:32, Evan Hunt wrote: But RFC 5155 is clear on the subject; empty non-terminal nodes are mentioned under "no data" rather than "name error". Ah, thanks, that's useful to know, and further it specifically says that the NSEC3 ETN response is different to an NSEC ETN response. I still thinks that RFC 4035 merits an errata, with perhaps all that's required is for the "Name Error" title to be expanded to say "Name Error Response or Empty Non-Terminal Response" (thus avoiding any implication that an ETN Response is a subset of a "Name Error Response"). Ray ___ 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] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On 26/10/2015 15:32, Evan Hunt wrote: > But RFC 5155 is clear on the subject; empty non-terminal nodes are > mentioned under "no data" rather than "name error". Ah, thanks, that's useful to know, and further it specifically says that the NSEC3 ETN response is different to an NSEC ETN response. I still thinks that RFC 4035 merits an errata, with perhaps all that's required is for the "Name Error" title to be expanded to say "Name Error Response or Empty Non-Terminal Response" (thus avoiding any implication that an ETN Response is a subset of a "Name Error Response"). Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Sun, Oct 25, 2015 at 6:49 AM, Stephane Bortzmeyer wrote: > On Sat, Oct 24, 2015 at 10:54:15PM +, > P Vixie wrote > a message of 73 lines which said: > > > To me this is a feature, possibly the most important feature. > > Specially now that Akamai's authoritative name servers properly handle > ENTs: > > % dig @n6dscx.akamaiedge.net A dscx.akamaiedge.net > > ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @n6dscx.akamaiedge.net A > dscx.akamaiedge.net > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11794 > ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > Hmm, what is the original full query name you were trying to resolve here Stephane? Perhaps it's fixed in the akamaiedge.net zone, but it isn't fixed in another Akamai zone I just tested (edgesuite.net): >> Resolving 'www.upenn.edu' >> Query: edu. A IN at zone . >>[Got Referral to zone: edu.] >> Query: upenn.edu. A IN at zone edu. >>[Got Referral to zone: upenn.edu.] >> Query: www.upenn.edu. A IN at zone upenn.edu. www.upenn.edu. 300 IN CNAME www.upenn.edu-dscg.edgesuite.net. >> Query: net. A IN at zone . >>[Got Referral to zone: net.] >> Query: edgesuite.net. A IN at zone net. >>[Got Referral to zone: edgesuite.net.] >> Query: edu-dscg.edgesuite.net. A IN at zone edgesuite.net. ERROR: NXDOMAIN: edu-dscg.edgesuite.net. not found www.upenn.edu. 300 IN CNAME www.upenn.edu-dscg.edgesuite.net. Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
> > i believe that in dnssec, an empty non-terminal has a proof that the > > name exists, and a proof that there are no RR's. thus, vastly > > different from the signaling for NXDOMAIN. > > RFC 4035 §3.1.3.2 appears to say differently :( But RFC 5155 is clear on the subject; empty non-terminal nodes are mentioned under "no data" rather than "name error". -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On 26/10/2015 09:52, I wrote: > That's clear - what isn't perhaps, is what the RCODE should be, given > that this text is in a section with "Name Error" in its title. For what it's worth, I expect the answer to be NOERROR, but I think the text that lumps empty-non-terminals in with "name error" causes sufficient ambiguity and confusion that an errata may be in order. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
> On 26 Oct 2015, at 09:52, Ray Bellis wrote: > > > > On 26/10/2015 09:50, Roy Arends wrote: >> Speaking only for myself, though I happen to be one of the authors. >> >> ... >> >> An Empty Non Terminal NoData response requires the same NSEC records as >> an Name Error Response. > > That's clear - what isn't perhaps, is what the RCODE should be, given > that this text is in a section with "Name Error" in its title. This section doesn’t give guidance on what RCODE to set. I understand that you’re surprised and I hope I clarified it. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On 26/10/2015 09:50, Roy Arends wrote: > Speaking only for myself, though I happen to be one of the authors. > > ... > > An Empty Non Terminal NoData response requires the same NSEC records as > an Name Error Response. That's clear - what isn't perhaps, is what the RCODE should be, given that this text is in a section with "Name Error" in its title. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
Speaking only for myself, though I happen to be one of the authors. On 26 Oct 2015, at 9:08, Ray Bellis wrote: RFC 4035 §3.1.3.2 appears to say differently :( The subject of that section is "Including NSEC RRs: Name Error Response", and it says: "Note that this form of response includes cases in which SNAME corresponds to an empty non-terminal name within the zone (a name that is not the owner name for any RRset but that is the parent name of one or more RRsets)." Paul and I already exchange mail off-list - I think we're both equally surprised at the above. Clarification from the authors of the rationale for this would be useful here! An Empty Non Terminal NoData response requires the same NSEC records as an Name Error Response. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On 26/10/2015 06:39, Paul Vixie wrote: > sanity check, someone? > > i believe that in dnssec, an empty non-terminal has a proof that the > name exists, and a proof that there are no RR's. thus, vastly > different from the signaling for NXDOMAIN. RFC 4035 §3.1.3.2 appears to say differently :( The subject of that section is "Including NSEC RRs: Name Error Response", and it says: "Note that this form of response includes cases in which SNAME corresponds to an empty non-terminal name within the zone (a name that is not the owner name for any RRset but that is the parent name of one or more RRsets)." Paul and I already exchange mail off-list - I think we're both equally surprised at the above. Clarification from the authors of the rationale for this would be useful here! Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
sanity check, someone? i believe that in dnssec, an empty non-terminal has a proof that the name exists, and a proof that there are no RR's. thus, vastly different from the signaling for NXDOMAIN. this ought to end, for all time, the debate about whether empty nonterminals exist or not. (there are some authority servers who return NXDOMAIN for them, and we need to know whether those servers are wrong, before we advance query minimization.) vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Sat, Oct 24, 2015 at 10:54:15PM +, P Vixie wrote a message of 73 lines which said: > To me this is a feature, possibly the most important feature. Specially now that Akamai's authoritative name servers properly handle ENTs: % dig A e8921.dscx.akamaiedge.net ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> A e8921.dscx.akamaiedge.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33630 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;e8921.dscx.akamaiedge.net. IN A ;; ANSWER SECTION: e8921.dscx.akamaiedge.net. 7 IN A 104.85.82.14 ;; AUTHORITY SECTION: dscx.akamaiedge.net.3987 IN NS n0dscx.akamaiedge.net. dscx.akamaiedge.net.3987 IN NS n6dscx.akamaiedge.net. dscx.akamaiedge.net.3987 IN NS n3dscx.akamaiedge.net. ... % dig @n6dscx.akamaiedge.net A dscx.akamaiedge.net ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @n6dscx.akamaiedge.net A dscx.akamaiedge.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11794 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dscx.akamaiedge.net. IN A ;; AUTHORITY SECTION: dscx.akamaiedge.net.1000 IN SOA n0dscx.akamaiedge.net. hostmaster.akamai.com. ( 1445770097 ; serial 1000 ; refresh (16 minutes 40 seconds) 1000 ; retry (16 minutes 40 seconds) 1000 ; expire (16 minutes 40 seconds) 1800 ; minimum (30 minutes) ) ;; Query time: 10 msec ;; SERVER: 2.16.117.216#53(2.16.117.216) ;; WHEN: Sun Oct 25 11:48:17 CET 2015 ;; MSG SIZE rcvd: 101 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
To me this is a feature, possibly the most important feature. On October 25, 2015 6:16:54 AM GMT+11:00, Stephane Bortzmeyer wrote: >[Re-reading all emails...] > >On Fri, Jul 10, 2015 at 11:53:30AM -0700, > 神明達哉 wrote > a message of 62 lines which said: > >> Regarding Section 5 (possible side effect on root servers), I wonder >> about the implication of qname-minimization (which I expect will be >> deployed much sooner than this proposal). A resolver that supports >> qname-minimization would first send a query to "local." to the root >> server upon receiving a "foo.local" query, and cache the result of >> NXDOMAIN for "local.". It will suppress subsequent external queries >> for any subdomain of it. > >Yes. Qname minimization relies on the fact that resolvers follow the >tree structure of the DNS. If "toto." does not exist, it means >"foobar.toto." certainly does not exist and there is no point querying >any authoritative server about it, a resolver can send back NXDOMAIN >immediately. > >In ietf-dnsop-qname-minimisation-07, it is discussed in section 3. > >___ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
[Re-reading all emails...] On Fri, Jul 10, 2015 at 11:53:30AM -0700, 神明達哉 wrote a message of 62 lines which said: > Regarding Section 5 (possible side effect on root servers), I wonder > about the implication of qname-minimization (which I expect will be > deployed much sooner than this proposal). A resolver that supports > qname-minimization would first send a query to "local." to the root > server upon receiving a "foo.local" query, and cache the result of > NXDOMAIN for "local.". It will suppress subsequent external queries > for any subdomain of it. Yes. Qname minimization relies on the fact that resolvers follow the tree structure of the DNS. If "toto." does not exist, it means "foobar.toto." certainly does not exist and there is no point querying any authoritative server about it, a resolver can send back NXDOMAIN immediately. In ietf-dnsop-qname-minimisation-07, it is discussed in section 3. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
Hi, Some thoughts below, strictly on the NSEC/NSEC3 algorithm. They're quite rough, but hopefully they're useful. Cheers, Casey On Tue, Jul 7, 2015 at 5:20 AM, wrote: > Please check this algorithm. Several times, the phrase "query as usual" is used. However, something might need to be said about the resolver modifying "query as usual" to save NSEC/NSEC3 records associated with wildcard and negative responses in a way that they can be used by the algorithm. For example, the following indexes could be maintained: Indexes: NSEC_TABLE = a canonically ordered mapping of NSEC owner names to NSEC records, grouped by corresponding SOA name NSEC3_TABLE = a canonically ordered mapping of NSEC3 owner names to NSEC3 records, grouped by corresponding SOA name and NSEC3 parameters NSEC3_NAMES = a canonically ordered mapping of names to their corresponding NSEC3-hashed names (or records) QNAME = the query name; > if (QNAME name entry exists in the cache) { > resolve the query as usual; > // if RRSet (query name and query type) exists in the cache, > // the resolver responds the RRSet from the cache > // Otherwise, the resolver needs to iterate the query. > } > > // Find closest enclosing NS RRset in the cache. > // The owner of this NS RRset will be a suffix of the QNAME > //- the longest suffix of any NS RRset in the cache. > SIGNER = closest enclosing NS RRSet of QNAME in the cache; > You should now find the SOA record corresponding to SIGNER. If there is no SOA record in cache, then there are no previously cached negative responses, so you can resolve the query as usual. if (SIGNER zone does not have a special NSEC/NSEC3 data structure) { > Resolve the query as usual; > } > I'm not sure what this means. > if (SIGNER zone is not signed or not validated) { >Resolve the query as usual; > } > You mean here: if the SOA record is not validated (signed is implied by validated). While colloquially we talk about zones being signed, in this case, you want an actual RRset--one that matters at that. The SOA record fits the bill here because of its role with negative responses. > if (SIGNER zone is signed with NSEC) { > While in theory a zone is signed with either NSEC or NSEC3, in practice all that matters is the NSEC or NSEC3 proofs provided in individual responses. While not necessarily desirable, it is entirely possible that subsequent responses could different NSEC/NSEC3 results. Therefore, for algorithm robustness, checking whether a zone is signed with NSEC or NSEC3 is less useful than simply looking at both NSEC and NSEC3 records in the cache. I would eliminate "if SIGNER zone is signed with NSEC" and its corresponding "else"/"else if" altogether. You should really check both NSEC and NSEC3. BEGIN NSEC SECTION if (covering NSEC RR of QNAME at SIGNER zone >doesn't exist in the cache) { > Resolve the query as usual. > } > s/Resolve the query as usual/Go to NSEC3 SECTION/ > > TEST = Find the longest existing domain name of QNAME >from the covering NSEC RR; > You could use the term "closest encloser"/CLOSEST_ENCLOSER instead of "longest existing domain name"/TEST. if (*.TEST name entry exists in the cache) { > the resolver can generate positive response > or resolve the query as usual; > } > s/resolve the query as usual/Go to the NSEC3 SECTION It could be a NODATA response (which is a negative response), if the type doesn't exist. Although, I think that's what you mean by "positive response or resolve the query as usual". > if covering NSEC RR of "*.TEST" at SIGNER zone exists > in the cache { > the resolver can generate negative response; > } > s/resolver can generate negative response/Return synthesized negative response/ > // Lack of information, need to resolve the query as usual > No. move on to NSEC3 now. > } else > if (SIGNER zone is signed with NSEC3 and does not use Opt-Out) { > Eliminate this "else if SIGNER zone is signed with NSEC3 and does not use Opt-out" check too. BEGIN NSEC3 SECTION TEST = SIGNER; > Again, I would look for closest encloser (CLOSEST_ENCLOSER) here (e.g., using the NSEC3_NAMES table). There might be multiple NSEC3 records for a single closest encloser if multiple sets of NSEC3 parameters are used across different responses, but really all you need is one. In this case, you would need to iterate through the different sets of NSEC3 parameters. Once you have the closest encloser, the algorithm looks more (but not entirely) like the NSEC portion above, but with NSEC3 instead. I'm not sure I follow the logic in the previously written NSEC3 section. I've made some modifications below. if (no CLOSEST_ENCLOSER is found) { Go to FALLBACK SECTION } NEXT_CLOSEST_ENCLOSER_PROOF_FOUND = False for each set of parameters corresponding to NSEC3 names in the appropriate zone { if (there is a NSEC3 RR covering
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
Thanks to Jinmei, Shumon and Mark. > From: 神明達哉 > While I see what it tries to say and don't disagree with it, I think > this is not very accurate. In fact, NXDOMAIN for "a.example.com" says > there is no such name *or any subdomain of it*. So it would still be > usable to suppress unnecessary external query for, e.g., > foo.a.example.com. I will add some text in next revision. > From: Shumon Huque > That's indeed the literal meaning of NXDOMAIN, but it turns out most > current resolver implementations don't treat it that way. The wording in > RFC2308, Section 5 is not entirely precise, but it seems to say that > negative answers should be cached only for the exact qname, and not > (necessarily) for anything below it. > From: Mark Andrews > Because the consensus at the time was not to support nxdomain > synthesis from signed zone (speaketh the author of RFC 2308). I will add texts to update RFC 2308. > Extreme care needs to be taken with nxdomain synthesis. You need > to choose the correct NSEC records especially for qnames which are > the subdomain of the NSEC owner name. The NS bit MUST NOT be set > in this case as the presence of the NS bit indicates a delegation. > > NSEC3 is even more complicted. YES. > DLV is only defined to use NSEC signed zones as I wasn't interested > in having to working out all the rules for NSEC3. I think the procedure is the same as NSEC3 validation. # and qname minimization discussion is interesting. # It may be listed in draft-ietf-dnsop-root-loopback # as a different approach. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Tue, Jul 14, 2015 at 1:00 PM, 神明達哉 wrote: > At Mon, 13 Jul 2015 22:01:29 -0400, > Shumon Huque wrote: > > > Regarding Section 5 (possible side effect on root servers), I wonder > > > about the implication of qname-minimization (which I expect will be > > > deployed much sooner than this proposal). A resolver that supports > > > qname-minimization would first send a query to "local." to the root > > > server upon receiving a "foo.local" query, and cache the result of > > > NXDOMAIN for "local.". It will suppress subsequent external queries > > > for any subdomain of it. > > > > Yes, this will certainly be a very beneficial result of qname > minimization. > > And the same remark should apply here, too. We'd need "Stopping > Downward Cache Search on NXDOMAIN" in addition to qname minimization > for this to work. > I think we can distinguish the negative caching algorithm and the iterative resolution algorithm. The current iterative resolution algorithm already interprets NXDOMAIN literally (unlike negative caching), so I don't think we need to explicitly say this for the qname minimization variant of iterative resolution either. However, I suppose there's no harm in adding explicit text around this point. Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
At Mon, 13 Jul 2015 22:01:29 -0400, Shumon Huque wrote: > > While I see what it tries to say and don't disagree with it, I think > > this is not very accurate. In fact, NXDOMAIN for "a.example.com" says > > there is no such name *or any subdomain of it*. So it would still be > > usable to suppress unnecessary external query for, e.g., > > foo.a.example.com. > > That's indeed the literal meaning of NXDOMAIN, but it turns out most > current resolver implementations don't treat it that way. The wording in > RFC2308, Section 5 is not entirely precise, but it seems to say that > negative answers should be cached only for the exact qname, and not > (necessarily) for anything below it. Ah, yes, thanks for pointing it out. I don't know or didn't check other resolver implementations, but BIND 9 certainly behaves that way. I should have known this, but I guess I was confused about the "meaning of NXDOMAIN", the behavior of authoritative server implementations and the behavior of recursive server implementations. > Regarding Section 5 (possible side effect on root servers), I wonder > > about the implication of qname-minimization (which I expect will be > > deployed much sooner than this proposal). A resolver that supports > > qname-minimization would first send a query to "local." to the root > > server upon receiving a "foo.local" query, and cache the result of > > NXDOMAIN for "local.". It will suppress subsequent external queries > > for any subdomain of it. > > Yes, this will certainly be a very beneficial result of qname minimization. And the same remark should apply here, too. We'd need "Stopping Downward Cache Search on NXDOMAIN" in addition to qname minimization for this to work. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
In message , Shumon Huque writes: > > On Fri, Jul 10, 2015 at 2:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 e...@wide.ad.jp> wrote: > > > On Tue, Jul 7, 2015 at 2:20 AM, wrote: > > [...] > > In Introduction it states: > > > >While negative (non-existence) information of DNS caching mechanism > >has been known as DNS negative cache [RFC2308], it requires exact > >matching in most cases. [...] > >This was because the NXDOMAIN response just says > >there is no such name "a.example.com" and it doesn't tell anything > >for "b.example.com". > > > > While I see what it tries to say and don't disagree with it, I think > > this is not very accurate. In fact, NXDOMAIN for "a.example.com" says > > there is no such name *or any subdomain of it*. So it would still be > > usable to suppress unnecessary external query for, e.g., > > foo.a.example.com. > > > > That's indeed the literal meaning of NXDOMAIN, but it turns out most > current resolver implementations don't treat it that way. The wording in > RFC2308, Section 5 is not entirely precise, but it seems to say that > negative answers should be cached only for the exact qname, and not > (necessarily) for anything below it. Because the consensus at the time was not to support nxdomain synthesis from signed zone (speaketh the author of RFC 2308). Extreme care needs to be taken with nxdomain synthesis. You need to choose the correct NSEC records especially for qnames which are the subdomain of the NSEC owner name. The NS bit MUST NOT be set in this case as the presence of the NS bit indicates a delegation. NSEC3 is even more complicted. DLV is only defined to use NSEC signed zones as I wasn't interested in having to working out all the rules for NSEC3. > Section 3 of http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 > ("Stopping Downward Cache Search on NXDOMAIN") proposed to fix this > resolver behavior. It would be great if this was standardized and adopted. > > Regarding Section 5 (possible side effect on root servers), I wonder > > about the implication of qname-minimization (which I expect will be > > deployed much sooner than this proposal). A resolver that supports > > qname-minimization would first send a query to "local." to the root > > server upon receiving a "foo.local" query, and cache the result of > > NXDOMAIN for "local.". It will suppress subsequent external queries > > for any subdomain of it. > > > > Yes, this will certainly be a very beneficial result of qname > minimization. > > Shumon. -- 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] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Fri, Jul 10, 2015 at 2:53 PM, 神明達哉 wrote: > On Tue, Jul 7, 2015 at 2:20 AM, wrote: > [...] > In Introduction it states: > >While negative (non-existence) information of DNS caching mechanism >has been known as DNS negative cache [RFC2308], it requires exact >matching in most cases. [...] >This was because the NXDOMAIN response just says >there is no such name "a.example.com" and it doesn't tell anything >for "b.example.com". > > While I see what it tries to say and don't disagree with it, I think > this is not very accurate. In fact, NXDOMAIN for "a.example.com" says > there is no such name *or any subdomain of it*. So it would still be > usable to suppress unnecessary external query for, e.g., > foo.a.example.com. > That's indeed the literal meaning of NXDOMAIN, but it turns out most current resolver implementations don't treat it that way. The wording in RFC2308, Section 5 is not entirely precise, but it seems to say that negative answers should be cached only for the exact qname, and not (necessarily) for anything below it. Section 3 of http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 ("Stopping Downward Cache Search on NXDOMAIN") proposed to fix this resolver behavior. It would be great if this was standardized and adopted. Regarding Section 5 (possible side effect on root servers), I wonder > about the implication of qname-minimization (which I expect will be > deployed much sooner than this proposal). A resolver that supports > qname-minimization would first send a query to "local." to the root > server upon receiving a "foo.local" query, and cache the result of > NXDOMAIN for "local.". It will suppress subsequent external queries > for any subdomain of it. > Yes, this will certainly be a very beneficial result of qname minimization. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Tue, Jul 7, 2015 at 2:20 AM, wrote: > Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01. > > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ > > * Added reference to DLV {{RFC5074}} and imported some sentences. > * Added Aggressive Negative Caching Flag idea. > * Added detailed algorithms in Appendix. > > Please check and comment. The primarily intended benefit of this approach seems to mitigate a DoS attack on a resolver (e.g., according to Section 3). But I'm skeptical about the effectiveness in that context: for this mitigation to work the zone in question needs to be DNSSEC-signed. But an attacker would be easily able to find unsigned zone to use for the attack, and they could even set up an unsigned zone they can control. Also, an equally effective attack is possible without relying non-existent names: an attacker would only find some wildcard name and send random queries that match the wildcard. So, if the proposed approach is really effective to "random (non-existent) sub-domain attacks", attackers would simply move to a variant of it that would still work. So, in the end, a resolver would still employ counter measures like rate limiting (which will work for both types of random name attacks, and will work for unsigned zones), and, if it's reasonably effective, the defense using "nsec-aggressiveuse" won't be that promising. That said, I wouldn't necessarily be opposed to the idea itself. It might still be some nice-to-have optimization for resolver performance, and if so, it's probably worth pursing. In Introduction it states: While negative (non-existence) information of DNS caching mechanism has been known as DNS negative cache [RFC2308], it requires exact matching in most cases. [...] This was because the NXDOMAIN response just says there is no such name "a.example.com" and it doesn't tell anything for "b.example.com". While I see what it tries to say and don't disagree with it, I think this is not very accurate. In fact, NXDOMAIN for "a.example.com" says there is no such name *or any subdomain of it*. So it would still be usable to suppress unnecessary external query for, e.g., foo.a.example.com. Regarding Section 5 (possible side effect on root servers), I wonder about the implication of qname-minimization (which I expect will be deployed much sooner than this proposal). A resolver that supports qname-minimization would first send a query to "local." to the root server upon receiving a "foo.local" query, and cache the result of NXDOMAIN for "local.". It will suppress subsequent external queries for any subdomain of it. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
> From: Bob Harold > On Tue, Jul 7, 2015 at 5:20 AM, wrote: > >> Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01. >> >> >> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ >> >> >> ... > >> -- >> Kazunori Fujiwara, JPRS >> >> I am concerned that the "AN" flag allows for easy zone walking, defeating > the purpose of minimal range NSEC records. So I don't think authoritative > servers would want to respect it. It's the problem. However, authoritative DNS servers can detect random subdomain attacks. They can generate NSEC resource records with wider range under random subdomain attacks. > I am also concerned that random subdomain queries will set the CD bit, if > that avoids aggressive negative caching. So I would think that the CD bit > should not be allowed to stop aggressive negative caching. Thanks. I will add. Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
On Tue, Jul 7, 2015 at 5:20 AM, wrote: > Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01. > > > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ > > > ... > -- > Kazunori Fujiwara, JPRS > > I am concerned that the "AN" flag allows for easy zone walking, defeating the purpose of minimal range NSEC records. So I don't think authoritative servers would want to respect it. I am also concerned that random subdomain queries will set the CD bit, if that avoids aggressive negative caching. So I would think that the CD bit should not be allowed to stop aggressive negative caching. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop