Re: [DNSOP] [[e-mail]: I-D Action: draft-bortzmeyer-dnsop-nxdomain-cut-00.txt]

["Wessels, Duane" <[e-mail]>]

> On Nov 12, 2015, at 12:15 AM, Stephane Bortzmeyer <[e-mail]> wrote:
> 
> On Wed, Nov 11, 2015 at 01:15:37AM +0000,
> Wessels, Duane <[e-mail]> wrote 
> a message of 107 lines which said:
> 
>> This updates RFC 2308 (Negative Caching of DNS Queries).
> 
> Good point, I'll add that. Also, I did not dare to add "Updates: RFC
> 1034". Should I?

That I don't know.  Someone with more experience should probably answer.


> 
>> I think the WG needs to discuss and agree whether or not to make the
>> NXDOMAIN cut based on QNAME only, or on the SOA owner name.
> 
> This is discussed (shortly) in section 5 of the draft. Apparently, it
> can be risky to rely on the SOA. More discussion welcome.

As Mark pointed out, we can't use the SOA to make NXDOMAIN more aggressive.

For a name like foo.bar.example.com and an NXDOMAIN response from example.com
we can't assume that there would be a zone cut between foo and bar.  

> 
>> I think its a little dangerous to say that an NXDOMAIN response
>> SHOULD cause a cache to delete already cached "positive" data.
> 
> Could you elaborate why is it dangerous? (See also the second
> paragraph of section 7.)

I'm thinking of worst-case scenarios where, say, an entire TLD is purged
from the cache due to a spoofed response.  Or, could you imagine a spoofed
"NXDOMAIN ." response?

In addition to denying service for the purged domain, a large purge also
causes the resolver to do a lot of (possibly CPU intensive) work, and
could also affect the traffic levels between a recursive and authoritatives.

Perhaps a cache may want to limit the number of nodes/records that it deletes
per NXDOMAIN response.  Or perhaps it could be configured to not "bulk delete"
TLDs (or root).  

Perhaps a recursive might be designed to negatively cache an entire zone
(including TLD) but continue answering positively cached answers in the zone
until they expire normally.

DW