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

[Warren Kumari <[e-mail]>]

On Wed, Jul 14, 2021 at 7:50 PM Warren Kumari <[e-mail]> wrote:

>
>
> On Wed, Jul 14, 2021 at 6:37 PM Wessels, Duane <[e-mail]>
> 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.
>

A reminder to publish a new version when able.

W


>
> Thanks again,
> W
>
>
>>
>>    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 <[e-mail]> 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
>>
>> --
> 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
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra