You're off course right about the long tail of outdated devices. But you should have more trust into what can happen, if only there is sufficient incentive.
Look at how long it took for HTTPS to get any meaningful traction. For the longest time, only e-commerce bothered with encryption. Then we had Snowden, Letsencrypt, and the browser-manufacturers/search-engines getting a lot more strict about encryption. And all of a sudden, people either upgraded their ancient software, installed a proxy that hides the limitations from the internet at large, or switched to a cloud provider that ensures modern standards. I'm sure the same would happen if you gave people enough incentive to switch to TCP enabled name servers. Many administrator would probably discover that they already support TCP or could do so with minimal effort. And the rest would use one of the approaches outlined above. As an example for how to provide this incentive, imagine Letsencrypt requiring TCP. Half a year from now, they won't allow new accounts without TCP support. A year from now, they won't sign new domains unless they can be verified by TCP. And two years from now, even certificate renewals require TCP. If this policy was advertised clearly enough, I'd expect the transition to work just fine. The last stragglers are then the same people who wouldn't use Letsencrypt in the first place, as they haven't even made the switch to HTTPS yet. You'll never completely eliminate the long tail. But you shouldn't fear it either. Markus On Apr 28, 2017 16:50, "Paul Vixie via Unbound-users" < unbound-users@unbound.net> wrote: Paul Vixie wrote: > > >> ... > > > > > > i'll go further: i think that's a good clarification of and alteration > > > to the standards. i just don't think it's wise to expect a tcp-only > > > initiator, or a tcp-only responder, to function reliably. (ever.) so the > > > standard is nominal, and should guide other standards, but in this case > > > may give unusable guidance to implementers and operators. > > > let me put that differently and perhaps more understandably: > > > <<That having been said, a stronger document set written today would not > > be able to put all of the DNS genies back into their bottles. Too many > > implementations have guessed differently when presented with a loose > > specification, and interoperability today is a moving, organic target. > > When I periodically itch to rewrite the specification from scratch, I > > know there are too many things that must be said that also cannot be > > said. It’s as though, in a discussion of the meaning of some bit > > pattern, a modern description of the protocol—written with full > > perspective on all that has been done in the DNS field—would have to > > say, “It could mean x but some implementations will think it means y so > > you must be cautious.”>> > > > http://queue.acm.org/detail.cfm?id=1242499 > > > -- > > P Vixie > >