Re: [DNSOP] AD review: draft-ietf-dnsop-dns-tcp-requirements

"Wessels, Duane" <dwessels@verisign.com> Wed, 14 July 2021 22:37 UTC

Return-Path: <dwessels@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C071A3A11DC; Wed, 14 Jul 2021 15:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRR0LJ7dIULy; Wed, 14 Jul 2021 15:37:34 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3063A11DE; Wed, 14 Jul 2021 15:37:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=12095; q=dns/txt; s=VRSN; t=1626302254; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=zqoO91i3CWC8uKQ4pJmZAAtxjpw2543yddRJNL2TRxo=; b=dawSEwduRlamYhAqYvS/AvkOVne26kZ85pqfOCUtf5UMBlqISoIakhKB 6uYdcLBzKKEsLPbNl6GGdTsNGf0V7jJCdS4CgVEe/sE9bmm1IW9AmpkQ/ XDxhC1y+153mGftJ8HVE6oMhscdiej6Ju5S/IObzMClicnPIuq6a3XtlW U56IsUq1ebCc+iB/PssC1FlK7vgZqSqwA+HFyiReKaF/qQUyF8QZ6x4TA EcDbZu5qEoSngeePOtlYmxaoOc6FaY5WkfwjOmF+HtJGAmAkFQVz9CBjW VcPnr58ttN7UHRELNqGxNpval3fw2/MQLYOm2W8mvcTf6LiuKHQUm4CPX A==;
IronPort-SDR: Ki8hSIKjpWeOyVgzmVpLweo1lkT250COsXAnz/JSOFAhzorONWycmaL4R0Wyjq5uOfJLCE91jc /12yQZ6YY0GYfGRSCdsegXBBbWcneFg+RmNBH+7Y6eduiUfTDo/KJm3A5qKfOKc1d9BvfKETIz dKwZ3RkWcjC4R52lHErvjz/RJw/r2Tdh5TpGwtXAMnqkKEGT3N8kAU+8jzUndUAS8tvKDmBrGW uc0toaZUfQ0gBdrAD5CByxfhpHD+9kIyOTZJcwEbjZsCX8yYL+k8sJtawoHTnUgTX5EgMJtZwt 7ao=
IronPort-HdrOrdr: A9a23:TugJoqwBK5xzvhp5xUaTKrPwD71zdoMgy1knxilNoERuA6ilf8 DHppgmPGzP+VEssRAb6Kq90ca7IU80maQe3WBVB8bGYOCEghrUEGgB1/qA/9SIIUSXndK1l5 0QEZSWY+eeMbEOt6fHCX6DferIruPrzEniv5a5854kd3ASV0nxhz0JcjpzPHcGPzV7OQ==
X-IronPort-AV: E=Sophos; i="5.84,240,1620705600"; d="p7s'?scan'208"; a="8351249"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 14 Jul 2021 18:37:28 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%12]) with mapi id 15.01.2242.010; Wed, 14 Jul 2021 18:37:28 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Warren Kumari <warren@kumari.net>
CC: dnsop <dnsop@ietf.org>, "draft-ietf-dnsop-dns-tcp-requirements@ietf.org" <draft-ietf-dnsop-dns-tcp-requirements@ietf.org>
Thread-Topic: [EXTERNAL] AD review: draft-ietf-dnsop-dns-tcp-requirements
Thread-Index: AQHXePh6JwlTjFnTQ0O08MSfVrzj/6tDUsKA
Date: Wed, 14 Jul 2021 22:37:28 +0000
Message-ID: <3E270EE8-62A5-44E1-B3A5-B0418C018D6D@verisign.com>
References: <CAHw9_iJOovKwVcSs_+jNZ5hQE9exWshpESpVmDfLEhB6wY=25A@mail.gmail.com>
In-Reply-To: <CAHw9_iJOovKwVcSs_+jNZ5hQE9exWshpESpVmDfLEhB6wY=25A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.7)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_88A3CC84-60C8-4A0F-8ED5-CC84F7C7A51C"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7SHCk1DDoMQbhu7IlkFLssdVcH0>
Subject: Re: [DNSOP] AD review: draft-ietf-dnsop-dns-tcp-requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 14 Jul 2021 22:37:40 -0000

Thanks Warren, I made all of your proposed changes.  Here's a rewrite of the DNS wedgie paragraph:

   Networks that filter DNS over TCP may inadvertently cause problems
   for third-party resolvers as experienced by [TOYAMA].  For example, a
   resolver receives queries for a moderately popular domain.  The
   resolver forwards the queries to the domain's authoritative name
   servers, but those servers respond with the TC bit set.  The resolver
   retries over TCP, but the authoritative server blocks DNS over TCP.
   The pending connections consume resources on the resolver until they
   time out.  If the number and frequency of these truncated-and-then-
   blocked queries is sufficiently high, the steady-state of lost
   resources as a result is a "DNS wedgie."  A DNS wedgie is generally
   not easily or completely mitigated by the affected DNS resolver
   operator.


DW


> On Jul 14, 2021, at 2:36 PM, Warren Kumari <warren@kumari.net> wrote:
> 
> 
> Hi there authors (and WG),
> 
> Firstly, thank you very much for this document -- I think that it's a
> useful document, although I'm a bit sad that it's needed :-)
> 
> I do have a number of editorial comments/ nits. Addressing these
> before IETF LC and IESG review should make progressing the document
> easier and smoother...
> 
> 
> 2.  History of DNS over TCP
> 
>   The curious state of disagreement in operational best practices and
> [O] disagreement in operational best practices
> [P] disagreement between operational best practices
> [R] clarity — I *think* this is what’s meant?
> 
>   guidance for DNS transport protocols derives from conflicting
>   messages operators have gotten from other operators, implementors,
>   and even the IETF.  Sometimes these mixed signals have been explicit,
>   on other occasions they have been suspiciously implicit.  This
> [O] explicit,
>   on other occasions they have been suspiciously implicit.
> [P] explicit; on other occasions, conflicting messages have been implicit.
> [R] semicolon for grammar (otherwise it’s a run on sentence). Consider
> dropping “suspiciously” — feels odd/awkward in this context.
> 
> Section 2.2
> "[...] it is also clear that some new DNS record types defined in
>      the future will contain information exceeding the 512 byte limit
>      that applies to UDP, and hence will require TCP.
> [R]: Nit - please add closing quote...
> 
> 
> 
> Section 2.3.
> EDNS(0) became widely deployed over the next
>   several years and numerous surveys ([CASTRO2010], [NETALYZR]) have
> [O] several years and numerous surveys
> [P] several years, and numerous surveys
> [R] grammar
> 
> While a non-negligible population of DNS systems lacked
>   EDNS(0) or fell back to TCP when necessary, DNS clients still
>   strongly prefer UDP to TCP.  For example, as of 2014 DNS over TCP
> 
> [O] For example, as of 2014 DNS
> [P] For example, as of 2014, DNS
> [R] clarity
> 
> 
> Section 2.4. Fragmentation and Truncation
> 
>   For IPv6, the situation is a little more complicated.  First, IPv6
>   headers are 40 bytes (versus 20 without options in IPv4).  Second, it
>   seems as though some people have mis-interpreted IPv6's required
> 
> [O] mis-interpreted
> [P] misinterpreted
> 
> 
> 2.5.  "Only Zone Transfers Use TCP"
> 
> "A popular meme has also held the imagination of some: that
> DNS over TCP is only ever used for zone transfers and is generally
>   unnecessary otherwise, with filtering all DNS over TCP traffic even
>   described as a best practice."
> [R]: I find the phrasing of this odd -- do memes hold people's
> imagination? Perhaps just "A popular meme is..."? Or even "Many people
> erroneously believe ..." ?
> 
> 
> However modern
>   standards and implementations are nearing parity with the more
> 
> [O] However modern
> [P] However, modern
> [R] grammar/readability
> 
>   sophisticated TCP management techniques employed by, for example,
>   HTTP(S) servers and load balancers.
> 
> 3.  DNS over TCP Requirements
> 
>   An average increase in DNS message size (e.g., due to DNSSEC), the
>   continued development of new DNS features (Appendix A), and a denial
>   of service mitigation technique (Section 9) show that DNS over TCP
> 
> [O] (Section 9) show that DNS
> [P] (Section 9), all show that DNS
> [R] readability
> 
> 
> 4.2.  Connection Management
> 
> This can be used to ensure that a single or small set of users can
> not consume ...
> [O] can not
> [P] cannot
> [R] spelling/clarity
> 
> 5.  DNS over TCP Filtering Risks
> 
> Therefore, filtering of DNS over TCP is considered harmful
>   and contrary to the safe and successful operation of the Internet.
>   This section enumerates some of the known risks known at the time of
> [O] known risks known at the time
> [P] known risks as of the time
> [R] readability
> 
>   this writing when networks filter DNS over TCP.
> 
> 
> 5.1.  DNS Wedgie
> 
> [O] If, for
>   instance, a resolver receives a truncated answer from a server, but
>   when the resolver resends the query using TCP and the TCP response
>   never arrives, not only will a complete answer be unavailable, but
>   the resolver will incur the full extent of TCP retransmissions and
>   timeouts.
> [R] is it possible to break this into multiple sentences? It's a
> little hard to parse....
> 
> 
> 
> Thank you very much - we are during posting cutoff, so please SHOUT
> LOUDLY once you've posted a new version and I'll progress it....
> W
> 
> 
> -- 
> Perhaps they really do strive for incomprehensibility in their specs.
> After all, when the liturgy was in Latin, the laity knew their place.
> -- Michael Padlipsky