Re: [Gen-art] [DNSOP] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Petr Špaček <[e-mail]>]

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 <[e-mail]> 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