Actually flushing resolver caches in larger environments (data
center/enterprise/etc) where even short TTLs doesn't quite handle
unexpected events, and there is a need to have consistent answers, even
if the consistency is NXDOMAIN.
I don't know if the NOTIFY semantic mechanism (while a simple way of
avoiding creating a new mechanism) is the correct method.
tim
On 6/26/13 1:39 AM, ice jew wrote:
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] <mailto:[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 <mailto:[email protected]>
*Date:* 2013-06-25 21:10
*To:* dengguangqing <mailto:[email protected]>
*CC:* [email protected] <mailto:[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]
<mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
