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
Date: 2013-06-25 21:10
To: dengguangqing
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
