Davey Song wrote: > I try to express the idea: is there any possibility that if we can > breaks the rareness of Root servers. The arguments and disputes will > cease accordingly. Actually this idea is out of the scope of this draft.
i think there is an interesting research question here: how many root name servers is too many, and what are the limitations, and what is the optimal number of root name servers? 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. RDNS servers who perform round trip measurements to each potential name server for each zone cut would have a lot more state to maintain, but that state would not be large by today's standards (DNSSEC signatures have bloated RDNS memory footprints far more, without concern.) 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. if 1300 is obviously too many, why? what's the optimal number of root name servers for an RDNS population estimated to be about 40M? does the optimal number change when some share of root name servers are widely anycasted? i share these research questions for four reasons. first, ZDNS and BII are ideally suited to investigate this matter in your test bed. second, there is no evidence at present that "13" is too many or too few root servers. third, this line of thinking is what led to my ICANN ITI proposal involving only two root name server identities, each of which being massively and hierarchically anycasted. fourth, because without an answer to these research questions, it's impossible to evaluate the cost and complexity tradeoff against increased internet resilience from pursuing your "tcp-primingexchange" proposal. -- Paul Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
