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."
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
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
