nominalism of standards (Re: TCP fallback on timeout)

[Markus Gutschke (顧孟勤)]

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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20170428/08874dee/attachment.htm>