This draft does provide some new possibility for decrease the negative effects for the authority name server's mis-configuration in a certain way. But I don't think it will work in the real world even if all prerequisites are meant.
First, there is standard way to solve this problem, as Guanqing says, it's to shorten the TTL (both positive and negative cache). This may lead to load increase for the authority name servers and recursive resolver. But this method take the least risk. Second, I think it won't work under the condition that the recursive resolver and the cache name server are deprived. The authority cleans the cache of the recursive resolver from the log but the cache name server won't go to the recursive resolver for a newer response until the TTL is expired. And the bad data in to cache name server still responses to the incoming queries. The cleaning-cache-mechanism doesn't help to decrease the negative effect. On Wed, Jun 26, 2013 at 10:26 AM, Guangqing Deng <[email protected]>wrote: > ** > > Hi, Joe. Just as you said, the need of flushing cache exists to a certain > extent. But maybe first we should check > > why the cache needs to be flushed. Is it due to errors in zone file, other > configuration errors in authority servers > > or the inefficiency of TTL mechanism? For the first two reasons, it is better > to do other work to avoid such kinds > > of errors and then cache flushing is bypassed. For the third reason, > shortening the TTL may be a potential approach, > > and also DNS FLUSH can be taken as an effective supplement of TTL mechanism. > Fundamentally, TTL mechanism is based > > on "pull" fashion while DNS FLUSH somehow is based on "push" fashion. And > then how to effectively bring them together > > is not an easy job. Anyway, this draft brings a new choice for authority > server operators and resolver server operators. > > ------------------------------ > Guangqing Deng > CNNIC > > *From:* Joe Abley <[email protected]> > *Date:* 2013-06-25 21:10 > *To:* dengguangqing <[email protected]> > *CC:* [email protected] > *Subject:* Re: [DNSOP] Fwd: New Version Notification for > draft-jabley-dnsop-dns-flush-00.txt > Hi Guangqing, > > On 2013-06-25, at 08:02, "Guangqing Deng" <[email protected]> wrote: > > > > Hi, Joe, I like this draft, though I am puzzled by some questions. First, > > the change of > > > the zone content of an authority server does not mean that a corresponding > > recursive server > > > has to flush its cache, since a recursive server usually just cache a small > > part of zone content > > > of an authority server but not all. Also, an authority server does not know > > which RRs of its > > > zone content are cached in recursive servers. So such mechanism of DNS > > FLUSH may bring about > > > some additional traffic between authority and recursive servers with no > > benefit. > > > I agree that in many cases this is a fairly coarse mechanism; however, > arguably there are situations where incurring that overhead is better than > enduring bad data that is widely-cached. > > > Following the recent incident affecting various .COM names there were > widespread pleas to resolver operators to "flush your cache". It seems likely > that some people interpreted that request on face-value, and flushed all > records from their caches. Flushing just the COM domain (or specific > sub-domains) would have been better. This mechanism would facilitate either > of those. > > I appreciate the previous paragraph is less than entirely convincing :-) > > > The BIZ event whereby (it appears from the outside) an apex DNSKEY RRSet was > published that did not include a key corresponding to the BIZ DS RRSet in the > root zone would have been another example where flushing the entire BIZ > domain would have been overkill, but arguably better (for validators) than > doing nothing. > > > I agree that it would make little sense for an authority server operator in > the absence of a problem to flush remote caches every time a new zone was > published. I would expect specific hooks to be in place to allow flush > directions to be propagated under manual operator control, rather than > automatically, triggered by a SOA serial bump. > > > There is a discontinuity here between the current use of DNS NOTIFY and the > proposed new use; the former is based on zones, while the latter is based on > domains. There is an argument here for a new opcode; the reuse of NOTIFY > seemed expedient when I wrote the draft, but perhaps it's not the best way. > > > Second, how > > > does the authority server obtain the IPs of recursive servers? From query > > logs? Then the > > > authority server sends DNS FLUSH to all or part of recursive servers? It > > seems that there > > > are big differences between DNS NOTIFY and so called DNS FLUSH and thus > > more things need to > > be clarified. > > I can think of various models for this. > > > Bilateral agreements between authority server operators and recursive server > operators would involve sharing of TSIG secrets as well as server addresses. > A set of bilats will not scale to the whole Internet, obviously, but perhaps > is good enough to deal with particular known resolvers that serve large > communities of users (e.g. Google DNS, OpenDNS, Comcast DNS). > > > A mechanism such as this would enable a clearinghouse style business model > where resolver operators and authority server operators could subscribe to a > service that mediated the flush directions between authority servers and > recursive servers, acting as a trusted intermediary. > > > Joe > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
