Subject: [Last-Call] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Wed, 01 Sep 2021 03:12:40 -0700

Reviewer: Dan Romascanu
Review result: Ready with Issues

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.

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 7 Sep 2021 16:46:06 +0000

Dan, thanks for the review.  Responses are inline.

> On Sep 1, 2021, at 3:12 AM, Dan Romascanu via Datatracker <[email-masked]> wrote:
> 
> 
> Minor issues:
> 
> 1. In Section 4.1:
> 

Originally this was "SHOULD ...  when possible" (meaning when
implemented/supported) but after conversations with tcpm this was changed
to MAY.  To avoid confusion with "when possible" I suggest we just drop
it so it will just say "DNS clients MAY also enable TFO."

> prefer a recommendation or one or more examples of how these limits can be set

Other reviewers called this out as well so I have added some recommended values.

For the limit on total number of connections: "Absent any other information,
150 is a reasonable value for this limit in most cases."

For the limit on connections per source address: "Absent any other
information, 25 is a reasonable value for this limit in most cases."

For the timeout on idle connections: "Absent any other information, 10
seconds is a reasonable value for this timeout in most cases."

> purposes only'). For example Section 2.

Done.

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

Good point.  Section 3 now looks like this:

   Section 6.1.3.2 in [RFC1123] is updated: All DNS resolvers and
   servers MUST support and service both UDP and TCP queries.

   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.

   Furthermore, the requirement in Section 6.1.3.2 of [RFC1123] around
   limiting the resources a server devotes to queries is hereby updated:

   OLD:

      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.

   NEW:

      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.

FYI we are tracking this in github at https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/4/files if that is helpful.

DW

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 8 Sep 2021 00:10:37 +0300

Hi Duane,

Thank you for your answer and for addressing my concerns. I am fine with
the proposed resolutions.

Regards,

Dan

On Tue, Sep 7, 2021 at 7:46 PM Wessels, Duane <[email-masked]> wrote:

> FYI we are tracking this in github at
> https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/4/files
> if that is helpful.
>
> DW
>
>

---

From: Petr Špaček <[email-masked]>
Date: Thu, 9 Sep 2021 16:09:35 +0200

> 150 is a reasonable value for this limit in most cases."

I think this "150" value is fine for plain/unencrypted DNS-over-TCP 
because UDP is still the main transport, but IMHO it is not applicable 
to recursives offering DNS-over-TLS.

Recursives with DoT should allow much more to avoid costly TCP 
handshakes and session resumption. It's perfectly possible to handle 
hundreds of thousands of DoT clients on one resolver (when configured 
appropriately, and yes, I did test this claim.)

Maybe this could use a clarification that 150 is good advice only if you 
_don't_ have any "TCP-only" clients, like e.g. DoT stubs?

Petr Špaček

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 13 Sep 2021 13:23:11 +0200

> [...]
> Maybe this could use a clarification that 150 is good advice only if 
> you _don't_ have any "TCP-only" clients, like e.g. DoT stubs?

I would not be so sure that DoT/DoH are the only cases.  What about busy 
authoritative servers?  You get 150 by default, and then some important 
RRset gets over the UDP limit (say, a DNSKEY rollover) and you get into 
problems due to overzealous connection limits.  IMHO 150 is extremely 
cheap for a (potentially) busy server.

--Vladimir | knot-resolver.cz