Ben Schwartz <[email protected]> writes: > 1. Root servers SHOULD offer open AXFR over TCP* (perhaps updating RFC > 7720).
There have been many discussions about RFC7720 in the past few years. One thing that has always come out of the discussions, right or wrong, is that RFC7720 should be restricted to mandatory and minimal service needs. IE, only MUSTs. Note that RFC7720 is an IAB document too, not a WG document. I don't think it can easily become a MUST because I don't know (we'd have to ask) if every RSO was willing to support AXFR. They don't all today, and there isn't a promise or requirement anywhere that says they have to in perpetuity. The RSS is designed primarily to support DNS over UDP and TCP, and AXFR is a fairly different transfer mechanism that isn't the best at efficiency (I've tested it with fairly large zones, and doing an AXFR across the planet of a fairly large ccTLD took an hour). > No HTTP, no URI schemes, no new registries, formats, or special IPs. Current implementations already support HTTP and seem to prefer it. Our HTTP infrastructure in the world has already proven to scale to the needs, where as we actually don't know if AXFR will. (ok, I've actually done some personal tests on our infrastructure that indicated it would for our infrastructure at least, but I can't promise that for all RSS infrastructure personally). By the important take away was hinted at by Michael: the new list gets out from underneath the limit of "there can be only 13" and separates out the zone distribution from the zone resolution services. Some RSOs may wish to support both, but there can be other zone distribution providers that aren't RSOs for resolution fallback as well. Zone file over HTTP has a number of advantages, according at least the views of a few people that I've talked with (and they should speak up here). One obvious one is negotiated compression (mentioned in the document) and potentially better global load balancing infrastructure. -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
