Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 26, 2021 at 01:09:00PM -0700, Erik Kline via Datatracker wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-dnsop-dns-tcp-requirements-13: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [abstract vs. S1/S3, question]
> 
> * The abstract says:
> 
>    "...strongly
>    encourages the operational practice of permitting DNS messages to be
>    carried over TCP"
> 
>   while section 1 says:
> 
>    "...all DNS resolvers and recursive
>    servers MUST support and service both TCP and UDP queries"
> 
>   and section 3 also some MUST text.
> 
>   Should the abstract be updated to say MUST rather than just
>   "strongly encourages", or is there a subtly in here I'm missing?

"require" might be better than "MUST", on the principle that if a given
requirement is stated in more than one place, there is risk of inadvertent
skew between what is actually stated; such skew can cause interoperability
failure or security vulnerabilities if different implementations use the
differing behaviors.

-Ben

> [S4.1, comment]
> 
> * "Resolvers and other DNS clients should be aware that some servers
>    might not be reachable over TCP.  For this reason, clients MAY want
>    to track and limit the number of TCP connections and connection
>    attempts to a single server."
> 
>   I think the same comment could be made about paths to a server from
>   a given network, e.g., in the case of one network filtering TCP/53 for
>   some reason.
> 
>   I'm not sure how to best reword this to add a per-network notion to
>   TCP connection success tracking, but I did want to note that a mobile
>   client's measure of TCP connection success to a single server might
>   vary from network to network.  (for your consideration)
> 
> 
>