DNS Transport over TCP - Operational Requirements
draft-ietf-dnsop-dns-tcp-requirements-15

Thanks for the work on this document. Many thanks to Jean Mahoney for her ART ART review: https://mailarchive.ietf.org/arch/msg/art/YAoRhQIrKn4g0L6XFZvV45bWL44/.

I only have one very minor comments, to take or leave as you please:

   headers are 40 bytes (versus 20 without options in IPv4).  Second, it
   seems as though some people have misinterpreted IPv6's required
   minimum MTU of 1280 as a required maximum.  Third, fragmentation in

FP: The "some people" is quite cryptic, in my opinion. What people? Does this come from analyzing implementations? Then it would probably be good to state so instead.


Francesca

Thanks for the well-written document!

A few comments --

1. I have similar concerns to Ben's regarding the use of BCP as a vehicle to update the Standards Track documents in question. If I had a better option to offer at this stage in the document's history, I would, but under the circumstances I don't. If we had it to do over again, my preference would have been to progress a small PS to update the Standards Track documents, and a BCP to provide all the rest of the content. In addition to the points Ben made, my discomfort also stems from the fact that the advice regarding implementations has inherently short shelf life (relatively speaking) whereas the updates are forever (or at least until the updated documents are bis'd). 
   I'm not requesting any change with this observation, just putting it out there for discussion (without making it a DISCUSS...).

2. In Section 3, another +1 to Ben's comment. In particular the "lastly" part seemed especially loosy-goosy to me as written, as to what precisely is updated in RFC 1536. The flow of the prose is nice, but the conclusion is less than clear. I do think some rewrite of this section would be helpful.

3. Section 6 says applications should perform “full TCP segment reassembly”. What does that mean? A quick google search doesn’t suggest it’s a well-known term of art. I'm guessing that what you mean is that the applications should capture (and log, etc) the bytestream that was segmented and transmitted by TCP?

First, this was really well done, and the historical context in particular is noteworthy.  Thanks for putting this together.

I support Roman's DISCUSS.

I'm particularly interested in how we resolve the status question, as Benjamin has mentioned.  Since BCP 97 is on the table, I'm already wondering what we do about updating an Internet Standard when the rare need for that arises.  Is there any guidance about this?  Is BCP the only way?  It seems like it might be, but that also feels wrong.  Then again, a new Proposed Standard theoretically can't update an Internet Standard either.  I'm quite tempted to DISCUSS this point just so we get it right here, but for now I'll settle for talking about it with the IESG at some point in the near future.

Thank you to Alan DeKok for the SECDIR review.

Thanks for addressing my DISCUSS point with the additional reference to DoH in Section 9 and addressing my COMMENTS. I continue to believe that additional treatment of TLS-based transports (e.g., DoH) in a single document would be helpful, but I can accept that the WG wants to keep the scope narrow.

===
** Section 9.  The text mentions that TCP is more susceptible to fingerprinting.  It would be also be worth mentioned that using DoH reduces susceptibility to traffic analysis.

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Suzanne Woolf for the shepherd's write-up about the WG consensus.

Thank you also to Ron Bonica for the shortest (1 line) but positive review for the Internet directorate:
https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-tcp-requirements-13-intdir-telechat-bonica-2021-10-26/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

I would have expected a little more about anycast DNS servers as TCP is probably a no-go for those servers. I see only one mention of anycast in the whole document.

-- Section 2.3 --
To be honest, I smiled when reading "For example, as of 2014, DNS over TCP" in 2021 ;-)

-- Section 2.4 --
The qualitative approach about IPv6 fragmentation makes me wonder about the sources of this paragraph.

Still about IPv6 fragmentation, while "hence is unable to fragment and re-send anyway" is most probably correct, the originating host should populate its Path MTU cache for the destination. So, it is not that bad.


== NITS ==

-- Section 3 --
While I appreciate 2nd degree, I wonder whether "serious" should really be part of "Furthermore, there has been serious research"

-- Section 4.4 --
Should the DoT acronym be used ?

I support Roman’s DISCUSS.

Thank you for addressing my previous discuss and comment points!
Please see https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/11
for a few follow-ups on the first discuss point.

Section 2.4. , paragraph 1, comment:
> 2.4.  Fragmentation and Truncation

Fragmentation and IP fragments getting dropped is one reason for needing more
retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0)
doesn't detect or recover from loss of any UDP packets making up the overall
message. That means that a normal packet loss (due to congestion or other
reasons) amplifies into loss of the entire DNS message.

Section 3. , paragraph 1, comment:
> 3.  DNS over TCP Requirements

While the history preceding this section is interesting for context, I think
moving this section up would increase readability significantly.

Section 4.2. , paragraph 3, comment:
>    DNS server software SHOULD provide a configurable limit on the total
>    number of established TCP connections.  If the limit is reached, the
>    application is expected to either close existing (idle) connections
>    or refuse new connections.  Operators SHOULD ensure the limit is
>    configured appropriately for their particular situation.

Again, the OS generally already imposes limits. Why recommend that DNS
implementations self-impose other (lower?) limits?

Section 4.2. , paragraph 3, comment:
>    DNS server software MAY provide a configurable limit on the number of
>    established connections per source IP address or subnet.  This can be
>    used to ensure that a single or small set of users cannot consume all
>    TCP resources and deny service to other users.  Operators SHOULD
>    ensure this limit is configured appropriately, based on their number
>    and diversity of users.

This limit only begins to establish fairness once the overall number of
permitted connections is reached. Until that point, it possibly limits client
performance without any benefit.

Section 4.2. , paragraph 3, comment:
>    DNS server software SHOULD provide a configurable timeout for idle
>    TCP connections.  For very busy name servers this might be set to a
>    low value, such as a few seconds.  For less busy servers it might be
>    set to a higher value, such as tens of seconds.

Ditto.

Section 4.2. , paragraph 3, comment:
>    DNS server software MAY provide a configurable limit on the number of
>    transactions per TCP connection.

What does that limit protect against?

Section 4.2. , paragraph 2, comment:
>    Similarly, DNS server software MAY provide a configurable limit on
>    the total duration of a TCP connection.

What does that limit protect against?

Section 4.5. , paragraph 3, comment:
>    Most open source DNS server implementations provide a configurable
>    limit on the total number of established connections.  Default values
>    range from 20 to 150.  In most cases, where the majority of queries
>    take place over UDP, 150 is a reasonable limit.  For services or
>    environments where most queries take place over TCP or TLS, 5000 is a
>    more appropriate limit.

20-150 is orders of magnitude less than I expected. Even 5000 seems very low,
given the capabilities of even low-end servers.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server".

 * Term "slave"; alternatives might be "follower", "peripheral", "replica",
   "responder", "secondary", "standby", "worker".


-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Abstract", paragraph 2, nit:
>  document also considers the consequences with this form of DNS communicatio
>                              ^^^^^^^^^^^^^^^^^
The usual preposition to use after "consequences" is not "with". Did you mean
"consequences of", "consequences for", or "consequences on"?

Section 2.4. , paragraph 7, nit:
> ctions occur without interference. However there has also been a long-held be
>                                    ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 5. , paragraph 4, nit:
> e no reported problems during the two month period when the old key was publi
>                                   ^^^^^^^^^
When a number forms part of an adjectival compound, use a hyphen.

Section 11.2. , paragraph 54, nit:
> s explain why DNS over TCP may often have been treated very differently than
>                                ^^^^^^^^^^^^^^^
The adverb "often" is usually put between "have" and "been".

Section 11.2. , paragraph 60, nit:
> teworthy, perhaps less common today then when this document was written, it
>                                     ^^^^
Did you mean "than"?

Reference [RFC2671] to RFC2671, which was obsoleted by RFC6891 (this may be on
purpose).

Document references draft-ietf-dnsop-avoid-fragmentation-04, but -05 is the
latest available revision.

Reference [RFC5966] to RFC5966, which was obsoleted by RFC7766 (this may be on
purpose).

Reference [RFC0883] to RFC883, which was obsoleted by RFC1034 and RFC1035 (this
may be on purpose).

Reference [RFC2541] to RFC2541, which was obsoleted by RFC4641 (this may be on
purpose).

These URLs in the document can probably be converted to HTTPS:
 * http://verisign.com

I support Roman's DISCUSS.

Otherwise, this is an excellent document and a joy to read.

Thank you for a well written and informative document.

Rob