Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Lars Eggert <[e-mail]>]

Hi,

thanks for the detailed response. I have a few comments below, and I've trimmed everything from this reply where I agree with the resolution you proposed in your response.

On 2021-11-30, at 1:53, Wessels, Duane <[e-mail]> wrote:
>> Section 4.2. , paragraph 3, discuss:
>>>  Since host memory for TCP state is a finite resource, DNS clients and
>>>  servers MUST actively manage their connections.  Applications that do
>>>  not actively manage their connections can encounter resource
>>>  exhaustion leading to denial of service.  For DNS, as in other
>>>  protocols, there is a tradeoff between keeping connections open for
>>>  potential future use and the need to free up resources for new
>>>  connections that will arrive.
>> 
>> For it to contain a MUST-level requirement, this section needs to give a lot
>> more concrete guidance on what it means to "actively" manage connections. Most
>> operating systems by default impose some application limits that usually
>> effectively prevent DOS or other resource exhaustion issues. Is the intent here
>> that DNS implementations need to do more? If so, what?
> 
> I can easily be convinced that SHOULD is more appropriate than MUST here.

I think that would be better, esp. for clients and because the "actively manage" term is still unclear to me - it seems to mean "must implement (some of) the limits below"?

> I dont necessarily agree that operating systems alone do a very good job
> of preventing DOS conditions.  It is possible that Im not up-to-date on
> the latest and greatest in terms of operating system features, but I think
> historically applications have fared better when they manage their own
> connections.  For example, can we realistically expect the OS to know which
> idle connections should be closed?

The OS will certainly try to close sufficient connections under DDoS to remain operational. But if an application wants to see connections closed according to a certain policy - and DNS servers probably would - they need to actively engage. Maybe that's the rationale here?

(Also, Linux and other major OSs these days handle very large numbers of TCP connections just fine, I think I recall seeing numbers up to a million for Linux (assuming sufficiently beefy hardware). And deployments that needs to handle such connection counts would normally load-balance into a server cluster anyway. So I remain a bit unconvinced that the limits described in this doc are all that important. But that's just a comment and I'm certainly not going to block the document over this.)

>> Section 3. , paragraph 1, comment:
>>> 3.  DNS over TCP Requirements
>> 
>> While the history preceding this section is interesting for context, I think
>> moving this section up would increase readability significantly.
> 
> Okay with me.  I would like to hear from the Chairs.

I'm OK with whatever resolution they prefer.

>> Section 4.2. , paragraph 3, comment:
>>>  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
>>>  and diversity of users.
>> 
>> This limit only begins to establish fairness once the overall number of
>> permitted connections is reached. Until that point, it possibly limits client
>> performance without any benefit.
> 
> I suppose this depends on how it is implemented and there are lessons to be
> learned from the world of IP QOS.
> 
> I surveyed open source DNS server code and their developers and found that only
> one implements this limit and ships with no limit by default.
> 
> Perhaps this current (updated) paragraph is better:
> 
>   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.  Note, however, that
>   if this limit is enabled, it possibly limits client performance while
>   leaving some TCP resources unutilized.  Operators SHOULD be aware of
>   these tradeoffs and ensure this limit, if configured, is set
>   appropriately based on the number and diversity of their users, and
>   whether users connect from unique IP addresses or through a shared
>   Network Address Translator [RFC3022].
> 
>> Section 4.2. , paragraph 3, comment:
>>>  DNS server software SHOULD provide a configurable timeout for idle
>>>  TCP connections.  For very busy name servers this might be set to a
>>>  low value, such as a few seconds.  For less busy servers it might be
>>>  set to a higher value, such as tens of seconds.
>> 
>> Ditto.
> 
> In this case all of the open source implementations I surveyed have this
> limit enabled by default.

It might be useful to add a brief note similar to the one above here as well.

Thanks,
Lars