DNS Zone Transfer over TLS
draft-ietf-dprive-xfr-over-tls-12

Thank you for the work on this document. My only (very minor) comment is on abbreviations, and will likely come up with the RFC Editor: there is a number of acronyms used throughout the text, please expand them on first use: XFR, AXFR, IXFR, SOA, ACL, RR, ALPN.

Francesca

Thanks for the well-written and easy to follow spec. Below are some comments you may want to take into consideration.

1. Abstract

   XFR-over-TLS (XoT).  Additionally, this specification updates
   RFC1995, RFC5936 and RFC7766.

Please say a few words about how the spec updates those RFCs, don’t make the reader go digging for it.

2. Section 1

   transfers (this draft) is orthogonal to preventing zone enumeration,
   though they aim to protect the same information.

s/this draft/this document/

3. Sections 6.1, 6.2

   3.  If the primary serial is higher than the secondaries serial

s/secondaries/secondary’s/

4. Section 6.3

   This section attempts to presents a rationale for considering

“Attempts to present”. But really, why not just “presents”?

5. Section 6.3

   Since the SOA of the published zone can be trivially discovered by
   simply querying the publicly available authoritative servers leakage

Comma between “servers” and “leakage”. 

6. Section 6.3.2

   For hidden primaries or secondaries the SOA response leaks only the
   degree of SOA serial number lag of any downstream secondary.

I don’t understand. This either means the sentence would make sense if only I had the right domain knowledge (which is OK then), or it means the sentence doesn’t make sense (which isn’t). 

7. Section 7

   The following sections include detailed clarifications on the updates
   to XFR behavior implied in [RFC7766] and how the use of [RFC7828]
   applies specifically to XFR exchanges.  It also discusses how IXFR
   and AXFR can reuse the same TCP connection.

“They also discuss” — agreement in number with “the following sections”.

8. Section 7.4

   This specification for XoT updates the guidance in [RFC7766] to
   provide the same separation of connection purpose (regular queries
   and zone transfers) for all transports being used on top of TCP.

The “for XoT” confuses this sentence, making it sound a bit like the advice is restricted to XoT. I think those two words should be struck, it would be just fine as “this specification updates…”

9. Section 8.1

   For improved security all implementations of this specification MUST
   use only TLS 1.3 [RFC8446] or later.

Improved compared to what? I think the first three words could go, then the question wouldn’t come up.

9. Section 8.4 (also 10.4)

   o  the server MUST validate the client is authorized to request or
      proxy a zone transfer by using one or both of the following:

      *  an IP based ACL (which can be either per-message or per-
         connection)

      *  Mutual TLS (mTLS)

The former is weaker, surely? I see Martin also raised this in his comments, I agree with what he wrote. It’s odd to see these two authorization methods, with very different security properties, presented as equivalent with no discussion anywhere of their relative (de)merits.

10. Section 8.8.1 (also 8.9.3)

   The goal of padding AXoT responses would be two fold:

“Is”, not “would be” (also 893)

11. Section 10.2

   SIG(0) [RFC2931] similarly also provides a mechanism to digitally

Similarly, or also — pick one.

12. Section 11

   The XoT authentication requirement specified in Section 8.4 addresses
   the issue of ensuring that the transfers is encrypted between the two
 
“Transfers are” or “transfer is”. 

13. Section 11

   endpoints directly involved in the current transfers.  The following
   table summarized the properties of a selection of the mechanisms

“Summarizes”

14. Appendix A

   For completeness, it is noted that an earlier version of the
   specification suggested using a XoT specific ALPN to negotiate TLS

Please define APLN on first use

15. A.4

   As an aside, whilst [RFC7766] makes a general purpose distinction to
   clients in the usage of connections (between regular queries and zone
 
Do you mean “general purpose distinction between clients“? The use of “to” doesn’t make sense to me.

16. A.4

   Client behavior to REFUSED response is not clearly defined (see
   below). 

I do not see anything relevant below.

With my BCP 14 language complainer hat on:

Section 7:

* "Implementations SHOULD use [RFC7828] [...] to manage persistent connections." -- since this is a SHOULD, can you suggest why an implementer might opt not to do this?  Section 7.3.1 does a great job of handling the SHOULD it presents, for example.

Sections 7.3.2 and 7.3.3:

* Same issue as above with the SHOULDs here.

Section 7.4:

* "Therefore, it is RECOMMENDED that [...] there SHOULD be no more than [...]." -- I don't know how to reconcile this RECOMMENDED-SHOULD combination in the same sentence.  I suggest that the first clause can be dropped with no loss of meaning.

Everything else is nits, some of which were probably also mentioned by others:

Section 1:

* "authoritatives" should probably be "authoritative nameservers"

* "authenticated denial of existences records" -- s/existences/existence/

Section 4:

* "The proposed mechanisms does not attempt" -- s/does/do/, or s/mechanisms/mechanism/

Section 6:

* "term is used to encompasses" -- s/encompasses/encompass/, or remove "is used to"

Sections 6.1 and 6.2

* "higher than the secondaries serial" -- s/secondaries/secondary's/

Section 6.2:

* "So there may be a fourth step above where [...].  There may also be a fourth step where [...]." -- so there can be two "fourth" steps?

Section 6.3:

* "This section attempts to presents" -- remove "attempts to", or s/presents/present/

* In the second paragraph, I think you need a comma after "servers".

Section 1.  s/can make reconnaissance trivial/can make reconnaissance and attack targeting easier/

Section 1.  Per “… zone walking is now possible with NSEC3 due to crypto-breaking advances”, a reference here would be helpful.

Section 1.  As far as I can tell the work on draft-vcelak-nsec5 has not been adopted and the draft is expired.  Perhaps this should be signaled via s/This has prompted further work on an alternative mechanism/This promoted work on an alternative mechanism/

Section 1.  Per “It is noted that in all of the common open source implementations …”, as this is a point in time assessment, it would be helpful to at least mention parenthetically the implementations/version numbers assessed informally for this conclusion.

Section 1.  Editorial.  “… must cater for accepting …” doesn’t parse for me.

Section 4. 

   The threat model does not, however, consider the existence of a zone,
   the act of zone transfer between two entities, nor the identities of
   the nameservers hosting a zone 

To further document the assumptions, consider adding that this threat model doesn’t consider/protect the mechanisms to decide on triggering the zone transfer (e.g., protecting NOTIFY messages from an active attacker)

Section 6.2.  Per “However it is noted that most widely used open source authoritative nameserver implementations (including both [BIND] and [NSD]) do IXFR using TCP by default in their latest releases”, as this document ages, “latest release” may not be meaningful.  Consider providing a version number for [BIND] and [NSD].

Section 8.4 and 10.4.  As already mentioned by Martin and John -- It seems like a strong statement to say that IP ACLs are in the same class of “channel authentication” as mTLS.

Section 8.8.1.  It’s difficult to assess how effective this notional padding approach would be for providing traffic analysis protection.  A few thoughts on the existing text realizing the details are out of scope:

-- Does padding for AXoT need to be coordinated with the padding on IXoT?

-- Is keeping state required to ensure that padding provides the appropriate obfuscation over time?

Thanks for addressing my Discuss points and most of my comments as well.
The original COMMENT section is preserved below for archival purposes.

The Introduction might mention the three documents being updated (in
addition to the Abstract and the dedicated document sections for
effectuating the updates).  We typically treat Abstract and Introduction
as things that are consumed entirely independently, even if that is not
always true in practice.

Both Abstract and Introduction could probably stand to say a bit more
about how this document is also providing general updates and
optimizations for DNS-over-TCP behavior (mostly, but not entirely, for
XFR-over-TCP), in addition to the details of XoT itself.  (This is
understandable since providing support for XoT is a convenient milestone
that other updates can be attached to.)

Thank you for updating in account of the genart reviewer; that saved me
a few comments.

I made some editorial suggestions via a github pull request at:
https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/pull/25

Section 1

   In what way is exposing the full contents of a zone a privacy risk?

Brainstorming, in split-DNS scenarios the contents of the "internal"
zone might only be intended for authenticated+authorized users, and
leaking it would provide reconaissance into the internal network.

   hard to enumerate an DNSSEC signed zone as an unsigned zone).  Whilst
   this is widely used, zone walking is now possible with NSEC3 due to
   crypto-breaking advances.  This has prompted further work on an
   alternative mechanism for DNSSEC authenticated denial of existence -
   NSEC5 [I-D.vcelak-nsec5] - however questions remain over the
   practicality of this mechanism.

Do we want to consider direct reference(s) for "crypto-breaking
advances" instead of leaving a layer of indirection through the nsec5
draft?

I would also strongly suggest demystifying the NSEC3 zone-walking
mechanism and not suggesting that there has been a magic break against
cryptographic hashes.  If I understand correctly, a mechanism roughly
analogous to the classical NSEC-walking mechanism is used to enumerate
the hash intervals in the zone, and then a standard brute-forcing
mechanism is applied to the hash values, facilitated by knowledge of the
structure of domain names (and optionally the statistical distribution
of domain names as well).  So this might instead become:

> Whilst this is widely used, zone walking is also possible with NSEC3.
> The initial procedure finds the hashed forms of the names in the zone,
> and using the known properties and distributions of domain names,
> brute-force attacks to recover the un-hashed names are feasible.  This
> has prompted further work [...]

   transfers using ACLs and TSIG in more detail.  It also discusses the
   possibility that specific deployments might choose to use a lower
   level network layer to protect zone transfers, e.g., IPSec.

I think the wording might be off, here, perhaps s/lower level network
layer/lower level security layer/?

   Because both AXFR and IXFR zone transfers are typically carried out
   over TCP from authoritative DNS protocol implementations, encrypting
   zone transfers using TLS, based closely on DoT [RFC7858], seems like
   a simple step forward.  This document specifies how to use TLS (1.3
   or later) as a transport to prevent zone collection from zone
   transfers.

This seems to be the first standalone mention of TLS, so an RFC 8446
reference is probably appropriate.

Section 3

Please use the boilerplate from RFC 8174 verbatim (it does not have an
"and" between [RFC2119] and [RFC8174], at least).

Section 4

   o  an attacker who can monitor network traffic can relatively easily
      infer relations between nameservers simply from traffic patterns,
      even when some or all of the traffic is encrypted

This is generally true, though I could construct some scenarios (e.g.,
using draft-ietf-ipsecme-iptfs) where it would not hold.  This would
generally only be achievable for the defender at significant cost in
unneeded ("chaff") traffic, though.  Should we qualify this statement
somehow, e.g., in terms of current deployments or the common case?

Section 5

I suggest including a preface to the list, other than the section title.
Perhaps "The following principles [are/were] considered in the design
for XoT"?

      *  Current usage of TCP for IXFR is sub-optimal in some cases i.e.
         connections are frequently closed after a single IXFR.

Perhaps say something about how XoT is an opportunity to improve
performance by providing different guidance, as was done for the
"backwards compatibility" sub-bullet?

Section 6.3

   Since the SOA of the published zone can be trivially discovered by
   simply querying the publicly available authoritative servers leakage
   of this RR is not discussed in the following sections.

It seems it *is* discussed, though, in the context of hidden primaries or
secondaries (which is qualitatively different from "the published zone"
and thus not quite in conflict with the first part of the claim).

Section 7

   o  remove any need for XoT implementations to support legacy behavior
      that XFR-over-TCP implementations have historically often
      supported

I'm not sure I follow the reasoning for "remove any need".  If an
authoritative resolver implementation that supports XoT also needs to
talk to any non-XoT-supporting primary or secondary, it seems like it
may still need that legacy behavior.  I see how an XoT-only
implementation can divest the legacy baggage, but don't think we can get
to assuming XoT-only in a single step.

Section 7.x

Is it possible to give clarity about which sections or which behaviors
are being updated in these respective subsections?

Section 7.2

   zones).  The response streams for concurrent AXFRs MAY be
   intermingled and AXFR-over-TCP clients compliant with this
   specification which pipeline AXFR requests MUST be able to handle
   this.

Should we say anything about the demultiplexing strategy here (DNS
header message ID?)?

Section 7.3.2

   o  pipeline such requests (if they pipeline XFR requests in general)
      and MAY intermingle them

I don't think I understand what it means to intermingle *requests* (vs
responses).  Is this defined somewhere that could be referenced?

Section 7.3.5

   Certain legacy behaviors were noted in [RFC5936], with provisions
   that implementations may want to offer options to fallback to legacy
   behavior when interoperating with servers known not to support
   [RFC5936].  For purposes of interoperability, IXFR and AXFR
   implementations may want to continue offering such configuration
   options, as well as supporting some behaviors that were
   underspecified prior to this work (e.g., performing IXFR and AXFRs on
   separate connections).  However, XoT implementations should have no
   need to do so.

Similarly to my remark on Section 7, does this only hold for "XoT-only
implementations"?

Section 7.4

Just to check my understanding, these updates to RFC 7766 apply for all
cases, not just XFR (in contrast to the Section 7.3 updates, which only
apply for XFR scenarios)?  I wonder if this could be emphasized somehow
(as well as that these updates apply for regular DNS over TCP, not just
DoT), though I don't have any ideas at the moment.

Section 8.1

   For improved security all implementations of this specification MUST
   use only TLS 1.3 [RFC8446] or later.

(nit) improved over what baseline?
Perhaps "In order to provide the highest level of security protections"?

Section 8.3

(nit) is there some reason why the SOA request/response exchange could
not be done on an unencrypted TCP connection (not that there would be
much reason to do so if TCP/TLS is to be used for the actual XFR)?

Section 8.7

   error or fallback path when queries were refused.  As a result the
   client behavior could vary significantly.  XoT servers that refuse
   queries must cater for the fact that client behavior might vary from
   continually retrying queries regardless of receiving REFUSED to every
   query, or at the other extreme clients may decide to stop using the
   server over any transport.  [...]

This (non-normative) requirement seems vague and unactionable.  Can we
give any more precise guidance on when the SHOULD from the previous can
be ignored?
(We might also clarify that the EDE code 21 is (likely?) to accompany a
REFUSED RCODE, since we only mention REFUSED in this paragraph.)

Section 8.8.1

   Note that the re-use of XoT connections for transfers of multiple
   different zones complicates any attempt to analyze the traffic size
   and timing to extract information.

I might try to hedge this statement a bit.  While it is technically true
that analyzing the combined transfer is more complicated than analyzing
individual transfers in isolation, past experience in traffic analysis
(combined with the ability to query the live serial numbers of the
domains being served) suggests that the additional burden on the
attacker is not very large.

Section 8.9.3

I'd suggest mentioning the possibility that a client will have to send
dummy IXFR requests in order to achieve the strongest level of
obfuscation (thus triggering dummy responses that do not correspond to
actual zone updates).  I don't have a great sense for how many ways such
dummy requests can be formed (is just asking for a repeat of the
previously requested delta going to work?) or whether it is worth
emphasizing that servers will need to be prepared to handle such
requests, though.

We don't need to specify the actual mechanism here, just raise awareness
that some mechanism might be used/defined in the future.

Section 9

The way we describe two potential options for policy on secondaries for
selecting which primary to request XFR from risks running afoul of the
RFC 7127 characterization that proposed standards have "resolved known
design choices".

I am choosing to not ballot Discuss on this topic because the scenario
is predicated on there existing a multi-primary configuration, which
suggests that any server that is primary is authorized to be a source of
the data, and thus that there is not supposed to be a difference in end
result regardless of which primary is selected.

Section 11

In the vein of my discuss point, it's not entirely clear whether it's
more important to focus on client authentication or client
authorization.  TSIG and SIG(0) seem to be better modeled as
authorization mechanisms than authentication ones (in addition to
providing DO as already indicated), and considering the questino of
authorization to initiate XFR may be more relevant to operational needs
than specifically authentication of the client (which is just going to
be used as input to an ACL that performs an authorization check).

Section 12

   Within any transfer group both AXFRs and IXFRs for a zone MUST all
   use the same policy, e.g., if AXFRs use AXoT then all IXFRs MUST use
   IXoT.

   In order to assure the confidentiality of the zone information, the
   entire transfer group MUST have a consistent policy of requiring
   confidentiality.  If any do not, this is a weak link for attackers to
   exploit.

These two requirements seem to be at least partially redundant.  It's
also not entirely clear to me how useful it is to preclude the
possibility of a mixed environment where all the protocols used provide
equivalent levesl of confidentiality protection.  (The latter
requirement on protecting confidentiality does not preclude this
possibility, to be clear, just the example policy of "MUST use XoT".)

   A XoT policy should specify

   o  What kind of TLS is required (Strict or Mutual TLS)

   o  or if an IP based ACL is required.

   o  (optionally) if TSIG/SIG(0) is required

I'm not sure this is a clear way to spell the required behavior.  In
particular, my understanding is that strict TLS is always required, plus
at least one of TLS client authentication (for mutual TLS) or IP ACL.
The rest of the document suggests that TSIG/SIG(0) is an orthogonal
axis, but my understanding is that TSIG/SIG(0), as cryptographic
mechanisms, would be preferred over the IP ACL, and in fact that they
would fill the roll well enough to be able to serve as a third option
alongside TLS client authentication and IP ACL.  I understand that some
changes to the exposition in this area are in preparation based on the
feedback already received from Martin D, John, and Roman, and may have
further comments when the updated text is available.

   Certain aspects of the Policies can be relatively easily tested
   independently, e.g., by requesting zone transfers without TSIG, from
   unauthorized IP addresses or over cleartext DNS.  Other aspects such
   as if a secondary will accept data without a TSIG digest or if
   secondaries are using Strict as opposed to Opportunistic TLS are more
   challenging.

(Pedantically, I don't think it would be very hard to acquire a
certificate+private key that could be used to produce a TLS connection
that would succeed if the secondary is using opportunistic TLS and fail
under strict TLS -- a self-signed certificate not expected to be trusted
would likely suffice.  That said, I don't dispute the "more challenging"
characterization, since the operational consequences of actually using
that mechanism to test the behavior of the secondary could be
significant.)

Section 14

Is there anything useful to say about a hidden primary setup where the
primary serves only XFR and not regular queries?  Off the top of my
head it might allow for enforcing the IP ACL sooner, before an actual
XFR request is seen, but I expect that my insight is not the most useful
contribution in this space.  Similarly, such a hidden primary might
reject all non-TLS connections, etc.

Section 16

   Both items 1. and 2.2. listed above require the client (secondary) to
   authenticate the server (primary) using a configured authentication
   domain name if XoT is used.

I recognize that this section is to be removed for publication, but
knowing what is used as the X.509 trust store along with the configured
authentication domain name would be interesting.

Section 21.2

Though RFC 2931 is not referenced in many places, the prose does have
some MAY-level guidance to use TSIG and SIG(0) as providing equivalent
protection, so I think that RFC 2931 should be classified as normative
just as RFC 8945 is.  (It's a proposed standard so there is no downref
issue.)

I guess that RFC 6891 is going to be transatively normative by way of
Extended DNS Errors and RFC 7828, but I'm not going to insist that it be
classified directly as normative here.

Section A.3

I'm extremely reluctant to suggest using SNI in this manner (as an
impromptu authorization bearer token, akin to port knocking).  At a
protocol level it would be just as easy to configure the use of TLS with
pre-shared key, that would provide real security.  Note that as of RFC
8773 it is permitted to use a PSK and certificate authentication in
combination, so use of PSK in this manner would not (again, at the
protocol level) impede security.  Implementation support is probably
lacking on this front, but that's no different than the currently
described mechanism...

Because this topic relates to TLS usage, I have started an email thread
with the TLS WG for it:
https://mailarchive.ietf.org/arch/msg/tls/ZIPo1mF_wnOXkgS7Uv_wzIBFmR8/

The tentative recommendation so far is in rough agreement with my
instincts, and suggest removing the entire appendix.

Section A.4

   Some primaries might rely on TSIG/SIG(0) combined with per-query IP
   based ACLs to authenticate secondaries.  In this case the primary
   must accept all incoming TLS connections and then apply a TLS
   specific response policy on a per query basis.

(nit) Is this actually necessarily a "TLS-specific" response policy?
IIUC essentially the same procedures apply today for DNS-over-TCP XFR.

   Cons: The server must handle the burden of accepting all TLS
   connections just to perform XFRs with a small number of secondaries.
   Client behavior to REFUSED response is not clearly defined (see
   below).  [...]

(nit) Is this still "below"?  I recall discussion of this up in §8.7 and
there's not much left in the document...

Section A.4.1

(Similar concerns as for A.3, above, apply to this (ab)use of SNI.
I expect there are other superior mechanisms here, as well, though did
not think about it much.  Even defining a new TLS extension (the policy
is only "specification required") would be an improvement (though still
not provide very solid security properties).

Section 7, paragraph 7, comment:
>    Therefore this document updates both the previous specifications for
>    XFR-over-TCP to clarify that

It would be useful to explicitly cite those here; I assume you mean [RFC1995]
and [RFC5936].

-------------------------------------------------------------------------------
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, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 10, nit:
-    contemplates the risk that someone gets the data through
-               -
+    contemplate the risk that someone gets the data through

Section 1, paragraph 11, nit:
-    Zone enumeration is trivially possible for DNSSEC zones which use
-                                                            ^ ^^^
-    NSEC; i.e.  queries for the authenticated denial of existences
-              ^
+    Zone enumeration is trivially possible for DNSSEC zones that use
+                                                            ^ ^^
+    NSEC; i.e., queries for the authenticated denial of existences
+              ^

Section 4, paragraph 4, nit:
-    o  much of this information can be obtained by various methods
+    o  much of this information can be obtained by various methods,
+                                                                  +

Section 5, paragraph 5, nit:
-          multiple AXFR sessions or XFRs of different zones because they
+          multiple AXFR sessions or XFRs of different zones, because they
+                                                           +

Section 5, paragraph 6, nit:
-       *  Current usage of TCP for IXFR is sub-optimal in some cases i.e.
+       *  Current usage of TCP for IXFR is sub-optimal in some cases, i.e.,
+                                                                    +     +

Section 6.1, paragraph 8, nit:
-        [RFC5936] defines this specific step as an 'AXFR session' i.e. as
+        [RFC5936] defines this specific step as an 'AXFR session', i.e., as
+                                                                 +     +

Section 6.2, paragraph 12, nit:
-    using TCP by default in their latest releases.  For BIND TCP
-    connections are sometimes used for SOA queries but in general they
+    using TCP by default in their latest releases.  For BIND, TCP
+                                                            +
+    connections are sometimes used for SOA queries, but in general they
+                                                  +

Section 6.3, paragraph 3, nit:
-    simply querying the publicly available authoritative servers leakage
+    simply querying the publicly available authoritative servers, leakage
+                                                                +

Section 6.3.2, paragraph 2, nit:
-    For hidden primaries or secondaries the SOA response leaks only the
+    For hidden primaries or secondaries, the SOA response leaks only the
+                                       +

Section 7, paragraph 4, nit:
-    specific guidance on TCP/TLS connection usage for XFR because this
+    specific guidance on TCP/TLS connection usage for XFR, because this
+                                                         +

Section 7, paragraph 9, nit:
-       significantly more complex for clients to handle both because of
+       significantly more complex for clients to handle, both because of
+                                                       +

Section 7, paragraph 9, nit:
-       be multiple messages in the responses.  For these reasons it is
+       be multiple messages in the responses.  For these reasons, it is
+                                                                +

Section 7, paragraph 9, nit:
-       when they are all XFR queries i.e. clients sending multiple XFRs
+       when they are all XFR queries, i.e., clients sending multiple XFRs
+                                    +     +

Section 7, paragraph 9, nit:
-       later) since they will never receive them.
+       later), since they will never receive them.
+             +

Section 7, paragraph 11, nit:
-    applies specifically to XFR exchanges.  It also discusses how IXFR
-                                            ^^             --
+    applies specifically to XFR exchanges.  They also discuss how IXFR
+                                            ^^^^

Section 7, paragraph 12, nit:
-    the extended DNS error code 18 (Prohibited) can also be sent.
-                                                ^^^
+    the extended DNS error code 18 (Prohibited) MAY also be sent.
+                                                ^^^

Section 7.1, paragraph 2, nit:
-    For clarity - an IXFR-over-TCP server compliant with this
-    ^^^^^^^^^^^^^^^
+    An IXFR-over-TCP server compliant with this
+    ^

Section 7.2, paragraph 2, nit:
-    For clarity - an AXFR-over-TCP server compliant with this
-    ^^^^^^^^^^^^^^^
+    An AXFR-over-TCP server compliant with this
+    ^

Section 7.3.1, paragraph 4, nit:
-       zones might be preferred for operational reasons.  In this case
+       zones might be preferred for operational reasons.  In this case,
+                                                                      +

Section 7.3.2, paragraph 7, nit:
-       available i.e. responses MAY be sent intermingled
+       available, i.e., responses MAY be sent intermingled
+                +     +

Section 7.3.4, paragraph 2, nit:
-    does not support edns-tcp-keepalive the client MAY keep the
+    does not support edns-tcp-keepalive, the client MAY keep the
+                                       +

Section 7.3.5, paragraph 2, nit:
-    that implementations may want to offer options to fallback to legacy
-    behavior when interoperating with servers known not to support
-                                                       ---
+    that implementations may want to offer options to fall back to legacy
+                                                          +
+    behavior when interoperating with servers known to not support
+                                                    +++

Section 7.4, paragraph 6, nit:
-    TCP in any given client/server interaction there SHOULD be no more
+    TCP in any given client/server interaction, there SHOULD be no more
+                                              +

Section 7.4, paragraph 7, nit:
-    As an illustration, it could be imagined that in future such an
+    As an illustration, it could be imagined that in the future such an
+                                                     ++++

Section 8.1, paragraph 2, nit:
-    For improved security all implementations of this specification MUST
+    For improved security, all implementations of this specification MUST
+                         +

Section 8.3, paragraph 2, nit:
-    It is useful to note that in XoT it is the secondary that initiates
+    It is useful to note that in XoT, it is the secondary that initiates
+                                    +

Section 8.3, paragraph 2, nit:
-    of connectivity the secondary is the TLS client and the primary the
+    of connectivity, the secondary is the TLS client and the primary the
+                   +

Section 8.4, paragraph 2, nit:
-    with XoT all XFR requests and response for that zone MUST be sent
+    with XoT, all XFR requests and responses for that zone MUST be sent
+            +                              +

Section 8.4, paragraph 3, nit:
-       authentication domain name using a Strict Privacy Profile as
+       authentication domain name using a Strict Privacy Profile, as
+                                                                +

Section 8.5, paragraph 2, nit:
-    However any behavior specified here takes precedence for XoT.
+    However, any behavior specified here takes precedence for XoT.
+           +

Section 8.6, paragraph 3, nit:
-    near future with a small number of configured secondaries but that do
-    wish to support DoT for regular queries from recursive in that same
+    near future with a small number of configured secondaries, but that do
+                                                             +
+    wish to support DoT for regular queries from recursives in that same
+                                                          +

Section 8.7, paragraph 2, nit:
-    connection it SHOULD respond with the extended DNS error code 21 -
-    Not Supported [RFC8914].  XoT clients should not send any further
-                                          ^^^^^^ ^^^
+    connection, it SHOULD respond with the extended DNS error code 21 -
+              +
+    Not Supported [RFC8914].  XoT clients SHOULD NOT send any further
+                                          ^^^^^^ ^^^

Section 8.7, paragraph 2, nit:
-    (for example, one hour) i.e., long enough that the server
+    (for example, one hour), i.e., long enough that the server
+                           +

Section 8.7, paragraph 3, nit:
-    Historically servers have used the REFUSED RCODE for many situations,
+    Historically, servers have used the REFUSED RCODE for many situations,
+                +

Section 8.7, paragraph 3, nit:
-    error or fallback path when queries were refused.  As a result the
+    error or fallback path when queries were refused.  As a result, the
+                                                                  +

Section 8.8.1, paragraph 3, nit:
-    o  to obfuscate the actual size of the transferred zone to minimize
+    o  to obfuscate the actual size of the transferred zone, to minimize
+                                                           +

Section 8.8.1, paragraph 4, nit:
-       updates to minimize information leakage about zone update activity
+       updates, to minimize information leakage about zone update activity
+              +

Section 8.8.1, paragraph 6, nit:
-    It is noted here that, depending on the padding policies eventually
-                         -
+    It is noted here that depending on the padding policies eventually

Section 8.8.1, paragraph 6, nit:
-    the EDNS(0) option for padding.  For example, without this capability
+    the EDNS(0) option for padding.  For example, without this capability,
+                                                                         +

Section 8.8.1, paragraph 6, nit:
-    theoretically be limited if there had to be a minimum of 1 RR per
+    theoretically be limited, if there had to be a minimum of 1 RR per
+                            +

Section 8.8.1, paragraph 7, nit:
-    response series in order to signal the conclusion of the zone
+    response series, in order to signal the conclusion of the zone
+                   +

Section 8.9.1, paragraph 2, nit:
-    Whilst it does add complexity to generating responses it can
-    significantly reduce the size of responses.  However any such
+    Whilst it does add complexity to generating responses, it can
+                                                         +
+    significantly reduce the size of responses.  However, any such
+                                                        +

Section 8.9.3, paragraph 2, nit:
-    incremental changes to the zone between SOA updates to minimize
+    incremental changes to the zone between SOA updates, to minimize
+                                                       +

Section 8.9.3, paragraph 3, nit:
-    IXFR responses can vary in size greatly from the order of 100 bytes
-                                   ^^^^^^^^
+    IXFR responses can greatly vary in size, from the order of 100 bytes
+                       ++++++++            ^

Section 8.10, paragraph 2, nit:
-    structure is 16384.  For some DNS implementations this limits the
+    structure is 16384.  For some DNS implementations, this limits the
+                                                     +

Section 8.10, paragraph 3, nit:
-    particularly helpful when padding is used since minimizing the
+    particularly helpful when padding is used, since minimizing the
+                                             +

Section 9, paragraph 3, nit:
-    When using persistent connections the secondary may have a XoT
+    When using persistent connections, the secondary may have a XoT
+                                     +

Section 9, paragraph 4, nit:
-    a 'preferred primary connection' model.  In this case the secondary
+    a 'preferred primary connection' model.  In this case, the secondary
+                                                         +

Section 9, paragraph 5, nit:
-    model.  Here a secondary could keep multiple persistent connections
+    model.  Here, a secondary could keep multiple persistent connections
+                +

Section 9, paragraph 5, nit:
-    reasonably low this might be feasible if latency is the most
+    reasonably low, this might be feasible if latency is the most
+                  +

Section 9, paragraph 6, nit:
-    document but implementations are encouraged to provide configuration
+    document, but implementations are encouraged to provide configuration
+            +

Section 10, paragraph 2, nit:
-    To provide context to the requirements in section Section 8.4, this
-                                              --------
+    To provide context to the requirements in Section 8.4, this

Section 10, paragraph 5, nit:
-       communication channel between the client and server (i.e. the two
+       communication channel between the client and server (i.e., the two
+                                                                +

Section 10.2, paragraph 2, nit:
-    sign a DNS message but uses public key authentication, where the
+    sign a DNS message, but uses public key authentication, where the
+                      +

Section 10.3.1, paragraph 4, nit:
-    o  however they MAY fallback to using TLS without authentication and
+    o  however, they MAY fallback to using TLS without authentication and
+              +

Section 10.3.1, paragraph 6, nit:
-    As such it does not offer a defense against active attacks (e.g., an
+    As such, it does not offer a defense against active attacks (e.g., an
+           +

Section 10.4, paragraph 3, nit:
-    This is also possible with XoT but it must be noted that, as with
+    This is also possible with XoT, but it must be noted that, as with
+                                  +

Section 10.4, paragraph 4, nit:
-    As discussed in Appendix A an IP based per connection ACL could also
-                                    ^         ^
-    be implemented where only TLS connections from recognized secondaries
+    As discussed in Appendix A, an IP-based per-connection ACL could also
+                              +      ^         ^
+    be implemented, where only TLS connections from recognized secondaries
+                  +

Section 10.5, paragraph 4, nit:
-    It is complementary but orthogonal the above mechanisms; and can be
-    used in conjunction with XoT but is not considered further here.
+    It is complementary but orthogonal to the above mechanisms; and can be
+                                        +++
+    used in conjunction with XoT, but is not considered further here.
+                                +

Section 11, paragraph 2, nit:
-    single primary/secondary relationship where both servers are under
-    the control of a single operator to a complex hierarchical structure
+    single primary/secondary relationship, where both servers are under
+                                         +
+    the control of a single operator, to a complex hierarchical structure,
+                                    +                                    +

Section 11, paragraph 9, nit:
-       origin authentication which might be desirable for deployments
+       origin authentication, which might be desirable for deployments
+                            +

Section 12, paragraph 6, nit:
-    both the client and server are configured to use only XoT and the
+    both the client and server are configured to use only XoT, and the
+                                                             +

Section 12, paragraph 10, nit:
-    Since this may require configuration of a number of servers who may
-                                                                ^ ^
-    be under the control of different operators the desired consistency
+    Since this may require configuration of a number of servers that may
+                                                                ^ ^^
+    be under the control of different operators, the desired consistency
+                                               +

Section 12, paragraph 11, nit:
-    Certain aspects of the Policies can be relatively easily tested
-                           ^
+    Certain aspects of the policies can be relatively easily tested
+                           ^

Section 12, paragraph 11, nit:
-    unauthorized IP addresses or over cleartext DNS.  Other aspects such
-    as if a secondary will accept data without a TSIG digest or if
-    secondaries are using Strict as opposed to Opportunistic TLS are more
+    unauthorized IP addresses or over cleartext DNS.  Other aspects, such
+                                                                   +
+    as if a secondary will accept data without a TSIG digest, or if
+                                                            +
+    secondaries are using Strict as opposed to Opportunistic TLS, are more
+                                                                +

Section 12, paragraph 12, nit:
-    the scope of this document but may be the subject of future
+    the scope of this document, but may be the subject of future
+                              +

"Appendix A.", paragraph 2, nit:
-    connections that supported only a limited set of queries (SOA, XRFs)
+    connections that supported only a limited set of queries (SOA, XRFs),
+                                                                        +

"A.1.", paragraph 2, nit:
-    Obviously a nameserver which hosts a zone and services queries for
+    Obviously, a nameserver which hosts a zone and services queries for
+             +

"A.2.", paragraph 3, nit:
-    assessed.  Once the connection is accepted the server might well be
-    willing to answer any query on that connection since it is coming
+    assessed.  Once the connection is accepted, the server might well be
+                                              +
+    willing to answer any query on that connection, since it is coming
+                                                  +

"A.4.", paragraph 2, nit:
-    based ACLs to authenticate secondaries.  In this case the primary
+    based ACLs to authenticate secondaries.  In this case, the primary
+                                                         +

"A.4.", paragraph 3, nit:
-    transfers) this is not strict and nothing in the DNS protocol
-    prevents using the same connection for both types of traffic.  Hence
+    transfers), this is not strict and nothing in the DNS protocol
+              +
+    prevents using the same connection for both types of traffic.  Hence,
+                                                                        +

"A.4.", paragraph 5, nit:
-    o  strict: REFUSE all queries on TLS connections except SOA and
+    o  strict: REFUSE all queries on TLS connections, except SOA and
+                                                    +

"A.4.", paragraph 8, nit:
-    o  relaxed: answer all non-XoT queries on all TLS connections with
+    o  relaxed: answer all non-XoT queries on all TLS connections, with
+                                                                 +

Section 1, paragraph 2, nit:
> rt by authoritatives might work. However there is currently no RFC that speci
>                                  ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 1, paragraph 15, nit:
> ations such ACLs are applied on a per query basis. Since requests typically
>                                   ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

Section 1, paragraph 16, nit:
> ow to use TLS (1.3 or later) as a transport to prevent zone collection from
>                                 ^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"transport".

Section 2, paragraph 1, nit:
> O BE REMOVED BEFORE PUBLICATION] The Github repository for this document is a
>                                      ^^^^^^
The official name of this software platform is spelled with a capital "H".

Section 4, paragraph 3, nit:
> information. The proposed mechanisms does not attempt to obscure such informa
>                                      ^^^^
You should probably use "do".

Section 4, paragraph 6, nit:
> n attacker had such capabilities. However this threat is likely true of any
>                                   ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 6, paragraph 9, nit:
> FR-over-TCP The term is used to encompasses the range of permutations that a
>                                 ^^^^^^^^^^^
The verb after "to" should be in the base form: "encompass".

Section 6.1, paragraph 10, nit:
> Rs and AXFRs of different zones. However [RFC5936] was constrained by having
>                                  ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 6.2, paragraph 9, nit:
>  packet, otherwise, TCP is used. In fact it says: "Thus, a client should f
>                                     ^^^^^^^
The comma is probably missing here: "fact, it".

Section 6.2, paragraph 11, nit:
> primary does not support IXFR. However it is noted that most widely used ope
>                                ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 6.3, paragraph 1, nit:
> xchanges This section attempts to presents a rationale for considering encryp
>                                   ^^^^^^^^
The verb after "to" should be in the base form: "present".

Section 7, paragraph 3, nit:
>  before TCP was considered a first class transport for DNS. [RFC1995], in fa
>                            ^^^^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"first class transport".

Section 7.3.1, paragraph 6, nit:
> on an open connection o a large number of timeouts or slow responses have oc
>                         ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, or simply use "many" or "numerous"

Section 7.3.1, paragraph 8, nit:
> received from the server and the client is in the process of closing the con
>                                         ^^
Did you mean "are"?

Section 8.6, paragraph 3, nit:
> e XoT in the near future with a small number of configured secondaries, but t
>                               ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some"

Section 8.8.1, paragraph 1, nit:
> l of padding AXoT responses would be two fold: o to obfuscate the actual size
>                                      ^^^^^^^^
The adjective or adverb 'twofold' needs to be written as one word.

Section 8.8.1, paragraph 6, nit:
>  is, AXoT responses that contain no RR's apart from an OPT RR containing the
>                                     ^^^^
The possessive apostrophe seems to be incorrect. Please remove the apostrophe
if you want to use the plural form of 'RR'.

Section 8.10, paragraph 2, nit:
> e to something around the order of 16kB. In principle, larger payload sizes
>                                    ^^^^
Insert a space between the numerical value and the unit symbol: "16 kB"

Section 9, paragraph 2, nit:
> messages and can send an SOA to all of the configured primaries. It can then
>                                 ^^^^^^^^^^
Consider using "all the".

Section 10, paragraph 2, nit:
> tion provides a brief summary of some of the existing authentication and vali
>                                  ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 10.4, paragraph 2, nit:
> transfers on primary servers on a per query basis. This is also possible wit
>                                   ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

Section 20, paragraph 13, nit:
>  references o Correct typos in acknowledgments draft-ietf-dprive-xfr-over-tls
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ('acknowledgment' and 'acknowledgement')
within a single text.

Section 20, paragraph 20, nit:
> -ietf-dprive-xfr-over-tls-04 o Add Github repository o Fix typos and referen
>                                    ^^^^^^
The official name of this software platform is spelled with a capital "H".

Section 21.2, paragraph 10, nit:
> nsaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, Sep
>                           ^^^
The word '0)s' is not standard English. Did you mean "0's" (curly apostrophe)
or "0's" (straight apostrophe)?

"A.1.", paragraph 3, nit:
> zone transfer on all transports on a per query basis. Cons: Attackers passiv
>                                      ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

"A.4.", paragraph 2, nit:
> TLS specific response policy on a per query basis. As an aside, whilst [RFC7
>                                   ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

"A.4.", paragraph 3, nit:
> d make per query decisions about whether or not to answer those queries. Exa
>                                  ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean 'regardless of whether'.

"A.4.", paragraph 10, nit:
> ions just to perform XFRs with a small number of secondaries. Client behavior
>                                ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some"

"A.4.1.", paragraph 1, nit:
> I based response policies In a similar fashion, XoT servers might use the pre
>                           ^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

"A.4.1.", paragraph 2, nit:
> S connections. Pros: This has to potential to allow a clean distinction betw
>                               ^^^^^^^^^^^^^^^
Did you mean "too potential to"?

Document references draft-ietf-dprive-rfc7626-bis-08, but
draft-ietf-dprive-rfc7626-bis-09 is the latest available revision.

Document references draft-ietf-dprive-dnsoquic-01, but
draft-ietf-dprive-dnsoquic-02 is the latest available revision.

Document references draft-ietf-tls-esni-09, but draft-ietf-tls-esni-10 is the
latest available revision.

Thanks for addressing my DISCUSS.

Hi,

Thank you for this document.

I was surprised by the length of this document - i.e., 40 pages to say to use TLS rather than TCP, and noting that DoH is only 20 pages long!

But in reality, this document seems to be more than just zone transfers over TLS and seems to clarify/optimize various behavior related to using TCP connection handling.

I have a few concrete suggestions that you are at liberty to handle as you see fit:

(1) Please ensure that the abstract accurately summarizes the focus on the document, with a sentence of two summarizing the updates to RFC1995, RFC5936 and RFC7766.

(2) I presume that section 21.3 is intended to be deleted (since the references appear to only be from section 16 which is planned to be removed), if so adding a RFC editor note would be helpful.

(3) It wasn't clear to me whether the text in the appendix is meant to be normative or illustrative.   It might be helpful to be clear which it is meant to be.

Regards,
Rob