> On Apr 19, 2021, at 4:31 AM, Joe Abley <jab...@hopcount.ca> wrote: > > > Hi Suz, > > On 18 Apr 2021, at 19:17, Suzanne Woolf <suzworldw...@gmail.com> 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/) > > 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. :-)
Thanks Joe!
>
> 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.
IIRC, DNS-over-TLS was added to this draft following a working group discussion
at IETF 104. I can easily be convinced to remove it, but I would like to hear
more people supporting its removal. I know Tony Finch also already raised
questions about including DNS-over-TLS.
> 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.
Okay, done.
>
> 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.
Thanks, I've added your new text here.
But was the change of Geoff's numbers from 35% to 37% intentional? I got 35%
from this part of the cited article:
We saw 10,115 individual IPv6 addresses used by IPv6-capable recursive
resolvers. Of this set of resolvers, we saw 3,592 resolvers that
consistently behaved in a manner that was consistent with being unable
to receive a fragmented IPv6 packet.
Maybe we should meet in the middle (and I should round up) and call it 36%?
>
> 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.
Done.
>
> The fifth paragraph refers to "growing sentiment in the DNSSEC community"
> which would benefit from being anchored in time, ideally with a citation.
Cited the 2015 article "Making the Case for Elliptic Curves in DNSSEC" by
Rijswijk-Deij et. al.
>
>
> 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").
Done.
>
>
> 4.1 "Connection Establishment and Admission"
>
> Third paragraph might benefit from a reference to RFC 5358/BCP 140.
Done.
DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
