Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2022-03-18
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-03-07
15 (System) RFC Editor state changed to AUTH48
2022-01-31
15 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-01-14
15 Cindy Morgan Downref to RFC 7873 approved by Last Call for draft-ietf-dnsop-dns-tcp-requirements-15
2022-01-14
15 Cindy Morgan Downref to RFC 7766 approved by Last Call for draft-ietf-dnsop-dns-tcp-requirements-15
2022-01-14
15 Cindy Morgan Downref to RFC 2181 approved by Last Call for draft-ietf-dnsop-dns-tcp-requirements-15
2022-01-13
15 (System) IANA Action state changed to No IANA Actions from In Progress
2022-01-13
15 (System) RFC Editor state changed to EDIT
2022-01-13
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-01-13
15 (System) Announcement was received by RFC Editor
2022-01-13
15 (System) IANA Action state changed to In Progress
2022-01-13
15 (System) Removed all action holders (IESG state changed)
2022-01-13
15 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2022-01-13
15 Cindy Morgan IESG has approved the document
2022-01-13
15 Cindy Morgan Closed "Approve" ballot
2022-01-13
15 Cindy Morgan Ballot approval text was generated
2022-01-13
15 Cindy Morgan Ballot writeup was changed
2022-01-06
15 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-15.txt
2022-01-06
15 (System) New version approved
2022-01-06
15 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2022-01-06
15 Duane Wessels Uploaded new revision
2022-01-05
14 Roman Danyliw
[Ballot comment]
Thank you to Alan DeKok for the SECDIR review.

Thanks for addressing my DISCUSS point with the additional reference to DoH in Section …
[Ballot comment]
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.
2022-01-05
14 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2021-12-24
14 Benjamin Kaduk [Ballot comment]
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.
2021-12-24
14 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-12-17
14 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2021-12-07
14 (System) Changed action holders to Warren Kumari (IESG state changed)
2021-12-07
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-12-07
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-12-07
14 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-14.txt
2021-12-07
14 (System) New version approved
2021-12-07
14 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2021-12-07
14 Duane Wessels Uploaded new revision
2021-10-28
13 (System) Changed action holders to Duane Wessels, John Kristoff, Warren Kumari (IESG state changed)
2021-10-28
13 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-10-28
13 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from No Record
2021-10-28
13 John Scudder
[Ballot comment]
Thanks for the well-written document!

A few comments --

1. I have similar concerns to Ben's regarding the use of BCP as a …
[Ballot comment]
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?
2021-10-28
13 John Scudder Ballot comment text updated for John Scudder
2021-10-28
13 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if …
[Ballot comment]
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 ?
2021-10-28
13 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-10-28
13 Francesca Palombini
[Ballot comment]
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 …
[Ballot comment]
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
2021-10-28
13 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-10-28
13 Murray Kucherawy
[Ballot comment]
First, this was really well done, and the historical context in particular is noteworthy.  Thanks for putting this together.

I support Roman's DISCUSS. …
[Ballot comment]
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.
2021-10-28
13 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-10-27
13 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-10-27
13 Alvaro Retana [Ballot comment]
I support Roman’s DISCUSS.
2021-10-27
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-10-26
13 Erik Kline
[Ballot comment]
[abstract vs. S1/S3, question]

* The abstract says:

  "...strongly
  encourages the operational practice of permitting DNS messages to be
  carried …
[Ballot comment]
[abstract vs. S1/S3, question]

* The abstract says:

  "...strongly
  encourages the operational practice of permitting DNS messages to be
  carried over TCP"

  while section 1 says:

  "...all DNS resolvers and recursive
  servers MUST support and service both TCP and UDP queries"

  and section 3 also some MUST text.

  Should the abstract be updated to say MUST rather than just
  "strongly encourages", or is there a subtly in here I'm missing?

[S4.1, comment]

* "Resolvers and other DNS clients should be aware that some servers
  might not be reachable over TCP.  For this reason, clients MAY want
  to track and limit the number of TCP connections and connection
  attempts to a single server."

  I think the same comment could be made about paths to a server from
  a given network, e.g., in the case of one network filtering TCP/53 for
  some reason.

  I'm not sure how to best reword this to add a per-network notion to
  TCP connection success tracking, but I did want to note that a mobile
  client's measure of TCP connection success to a single server might
  vary from network to network.  (for your consideration)
2021-10-26
13 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2021-10-26
13 Ron Bonica Request for Telechat review by INTDIR Completed: Ready. Reviewer: Ron Bonica. Sent review to list.
2021-10-26
13 Lars Eggert
[Ballot discuss]
Section 4.2. , paragraph 3, discuss:
>    Since host memory for TCP state is a finite resource, DNS clients and
>    …
[Ballot discuss]
Section 4.2. , paragraph 3, discuss:
>    Since host memory for TCP state is a finite resource, DNS clients and
>    servers MUST actively manage their connections.  Applications that do
>    not actively manage their connections can encounter resource
>    exhaustion leading to denial of service.  For DNS, as in other
>    protocols, there is a tradeoff between keeping connections open for
>    potential future use and the need to free up resources for new
>    connections that will arrive.

For it to contain a MUST-level requirement, this section needs to give a lot
more concrete guidance on what it means to "actively" manage connections. Most
operating systems by default impose some application limits that usually
effectively prevent DOS or other resource exhaustion issues. Is the intent here
that DNS implementations need to do more? If so, what?
2021-10-26
13 Lars Eggert
[Ballot comment]
Section 2.4. , paragraph 1, comment:
> 2.4.  Fragmentation and Truncation

Fragmentation and IP fragments getting dropped is one reason for needing more …
[Ballot comment]
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
2021-10-26
13 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2021-10-26
13 Robert Wilton [Ballot comment]
Thank you for a well written and informative document.

Rob
2021-10-26
13 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-10-25
13 Martin Duke [Ballot comment]
I support Roman's DISCUSS.

Otherwise, this is an excellent document and a joy to read.
2021-10-25
13 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-10-25
13 Benjamin Kaduk
[Ballot discuss]
(1) This should be pretty easy to resolve, but this text from §4.4
does not seem to match up with the referenced document: …
[Ballot discuss]
(1) This should be pretty easy to resolve, but this text from §4.4
does not seem to match up with the referenced document:

  The use of TLS places even stronger operational burdens on DNS
  clients and servers.  Cryptographic functions for authentication and
  encryption requires additional processing.  Unoptimized connection
  setup takes two additional round-trips compared to TCP, but can be
  reduced with TCP Fast Open, TLS session resumption [RFC8446] and TLS
  False Start [RFC7918].

Two additional round trips was true of TLS 1.2 and prior versions, but
as of TLS 1.3 the application data from the client can be sent after
only 1 round trip, accompanying the client Finished (and authentication
messages, if in use).  Given the nature of the rest of the sentence, we
might want to specifically mention TLS 1.3 as an improvement over TLS
1.2, but there are probably a number of ways that we could fix it.  Note
additionally that for TLS 1.3, session resumption is not a reduction in
the number of round trips unless 0-RTT data is used (but AFAIK there is
not a published application profile specifying acceptable DNS content
for TLS 0-RTT data, so use of TLS 0-RTT data for DNS is forbidden), but
is still an efficiency gain due to the reduced number of cryptographic
operations (including certificate validation).

(2) Trivial to address, but the section heading for Appendix A.8
references RFC 3326 (The Reason Header Field for the Session Initiation
Protocol (SIP)), not RFC 3226 (DNSSEC and IPv6 A6 aware server/resolver
message size requirements)
2021-10-25
13 Benjamin Kaduk
[Ballot comment]
This document targets BCP status, while proposing an Updates:
relationship with an Internet Standard and an Informational document.
As mentioned in
https://mailarchive.ietf.org/arch/msg/last-call/oMhqRigr4nbRSMll5NY4zXpZu20/
there …
[Ballot comment]
This document targets BCP status, while proposing an Updates:
relationship with an Internet Standard and an Informational document.
As mentioned in
https://mailarchive.ietf.org/arch/msg/last-call/oMhqRigr4nbRSMll5NY4zXpZu20/
there is some motivation for having updates to standards-track documents
occur via other standards-track documents, but given that this document
is mostly about giving operational guidance for DNS-over-TCP usage,
there seems to be some argument that BCP is a more appropriate status
for it.  However, I do wonder if there is some existing BCP that this
document would become part of, or if it would need to be given a new BCP
number.  It's not entirely clear how much scope there is for future
additions that would become part of that same BCP, and whether a BCP
number is truly needed in that scenario.  It would be good to hear
others' thoughts on this topic, especially in the form of references to
previous WG discussion.

I made a pull request on github with some editorial suggestions, most of
which by volume are classifying the "Standards Track" documents in
Appendix A properly as Internet Standard or Proposed Standard (there
don't seen to be any lingering Draft Standards in the list):
https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/10

Section 2.4

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

I looked through [HUSTON] and wasn't able to find this "35%" figure.
There is a remark that "37% of endpoints used IPv6-capable DNS resolvers
that were incapable of receiving a fragmented IPv6 response", but that
seems to be a somewhat different statement in addition to a somewhat
different percentage value.  In particular, the sampling domain for the
[HUSTON] statement as written appears to be "all endpoints", but the
statement in this draft uses the sampling domain of "IPv6-capable
recursive resolvers".  However, the corresponding calculation in
[HUSTON] looks to be using "IPv6-capable resolvers" as the sampling
domain, just as this document states, which suggests that the error in
phrasing is in [HUSTON] and not in this document.

Section 3

As the directorate review noted, it's a little surprising to see the
OLD/NEW formulation for one of the updates to §6.1.3.2 of RFC 1123 but
not the others.

In particular, using OLD/NEW would allow us to implicitly reiterate that
the "MUST send a UDP query first" requirement for non-zone-transfers
is no longer present (by virtue of the update made by RFC 7766).

  *  Recursive servers (or forwarders) MUST support and service all TCP
      queries so that they do not prevent large responses from a TCP-
      capable server from reaching its TCP-capable clients.

This might benefit from a bit of unpacking.  I think that "MUST support
and service ... queries" refers to the stub/recursive side of things,
with "responses from a TCP-capable server" would refer to the
recursive/authoritative side.  But the rest of the sentence seems to be
assuming that if TCP is used on one side then it is used on the other
side, so that limitations of TCP use on one side do not carry over to
the other.  However, I didn't think that there was a requirement on
recursives to go forward with TCP for queries received over TCP, so I'm
not entirely sure what the actual guidance here is intended to be.

Section 4.2

  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.

I think that one of the directorate reviews touched on this topic, but I
wonder if we can give more guidance on what factors of a particular
situation might be relevant for determining what is appropriate.  In
this case, that might include the number of requests the hardware is
capable of serving and the number of requests expected from legitimate
clients; we do seem to provide a bit more detail in the following
paragraph (not quoted here) regarding "number and diversity of users"

Section 8

There's a lot of good advice interspersed in the main body text already;
thank you for that!

The discussion in §4.1 suggests ("SHOULD") to share a TFO server key
amongst servers in a server farm, but this introduces the usual security
considerations for a group-shared symmetric key.  The highlights are
that any member of the group can impersonate any other member, and
compromise of one machine compromises all members' use of the key.
While there's not a great fully generic treatment of these issues in the
RFC series that I know of (yet, at least), I've seen RFC 4046 cited for
it sometimes, and draft-ietf-core-oscore-groupcomm has a section on
"security of the group mode" that also has some overlap with the
relevant considerations for sharing TFO keys.

In a similar vein, in §6 we again SHOULD-level recommend that
applications capturing network packets do TCP segment reassembly in
order to defeat obfuscation techniques involving TCP segmentation.  I am
happy to see that we go on to caution against resource exhaustion
attacks while doing so, but have two related comments: first, that
caution might merit mention again here, and second, that we should note
(either here or there) that when applying resource limits, there's a
tradeoff between allowing service and allowing some attacks to succeed.
Giving up on segmentation reassembly due to resource usage means that a
potential attack could succeed, but dropping streams where segmentation
recovery uses excess resources might deny legitimate service.

We might also consider reiterating that the core DNS over TCP security
considerations (RFC 1035, ???) continue to apply.

Clients that keep state about whether a given server supports TCP (per
discussion in §4.1) might be susceptible to an attacker that is on-path
in one location disrupting TCP in that location and causing the client
to store state that a given server does not support TCP, when TCP
connections from a different location, where the attacker is not on
path, would succeed.

  short-lived DNS transactions over TCP may pose challenges.  In fact,
  [DAI21] details a class of IP fragmentation attacks on DNS
  transactions if the IP ID field can be predicted and a system is
  coerced to fragment rather than retransmit messages.  [...]

I suggest more detail on the "IP ID field" (including IPv4/v6
differences).

Section 9

  being queried).  DNS over TLS or DTLS is the recommended way to
  achieve DNS privacy.

Is it really the (sole) recommended way?  It certainly suffices, but
what is the status of DoH/DoQ?  Perhaps "DNS over TLS or DTLS serves to
provide DNS privacy" optionally followed by a note about DoH or "other
mechanisms" in general.  (May be superseded by Roman's Discuss.)

Section 11.1

I recommend re-review of the classification of the references.
Just because a reference is on the standards-track does not mean that we
must reference it normatively -- e.g., RFC 1995/1996 are mentioned only
in the listing of "other standards related to DNS transport over TCP",
but they are not required reading in order to understand and implement this
document.  See
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
.

Section 11.2

I'm having a really hard time seeing how RFC 1123 is classified as
informative given that we have an Updates: relationship to it -- that
would seem to require some familiarity with its contents in order to
know how to use this document properly.  The same question might be
asked of RFC 1536 as well.

The link for [FRAG_POISON] did not lead me to the desired document, just
a generic homepage.

I couldn't locate anything about [DAI21]; is there additional
information that can be provided to assist in locating it?

It is slightly surprising that RFC 1034 does not need to be normative,
but it seems that the only places we directly reference use 1035 rather
than 1034, so informative would be correct.

The "SHOULD enable TFO" might make RFC 7413 into a normative reference
(see the IESG statement linked above)

Since [TDNS] is available at
https://www.isi.edu/~johnh/PAPERS/Zhu15b.html should we include that
link?

Likewise, [TOYAMA] seems to refer to
https://archive.nanog.org/meetings/nanog32/presentations/toyama.pdf, and
[VERISIGN] to
https://indico.dns-oarc.net/event/20/contributions/270/attachments/249/465/rtt_Oarc_ThomasWessels_v1.pdf

Appendix A.2

  This Informational document [RFC1536] states UDP is the "chosen
  protocol for communication though TCP is used for zone transfers."
  That statement should now be considered in its historical context and
  is no longer a proper reflection of modern expectations.

That statement is explicitly updated by this document, which might be
worth noting.

NITS

Section 3

  of the Internet DNS as ever, if not more so.  Furthermore, there has
  been serious research that argues connection-oriented DNS
  transactions may provide security and privacy advantages over UDP
  transport [TDNS].  In fact, the standard for DNS over TLS [RFC7858]
  is just this sort of specification.  [...]

This might be some editing remnants -- "just this sort of specification"
seems to be trying to refer to some previous discussion of a type of
specification, but there isn't any in the preceding text anymore.
([TDNS] does propose a specification for a DNS-over-TLS type scheme,
from a very quick glance, or maybe there is an intent to connect
"specification" with "[of a] connection-oriented DNS transaction
[protocol]".)
2021-10-25
13 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-10-25
13 Roman Danyliw
[Ballot discuss]
This document has a dedicated section for DNS over TLS, makes a number of configuration recommendations for DoT, and notes it in the …
[Ballot discuss]
This document has a dedicated section for DNS over TLS, makes a number of configuration recommendations for DoT, and notes it in the Privacy Considerations.  However, there is no mention of DNS over HTTPS (DoH).  It seems like DoH should get similar treatment.
2021-10-25
13 Roman Danyliw
[Ballot comment]
Thank you to Alan DeKok for the SECDIR review.

** Section 2.2. 
  Yet, defying some expectations, DNS over TCP remained little-used in …
[Ballot comment]
Thank you to Alan DeKok for the SECDIR review.

** Section 2.2. 
  Yet, defying some expectations, DNS over TCP remained little-used in
  real traffic across the Internet around this time. 

This section doesn’t define a time period to associate with “… around this time”.

** Section 2.2.
  Around the time
  DNSSEC was first defined, another new feature helped solidify UDP
  transport dominance for message transactions.

Is that “new feature” EDNS(0) per Section 2.3?

** Section 2.5
  Today, the majority of the DNS community expects, or at least has a
  desire, to see DNS over TCP transactions occur without interference.

Is there a citation for this assertion?

** Section 2.5.  Per the use of [CHES94] and [DJBDNS] to motivate the position that DNS over TCP is not needed, are there more modern references?  The former is from 1994, and the latter appears to be last updated in 2002.

** Section 3.
  Lastly, Section 1 of [RFC1536] is updated to eliminate the
  misconception that TCP is only useful for zone transfers.

With what text is Section 1 of [RFC1536] updated?

** Section 4.1.  Consider adding a reference of SYN cookies.

** Section 5.1.  Does the term “DNS Wedgie” have to be used here given its use in American English as the name for a bullying practice?  Judging from a google search (https://www.google.com/search?q="dns+wedgie"), this document appears to be inventing the term in the context of DNS.

** Section 6.  Per “Furthermore, as with real TCP, …”, what is “real TCP”?

** Section 9.
  Because TCP is somewhat more complex than UDP, some characteristics
  of a TCP conversation may enable fingerprinting and tracking that is
  not possible with UDP. 

Recommend being clearer on who is being fingerprinted – s/fingerprinting/DNS client fingerprinting/

** Section 9.  The text “DNS over TLS or DTLS is the recommended way to achieve DNS privacy” seems rather soft on recommending encrypted DNS of any flavor.  Was there any WG conversation to same something stronger?

** 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.
2021-10-25
13 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2021-10-20
13 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Ron Bonica
2021-10-20
13 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Ron Bonica
2021-10-20
13 Éric Vyncke Requested Telechat review by INTDIR
2021-10-15
13 Amy Vezza Placed on agenda for telechat - 2021-10-28
2021-10-14
13 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-10-14
13 Warren Kumari Ballot has been issued
2021-10-14
13 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2021-10-14
13 Warren Kumari Created "Approve" ballot
2021-10-14
13 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-10-13
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-10-13
13 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-13.txt
2021-10-13
13 (System) New version approved
2021-10-13
13 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2021-10-13
13 Duane Wessels Uploaded new revision
2021-09-03
12 Jean Mahoney Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Jean Mahoney. Sent review to list.
2021-09-03
12 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-09-02
12 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-09-02
12 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-dns-tcp-requirements-12, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-dns-tcp-requirements-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-09-02
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Alan DeKok. Submission of review completed at an earlier date.
2021-09-01
12 Dan Romascanu Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. Sent review to list.
2021-08-27
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Alan DeKok.
2021-08-26
12 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2021-08-26
12 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2021-08-26
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2021-08-26
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2021-08-25
12 Mirja Kühlewind Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Mirja Kühlewind. Sent review to list.
2021-08-24
12 Barry Leiba Request for Last Call review by ARTART is assigned to Jean Mahoney
2021-08-24
12 Barry Leiba Request for Last Call review by ARTART is assigned to Jean Mahoney
2021-08-24
12 Wesley Eddy Request for Last Call review by TSVART is assigned to Mirja Kühlewind
2021-08-24
12 Wesley Eddy Request for Last Call review by TSVART is assigned to Mirja Kühlewind
2021-08-23
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2021-08-23
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2021-08-20
12 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-08-20
12 Amy Vezza
The following Last Call announcement was sent out (ends 2021-09-03):

From: The IESG
To: IETF-Announce
CC: Suzanne Woolf , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dns-tcp-requirements@ietf.org, …
The following Last Call announcement was sent out (ends 2021-09-03):

From: The IESG
To: IETF-Announce
CC: Suzanne Woolf , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dns-tcp-requirements@ietf.org, suzworldwide@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Transport over TCP - Operational Requirements) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Transport over TCP -
Operational Requirements'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 1123.  This document strongly encourages
  the operational practice of permitting DNS messages to be carried
  over TCP on the Internet as a best current practice.  Such
  encouragement is aligned with the implementation requirements in RFC
  7766
.  The use of TCP 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc8490: DNS Stateful Operations (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc7873: Domain Name System (DNS) Cookies (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc7828: The edns-tcp-keepalive EDNS0 Option (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc7477: Child-to-Parent Synchronization in DNS (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6762: Multicast DNS (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc5936: DNS Zone Transfer Protocol (AXFR) (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc2181: Clarifications to the DNS Specification (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc1995: Incremental Zone Transfer in DNS (Proposed Standard - Internet Engineering Task Force (IETF))



2021-08-20
12 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-08-20
12 Warren Kumari Last call was requested
2021-08-20
12 Warren Kumari Last call announcement was generated
2021-08-20
12 Warren Kumari Ballot approval text was generated
2021-08-20
12 (System) Changed action holders to Warren Kumari (IESG state changed)
2021-08-20
12 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation
2021-08-20
12 Warren Kumari Ballot writeup was changed
2021-08-18
12 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-12.txt
2021-08-18
12 (System) New version approved
2021-08-18
12 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2021-08-18
12 John Kristoff Uploaded new revision
2021-08-06
11 Warren Kumari Changed action holders to Duane Wessels, John Kristoff
2021-07-15
11 (System) Changed action holders to Warren Kumari (IESG state changed)
2021-07-15
11 Warren Kumari IESG state changed to AD Evaluation from Publication Requested
2021-07-09
11 Suzanne Woolf
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP. This is appropriate because the document collects a fair amount of history and detail in order to clearly establish a specific feature of the standard and best practices for operators with regards to configuration and monitoring.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document updates [RFC1123] to make a SHOULD into a MUST in the standard, and strongly encourages the operational practice of permitting DNS messages to be carried over TCP on the Internet as a best current practice.  Such encouragement is aligned with the implementation requirements in RFC 7766.  The use of TCP 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.

Working Group Summary:

This document has been around in various forms for some time, and has been extensively reviewed in the WG by both protocol experts and DNS operators.  THe authors are experienced DNS protocol designers and operators as well, and responded to every issue raised in the WG discussion over time.

Document Quality:

This document clarifies and strengthens an existing protocol feature specified in RFC 1123 from a SHOULD to a MUST. The bulk of it is a justification of the MUST for implementers, and corresponding advice to operators that they use the feature.  For many years it's been typical for DNS implementers to provide code for servicing DNS requests over TCP, but it has also been common for operators to turn it off; this document attempts to establish a best common practice for operators to only use DNS software that implements TCP support and to not disable the capability.

Personnel:

Who is the Document Shepherd? Suzanne Woolf
Who is the Responsible Area Director?  Warren Kumari

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd has extensively reviewed the current version and recent discussion of it. It clearly states its recommendations and the reasons for them, and has gotten support in the WG from both implementers and operators.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. This document makes a straightforward set of recommendations with clear justification.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes we have confirmation.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a good diversity of support in the WG Last Call. Authors were engaged in the discussion and responsive to concerns.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nits from the previous draft have been covered by the editors.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC 1123. This is mentioned in the Abstract and discussed in detail in Section 3.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA actions or substantive considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

2021-07-09
11 Suzanne Woolf Responsible AD changed to Warren Kumari
2021-07-09
11 Suzanne Woolf IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-07-09
11 Suzanne Woolf IESG state changed to Publication Requested from I-D Exists
2021-07-09
11 Suzanne Woolf IESG process started in state Publication Requested
2021-07-09
11 Suzanne Woolf
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP. This is appropriate because the document collects a fair amount of history and detail in order to clearly establish a specific feature of the standard and best practices for operators with regards to configuration and monitoring.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document updates [RFC1123] to make a SHOULD into a MUST in the standard, and strongly encourages the operational practice of permitting DNS messages to be carried over TCP on the Internet as a best current practice.  Such encouragement is aligned with the implementation requirements in RFC 7766.  The use of TCP 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.

Working Group Summary:

This document has been around in various forms for some time, and has been extensively reviewed in the WG by both protocol experts and DNS operators.  THe authors are experienced DNS protocol designers and operators as well, and responded to every issue raised in the WG discussion over time.

Document Quality:

This document clarifies and strengthens an existing protocol feature specified in RFC 1123 from a SHOULD to a MUST. The bulk of it is a justification of the MUST for implementers, and corresponding advice to operators that they use the feature.  For many years it's been typical for DNS implementers to provide code for servicing DNS requests over TCP, but it has also been common for operators to turn it off; this document attempts to establish a best common practice for operators to only use DNS software that implements TCP support and to not disable the capability.

Personnel:

Who is the Document Shepherd? Suzanne Woolf
Who is the Responsible Area Director?  Warren Kumari

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd has extensively reviewed the current version and recent discussion of it. It clearly states its recommendations and the reasons for them, and has gotten support in the WG from both implementers and operators.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. This document makes a straightforward set of recommendations with clear justification.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes we have confirmation.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a good diversity of support in the WG Last Call. Authors were engaged in the discussion and responsive to concerns.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nits from the previous draft have been covered by the editors.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC 1123. This is mentioned in the Abstract and discussed in detail in Section 3.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA actions or substantive considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

2021-06-11
11 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-11.txt
2021-06-11
11 (System) New version approved
2021-06-11
11 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2021-06-11
11 Duane Wessels Uploaded new revision
2021-06-10
10 Suzanne Woolf
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP. This is appropriate because the document collects a fair amount of history and detail in order to clearly establish a specific feature of the standard and best practices for operators with regards to configuration and monitoring.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document updates [RFC1123] to make a SHOULD into a MUST in the standard, and strongly encourages the operational practice of permitting DNS messages to be carried over TCP on the Internet as a best current practice.  Such encouragement is aligned with the implementation requirements in RFC 7766.  The use of TCP 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.

Working Group Summary:

This document has been around in various forms for some time, and has been extensively reviewed in the WG by both protocol experts and DNS operators.  THe authors are experienced DNS protocol designers and operators as well, and responded to every issue raised in the WG discussion over time.

Document Quality:

This document clarifies and strengthens an existing protocol feature specified in RFC 1123 from a SHOULD to a MUST. The bulk of it is a justification of the MUST for implementers, and corresponding advice to operators that they use the feature.  For many years it's been typical for DNS implementers to provide code for servicing DNS requests over TCP, but it has also been common for operators to turn it off; this document attempts to establish a best common practice for operators to only use DNS software that implements TCP support and to not disable the capability.

Personnel:

Who is the Document Shepherd? Suzanne Woolf
Who is the Responsible Area Director?  Warren Kumari

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd has extensively reviewed the current version and recent discussion of it. It clearly states its recommendations and the reasons for them, and has gotten support in the WG from both implementers and operators.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. This document makes a straightforward set of recommendations with clear justification.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are no concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes we have confirmation.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a good diversity of support in the WG Last Call. Authors were engaged in the discussion and responsive to concerns.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a couple of nits that appear to be punctuation ('[]'  instead of '()') and a minor edit to the Abstract to remove a reference to RFC 1123. These will be addressed in the next edit, but may be batched with IESG comments or any other minor changes requested by the WG.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC 1123. This is mentioned in the Abstract and discussed in detail in Section 3.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA actions or substantive considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

2021-06-08
10 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-10.txt
2021-06-08
10 (System) New version approved
2021-06-08
10 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2021-06-08
10 Duane Wessels Uploaded new revision
2021-05-31
09 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-09.txt
2021-05-31
09 (System) New version approved
2021-05-31
09 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2021-05-31
09 John Kristoff Uploaded new revision
2021-05-23
08 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-08.txt
2021-05-23
08 (System) New version approved
2021-05-23
08 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2021-05-23
08 John Kristoff Uploaded new revision
2021-05-12
07 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-04-19
07 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2021-03-10
07 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-07.txt
2021-03-10
07 (System) New version accepted (logged-in submitter: John Kristoff)
2021-03-10
07 John Kristoff Uploaded new revision
2020-11-16
06 (System) Document has expired
2020-05-06
06 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-06.txt
2020-05-06
06 (System) New version approved
2020-05-06
06 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2020-05-06
06 Duane Wessels Uploaded new revision
2020-05-05
05 (System) Document has expired
2020-01-12
05 Suzanne Woolf Notification list changed to Suzanne Woolf <suzworldwide@gmail.com>
2020-01-12
05 Suzanne Woolf Document shepherd changed to Suzanne Woolf
2019-11-18
05 Tim Wicinski Added to session: IETF-106: dnsop  Thu-1330
2019-11-02
05 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-05.txt
2019-11-02
05 (System) New version approved
2019-11-02
05 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2019-11-02
05 Duane Wessels Uploaded new revision
2019-06-24
04 Duane Wessels New version available: draft-ietf-dnsop-dns-tcp-requirements-04.txt
2019-06-24
04 (System) New version approved
2019-06-24
04 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2019-06-24
04 Duane Wessels Uploaded new revision
2019-03-26
03 Tim Wicinski Changed consensus to Yes from Unknown
2019-03-26
03 Tim Wicinski Intended Status changed to Best Current Practice from None
2019-03-23
03 Tim Wicinski Added to session: IETF-104: dnsop  Tue-1350
2019-01-02
03 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-03.txt
2019-01-02
03 (System) New version approved
2019-01-02
03 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2019-01-02
03 John Kristoff Uploaded new revision
2018-11-18
02 (System) Document has expired
2018-05-17
02 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-02.txt
2018-05-17
02 (System) New version approved
2018-05-17
02 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2018-05-17
02 John Kristoff Uploaded new revision
2017-11-14
01 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-01.txt
2017-11-14
01 (System) New version approved
2017-11-14
01 (System) Request for posting confirmation emailed to previous authors: Duane Wessels , John Kristoff
2017-11-14
01 John Kristoff Uploaded new revision
2017-06-20
00 Tim Wicinski This document now replaces draft-kristoff-dnsop-dns-tcp-requirements instead of None
2017-06-20
00 John Kristoff New version available: draft-ietf-dnsop-dns-tcp-requirements-00.txt
2017-06-20
00 (System) WG -00 approved
2017-06-20
00 John Kristoff Set submitter to "John Kristoff ", replaces to draft-kristoff-dnsop-dns-tcp-requirements and sent approval email to group chairs: dnsop-chairs@ietf.org
2017-06-20
00 John Kristoff Uploaded new revision