> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
