In message <29b4a430-80c7-44c8-a6fa-54a1560d3...@icann.org>, Edward Lewis writ es: > #2. Rule > # > # When an iterative caching DNS resolver receives a response NXDOMAIN, > # it SHOULD store it in its cache and all names and RRsets at or below > # that node SHOULD then be considered to be unreachable. Subsequent > # queries for such names SHOULD elicit an NXDOMAIN response. > # > # But if a resolver has cached data under the NXDOMAIN cut, it MAY > # continue to send it as a reply (until the TTL of this cached data > # expires), since this may avoid additional processing when a query is > # received. Section 6 provides more information about this. > > For consistency, the SHOULD's in the first paragraph ought to be MAY's. > (Loically, it has to be. If I treat it as SHOULD, I'd never discover > data below that I MAY elect to return.)
No. SHOULD is not MUST. Every SHOULD has a implict UNLESS <unspecified reason>. In this case we actually have a reason for the why the second and third SHOULD are not MUSTs. I could turn first SHOULD into a MUST and still reach the MAY. > As the authority server may change its version of a zone and the SOA > (with serial) is not in every response, it's impossible (computationally > undecidable) to know whether the answer with the NXDOMAIN was created > before or after lower data. Maybe the lower data is "currently correct" > and the NXDOMAIN is stale-ish. Or not. Temporal issues are not new. All DNS caches have them. > DNSSEC does not solve this - the inception time of a RRSIG is a tempting > metric of freshness but that timestamp is not reliable for that purpose. > (From the early days, signers would post date the signature on purpose to > avoid then-common clock skew issues.) This would be good to reinforce. > > Given a temporally valid answer with data below a temporally denied name > is possible (as zones change over time), I'd say that it is up to the > implementer to choose one way or the other. All things being static, an > NXDOMAIN would occlude lower data. But things are not static. > > When I wrote "occlude" above I thought of the rule that an NS set > occludes data below it the cut. That is, hide it from answers but > include it in zone transfers. But that doesn't mean we NXDOMAIN the same > way - because the rule for NS impacts authorities, the NXDOMAIN issue is > in caches. -- 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
