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

["Wessels, Duane" <[e-mail]>]

> On Sep 7, 2021, at 9:42 AM, Mirja Kuehlewind <[e-mail]> wrote:
> 
> Thanks for the updates! One quick comment below.
> 
>> On 7. Sep 2021, at 18:23, Wessels, Duane <[e-mail]> wrote:
>> 
>>> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <[e-mail]> wrote:
>>> 
>>> And a more general comment on section 4.2: this section takes about various
>>> limits but doesn't recommend any values. I understand that there is not a
>>> one-fits-all solution here but not knowing how to set these values correctly
>>> might scared people aways from supporting TCP. So I think having a discussion
>>> either of default values or how to derives these values based on a certain
>>> configuration would be a very valuable contribution in this document.
>> 
>> I've added some recommendations to the paragraphs in section 4.2.
>> 
>> 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."
> 
> I think it would also make sense to explain a bit more why these values were taken and what considerations/“other information" can be used to make a different decisions. I know that might not be fully straight-forward but just providing “random” numbers might also only provide limited value.
> 
> Mirja


Mirja,

I have gathered some information from the open source implementations and written a new section to talk about defaults and recommended values (below).  The full document and diff from previous can be found in our github repo https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/tree/master/Versions

DW


4.5.  Defaults and Recommended Limits

   A survey of features and defults was conducted for popular open
   source DNS server implementations at the time of writing.  This
   section documents those defaults and makes recommendations for
   configurable limits that can be used in the absence of any other
   information.  Any recommended values in this document are only
   intended as a starting point for administrators that are unsure what
   sorts of limits might be reasonable.  Operators SHOULD use
   application-specific monitoring, system logs, and system monitoring
   tools to gauge whether their service is operating within or exceeding
   these limits, and adjust accordingly.

   Most open sorcue DNS server implementations provide a configurable
   limit on the total number of established connections.  Default values
   range from 20 to 150.  In most cases, where the majority of queries
   take place over UDP, 150 is a reasonable limit.  For services or
   enviroments where most queries take place over TCP or TLS, 5000 is a
   more appropriate limit.

   Only some open source implementations provide a way to limit the
   number of connections per source IP address or subnet, but the
   default is to have no limit.  For environments or situations where it
   may be neccessary to enable this limit, 25 connections per source IP
   address is a reasonable starting point.  The limit should be
   increased when aggregated by subnet, or for services where most
   queries take place over TCP or TLS.

   Most open source implementations provide a configurable idle timeout
   on connections.  Default values range from 2 to 30 seconds.  In most
   cases, 10 seconds is a reasonable default for this limit.  Longer
   timeouts improve connection reuse, but busy servers may need to use a
   lower limit.

   Only some open source implementations provide a way to limit the
   number of transactions per connection, but the default is to have no
   limit.  This document does not offer advice on particular values for
   such a limit.

   Only some open source implementations provide a way to limit the
   duration of connection, but the default is to have no limit.  This
   document does not offer advice on particular values for such a limit.