On Mon, Oct 10, 2016 at 6:15 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <0be787cd-3877-48c0-8bf9-3e15f605d...@dnss.ec>, Roy Arends writes: >> On 10 Oct 2016, at 21:39, Mark Andrews <ma...@isc.org> wrote: >> >=20 >> >=20 >> > In message <ea312f37-2e4c-45e0-af0a-b0a0663b7...@dnss.ec>, Roy Arends = >> writes: >> >> Having read the draft >> >>=20 >> >> How does one distinguish a Empty Non-Terminal NODATA response from an >> >> NXDOMAIN response, solely by looking at the NSEC or NSEC3 records. >> >=20 >> > NSEC: Find the NSEC record that proves that there are no records >> > at the given name (note all of the owner, the next domain name and >> > the bit map need to be examined to do this). It either the owner >> > name or the next domain name of that record are a subdomain of the >> > given name then it is a ENT otherwise it is a NXDOMAIN. >> >> Thanks Mark. >> >> There should be some guidance to this in the draft. >> >> To be complete, for NSEC3: each empty non-terminal has an NSEC3 record = >> associated with it, so there is always a matching NSEC3 record. >> >> The issue remains with NSEC. It is possible to determine the difference. = >> It is important to determine the difference. This method is not = >> specified in the draft that encourages this local optimisation. >> >> Warmly >> >> Roy
Mark, I hope you don't mind, but I stole your below text and included it as an Appendix in the NSEC document. It's been pushed to GitHub -- https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse W > > If the NSEC record has not been verified as secure discard it. > > If the given name sorts before or matches the NSEC owner name discard > it as it does not prove the NXDOMAIN or ENT. > > If the given name is a subdomain of the NSEC owner name and the NS > bit is present and the SOA bit is absent then discard the NSEC as > it is from a parent zone. > > If the next domain name sorts after the NSEC owner name and the > given name sorts after or matches next domain name then discard the > NSEC record as it does not prove the NXDOMAIN or ENT. > > If the next domain name sorts before or matches the NSEC owner name > and the given name is not a subdomain of the next domain name then > discard the NSEC as it does not prove the NXDOMAIN or ENT. > > You now have a NSEC record that proves the NXDOMAIN or ENT. > > If the next domain name is a subdomain of the given name you have > a ENT otherwise you have a NXDOMAIN. > >> >=20 >> >> There is an attack vector where an RCODE0 can be replaced by RCODE3 = >> while >> >> keeping the rest of the response completely intact, causing an = >> aggressive >> >> use enabled cache to deny existing records. >> >>=20 >> >> These kind of subtleties arent described in the draft, as far as I = >> can >> >> tell. >> >>=20 >> >> Roy >> >> _______________________________________________ >> >> DNSOP mailing list >> >> DNSOP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsop >> >=20 >> > --=20 >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> > -- > 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 -- 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
