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
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
Paul Vixie 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
I think I agree, it's just that I think there's a difference between
"what is nominally adhering to the specifications as written" and
"what is good operational advice", and I perceived the statement which
started this to say something about the former ("DNS servers aren't
required to support TCP.").
If someone were to set up a new authoritative name server and asked me
if DNS over TCP is required to be supported also for non-AXFR queries,
I would without hesitation say "yes", and point to RFC7766 (thanks,
David, for finding the additional quote I was looking for, but could
not find off-hand). Its predecessor, RFC5966, said essentially the
same wrt. this requirement, and that document is now 7 years old, so
it would not be entirely unreasonable to expect implementors who
continue to maintain their products to have taken notice (although
that is perhaps ... somewhat optimistic if we're instead talking about
"all" implementors of "things which operate or ... interfere with
DNS").
However, as Paul says, expecting a recursive resolver which only does
TCP today to get a sufficiently good lookup success rate would be too
optimistic (of course depending on your target and environment).
However, that's not because the current collection of specs covering
DNS say that TCP/DNS is optional, it's because for a long time many
have (perhaps mistakenly) thought that TCP/DNS is only (or "would ever
be") needed for AXFR towards slave name servers.
In short, there's a difference between scripture and practice.
Regards,
- Håvard