> On Nov 8, 2021, at 4:24 PM, Joe Abley <jab...@hopcount.ca> wrote:
>
> Caution: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
> On Nov 8, 2021, at 17:35, Wessels, Duane
> <dwessels=40verisign....@dmarc.ietf.org> wrote:
>
>> Is this better?
>>
>> The use of TLS places even stronger operational burdens on DNS
>> clients and servers. Cryptographic functions for authentication and
>> encryption requires additional processing.
>
> Require, not requires. I know, I know.
Fixed!
>
>> Unoptimized connection
>> setup with TLS 1.3 [RFC8446] takes one additional round-trip compared
>> to TCP. Connection setup times can be reduced with TCP Fast Open,
>> and TLS False Start [RFC7918]. TLS session resumption does not
>> reduce round-trip latency becase no application profile for use of
>> TLS 0-RTT data with DNS has been published at the time of this
>> writing. However, TLS session resumption can reduce the number of
>> cryptographic operations.
>
> [...]
>
>> Agreed, hopefully this is better:
>>
>> o Authoritative servers MUST support and service TCP for receiving
>> queries, so that resolvers can reliably receive responses that are
>> larger than what fits in a single UDP packet.
>
> RFC 6891 anticipates reassembly and doesn't advise against setting a UDP
> payload size that would cause fragmentation (although it mentions that people
> should be careful). So "single UDP packet" seems a bit awkward, especially
> since in principle the size limit is 0xffff octets in both the UDP header and
> the corresponding EDNS(0) pseudo-header.
>
> This paragraph (and the ones that follow) seem like they are implying that
> large responses are the only reason to use TCP (which is surely just a
> side-effect of wording; I'm not suggesting the authors are unaware of other
> reasons). Using truncated responses as an example seems fine though.
>
> I don't think the taxonomy of "authoritative servers", "recursive servers"
> and "forwarders" is necessarily complete. The terminology in common usage is
> not tightly bound by common sense, and there is an apparently unlimited
> supply of words and phrases that people use to mean "a DNS thing attached to
> a network".
>
> This seems like it could be a job for "initiators" and "responders", except
> that in this case I think we're really talking about all DNS implementations,
> regardless of function. Hooray! Bullet dodged, maybe.
>
> How about something like:
>
> o All DNS implementations, regardless of function, MUST support and service
> TCP for sending and receiving queries, e.g. to accommodate the sending and
> receiving of DNS messages that are too large to handle using UDP without
> truncation.
Thanks for pointing this out. I agree that “single UDP packet” is problematic
and we missed this detail before.
Here’s how this text appeared in version 13:
o Authoritative servers MUST support and service all TCP queries so
that they do not limit the size of responses to what fits in a
single UDP packet.
o Recursive servers (or forwarders) MUST support and service all TCP
queries so that they do not prevent large responses from a TCP-
capable server from reaching its TCP-capable clients.
Based on Ben’s comments, I then proposed this:
o Authoritative servers MUST support and service TCP for receiving
queries, so that resolvers can reliably receive responses that are
larger than what fits in a single UDP packet.
o Recursive servers (and forwarders) MUST support and service TCP
for receiving queries, so their TCP-capable clients can reliably
receive responses that are larger than what fits in a single UDP
packet.
o Recursive servers (and forwarders) MUST support TCP for sending
queries, so that they can retry truncated UDP responses as
necessary.
And based on your further suggestions I think it makes sense to combine
authoritative and recursive together, but keep clients as a separate bullet:
o DNS servers (including forwarders) MUST support and service TCP
for receiving queries, so that clients can reliably receive
responses that are larger than what either side considers too
large for UDP.
o DNS clients MUST support TCP for sending queries, so that they can
retry truncated UDP responses as necessary.
“what either side considers too large for UDP” is an oblique reference to
EDNS(0) UDP buffer size parameters.
How does that strike you?
DW
>
>
> Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
