On Fri, Nov 28, 2014 at 3:21 PM, Paul Vixie <p...@redbarn.org> wrote:
> > for example, if 13 is good, would 130 (10X) or 1300 (100X) be better? > even with 1300 root name servers, the fallback to TCP after TC=1 in a > priming query (even with EDNS) would only add one extra round trip over > the three that are required to run a TCP query. since priming queries > are uncommon, i still don't see why that first round trip is worth > avoiding. > > At least we can try Fast Open TCP on it to save more round for performance purpose . Priming exchange is special because this exchange lead the people to the unique name space of Internet. If we share the same dream of "One World One Internet" , any extra effort is deserved to protect its resiliency in IPv6 network(section 2.1), integrity with fully signed(section 2.2) and more NS server to enable more participation of CDOs. (section 2.3) > > however, the systemic complexity of all those RDNS servers performing > all those measurements seems like cause for concern. with 1300 root name > servers, it would take 1300 referrals for any given RDNS server to learn > which root name server was closest to it. unless all 1300 of those > servers are widely anycast, then many of those initial 1300 referrals > would have suboptimal round trip times. also with that many servers, > error theory predicts that some number of them will be unreachable, > causing retries that add to the total number of referral events required > to locate the closest (by RTT) root server. > > The difficulty of comparing 1300 referrals triggers me to think of introducing special measures to Priming Exchange, such as the mechanism like CDN/smart DNS to return a set of address (maybe less than 5) best suit for the resolver. Well, if that possible, that requirement makes Priming Exchange more special because it break the atomic principle of DNS. > > i share these research questions for four reasons. > > first, ZDNS and BII are ideally suited to investigate this matter in > your test bed. > > Thanks Paul. our discussion broadens and enrich our thinking on section 2.3 issue. We will continue working on that to explore the space for the question and answer . As to the draft, be aware the proposal is not particularly for the root NS number issue. Actually I realized in advance that if section 2.3 is too controversial I will think of remove or amend it. Davey > -- > Paul Vixie >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
