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 <war...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
