Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Joe Abley <[e-mail]>]

Hi Suz,

On 18 Apr 2021, at 19:17, Suzanne Woolf <[e-mail]> wrote:

> This message starts the Working Group Last Call for draft-ietf-dnsop-tcp-requirements (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/>)

I have read draft-ietf-dnsop-dns-tcp-requirements-07 and have the following comments, in flagrant defiance of George's advice to ship the document based mainly on considerations of age. :-)

I think these are all fairly minor.


Abstract, Section 4.4 "DNS-over-TLS"

The abstract includes the sentence "This includes both DNS over unencrpted TCP, as well as over an encrypted TLS session." The later section 4.4 says "this document applies equally well to DNS-over-TLS'.

The inclusion of DoT looks like an afterthought that has not been entirely afterthought-through. The procedural updates to 1034 in section 3 clearly don't apply to RFC 7858; the justifiable confusion about transports in the DNS (the main topic of this document) also doesn't apply to 7858 which only specifies use of TLS, not DTLS.

I suggest that this document is really only concerned with strengthening the requirements around the use of TCP transport as described in 1034 and 1035 and that mentioning any other transport is unhelpful and arguably introduces more confusion. I think that sentence should be changed in the abstract to reflect that and section 4.4 should be removed. I would not be surprised to hear that this DoT text was added precisely to address some other earlier reviewer's opinion to the contrary, but this is what I think.

While we're at it, I think this document *requires* the practice of permitting TCP transport; it doesn't simply encourage it. So how about:

OLD:

   This document encourages the practice of permitting DNS messages to
   be carried over TCP on the Internet.  This includes both DNS over
   unencrypted TCP, as well as over an encrypted TLS session.  The
   document also considers the consequences with this form of DNS
   communication and the potential operational issues that can arise
   when this best current practice is not upheld.

NEW:

   The specification of the DNS allows both UDP and TCP to be used 
   as transport protocols for exchanging unencrypted DNS messages.
   However, for various reasons, the availability of TCP transport
   has sometimes been interpreted as being optional.  This document 
   clarifies the need to provide TCP transport for both clients and
   servers and strengthens the requirement of DNS implementations
   to support both.


2.3 EDNS0

RFC 6891 uses the notation EDNS(0), not EDNS0. Since 6891 obsoletes 2671 it seems reasonable to adopt its notation. I suggest going all search and replace on that.


2.4 Fragmentation and Truncation

The second paragraph does not mention another fundamental problem with stateless protocols over IPv6 when datagrams require truncation, which is that the requirement in v6 to fragment and resent from the source is not possible when the source has not retained any state regarding to the response that was just sent. While I had my hands in the patient I also added a small reference to tunnel encaps in IPv4.

OLD:

   For IPv4-connected hosts, the de-facto MTU is often the Ethernet
   payload size of 1500 bytes.  This means that the largest unfragmented
   UDP DNS message that can be sent over IPv4 is likely 1472 bytes.  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
   minimum MTU of 1280 as a required maximum.  Third, fragmentation in
   IPv6 can only be done by the host originating the datagram.  The need
   to fragment is conveyed in an ICMPv6 "packet too big" message.  The
   originating host indicates a fragmented datagram with IPv6 extension
   headers.  Unfortunately, it is quite common for both ICMPv6 and IPv6
   extension headers to be blocked by middleboxes.  According to
   [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to
   receive a fragmented IPv6 packet.

NEW:

   For IPv4-connected hosts, the MTU is often the Ethernet payload
   size of 1500 bytes.  This means that the largest unfragmented
   UDP DNS message that can be sent over IPv4 is likely 1472 bytes,
   although tunnel encapsulation may reduce that maximum message
   size in some cases.

   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 minimum MTU of 1280 as a required maximum.  Third,
   fragmentation in IPv6 can only be done by the host originating
   the datagram.  The need to fragment is conveyed in an ICMPv6
   "packet too big" message.  The originating host indicates a
   fragmented datagram with IPv6 extension headers.  Unfortunately,
   it is quite common for both ICMPv6 and IPv6 extension headers
   to be blocked by middleboxes. According to [HUSTON] some 37% of
   IPv6-capable recursive resolvers were unable to receive a
   fragmented IPv6 packet.  Even if the originating host does receive
   a signal that fragmentation is required, the stateless nature
   of the DNS protocol is such that the host does not generally
   retain a copy of the message concerned and hence is unable to  
   fragment and re-send anyway. 

The third paragraph refers to "BIND" without a reference. While it seems ridiculous to imagine that anybody my age would not know what BIND was (ignoring the distinction that has been made between BIND and BIND9) there are other popular products today and terrible young people who are wandering all over my lawn. I think a reference would be useful.

The fifth paragraph refers to "growing sentiment in the DNSSEC community" which would benefit from being anchored in time, ideally with a citation.


2.5 "Only Zone Transfers Use TCP"

Second paragraph: replace "historic" ("having importance in or influence on history") with "historical" ("based on past events or set in the past").


4.1 "Connection Establishment and Admission"

Third paragraph might benefit from a reference to RFC 5358/BCP 140.


Joe