On 7/6/25 13:44, Joe Abley wrote:
On 6 Jul 2025, at 20:59, Tommy Jensen<[email protected]> wrote:
Thank you for responding. I'm confused because I sees these statements as
conflicting: (1) this isn't how protocols work, and (2) this is at least 10
years too soon. If (1) is true, I do not understand how (2) can be true.
I think you're only talking about the DNS protocol as it is used between an
application and a resolver. I don't think you are talking about the DNS
protocol as it is used between resolvers and authoritative servers. But I could
be wrong because you don't say that clearly.
I think Paul is saying that most applications don't make their own transport
choices, but instead inherit the decisions made by the administrator of the
local host or network. A protocol implemented by an application in this
environment doesn't have a way to influence the choice of DNS transport
protocol. It could really hope that UDP is not used but it doesn't usually have
a way to communicate that preference or for it to otherwise be actionable.
This depends on the stub resolver. I replied on another fork on this. In
general though, not all uses of the DNS are cleanly separated into
sometime app space above the resolver API. Also, I shouldn't have used
"protocol" when I correctly used "document" elsewhere.
Maybe your document is saying "don't take any special measures to accommodate DNS
over UDP" and just assume that the DNS will cope? If that's what it is saying,
perhaps it could say so more clearly.
Fair enough. Yes, that's what I was going for, with added context that
some "protocols" (procedures? extensions? mechanisms defined in new
docs, anyway) are intended to be implemented by DNS code bases directly,
making the coping in their control even if the resolver's APIs don't
give that control to callers.
If your document is saying something else, I don't find it very clear. Perhaps
"accommodate" needs to be spelt out a bit.
For what it's worth, although anecdotally I hear that TCP transport is broken
or unavailable more often than UDP transport, I don't remember the last time I
saw that myself. If other protocols are jumping through hoops to accommodate a
perceived inevitability of UDP transport I am sympathetic to the idea that they
shouldn't bother.
In my experiences from the last six years, TCP was viewed as a reliable
fallback whenever anything when wrong with UDP (unexpected messages from
the peer, TC=1, missing response rate too high). I will not claim to
have numbers to compare at scale though.
Joe
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
