Subject: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-dns-flush-00.txt

From: Joe Abley <[email-masked]>
Date: Mon, 24 Jun 2013 15:32:45 -0400

Greetings, draft-fans!

I just exhumed the below-mentioned draft and recruited a co-author, since it seems like a timely topic for discussion.

This draft proposes a mechanism whereby an authority-server operator can signal to one or more recursive servers that the recursive server should flush a section of its cache. It's an in-band mechanism using TSIG-secured NOTIFY.

No code-points were depleted during the preparation of this proposal.

The use-cases are things like "prominent zone suffered some kind of signing error, things are better now, bad data is cached, would be nice to flush it" and "registrar suffered some kind of database error, things are better now, bad data is cached, etc." hence timely, above.

Comments on the general idea or the specific proposal would be most welcome.

Joe

Begin forwarded message:

> From: "[email-masked]" <[email-masked]>
> Subject: New Version Notification for draft-jabley-dnsop-dns-flush-00.txt
> Date: 24 June 2013 15:16:29 EDT
> To: Joe Abley <[email-masked]>
> 
> 
> A new version of I-D, draft-jabley-dnsop-dns-flush-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Filename:	 draft-jabley-dnsop-dns-flush
> Revision:	 00
> Title:		 A Mechanism for Remote-Triggered DNS Cache Flushes (DNS FLUSH)
> Creation date:	 2013-06-24
> Group:		 Individual Submission
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-jabley-dnsop-dns-flush-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-jabley-dnsop-dns-flush
> Htmlized:        http://tools.ietf.org/html/draft-jabley-dnsop-dns-flush-00
> 
> 
> Abstract:
>   DNS NOTIFY is a mechanism for prompt notification of zone changes
>   between DNS authority servers that is usually employed to trigger
>   immediate zone transfers.
> 
>   This document specifies an additional use of DNS NOTIFY to allow DNS
>   authority servers to trigger cache flushes on recursive DNS servers.
>   Such signalling is authenticated and is intended for use between
>   cooperating DNS server operators.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: "Guangqing Deng" <[email-masked]>
Date: Tue, 25 Jun 2013 20:02:46 +0800

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. 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.

Guangqing Deng
cnnic 

From: Joe Abley
Date: 2013-06-25 03:32
To: IETF DNSOP WG
Subject: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-dns-flush-00.txt
Greetings, draft-fans!

Joe

>   cooperating DNS server operators.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Jun 2013 09:10:00 -0400

Hi Guangqing,

On 2013-06-25, at 08:02, "Guangqing Deng" <[email-masked]> wrote:

> 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 

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

---

From: "Guangqing Deng" <[email-masked]>
Date: Wed, 26 Jun 2013 10:26:09 +0800

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-masked]
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-dns-flush-00.txt
Hi Guangqing,

Joe

---

From: ice jew <[email-masked]>
Date: Wed, 26 Jun 2013 13:39:01 +0800

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-masked]>wrote:

> **
> ------------------------------
>  Guangqing Deng
> CNNIC
>
>  *From:* Joe Abley <[email-masked]>
> *Date:* 2013-06-25 21:10
> *To:* dengguangqing <[email-masked]>
> *CC:* [email-masked]
> *Subject:* Re: [DNSOP] Fwd: New Version Notification for
> draft-jabley-dnsop-dns-flush-00.txt
>  Hi Guangqing,
>

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 28 Jun 2013 04:56:55 -0400

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:
> 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.
>
> 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-masked] <mailto:[email-masked]>> wrote:
>
>     ------------------------------------------------------------------------
>     Guangqing Deng
>     CNNIC
>     *From:* Joe Abley <mailto:[email-masked]>
>     *Date:* 2013-06-25 21:10
>     *To:* dengguangqing <mailto:[email-masked]>
>     *CC:* [email-masked] <mailto:[email-masked]>
>     On 2013-06-25, at 08:02, "Guangqing Deng" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>

---

From: "Guangqing Deng" <[email-masked]>
Date: Sun, 30 Jun 2013 00:41:48 +0800

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

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-masked]> wrote:

Guangqing Deng
CNNIC 

From: Joe Abley
Date: 2013-06-25 21:10
To: dengguangqing
CC: [email-masked]

Joe