Davey Song(宋林健) <ljs...@biigroup.cn>于2017年9月8日周五 下午5:16写道：
> I just notice it asks for "Standards Track" document. If it aims to > introduce a special use of resolver to achieve some features for their > users' benefit, I think informational document may be more appropriate ? I > guess, like what RFC7706 does. > +1, I support the adoption of this document if it is informational. recursive can choose to support this "cache operation improvement feature" or not, but not update 1034/1035's TTL definition. recursive may use stale data/extend the TTL for some special scenario, for example: ==not ddos attack== 1) some domains' A TTL are set to 1s, and they will not change it, because they think that will help new RR spreads faster... recursives offen have to extend the TTL = 90s or 600s or 3600s. 2) network temporary failure on resolution path ( recursive -> authoritative ) , SERVFAIL / TIMEOUT, offen short time trigger some "use stale bread" callback function to deal with the SRRVFAIL/TIMEOUT failure, the data is snapshot from online hot cache LRU/cache aging heuristic. ==ddos attack== 3) recursive encounter ddos attack trigger "proxy top-N important domain's dns response" on the ddos firewall, the top-N important domain's data is generated from the whole latest-M days query log. 4) important SLD authoritative encounter ddos attack SLD authoritative wants recursives trigger above 2) solution on its hot domains, for its most visited service. SLD authoritative wants recursives have some knowledge about its subdomain wildcards, to avoid not-visited subdomain wildcard failure. > Davey > > > -----邮件原件----- > > 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Stephane Bortzmeyer > > 发送时间: 2017年9月7日 23:43 > > 收件人: tjw ietf > > 抄送: dnsop > > 主题: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale > > > > On Tue, Sep 05, 2017 at 03:25:39PM -0400, tjw ietf <tjw.i...@gmail.com> > > wrote a message of 77 lines which said: > > > > > This starts a formal Call for Adoption for > > > draft-tale-dnsop-serve-stale > > > > > > The draft is available here: > > > https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ > > > > I'm not enthousiastic. We should focus on making the DNS infrastructure > more > > reliable, not on adding something to a pile of already fragile protocols. > > > > There is also an opportunity that it masks failures and prevents people > from > > properly assigning blame: "example.com works if I use Something Public > DNS > > but not if I use my ISP's resolver, therefore my ISP is broken". > > > > Also, the current draft does not make crystal-clear that stale data MUST > NOT > > be served unless no authoritative name server replies. > > > > If it is adopted, I think that requesting some way to convey the fact it > is stale to > > the client (Davey Song's message) is necessary. > > > > Regarding the draft, I'm surprised by the paragraph starting with "Paul > Vixie > > has suggested", paragraph which seems to completely ignore RFC 8020. > > > > _______________________________________________ > > 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 > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
