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

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Jul 2021 17:36:55 -0400

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

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 14 Jul 2021 22:37:28 +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 <[email-masked]> wrote:
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Jul 2021 19:50:54 -0400

On Wed, Jul 14, 2021 at 6:37 PM Wessels, Duane <[email-masked]>
wrote:

> Thanks Warren, I made all of your proposed changes.

Gadzooks that was fast!

  Here's a rewrite of the DNS wedgie paragraph:

Excellent, thank you, I find that much easier to parse.

Please let me know once you are able to submit it.

Thanks again,
W