Last Call Review of draft-ietf-dnsop-dns-tcp-requirements-12
review-ietf-dnsop-dns-tcp-requirements-12-genart-lc-romascanu-2021-09-01-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-dns-tcp-requirements-12
Reviewer: Dan Romascanu
Review Date: 2021-09-01
IETF LC End Date: 2021-09-03
IESG Telechat date: Not scheduled for a telechat

Summary:

Ready with minor issues and editorial comments.

This document with intended status BCP updates RFC 1123 encouraging the
operational practice of permitting DNS messages to be carried over TCP on the
Internet. It is aligned with the implementation requirements in RFC 7766. It is
highly significant for the operators community as is the formal requirements
equivalent for the operational community, encouraging system administrators,
network engineers, and security staff to ensure DNS over TCP communications
support is on par with DNS over UDP communications and as it also considers the
consequences with this form of DNS communication and the potential operational
issues that can arise when this best current practice is not upheld.

This document is welcome and clear for anybody who is familiar with the field.
However, because of the long history it would be useful to think ahead for
readers that will read and use 5, 10 or 20 years from now. Hence, a few
editorial comments. I put them in the Nits/editorial category, but they are
really more than nits, so I recommend that the authors consider them, before
the document gets to the RFC Editor.

Major issues:

Minor issues:

1. In Section 4.1:

> DNS clients MAY also enable TFO when possible.

Maybe I do not fully understand the intent here, but 'MAY ... when possible'
sounds like a SHOULD to me.

2.In Section 4.2

>   DNS server software SHOULD provide a configurable limit on the total
   number of established TCP connections.  If the limit is reached, the
   application is expected to either close existing (idle) connections
   or refuse new connections.  Operators SHOULD ensure the limit is
   configured appropriately for their particular situation.

   DNS server software MAY provide a configurable limit on the number of
   established connections per source IP address or subnet.  This can be
   used to ensure that a single or small set of users cannot consume all
   TCP resources and deny service to other users.  Operators SHOULD
   ensure this limit is configured appropriately, based on their number
   of diversity of users.

The lack of recommendations about how these limits should be set would leave
less experienced operators in the dark. There is not even a sentence like 'This
document does not offer advice on particular values for such a limit' as for
other parameters in the same section. From an operators point of view I would
prefer a recommendation or one or more examples of how these limits can be set
in real life cases.

Nits/editorial comments:

1. Sections in the document that are obviously for informational pursposes
should be clearly marked so (like 'This section is included for informational
purposes only'). For example Section 2.

2. In Section 3:

Regarding the choice of limiting the resources a server devotes to
   queries, Section 6.1.3.2 in [RFC1123] also says:

      "A name server MAY limit the resources it devotes to TCP queries,
      but it SHOULD NOT refuse to service a TCP query just because it
      would have succeeded with UDP."

   This requirement is hereby updated: A name server MAY limit the
   resources it devotes to queries, but it MUST NOT refuse to service a
   query just because it would have succeeded with another transport
   protocol.

Similar alignment of the old and new text is desirable. Even using the OLD /
NEW format.