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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, 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: [phone]                 INTERNET: [e-mail]