In message <[email protected]>, Paul Vixie writes: > > Mark Andrews <mailto:[email protected]> > > Saturday, January 24, 2015 2:44 PM > > In message <[email protected]>, Paul Vixie writes: > > Pipeling over UDP has been standard practice between nameservers for > > 25 years. Why are we even worrying about whether it should be > > permitted over TCP? > > because tcp has been a fallback-only for all these years, and someone > who wasn't pipelining or wasn't checking txid would never have been > penalized for it. > > > ... > > > > We should also stop thinking of the installed base as something > > that cannot be changed. This is particularly true of authoritative > > servers. We can identify broken servers. We can inform their > > operators that they are broken. > > mark, you and i know better than anybody that this approach doesn't > work. it didn't work for lame delegation checking, it hasn't worked for > EDNS, and it's so much of a risk in DNSSEC that we're now discussing > ways that an RDNS operator can turn off validation for signed zones > rather than signal failures on failed lookups.
Actually we don't know that it won't work. It has not been tried at scale (and it works at the tld level) and delegations require the operator to know what they are doing. Installing a fixed server provided by your DNS vendor is a different type of request. Package managers have made upgrading nameserver versions a pretty trivial operation these days regardless of which vendor you use. This is more about telling the operator that they need to run the command to do the upgrade. > > RFC 1033 even detailed how to do > > this. > > RFC 1033's complaint process contemplated a network of about the size of > the pre-NSFnet "ARPAnet", and could have scaled anyway as far as the > size of the pre-commercial "NSFnet". it can work for Internet2. but it's > not going to work on the big-eye Internet as we know it today. > > paul > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
