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

[Matthew Pounsett <[e-mail]>]

On 27 September 2016 at 12:28, White, Andrew <[e-mail]>
wrote:

> Hi Shumon,
>
>
>
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would it
> better to say the resolver SHOULD drop from cache all descendents of
> x.example.com, or MAY?
>
>
>
> It may be computationally expensive to search cache to remove cached
> NXDOMAIN responses below x.example.com, and I see no harm in letting
> those cached entries expire as their TTL runs out.
>

Would it be better then to leave early expiry as an implementation choice,
and instead say that the implementation SHOULD respond with NXDOMAIN for
any QNAME at or below a cached NXDOMAIN?

# When an iterative caching DNS resolver receives a response with RCODE
being
# NXDOMAIN, the resolver SHOULD store the response in its (negative) cache.
# During the time the response is cached, any query with a QNAME at or
# descended from the denied name SHOULD be assumed to result in a name
error.
# Responses to those queries SHOULD set RCODE=NXDOMAIN (using the DNSSEC
# records cached as proof).  Any names at or below the name received in the
# NXDOMAIN response MAY be flushed from cache at the time the response is
# received.

If foo.bar.example.org has a cached record, and an nxdomain for
bar.example.org is then cached, further queries for foo.bar.example.org
would also trigger NXDOMAIN for as long as bar.example.org is in the
negative cache.

If the negative response for bar.example.org expires before the positive
response for foo.bar.example.org, then that name could pop up in positive
responses again... if the implementation hasn't chosen to expire it as well.

My rationale is that if foo.bar.example.org were still a valid name at the
time that the bar.example.org NXDOMAIN response was issued, then NXDOMAIN
was not the correct response.  It would be inappropriate to answer for
foo.bar.example.org out of the cache in that case.