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

From: Suzanne Woolf <[email-masked]>
Date: Sun, 18 Apr 2021 19:17:04 -0400

Dear colleagues,

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/>)

Since this draft has not been recently discussed in the WG, we figure people might need to swap it back in, and we’re requesting BCP status. So the WGLC will end in three weeks (instead of the usual two), on 3 May.

Substantive comments to the list, please. It’s fine for minor edits to go direct to the authors.

We’d like to advance this but it needs some active support, so we need to hear from folks who have found it useful, especially implementers.

Thanks,
Suzanne
For the chairs

---

From: George Michaelson <[email-masked]>
Date: Mon, 19 Apr 2021 13:36:36 +1000

It's time to ship. I mean sure, if somebody who does detailed reading
has a killer problem I can see we'd talk it out but we're 7 revisions
in, its 4 years later, and it seems rational to document the
expectation this is modern DNS, and we do TCP as a MUST SUPPORT, Auth
and recursive.

Its overdue.

so +1 to ship

-G

On Mon, Apr 19, 2021 at 9:17 AM Suzanne Woolf <[email-masked]> wrote:
>
> Dear colleagues,
>
>
> 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/)
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Mon, 19 Apr 2021 07:31:49 -0400

Hi Suz,

> 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/draf…

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

---

From: John Kristoff <[email-masked]>
Date: Mon, 19 Apr 2021 06:57:35 -0500

On Mon, 19 Apr 2021 07:31:49 -0400

>    servers and strengthens the requirement of DNS implementations

Hi Joe,

Thanks for your careful read and thoughtful comments.  I would just
point out that there is already a document that specifically requires
this of the implementations, IETF RFC 7766.  This draft was
specifically aimed at operators, which have that document had
sidestepped "this document makes no specific requirements for
operators".  So maybe a simple "implementations" to "operators" change
of your text would work?

John

---

From: Joe Abley <[email-masked]>
Date: Mon, 19 Apr 2021 08:19:45 -0400

Hi John,

> operators".  So maybe a simple "implementations" to "operators" change

Oh, I missed that, sorry. Yes, I agree, "operators" makes sense.

Someone is going to ask whether this document, as a BCP, can update 1123 which pre-dates such designations as standard track. That person is not going to be me, however.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 19 Apr 2021 08:46:26 -0400

> We’d like to advance this but it needs some active support, so we need to hear from folks who have found it useful, especially implementers.

I didn't mention explicitly before, sorry, but I think this is a good document, it's useful and it should be published.

Joe

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Apr 2021 16:45:22 +0100

Suzanne Woolf <[email-masked]> wrote:
>
> This message starts the Working Group Last Call for
> draft-ietf-dnsop-tcp-requirements

I have read the draft and I am keen to see it published. Just the other
day I was having a discussion about whether TCP support is really needed,
and I wanted something stronger than RFC 7766 to point to.

The draft is readable and comprehensive. I like it.

Some minor and pedantic nits:

2.2:

   DNSSEC originally specified in [RFC2541]

I thought this should be RFC 2535 rather than the operational guidelines?

2.3:

   This unsigned 16-bit field specifies, in bytes, the maximum
   (possibly fragmented) DNS message size a node is capable of
   receiving.

I suggest adding "over UDP" to the end of the sentence (since the EDNS
buffer size doesn't restrict messages over other transports).

2.4:

Last 2 paragraph s re. avoiding fragmentation, it might be worth
suggesting minimal-any [RFC 8482].

4.3:

   the Linux kernel provides a number of "sysctl" parameters related to
   TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle,
   and net.ipv4.tcp_tw_reuse.

I believe that net.ipv4.tcp_tw_recycle is problematic and has been removed
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux#netipv4tcp_tw_recycle

4.4:

   Although DNS-over-TLS utilizes TCP port
   853 instead of port 53, this document applies equally well to DNS-
   over-TLS.

Um, how much of this document applies to DoT? Just the tuning advice, or
the requirement that TLS MUST be supported like TCP MUST be?

5:

re "DDoS mitigation techniques" would it be worth citing DNS RRL here as
well as in section 9?

10:

   Since DNS over both UDP and TCP use the same underlying message
   format, the use of one transport instead of the other does change the
   privacy characteristics of the message content

Missing "not"?

A:

Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
not sure how much UDP is used, but I certainly rely on 60+ KB updates.

Also RFC 8482 section 4.4 talks about possible different behaviour for ANY
queries over UDP compared to TCP.

A.8:

   [RFC3226] strongly argued in favor of UDP messages over TCP largely

I had to read this twice! How about "instead of" instead of "over"?

A.14:

I think there should be a note that RFC 5966 has been obsoleted by RFC
7766, with a cross-reference to A.21.

(that's all I spotted)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and
North Channel: Southeasterly 3 to 5 at first in west, otherwise
southwesterly 2 to 4, becoming variable 3 or less. Smooth or slight,
occasionally moderate near Mull of Kintyre. Occasional rain. Good,
occasionally moderate.

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 19 Apr 2021 18:34:12 +0200

> 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/)

This is a good document.

One comment here:

   The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept
   filter" feature ([accept_filter]) that postpones delivery of TCP
   connections to applications until a complete, valid request has been
   received.  The dns_accf(9) filter ensures that a valid DNS message
   is received.  If not, the bogus connection never reaches the
   application.  Applications must be coded and configured to make use
   of this filter.

While it's good to point out that this feature exists, I do not think
mandating it makes sense - implementers and operators might have other
preferences for handling open-but-as-yet-unused TCP connections. (Also
the lowercase 'must' is confusing.)

Suggested extra text:

> The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
provide some of the same benefits as the BSD accept filter feature.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 19 Apr 2021 18:40:15 +0200

>    fragment and re-send anyway. 

This note on statelessness is good, but I don't think it should be tied to IPv6. Packets get lost in IPv4 too, especially when they are big, and even if such evens trigger a report in the form of an ICMP message, the same lack-of-state problem applies.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ even proposes setting DONTFRAG socket options, and some servers out there already send IPv4 replies with the DF bit set (the two I can verify immediately are OpenDNS, and whatever is running on the router my provider gave me, but most likely there are others too).

Kind regards,

---

From: Joe Abley <[email-masked]>
Date: Mon, 19 Apr 2021 13:16:53 -0400

> This note on statelessness is good, but I don't think it should be tied to IPv6. Packets get lost in IPv4 too, especially when they are big, and even if such evens trigger a report in the form of a…

In IPv4, datagrams that need to be transmitted over a link with an MTU is too low are fragmented by the router attached to the link, assuming DF=0. There is no signal sent back to the source in that case. In IPv6 that doesn't happen.

In the v4 case a large DNS message (large enough to require fragmentation along the path) can be transmitted without the source having to retain any state. That's not true in v6.

So I think the v4 and v6 cases are different. That's why I attached that comment to the v6 case.

DNS messages can be lost in both v4 and v6 for a variety of other reasons, I agree.

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ even proposes setting DONTFRAG socket options, and some servers out there already send IPv4 replies with the DF bit set (the t…

Setting DF=1 does seem like it would avoid the differences I was trying to allude to above, I agree. With DF=1 fragmentation (or not-fragmentation) is just another reason for a packet to get dropped.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Mon, 19 Apr 2021 11:47:05 -0700

On Sun, Apr 18, 2021 at 4:17 PM Suzanne Woolf <[email-masked]>
wrote:

> Dear colleagues,
>
>
> 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/)
>
> Since this draft has not been recently discussed in the WG, we figure
> people might need to swap it back in, and we’re requesting BCP status. So
> the WGLC will end in three weeks (instead of the usual two), on 3 May.
>
> We’d like to advance this but it needs some active support, so we need to
> hear from folks who have found it useful, especially implementers.
>

I have found it useful, and am strongly in favor of advancing this as a BCP.
I concur with the on-list comments from everyone on updates, too.

Brian

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 19 Apr 2021 19:59:31 -0400

(no hats on)

I've read this, and I agree it should move forward.
Should there be a reference to RFC8499 in here as well?

(with chairs hat on)

Mr Finch made some editorial nits that I concur with.  I also ran the Nits
tool and found several outdated references,
among other things.  I've requested that the authors fix these up before it
ends up heading to the IESG.

tim

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Apr 2021 18:27:43 +0000

> We’d like to advance this but it needs some active support, so we need to hear from folks who have found it useful, especially implementers.

It is indeed useful, and should be published. However, the wording in the draft needs to be updated about living in the world where TCP is already required. RFC 7766 has been a standard for over five years, but some parts of draft-ietf-dnsop-tcp-requirements, notably the abstract and introduction, use words that indicate that support for TCP is not necessary mandated. All this text should be updated before the document goes to IETF Last Call. If others agree, I would be happy to help the authors find and replace the weak requirements language.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Wed, 21 Apr 2021 14:59:40 -0400

On 21 Apr 2021, at 14:27, Paul Hoffman <[email-masked]> wrote:

> It is indeed useful, and should be published. However, the wording in the draft needs to be updated about living in the world where TCP is already required. RFC 7766 has been a standard for over five years, but some parts of draft-ietf-dnsop-tcp-requirements, notably the abstract and introduction, use words that indicate that support for TCP is not necessary mandated.

The nuance that jtk pointed out on Monday was that 7766 largely punts on requirement for operators and instead focuses on requirements for implementers with updates on the standards track:

   Whilst this document makes no specific requirements for operators of
   DNS servers to meet, it does offer some suggestions to operators to
   help ensure that support for TCP on their servers and network is
   optimal.  It should be noted that failure to support TCP (or the
   blocking of DNS over TCP at the network layer) will probably result
   in resolution failure and/or application-level timeouts.

This document seeks to provide the same strong requirements language for operators, with updates as a BCP. That seems reasonable to me. The operational guidance in this document certainly seems to me usefully to fill a gap.

I think I just spaced on the distinction during my Monday-morning review, but I suppose I might not be the only one, and that might be a sign that this document needs to make that point more forcefully.

Joe

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 21 Apr 2021 23:29:19 +0000

> On Apr 19, 2021, at 4:31 AM, Joe Abley <[email-masked]> wrote:
> 
> 
> Hi Suz,
> 

Thanks Joe!

> 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 un…

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.

> 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.

>    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…

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.

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

Done.

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

Done.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 21 Apr 2021 23:39:17 +0000

> On Apr 19, 2021, at 8:45 AM, Tony Finch <[email-masked]> wrote:
> 

Sure, 2535 works for me.

Done.

> suggesting minimal-any [RFC 8482].

I did add 8482 to the Appendix as you also suggested below.  I'm a little reluctant to
add a reference in section 2.4 since I think the primary motivation for 8482 was about
DDoS amplification, rather than fragmentation.   But I could still be convinced otherwise.

> https://secure-web.cisco.com/1zq_T2G9VjiDGyCD0UqiwfZ7i0Jc_JcoiRaUvHdWj_Nfh6pjxxQygRKERClmruWq9Yie54GznGNn-TR0ijjBYdidyWjP-mbPF5EWAwdDtalD86OTC3Z--zQWHcwkJtpdtD_iHBJqo4tRAddX5cQM8cJpMFTDMKKcXx-upQpjW14N1FwLeCniHz9apzZbWcIvZ_xlx3UDB4cvVJmNXzOZni24brGiihUnUPzUOipM8mAlwkq7ZuVgFJYRfKCc4DjCjiBYP9m5stLbRNYinc72Nlw/https%3A%2F%2Fvincent.bernat.ch%2Fen%2Fblog%2F2014-tcp-time-wait-state-linux%23netipv4tcp_tw_recycle

I removed tcp_tw_recycle.

> re "DDoS mitigation techniques" would it be worth citing DNS RRL here as

Hows this?

   message sizes, lack of EDNS(0) support, DDoS mitigation techniques
   (including [RRL]), or perhaps some future capability that is as yet

>   privacy characteristics of the message content

Yes indeed.

> not sure how much UDP is used, but I certainly rely on 60+ KB updates.

I probably don't have enough direct experience with UPDATE to say.  If it is largely
over TCP then I think it should be included.

> queries over UDP compared to TCP.

RFC 8482 has been added to the appendix.

> I had to read this twice! How about "instead of" instead of "over"?

yes, agreed.

Done.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 21 Apr 2021 23:47:43 +0000

> On Apr 19, 2021, at 9:34 AM, Peter van Dijk <[email-masked]> wrote:
> 
>> This message starts the Working Group Last Call for draft-ietf-dnsop-tcp-requirements (https://secure-web.cisco.com/1GUztR-Nd5B-MpjncjmDNOnqlKoeK5-09UeTvbL1dFyQqc0x3GpwWIzNUMvS9B4MsWztiWQY9T4fEg5m6LLL1pIw6mIP3Glh5Dv0eS5QuBH0_Er0tAvzCWC4zQmflkrgxR33_ZI_bjrpDA44xWmAs5GaN2Xu6HgIlfNUxBYXJzJjwsgJ_xviwCeTT7debqaByK_Oko0XxsVpateA6jVRS5dByfqyYMX03JeB_kJbfBGxtfsoWTcBVWSYTpsCG7_KrY8EWi3H9J7_369rrwCogbQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F)
> 
> This is a good document.
> 
> One comment here:
> 

It was not intended as a requirement, but rather to note that the application 
needs to do some work to utilize them.  Hows this?

       These features are implemented as low-level socket options.
       It is necessary for applications to be specifically coded and
       configured to make use of them.

> provide some of the same benefits as the BSD accept filter feature.

Added, thanks.

DW

---

From: Peter van Dijk <[email-masked]>
Date: Thu, 22 Apr 2021 13:52:04 +0200

On Wed, 2021-04-21 at 23:47 +0000, Wessels, Duane wrote:
> needs to do some work to utilize them.

Ah! That makes a lot more sense, yes.

>        configured to make use of them.

To my non-native eyes this still smells like 'you should do this'.

How about:

These features are implemented as low-level socket options, and they
are not activated automatically. If applications wish to use these
features, they will need to make specific calls to set the right
options, and administrators may need to configure the applications to
make these calls.

Kind regards,

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 22 Apr 2021 18:38:22 +0000

> On Apr 21, 2021, at 4:39 PM, Wessels, Duane <dwessels=[email-masked]> wrote:
> 
>> 2.2:
>> 

Oops, correcting myself here.  It needs to be RFC 2541 because that is the
one that mentions TCP.  The text has been updated like this:

   and the second was the set of extensions
   collectively known as DNSSEC, whose operational considerations are
   originally given in [RFC2541].    ...    while the latter
   warned "... larger keys increase the size of KEY and SIG RRs.  This
   increases the chance of DNS UDP packet overflow and the possible
   necessity for using higher overhead TCP in responses."

DW

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 22 Apr 2021 14:50:41 -0400

Hi,

This is a good document and I support publication.

However, I do have some comments. I scanned the Last Call comments by
others, and they mostly seem like improvements, but some of my
comments below may duplicate others for which I apologize in advance.

Section 3, last paragraph: Cut out wishy-washy superfluous words. Be bold!
OLD
vice-versa.  However, it is the aim of this document to argue that
BETTER
vice-versa.  However, this document argues that
BEST
vice-versa.  However,

Although Cookies are mentioned in this draft with a reference to the
RFC 7873, it would be good to work in the point that the Cookies RFC
recommends use of TCP whenever Cookies are not available as a way to
get some of the benefits of Cookies. Thus, if I remember correctly,
someone following that RFC would use Cookies or, when they are not
available, TCP.

Section 9, last paragraph: Don't be so negative :-)
"not unlike" -> "similar to"

Make the name of Section 2 a bit more explicit, something like
"History of DNS over TCP"

Section 1.1: Update as per RFC 8174.

Lots of references are good but I find it disturbing that all
technical references are shown as Informational. I think a lot of them
should be moved to Normative.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Apr 2021 20:23:19 +0100

Wessels, Duane <[email-masked]> wrote:

Thanks for looking through my suggestions! All the changes look good.
A few follow-up points:

> one that mentions TCP.

Aha, that makes sense

> I did add 8482 to the Appendix as you also suggested below.  I'm a
> little reluctant to add a reference in section 2.4 since I think the
> primary motivation for 8482 was about DDoS amplification, rather than
> fragmentation.  But I could still be convinced otherwise.

I needed minimal-any when my auth servers were being hammered by lots of
recursive servers making ANY requests; the responses were being truncated
because my servers have for a long time been configured to avoid
fragmentation, and the retries over TCP caused an overload.

I tend to think of all settings that reduce response size as tools for
avoiding fragmentation. Which makes me realise that BIND's
minimal-responses setting is probably also worth a mention. (I dunno if
other servers have a similar knob?)

> I probably don't have enough direct experience with UPDATE to say.  If
> it is largely over TCP then I think it should be included.

I listed the main section numbers that mention TCP. One point in RFC 2136
that's notable from an operational point of view is that an UPDATE client
has to use TCP if it wants to be sure to get a response. Unlike QUERY,
UPDATE is not idempotent so UPDATE-over-UDP can't be retried when there is
packet loss. (But `nsupdate` still uses UDP for small changes; I run it
over localhost which is reliable enough.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
East Forties: Northwesterly 3 to 5. Moderate. Showers. Good.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 23 Apr 2021 17:36:12 +0000

> On Apr 22, 2021, at 11:50 AM, Donald Eastlake <[email-masked]> wrote:
> 
> 
> Hi,
> 

Done!

> someone following that RFC would use Cookies or, when they are not

The appendix entry for RFC 7873 said:

    [RFC 7873] mentions DNS over TCP as a reasonable fallback mechanism when DNS Cookies
    are not available.

The phrase "reasonable fallback" doesn't sit quite right with me so I changed it to
"...as an alternative mechanism...".  Does that work for you or were you suggesting
that this point be made in the body of the document rather than only in the appendix?

Done.

> "History of DNS over TCP"

Yes, done.

Done.

> should be moved to Normative.

I wondered about that as well.  I moved many of the standards track RFCs to the normative section.  I will highlight this change when the next version is posted and I hope someone lets us know if any of those are not appropriate there.

DW

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 23 Apr 2021 16:44:02 -0400

Hi,

Thanks for the quick response. See below.

> that this point be made in the body of the document rather than only in the appendix?

Well, ideally it would be in the body of the document but it looks
like it would take a moderate amount of work to do that. I am
satisfied with the rewording in the appendix.

> I wondered about that as well.  I moved many of the standards track RFCs to the normative section.  I will highlight this change when the next version is posted and I hope someone lets us know if a…

Sounds good. Probably not a serious problem as I think all the
references that maybe should be normative are already standards track
so there won't be any down-references... Probably Document Shepherds
review and AD review will catch any further changes needed here.

Thanks,
Donald

---

From: John Kristoff <[email-masked]>
Date: Tue, 27 Apr 2021 09:58:30 -0500

On Thu, 22 Apr 2021 20:23:19 +0100

> fragmentation, and the retries over TCP caused an overload.

Hi Tony,

Minimal answers I think is an interesting and in a more general context
I'm interested in exploring it as an operational practice (e.g. I think
it can help relieve some of the burden and problems of parent/child
inconsistency).

However, I think we'd be reluctant to say much about minimal-answers
here in a context that suggests it is some sort of DDoS mitigation
mechanism and that you need it because... "TCP".  Maybe there is some
adjustments to the text somewhere that can help highlight that certain
RRsets or settings may lead to more TCP traffic?

Thanks for taking on a bulk of replies so far.  I tend to like to
digest them first, before replying to them in rapid succession so
you're beating me to it.  I can do some of the follow up work in the
repo where I find things that are not yet addressed.

> over localhost which is reliable enough.)

IETF RFC 2136 (UPDATE) is already referenced in our draft, section
2.2.  Is this insufficient?

John

---

From: Tony Finch <[email-masked]>
Date: Wed, 28 Apr 2021 16:05:54 +0100

> RRsets or settings may lead to more TCP traffic?

There's this paragraph:

   Often, reducing the EDNS0 UDP packet size leads to a successful
   response.  That is, the necessary data fits within the smaller
   message size.  However, when the data does not fit, the server sets
   the truncated flag in its response, indicating the client should
   retry over TCP to receive the whole response.  This is undesirable
   from the client's point of view because it adds more latency and
   potentially undesirable from the server's point of view due to the
   increased resource requirements of TCP.

which is followed by discussion of various ways of reducing response sizes
to avoid fragmentation and truncation. I thought that minimal-responses
and minimal-any could also be mentioned as useful ways to avoid large
responses. The anti-DDoS aspect of minimal-any isn't the main point in
this context.

> 2.2.  Is this insufficient?

Oh yes, that's the kind of text I was expecting :-)

I guess I had forgotten about it by the time I got to the appendix and
thought it must have been missing because RFC 2136 isn't listed in the
appendix.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Lundy: Northeast 4 to 6 becoming variable 4 or less. Smooth or slight,
but moderate until later in west. Rain then showers. Good,
occasionally moderate at first.