Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Joe Abley <[e-mail]>]

On Nov 8, 2021, at 17:35, Wessels, Duane <dwessels=[e-mail]> 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.

>  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.


Joe