kato san, what is the statistical likelihood of a routing break happening at a specific anycast node, during the life of a TCP session, and whats the consequence?
likelihood: it depends on the frequency of A/I XFR, the volume of query, and the frequency of routing break consequence: the TCP session dies and the client re-tries Which will connect to another anycast node and continue. I believe the frequency is going to be down below 1% and probably below 0.001% as orders of magnitude. I suspect it is no worse and no more likely than A/I XFR long held TCP, and breaking routing in the current model. I don't believe the consequence is severe because the global applicability of a single update fail is that you had to retry -G On Wed, Mar 25, 2015 at 9:01 AM, <k...@wide.ad.jp> wrote: > > From: Paul Hoffman <paul.hoff...@vpnc.org> > Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01 > Date: Wed, 25 Mar 2015 07:36:39 -0500 > > > On Mar 25, 2015, at 12:19 AM, k...@wide.ad.jp wrote: > >> It is better to describe that the update of the zone can be delayed a > >> little bit as no NOTIFY message is sent to the root-on-loopback. > > > > Good point; added. > > > >> In Appendix A, the root servers listed allow AXFR currently, but I am > >> afraid they don't guarantee it in the future. It may be necessary to > >> confirm it with the operator of each root server listed. > > > > The appendix already says: > > > > It is crucial to note that none of the above services are > guaranteed > > to be available. It is possible that ICANN or some of the root > server > > operators will turn off the AXFR capability on the servers listed > above. > > > > Asking any operator to guarantee something in the future doesn't mean > they actually will do so, so this warning is more appropriate. > > Sorry, I missed the paragraph. > > >> In Appendix B, most of the IP addresses of the root DNS servers are > >> anycasted. They are not suitable for the target to pull the zone data > >> in AXFR over TCP. > > > > Fully disagree. AXFR of the root zone over TCP over anycast works just > fine in all our testing. As Tony Finch points out, it works well in the > current Internet. > > I don't think Akamai uses anycast, but it answers "suitable" > non-anycast IP address in DNS query depending on the source address. > I don't know if such ISPs still exist, but when we started Anycast, it > was reported that some ISPs did per-packet load balancing. The root > zone grows over time in almost monotonous manner and longer TCP > sessions (especially over narrow bandwidth circuits) could break due > to routing change. I'd appreciate if you can add my concern to the > text. > > >> Also it must be noted that these addresses may change over time (while > >> the frequency is not high), it may need to give a warning to > >> periodically check if the addresses are valid. > > > > Is the above warning not sufficient? > > OK > > >> Generating the > >> configuration after priming query? (this is a joke) > >> > >> IMHO, it may necessary to establish an infrastructure to distribute > >> root zone in scalable/reliable manner. > > > > Feel free to create such an infrastructure. After it is in place, we can > update this document. In the meantime, this document describes a practice > that many operators are already using quite successfully. > > Publishing XML/JSON/YAML encoded root zone via CDN? I don't know who should > pay the cost. > > > > > --Paul Hoffman > > -- Akira Kato > > _______________________________________________ > 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
