<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, <internet-dra...@ietf.org> wrote: > > 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/ > > _______________________________________________ > I-D-Announce mailing list > i-d-annou...@ietf.org > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
