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

Lars Eggert via Datatracker <noreply@ietf.org> Tue, 26 October 2021 11:35 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F35893A0A1F; Tue, 26 Oct 2021 04:35:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-dns-tcp-requirements@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Suzanne Woolf <suzworldwide@gmail.com>, suzworldwide@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <163524814397.6773.7925615506385048342@ietfa.amsl.com>
Date: Tue, 26 Oct 2021 04:35:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PbVQeO3SGfWUdeSe6cuVQORRbbQ>
Subject: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2021 11:35:44 -0000

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:


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?


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.


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

 * 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

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

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

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