How to propagate the newly generated (or newly changed) DNS resource records
(RRs) from authority to recursive servers is obviously very important for the
DNS system.
For RR propagation, there are fundamentally two approaches: pull-based and
push-based approach. In the former one, recursive servers pull RRs from
authority
servers when the TTL expires. Usually, this kind of approach has advantages of
low traffic overhead and high resilience but a disadvantage of bad real time.
In the latter one, authority servers push the RRs to recursive servers when
zone file is changed. This approach has good real time but brings very high
traffic
overhead since authority servers do not know which RRs is needed by recursive
servers. Obviously, the pull-based approach now is widely used in DNS due to
its simplicity.
If there is a third approach, it must be a mixture of pull-based and push-based
approaches and a new signaling protocol between authority and recursive servers
may
be needed to schedule the transmission of RRs (DNS NOTIFY can be taken as an
example). However, the drawback of the second approach is also brought into the
third
one. Lastly, though I am not totally satisfied with the currently used
approach, I have not got a better idea yet. Anyway, DNS NOTIFY is a good start
in my opinion.
Guangqing Deng
CNNIC
From: Tim Wicinski
Date: 2013-06-28 16:56
To: ice jew; Guangqing Deng
CC: dnsop; Joe Abley
Subject: Re: [DNSOP] Fwd: New Version Notification for
draft-jabley-dnsop-dns-flush-00.txt
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]> 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
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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
