Hi, Comment is in-line.
> On 18-Apr-2019, at 4:34 PM, Davey Song <songlinj...@gmail.com> wrote: > > <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. 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 > > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
