[DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Edward Lewis <[e-mail]>]

#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.  (Logically, it has to be.  If I treat it as SHOULD, I'd never discover data below that I MAY elect to return.)

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.

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.