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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Tue, 26 Oct 2021 04:35:43 -0700

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.4. , paragraph 1, comment:
> 2.4.  Fragmentation and Truncation

Fragmentation and IP fragments getting dropped is one reason for needing more
retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0)
doesn't detect or recover from loss of any UDP packets making up the overall
message. That means that a normal packet loss (due to congestion or other
reasons) amplifies into loss of the entire DNS message.

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.

Section 4.2. , paragraph 3, comment:
>    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.

Again, the OS generally already imposes limits. Why recommend that DNS
implementations self-impose other (lower?) limits?

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.

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.

Section 4.2. , paragraph 3, comment:
>    DNS server software MAY provide a configurable limit on the number of
>    transactions per TCP connection.

What does that limit protect against?

Section 4.2. , paragraph 2, comment:
>    Similarly, DNS server software MAY provide a configurable limit on
>    the total duration of a TCP connection.

What does that limit protect against?

Section 4.5. , paragraph 3, comment:
>    Most open source 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
>    environments where most queries take place over TCP or TLS, 5000 is a
>    more appropriate limit.

20-150 is orders of magnitude less than I expected. Even 5000 seems very low,
given the capabilities of even low-end servers.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server".

 * Term "slave"; alternatives might be "follower", "peripheral", "replica",
   "responder", "secondary", "standby", "worker".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Abstract", paragraph 2, nit:
>  document also considers the consequences with this form of DNS communicatio
>                              ^^^^^^^^^^^^^^^^^
The usual preposition to use after "consequences" is not "with". Did you mean
"consequences of", "consequences for", or "consequences on"?

Section 2.4. , paragraph 7, nit:
> ctions occur without interference. However there has also been a long-held be
>                                    ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 5. , paragraph 4, nit:
> e no reported problems during the two month period when the old key was publi
>                                   ^^^^^^^^^
When a number forms part of an adjectival compound, use a hyphen.

Section 11.2. , paragraph 54, nit:
> s explain why DNS over TCP may often have been treated very differently than
>                                ^^^^^^^^^^^^^^^
The adverb "often" is usually put between "have" and "been".

Section 11.2. , paragraph 60, nit:
> teworthy, perhaps less common today then when this document was written, it
>                                     ^^^^
Did you mean "than"?

Reference [RFC2671] to RFC2671, which was obsoleted by RFC6891 (this may be on
purpose).

Document references draft-ietf-dnsop-avoid-fragmentation-04, but -05 is the
latest available revision.

Reference [RFC5966] to RFC5966, which was obsoleted by RFC7766 (this may be on
purpose).

Reference [RFC0883] to RFC883, which was obsoleted by RFC1034 and RFC1035 (this
may be on purpose).

Reference [RFC2541] to RFC2541, which was obsoleted by RFC4641 (this may be on
purpose).

These URLs in the document can probably be converted to HTTPS:
 * http://verisign.com

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 29 Oct 2021 20:53:58 +0000

Lars, thank you for the review.  

Some of your easier comments and suggestions have been addressed, but for some of them will require more thought and attention.  I am waiting to coordinate with my coauthor, and possibly the WG chairs.

> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker <[email-masked]> wrote:
> 
> 

How does this new paragraph look to you?

       <t>Note that a receiver is unable to differentiate between packets
       lost due to congestion and packets (fragments) intentionally
       dropped by firewalls or middleboxes.  Over network paths with
       non-trival amounts of packet loss, larger, fragmented DNS responses
       are more likely to never arrive and time out compared to smaller,
       unfragmented responses.  Clients might be misled into retrying
       queries with different EDNS(0) UDP packet size values for the
       wrong reason.</t>

> Found terminology that should be reviewed for inclusivity; see

Thanks, changed to primary and secondary.

> address in some way - or ignore - as you see fit.

These have all been accepted, except for the cases where we do intentionally refer to obsoleted RFCs.

DW