In message <[email protected]>, "Wessels, Duane " writes: > > > On Nov 12, 2015, at 12:15 AM, Stephane Bortzmeyer <[email protected]> wrote > : > > > > On Wed, Nov 11, 2015 at 01:15:37AM +0000, > > Wessels, Duane <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
