On 07. 09. 21 18:46, Wessels, Duane wrote:
Dan, thanks for the review. Responses are inline.
On Sep 1, 2021, at 3:12 AM, Dan Romascanu via Datatracker <noreply@xxxxxxxx> wrote:
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.
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."
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.
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."
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
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."
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.
Done.
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.
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
