Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-bortzmeyer-dnsop-nxdomain-cut-00.txt]

In message <39D878B4-9239-4983-8083-36BCA365BE62@verisign.com>, "Wessels, Duane
" writes:
> 
> > On Nov 12, 2015, at 12:15 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote
> :
> > 
> > On Wed, Nov 11, 2015 at 01:15:37AM +0000,
> > Wessels, Duane <dwessels@verisign.com> 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

Or we can not do anything special w.r.t. TLDs.  DNSSEC prevents this attack.
TLD operators are all in a position to do the right thing and deploy DNSSEC. 

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org