Subject: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-05.txt

From: [email-masked]
Date: Tue, 16 Apr 2019 10:52:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Serving Stale Data to Improve DNS Resiliency
        Authors         : David C Lawrence
                          Warren "Ace" Kumari
                          Puneet Sood
	Filename        : draft-ietf-dnsop-serve-stale-05.txt
	Pages           : 12
	Date            : 2019-04-16

Abstract:
   This draft defines a method (serve-stale) for recursive resolvers to
   use stale DNS data to avoid outages when authoritative nameservers
   cannot be reached to refresh expired data.  It updates the definition
   of TTL from [RFC1034], [RFC1035], and [RFC2181] to make it clear that
   data can be kept in the cache beyond the TTL expiry and used for
   responses when a refreshed answer is not readily available.  One of
   the motivations for serve-stale is to make the DNS more resilient to
   DoS attacks, and thereby make them less attractive as an attack
   vector.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-05
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Apr 2019 13:56:08 -0700

i remain opposed to the protocol described here, for reasons previously 
given.

---

From: Davey Song <[email-masked]>
Date: Thu, 18 Apr 2019 19:04:44 +0800

<It is my second time to read it. I may miss something discussed before.
Sorry>

Some concerns and comments:

1) It sounds to me that the primary targeted outage described in this draft
is on the authoritative server during DDOS attack especially. Think about a
case of outage of resolver due to a failure in its network path to the
authoritative server. Normally end user have more than one configured
resolvers. If only one resolver experience the outage and serve the stale
data, could the user tell which resolver have more refreshed data ? If not,
it may impact users experience if they have to accept stale data during the
period when they still have the choice for refreshed ones. As I mentioned
the first time I read it, I dislike the fact of concealing using of stale
data from end users.

2) I notice it is proposed as a stand track document. If more people here
think its benefit outweighs its impacts, I prefer it published as
informational document, because it is based on implementation and operation
experience. There is no need to change the protocol and the definition of
TTL. I prefer to take the serve-stale behavior as a local policy and a side
channel in case of resolver's cache-miss.

3) A minor concern: in an thread in dns-operation mailing list last week,
it is said that the behavior of serve stale in some ISPs is abused for
reason of traffic hijack/tampering/spoofing. I'm afraid it will be
encouraged by this document.

Best regards,

Davey

On Wed, 17 Apr 2019 at 01:52, <[email-masked]> wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Karan Saini <[email-masked]>
Date: Fri, 26 Apr 2019 14:53:10 +0530

Hi,

Comment is in-line.

> On 18-Apr-2019, at 4:34 PM, Davey Song <[email-masked]> wrote:
> 
> <It is my second time to read it. I may miss something discussed before. Sorry>
>  
> 1) It sounds to me that the primary targeted outage described in this draft is on the authoritative server during DDOS attack especially. Think about a case of outage of resolver due to a failure in its network path to the authoritative server. Normally end user have more than one configured resolvers. If only one resolver experience the outage and serve the stale data, could the user tell which resolver have more refreshed data ? If not, it may impact users experience if they have to accept stale data during the period when they still have the choice for refreshed ones. As I mentioned the first time I read it, I dislike the fact of concealing using of stale data from end users. 
>  
> 2) I notice it is proposed as a stand track document. If more people here think its benefit outweighs its impacts, I prefer it published as informational document, because it is based on implementation and operation experience. There is no need to change the protocol and the definition of TTL. I prefer to take the serve-stale behavior as a local policy and a side channel in case of resolver's cache-miss.

I agree with Davey, perhaps publishing this as an experimental or informational document may be beneficial for the purpose that is trying to be fulfilled.

>  
> 3) A minor concern: in an thread in dns-operation mailing list last week, it is said that the behavior of serve stale in some ISPs is abused for reason of traffic hijack/tampering/spoofing. I'm afraid it will be encouraged by this document.
>  
> Best regards,
> Davey
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop