DNS over Dedicated QUIC Connections
draft-ietf-dprive-dnsoquic-12

[Ballot comment]
Thanks for this, I found it clear and easy to read. I have just a couple comments.

1. In §5.2, there is

  Servers MAY defer processing of a query until the STREAM FIN has been
  indicated on the stream selected by the client.  Servers and clients
  MAY monitor the number of "dangling" streams for which the expected
  queries or responses have been received but not the STREAM FIN.
  Implementations MAY impose a limit on the number of such dangling
  streams.  If limits are encountered, implementations MAY close the
  connection.

Wouldn’t a stream be dangling even if the expected queries and responses hadn’t been received? I.e., isn’t the thing that makes a stream “dangling” simply the lack of a STREAM FIN?

2. In §5.4,

                                                      Client and servers
  that send packets over a connection discarded by their peer MAY
  receive a stateless reset indication.

This seems like a misuse of the RFC 2119 MAY. Do you mean "may" or better still, "might" or "could"? If you really mean the 2119 keyword, then a rewrite seems to be in order to put this in terms of the other party being permitted to send the reset.

[Ballot comment]
Moving my previous Discuss point to the Comment section: Thank you for
confirming that the server is permitted to disable 0-RTT entirely.
Let's try to work out a way to add some text that makes this more explicit.

[previous COMMENT position retained below, unchanged]

Thanks to Phillip Hallam-Baker for the secdir review.  I did want to
reiterate one of his comments, regarding the potential for harmful
interaction between use of DoQ (or really, any encrypted DNS transport)
and captive portals.  While this would accordingly have been best placed
in something generic to DNS privacy mechanisms, such as RFC 9076 or RFC
8932, I think there might still be room to mention it here.  I could
attempt to craft some text, if there is interest.

I made a pull request with some editorial suggestions at
https://github.com/huitema/dnsoquic/pull/154

Section 1

  The specific non-goals of this document are:
  [...]
  2.  No attempt to support server-initiated transactions, which are
      used only in DNS Stateful Operations (DSO) [RFC8490].

RFC 8490 is a proposed standard, so excluding it maybe is a bit in
conflict with claiming that this is a "general-purpose transport for DNS",
absent some other argument that DSO is a special-purpose tool.

Section 5.1.2

  DoQ connections MUST NOT use UDP port 53.  This recommendation
  against use of port 53 for DoQ is to avoid confusion between DoQ and
  the use of DNS over UDP [RFC1035].

Just to clarify: this prohibition is intended to apply even if there would
otherwise be mutual agreement to use port 53?

Section 5.2

  DNS traffic follows a simple pattern in which the client sends a
  query, and the server provides one or more responses (multiple
  responses can occur in zone transfers).

Is this true even for DSO server-initiated transactions?

  The client MUST select the next available client-initiated
  bidirectional stream for each subsequent query on a QUIC connection,
  in conformance with the QUIC transport specification [RFC9000].

Just to note: RFC 9000 does not require the client to *use* the "next
available" stream, instead saying that "a stream ID that is used out of
order results in all streams of that type with lower- numbered stream IDs
also being opened".  So this "MUST select the next available" is a new
requirement for DoQ, and it's not entirely clear to me that it's required
for interop (though it is more efficient than any alternatives).

Section 5.2.1

  This has implications for proxying DoQ message to and from other
  transports.  For example, proxies may have to manage the fact that
  DoQ can support a larger number of outstanding queries on a single
  connection than e.g., DNS over TCP because DoQ is not limited by the
  Message ID space.  This issue already exists for DoH, where a Message
  ID of 0 is recommended.

I'm not sure how often this motivating text is relevant.  The ID field
seems to be 16 bits, thus enabling 65k outstanding queries on a single
connection -- how often is there a need to have that many queries
outstanding at once?  It looks like the motivation presented in RFC 8484
for setting the ID to zero is to improve caching, as otherwise queries
identical at the DNS level would be cached as separate requests by HTTP.
I agree, of course, that the ID field is redundant with the QUIC stream ID
and that it should be set to zero, I am just not sure if the number of
outstanding queries is a relevant motivation for doing so.

(It also looks like RFC 8484 refers to this value as the "DNS ID" rather than
"Message ID".  I guess our options for consistent terminology are somewhat
limited, though.)

Section 5.3

  The following error codes are defined for use when abruptly
  terminating streams, aborting reading of streams, or immediately
  closing connections:

Should we say that these are what QUIC calls "application error code"s?
(Subsequent occurrences of the phrase "error code" might be modified to
"application error code" as well.)

Section 5.3.2

  set to DOQ_INTERNAL_ERROR.  [...]

Is there any further guidance to give on when a DNS SERVFAIL response vs
QUIC RESET_STREAM is preferred (or is the guidance really always to issue
RESET_STREAM)?

Section 5.3.3

  It is noted that the restrictions on use of the above EDNS(0) options
  has implications for proxying message from TCP/DoT/DoH over DoQ.

Was it already rejeted to spend a sentence mentioning that such proxying
would involve translating the messages per the needs of the different
protocols on the different connections?

Section 5.5

  Servers MUST NOT execute non replayable transactions received in
  0-RTT data.  Servers MUST adopt one of the following behaviors:

I think we should clarify whether "execute" means "take any action in
response to" or just "send a response message for".  (I think it needs to
be the former.)

Section 6.4

  Implementations MUST protect against the traffic analysis attacks
  described in Section 9.5 by the judicious injection of padding.  This

I think this is already overtaken by events, but a MUST-level requirement
seems overbearing here.  My understanding is that providing complete
protection against these types of attack is still an open research
question....

  could be done either by padding individual DNS messages using the
  EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see
  Section 8.6 of [RFC9000], the QUIC transport specification.

There is no Section 8.6 in RFC 9000.

Section 6.5.2

  Clients that want to maintain long duration DoQ connections SHOULD
  use the idle timeout mechanisms defined in Section 10.1 of [RFC9000],
  the QUIC transport specification.  Clients and servers MUST NOT send
  the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent
  on a DoQ connection (because it is specific to the use of TCP/TLS as
  a transport).

Should we make some statement (analogous to what RFC 7828 does) that if
such an option is received it MUST be ignored?  In the absence of such
guidance I can imagine implementors feeling a need to enforce the "MUST
NOT send" on the receiving end.

Section 6.7

  [RFC9103] specifies zone transfer over TLS (XoT) and includes updates
  to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766].  [...]

I note that there is currently no "Updates:" header to indicate this
relationship.

  *  DoQ implementations SHOULD

      -  use the same QUIC connection for both AXFR and IXFR requests to
        the same primary

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

      -  send the response(s) for each request as soon as they are
        available i.e. responses MAY be sent intermingled

Given the "SHOULD use the same QUIC connection", what does MAY-level
guidance to "intermingle such requests" mean, in a QUIC context?  Each DoQ
request is on a separate QUIC stream, so I do not see any opportunity for
intermingling other than by virtue of being in the same QUIC connection,
which is already a SHOULD.  This is in contrast to a TCP or TLS situation,
where there is only a single data stream and intermingling has some
natural meaning (or meanings, for the response case specifically, where it
might apply to overall responses (composed of multiple response messages)
or individual response messages).

Section 8

The discussion in §6.5.2 about resource management could be security
relevant at times, if we wanted to backreference it.

  The security considerations of DoQ should be comparable to those of
  DoT [RFC7858].  DoT as specified in [RFC7858] only addresses the stub

The security considerations section of RFC 7858 includes a MUST-level
requirement to adhere to the recommendations of BCP 195.  Does such a
MUST-level requirement apply to DoQ as well?  (I note that BCP 195 is
currently listed as only an informative reference, which would need to
change if a MUST-level requirement was added.)

  to recursive resolver scenario, but the considerations about person-
  in-the-middle attacks, middleboxes and caching of data from clear
  text connections also apply for DoQ to the resolver to authoritative
  server scenario.  [...]

RFC 7858 also lists a fourth consideration, traffic analysis or
side-channel leaks.  Do we want to forward-reference §9.5 for completeness
(or even take the secdir reviewer's suggestion of coalescing the privacy
considerations into the security considerations section as confidentiality
considerations)?

Section 9.1

  The prevention on allowing replayable transactions in 0-RTT data
  expressed in Section 5.5 blocks the most obvious risks of replay

Is the parity of negations correct here ("prevention on allowing")?  I see
§5.5 prohibiting execution of non-replayable transactions in 0-RTT data,
i.e., allowing replayable ones.

Section 10.4

  Provisional reservations share the range of values larger than 0x3f
  with some permanent registrations.  This is by design, to enable
  conversion of provisional registrations into permanent registrations
  without requiring changes in deployed systems.  (This design is
  aligned with the principles set in Section 22 of [RFC9000].)

Do we want to specifically call out the guidance on selecting specific
codepoints from §22.1.2 of RFC 9000?  (Or is it seen as not applicable
here?)

Section 12.1

We currently only specifically reference RFC 6891 in one place, to mention
that its provision for specifying maximum UDP message size is not relevant
for DoQ.  However, since we do define and require (in some cases) use of a
new "Too Early" EDNS(0) error code, it seems that the solution should be
to reference it from more places, rather than to demote it to an
informative reference.

Similarly, we only reference RFC 8914 in the IANA considerations where we
allocate the codepoint, and would likely benefit from sprinkling an
additional reference or two in the main body of the text.

RFC 7828, on the other hand, seems to only be mentioned to say that you
MUST NOT use it, which would probably be fine as an informative reference.

RFC 7873 is referenced for "similar to the DNS Cookies mechanism", which
also sounds solely informative.

  [I-D.ietf-dnsop-rfc8499bis]
              Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
              Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,

It's kind of surprising to see DoQ electing to take a normative dependency
on this draft that is not even in WGLC yet.  Wouldn't that risk incurring
substantial (unbounded) delays?

Section 12.2

A SHOULD-level requirement to implement the anti-replay mechanisms from
RFC 8446 seems to promote it to normative status, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

[Ballot comment]
Now THAT is a well done shepherd writeup.

Thanks for this work, which was an interesting read.  It's great to see this so quickly on the heels of QUIC itself.

Just a couple of BCP 14 things to point out.  In Section 5.4, we have this:

  Clients SHOULD monitor the idle time incurred on their connection to
  the server, defined by the time spent since the last packet from the
  server has been received.  When a client prepares to send a new DNS
  query to the server, it will check whether the idle time is
  sufficiently lower than the idle timer.  If it is, the client will
  send the DNS query over the existing connection.  If not, the client
  will establish a new connection and send the query over that
  connection.

There's a blanket SHOULD, followed by two "will"s.  I read those as normative requirements, even though they don't use BCP 14 language.  But that means they conflict with the SHOULD.  IMHO, this needs to be resolved.

In Section 5.5:

  Clients SHOULD consider potential privacy issues associated with
  session resumption before deciding to use this mechanism.  [...]

I find "SHOULD consider" to be far too vague for this to be meaningful.  If I've thought about it, have I met my burden here?

Thank you for including Section 7.

And now, some nits.

Abstract:

* "... similar properties to that provided by ..." -- s/that/those/

Section 1:

* "DNS over QUIC is referred here as ..." -- s/referred/referenced/ or s/referred/referred to/

Section 5.2:

* The second-last paragraph is missing a closing parenthesis.

[Ballot discuss]
I have a 0-RTT-related topic that I'd like to discuss, as the current
situation isn't entirely clear to me.  In particular, TLS 1.3 provides
(and QUIC inherits) a mechanism for a server to advertise that it just
does not support 0-RTT at all, via the (absence of the) "early_data"
extension.  This meshes nicely with the guidance in RFC 8446 that 0-RTT is
to only be used cautiously, and only with specific request from the
application.  However, this specificiation diverges from that requirement
for application opt-in (per §9.1), and so when I read the directive in
§5.5 that "servers MUST adopt one of the following behaviors", I am forced
to wonder if the absence of a "abort the connection, because you do not
enable early data at all" option is intended to forbid a server from
taking that approach and thus require servers to implement and enable
0-RTT at runtime.
I hope that the intent was just for the §5.5 listing to be predicated on
the server using 0-RTT at all, but it's hard to reach that conclusion from
the existing text, so I have to seek clarification.

[Ballot comment]
Thanks to Phillip Hallam-Baker for the secdir review.  I did want to
reiterate one of his comments, regarding the potential for harmful
interaction between use of DoQ (or really, any encrypted DNS transport)
and captive portals.  While this would accordingly have been best placed
in something generic to DNS privacy mechanisms, such as RFC 9076 or RFC
8932, I think there might still be room to mention it here.  I could
attempt to craft some text, if there is interest.

I made a pull request with some editorial suggestions at
https://github.com/huitema/dnsoquic/pull/154

Section 1

  The specific non-goals of this document are:
  [...]
  2.  No attempt to support server-initiated transactions, which are
      used only in DNS Stateful Operations (DSO) [RFC8490].

RFC 8490 is a proposed standard, so excluding it maybe is a bit in
conflict with claiming that this is a "general-purpose transport for DNS",
absent some other argument that DSO is a special-purpose tool.

Section 5.1.2

  DoQ connections MUST NOT use UDP port 53.  This recommendation
  against use of port 53 for DoQ is to avoid confusion between DoQ and
  the use of DNS over UDP [RFC1035].

Just to clarify: this prohibition is intended to apply even if there would
otherwise be mutual agreement to use port 53?

Section 5.2

  DNS traffic follows a simple pattern in which the client sends a
  query, and the server provides one or more responses (multiple
  responses can occur in zone transfers).

Is this true even for DSO server-initiated transactions?

  The client MUST select the next available client-initiated
  bidirectional stream for each subsequent query on a QUIC connection,
  in conformance with the QUIC transport specification [RFC9000].

Just to note: RFC 9000 does not require the client to *use* the "next
available" stream, instead saying that "a stream ID that is used out of
order results in all streams of that type with lower- numbered stream IDs
also being opened".  So this "MUST select the next available" is a new
requirement for DoQ, and it's not entirely clear to me that it's required
for interop (though it is more efficient than any alternatives).

Section 5.2.1

  This has implications for proxying DoQ message to and from other
  transports.  For example, proxies may have to manage the fact that
  DoQ can support a larger number of outstanding queries on a single
  connection than e.g., DNS over TCP because DoQ is not limited by the
  Message ID space.  This issue already exists for DoH, where a Message
  ID of 0 is recommended.

I'm not sure how often this motivating text is relevant.  The ID field
seems to be 16 bits, thus enabling 65k outstanding queries on a single
connection -- how often is there a need to have that many queries
outstanding at once?  It looks like the motivation presented in RFC 8484
for setting the ID to zero is to improve caching, as otherwise queries
identical at the DNS level would be cached as separate requests by HTTP.
I agree, of course, that the ID field is redundant with the QUIC stream ID
and that it should be set to zero, I am just not sure if the number of
outstanding queries is a relevant motivation for doing so.

(It also looks like RFC 8484 refers to this value as the "DNS ID" rather than
"Message ID".  I guess our options for consistent terminology are somewhat
limited, though.)

Section 5.3

  The following error codes are defined for use when abruptly
  terminating streams, aborting reading of streams, or immediately
  closing connections:

Should we say that these are what QUIC calls "application error code"s?
(Subsequent occurrences of the phrase "error code" might be modified to
"application error code" as well.)

Section 5.3.2

  set to DOQ_INTERNAL_ERROR.  [...]

Is there any further guidance to give on when a DNS SERVFAIL response vs
QUIC RESET_STREAM is preferred (or is the guidance really always to issue
RESET_STREAM)?

Section 5.3.3

  It is noted that the restrictions on use of the above EDNS(0) options
  has implications for proxying message from TCP/DoT/DoH over DoQ.

Was it already rejeted to spend a sentence mentioning that such proxying
would involve translating the messages per the needs of the different
protocols on the different connections?

Section 5.5

  Servers MUST NOT execute non replayable transactions received in
  0-RTT data.  Servers MUST adopt one of the following behaviors:

I think we should clarify whether "execute" means "take any action in
response to" or just "send a response message for".  (I think it needs to
be the former.)

Section 6.4

  Implementations MUST protect against the traffic analysis attacks
  described in Section 9.5 by the judicious injection of padding.  This

I think this is already overtaken by events, but a MUST-level requirement
seems overbearing here.  My understanding is that providing complete
protection against these types of attack is still an open research
question....

  could be done either by padding individual DNS messages using the
  EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see
  Section 8.6 of [RFC9000], the QUIC transport specification.

There is no Section 8.6 in RFC 9000.

Section 6.5.2

  Clients that want to maintain long duration DoQ connections SHOULD
  use the idle timeout mechanisms defined in Section 10.1 of [RFC9000],
  the QUIC transport specification.  Clients and servers MUST NOT send
  the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent
  on a DoQ connection (because it is specific to the use of TCP/TLS as
  a transport).

Should we make some statement (analogous to what RFC 7828 does) that if
such an option is received it MUST be ignored?  In the absence of such
guidance I can imagine implementors feeling a need to enforce the "MUST
NOT send" on the receiving end.

Section 6.7

  [RFC9103] specifies zone transfer over TLS (XoT) and includes updates
  to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766].  [...]

I note that there is currently no "Updates:" header to indicate this
relationship.

  *  DoQ implementations SHOULD

      -  use the same QUIC connection for both AXFR and IXFR requests to
        the same primary

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

      -  send the response(s) for each request as soon as they are
        available i.e. responses MAY be sent intermingled

Given the "SHOULD use the same QUIC connection", what does MAY-level
guidance to "intermingle such requests" mean, in a QUIC context?  Each DoQ
request is on a separate QUIC stream, so I do not see any opportunity for
intermingling other than by virtue of being in the same QUIC connection,
which is already a SHOULD.  This is in contrast to a TCP or TLS situation,
where there is only a single data stream and intermingling has some
natural meaning (or meanings, for the response case specifically, where it
might apply to overall responses (composed of multiple response messages)
or individual response messages).

Section 8

The discussion in §6.5.2 about resource management could be security
relevant at times, if we wanted to backreference it.

  The security considerations of DoQ should be comparable to those of
  DoT [RFC7858].  DoT as specified in [RFC7858] only addresses the stub

The security considerations section of RFC 7858 includes a MUST-level
requirement to adhere to the recommendations of BCP 195.  Does such a
MUST-level requirement apply to DoQ as well?  (I note that BCP 195 is
currently listed as only an informative reference, which would need to
change if a MUST-level requirement was added.)

  to recursive resolver scenario, but the considerations about person-
  in-the-middle attacks, middleboxes and caching of data from clear
  text connections also apply for DoQ to the resolver to authoritative
  server scenario.  [...]

RFC 7858 also lists a fourth consideration, traffic analysis or
side-channel leaks.  Do we want to forward-reference §9.5 for completeness
(or even take the secdir reviewer's suggestion of coalescing the privacy
considerations into the security considerations section as confidentiality
considerations)?

Section 9.1

  The prevention on allowing replayable transactions in 0-RTT data
  expressed in Section 5.5 blocks the most obvious risks of replay

Is the parity of negations correct here ("prevention on allowing")?  I see
§5.5 prohibiting execution of non-replayable transactions in 0-RTT data,
i.e., allowing replayable ones.

Section 10.4

  Provisional reservations share the range of values larger than 0x3f
  with some permanent registrations.  This is by design, to enable
  conversion of provisional registrations into permanent registrations
  without requiring changes in deployed systems.  (This design is
  aligned with the principles set in Section 22 of [RFC9000].)

Do we want to specifically call out the guidance on selecting specific
codepoints from §22.1.2 of RFC 9000?  (Or is it seen as not applicable
here?)

Section 12.1

We currently only specifically reference RFC 6891 in one place, to mention
that its provision for specifying maximum UDP message size is not relevant
for DoQ.  However, since we do define and require (in some cases) use of a
new "Too Early" EDNS(0) error code, it seems that the solution should be
to reference it from more places, rather than to demote it to an
informative reference.

Similarly, we only reference RFC 8914 in the IANA considerations where we
allocate the codepoint, and would likely benefit from sprinkling an
additional reference or two in the main body of the text.

RFC 7828, on the other hand, seems to only be mentioned to say that you
MUST NOT use it, which would probably be fine as an informative reference.

RFC 7873 is referenced for "similar to the DNS Cookies mechanism", which
also sounds solely informative.

  [I-D.ietf-dnsop-rfc8499bis]
              Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
              Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,

It's kind of surprising to see DoQ electing to take a normative dependency
on this draft that is not even in WGLC yet.  Wouldn't that risk incurring
substantial (unbounded) delays?

Section 12.2

A SHOULD-level requirement to implement the anti-replay mechanisms from
RFC 8446 seems to promote it to normative status, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

[Ballot comment]
Thank you for the work on this document, I only have two comments below.

Francesca

1. -----

  443 is less likely to be blocked than other ports.  Several
  mechanisms for stubs to discover recursives offering encrypted
  transports, including the use of custom ports, are the subject of
  ongoing work.

and

  For the recursive resolver to authoritative nameserver scenario,
  authentication requirements are unspecified at the time of writing
  and are the subject on ongoing work in the DPRIVE WG.

FP: Are there (informative) references you can point the reader to?

2. ----

  If a peer encounters such an error condition it is considered a fatal
  error.  It SHOULD forcibly abort the connection using QUIC's
  CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code
  DOQ_PROTOCOL_ERROR.

FP: Just seeing now that Alvaro has the same comment here - it would make sense to state why the first SHOULD is not a MUST. What is the exception where it would make sense that the peer does not abort the connection? Or is it the CONNECTION_CLOSE mechanism that can be skipped in some cases, so the "SHOULD" apply only to that mechanism and not to the abort? Some more text here would be useful.

[Ballot comment]
Thanks for this draft! It was very easy to read.

(4.3) says:

"Using QUIC might allow a protocol to disguise its purpose from devices on the network path using encryption and traffic analysis resistance techniques like padding. This specification does not include any measures that are designed to avoid such classification."

but then Sec 6.4 has a detailed, normative discussion of how to use padding to avoid classification. I suggest you delete or edit the bit in 4.3.

(5.3.1) Clients are allowed to send STOP_SENDING and servers are allowed to send RESET_STREAM. Servers sending STOP_SENDING break the connection. Given the prescriptiveness of these rules, it's odd that you don't address clients sending RESET_STREAM. IMO this should be allowed, but either way it should be specified.

(6.5.4) and (9.4) I hesitate to write this, as Christian is as well aware as anyone, but IMO QUIC address migration is not quite as privacy-destroying as this draft suggests. RFC9000 has a number of normative requirements to reduce linkability, and work is ongoing to reduce it further. Granted, no anti-linkability mitigation is perfect, and if this is a primary goal of DoQ it's OK to discourage migration as you've done here.

[Ballot comment]
§5.3.3 lists some protocol error scenarios that are considered fatal.

  If a peer encounters such an error condition it is considered a fatal
  error.  It SHOULD forcibly abort the connection using QUIC's
  CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code
  DOQ_PROTOCOL_ERROR.

When is it ok not to abort the connection?  Why is aborting the connection recommended and not required if the errors are considered fatal?

[Ballot comment]
Thanks a lot for working on this specification. Thanks to Brian Trammell  for the TSVART review. 

I have following comments and I think addressing them will improve this documentation-
 
  * Section 5.3.3 - should also list the protocol error case related to  session resumption and 0-RTT, and put a reference to section 5.5 for further details.

  * Section 5.2 says -

    "Implementations MAY impose a limit on the number of such dangling streams. If limits are encountered, implementations MAY close the connection."

    However, I have  not notices any indication  of how this limits can be set. I would be great if we can say how the implementer can enforce the normative "MAY".

[Ballot comment]
Thanks a lot for working on this specification. Thanks for Brian Trammell the TSVART review. 

I have following comments and I think addressing them will improve this documentation-
 
  * Section 5.3.3 - should also list the protocol error case related to  session resumption and 0-RTT, and put a reference to section 5.5 for further details.

  * Section 5.2 says -

    "Implementations MAY impose a limit on the number of such dangling streams. If limits are encountered, implementations MAY close the connection."

    However, I have  not notices any indication  of how this limits can be set. I would be great if we can say how the implementer can enforce the normative "MAY".

[Ballot comment]
Hi,

Thanks for this doc.  It looks like DNS and QUIC could be a good fit.  Just a few minor comments/questions.

  In QUIC, sending STOP_SENDING requests that a peer cease transmission
  on a stream.  If a DoQ client wishes to cancel an outstanding
  request, it MUST issue a QUIC STOP_SENDING with error code
  DOQ_REQUEST_CANCELLED.  This may be sent at any time but will be
  ignored if the server response has already been acknowledged.  The
  corresponding DNS transaction MUST be abandoned.

I presume that there is no requirement that the DNS transaction be immediately abandoned.  E.g., if a server already has a reply queued for sending, then it is still reasonable to send that response?


  Because new error codes can be defined without negotiation, use of an
  error code in an unexpected context or receipt of an unknown error
  code MUST be treated as equivalent to DOQ_NO_ERROR.


I find DOQ_NO_ERROR to be a strange name for an error code because I would naturally assume that DOQ_NO_ERROR is equivalent to "success", but that doesn't seem to be the intention here.  In particular, I find it strange to treat an unknown error equivalently to DOQ_NO_ERROR.  I'm not saying that the behaviour is wrong, only that the naming is slightly strange/confusing.


  In theory, padding at the QUIC level could result in better
  performance for the equivalent protection

As a nit, I didn't find "QUIC level" to be particularly clear, and hence I was wondering whether this could be clarified.  E.g., is this at the QUIC protocol level, or QUIC packet level.


10.4.  DNS over QUIC Error Codes Registry
  Registrations in this registry MUST include the following fields:

This lists various fields that MUST be included, but doesn't specify values for the initially assigned values in the table.

Regards,
Rob

[Ballot comment]
Section 5.5. , paragraph 4, comment:
>    The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are
>    not "replayable" transactions.  In this specification, only
>    transactions that have an OPCODE of QUERY or NOTIFY are considered
>    replayable and MAY be sent in 0-RTT data.  See Appendix A for a
>    detailed discussion of why NOTIFY is included here.

I think the "SHOULD NOT" should become a "MUST NOT", given that servers don't
execute it anyway. Also, the "and MAY be sent in 0-RTT data" bit isn't using
the RFC2119 terms correctly. Suggest to remove it and replace it with "other
OPCODEs MUST NOT be sent in 0-RTT data".

Thanks to Stewart Bryant for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/knoZG7fEYMwRxN7B5Q5o8YhPcbw).

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

Section 1. , paragraph 7, nit:
-    3.  Provide a transport that is not constrained by path MTU
-                                ^      ^ - ----- ----
-        limitations on the size of DNS responses it can send.
-                                      ^  ---
+    3.  Provide a transport that does not impose path MTU
+                                ^^^      ^^^
+        limitations on the size of DNS messages it can send.
+                                      ^  ++

Section 5.3.3. , paragraph 6, nit:
-      expected (e.g. multiple responses to a query for an A record)
+      expected (e.g., multiple responses to a query for an A record)
+                    +

Section 5.5. , paragraph 4, nit:
-    Servers MUST NOT execute non replayable transactions received in
-                                ^
+    Servers MUST NOT execute non-replayable transactions received in
+                                ^

Section 9.5. , paragraph 2, nit:
-    dozen of DNS names.  If an application adopts a simple mapping of one
+    dozens of DNS names.  If an application adopts a simple mapping of one
+        +

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

Section 5.2.1. , paragraph 2, nit:
> : The DoQ implementation encountered an protocol error and is forcibly aborti
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 5.3. , paragraph 5, nit:
> rcumstances servers might very well chose to send different error codes. Not
>                                    ^^^^^
The modal verb "might" requires the verb's base form.

Section 6.5.1. , paragraph 2, nit:
> ssion create privacy risks detailed in detailed in Section 9.2 and Section 9
>                            ^^^^^^^^^^^^^^^^^^^^^^^
This phrase is duplicated. You should probably use "detailed in" only once.

Section 6.5.2. , paragraph 5, nit:
>  tickets with a sufficiently long life time (e.g., 6 hours), so that clients
>                                  ^^^^^^^^^
This noun is normally spelled as one word.

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

The IANA Functions Operator has completed its review of draft-ietf-dprive-dnsoquic-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a new registration is to be made as follows:

Protocol: DoQ
Identification Sequence: 0x64 0x6F 0x71 ("doq")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, we will update the description and list this document as an additional reference for UDP port 853:

Service Name: domain-s
Port Number: 853
Transport Protocol(s): UDP
Assignee: IETF DPRIVE Chairs
Contact: Brian Haberman
Description: DNS query-response protocol run over DTLS or QUIC
Reference: [RFC7858][RFC8094][ RFC-to-be ]

In addition, the Description field for the corresponding TCP port 853 allocation will be changed to 'DNS query-response protocol run over TLS'.

IANA Question: According to Section 8.1.1 of RFC 6335, the IESG should be listed as the assignee and the IETF Chair as the contact for an IETF-stream document. Can the assignee and contact fields in Section 10.2 be updated?

IANA understands that the IETF Port expert team has reviewed the modifications above and has found them to be acceptable.

Third, in the Extended DNS Error Codes registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

a new registration will be made as follows:

INFO-CODE: [ TBD-at-Registration ]
Purpose: Too Early
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the DNS over QUIC Error Codes registry. The new registry will be located on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

The registration rules for the new registry are:

0x00 - 0x3f require Standards Action or IESG Approval

Permanent registrations for values larger than 0x3f, which are assigned using the Specification Required policy (as defined in [RFC8126])

Provisional registrations for values larger than 0x3f, which require Expert Review, as defined in Section 4.5 of [RFC8126].

There are initial registrations in the new registry as follows:

+==========+=======================+================+============================+
|Value | Error |Description | Specification |
+==========+=======================+================+============================+
|0x0 | DOQ_NO_ERROR |No error | [ RFC-to-be; Section 5.3 ] |
+----------+-----------------------+----------------+----------------------------+
|0x1 | DOQ_INTERNAL_ERROR |Implementation | [ RFC-to-be; Section 5.3 ] |
| | |error | |
+----------+-----------------------+----------------+----------------------------+
|0x2 | DOQ_PROTOCOL_ERROR |Generic protocol| [ RFC-to-be; Section 5.3 ] |
| | |violation | |
+----------+-----------------------+----------------+----------------------------+
|0x3 | DOQ_REQUEST_CANCELLED |Request | [ RFC-to-be; Section 5.3 ] |
| | |cancelled by | |
| | |client | |
+----------+-----------------------+----------------+----------------------------+
|0x4 | DOQ_EXCESSIVE_LOAD |Closing a | [ RFC-to-be; Section 5.3 ] |
| | |connection for | |
| | |excessive load | |
+----------+-----------------------+----------------+----------------------------+
|0xd098ea5e| DOQ_ERROR_RESERVED |Alternative | [ RFC-to-be; Section 5.3 ] |
| | |error code used | |
| | |for tests | |
+----------+-----------------------+----------------+----------------------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-02-23):

From: The IESG
To: IETF-Announce
CC: brian@innovationslab.net, dns-privacy@ietf.org, dprive-chairs@ietf.org, draft-ietf-dprive-dnsoquic@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Second Last Call:  (DNS over Dedicated QUIC Connections) to Proposed Standard


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'DNS over Dedicated QUIC Connections'
  as Proposed Standard

As RFC 8467 is now a normative reference and as the text of section 6.4 (padding) has
changed since the first IETF Last Call, I am requesting a second IETF Last Call.

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 2022-02-23. 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 describes the use of QUIC to provide transport privacy
  for DNS.  The encryption provided by QUIC has similar properties to
  that provided by TLS, while QUIC transport eliminates the head-of-
  line blocking issues inherent with TCP and provides more efficient
  packet loss recovery than UDP.  DNS over QUIC (DoQ) has privacy
  properties similar to DNS over TLS (DoT) specified in RFC7858, and
  latency characteristics similar to classic DNS over UDP.  This
  specification describes the use of DNS over QUIC as a general-purpose
  transport for DNS and includes the use of DNS over QUIC for stub to
  recursive, recursive to authoritative, and zone transfer scenarios.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0)) (Experimental - Internet Engineering Task Force (IETF))

As RFC 8467 is now a normative reference and as the text of section 6.4 (padding) has changed since the first IETF Last Call, I am requested a second IETF Last Call.

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

The IANA Functions Operator has completed its review of draft-ietf-dprive-dnsoquic-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a new registration is to be made as follows:

Protocol: DoQ
Identification Sequence: 0x64 0x6F 0x71 ("doq")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, we will update the description and list this document as an additional reference for UDP port 853:

Service Name: domain-s
Port Number: 853
Transport Protocol(s): UDP
Assignee: IETF DPRIVE Chairs
Contact: Brian Haberman
Description: DNS query-response protocol run over DTLS or QUIC
Reference: [RFC7858][RFC8094] This document

In addition, the Description field for the corresponding TCP port 853 allocation will be changed to 'DNS query-response protocol run over TLS'.

IANA Question: We understand from Section 8.1.1 of RFC 6335 that the IESG should be listed as the assignee and the IETF Chair as the contact for an IETF-stream document. Can you confirm that this is correct?

IANA Question: Since we didn't make a temporary early allocation request for the above port, can the early allocation language be removed from the document? We will make the changes as agreed with the port experts when the document is approved for publication.

IANA notes that section 10.2.1 contains notes for implementer of early experiments and no instructions for IANA.

Third, in the Extended DNS Error Codes registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

a new registration will be made as follows:

INFO-CODE: [ TBD-at-Registration ]
Purpose: Too Early
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the DNS over QUIC Error Codes registry. The new registry will be located on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

The registration rules for the new registry are:

0x00 - 0x3f require Standards Action or IESG Approval

Permanent registrations for values larger than 0x3f, which are assigned using the Specification Required policy (as defined in [RFC8126])

Provisional registrations for values larger than 0x3f, which require Expert Review, as defined in Section 4.5 of [RFC8126].

There are initial registrations in the new registry as follows:

+==========+=======================+================+============================+
|Value | Error |Description | Specification |
+==========+=======================+================+============================+
|0x0 | DOQ_NO_ERROR |No error | [ RFC-to-be; Section 5.3 ] |
+----------+-----------------------+----------------+----------------------------+
|0x1 | DOQ_INTERNAL_ERROR |Implementation | [ RFC-to-be; Section 5.3 ] |
| | |error | |
+----------+-----------------------+----------------+----------------------------+
|0x2 | DOQ_PROTOCOL_ERROR |Generic protocol| [ RFC-to-be; Section 5.3 ] |
| | |violation | |
+----------+-----------------------+----------------+----------------------------+
|0x3 | DOQ_REQUEST_CANCELLED |Request | [ RFC-to-be; Section 5.3 ] |
| | |cancelled by | |
| | |client | |
+----------+-----------------------+----------------+----------------------------+
|0x4 | DOQ_EXCESSIVE_LOAD |Closing a | [ RFC-to-be; Section 5.3 ] |
| | |connection for | |
| | |excessive load | |
+----------+-----------------------+----------------+----------------------------+
|0xd098ea5e| DOQ_ERROR_RESERVED |Alternative | [ RFC-to-be; Section 5.3 ] |
| | |error code used | |
| | |for tests | |
+----------+-----------------------+----------------+----------------------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-01-25):

From: The IESG
To: IETF-Announce
CC: brian@innovationslab.net, dns-privacy@ietf.org, dprive-chairs@ietf.org, draft-ietf-dprive-dnsoquic@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS over Dedicated QUIC Connections) to Proposed Standard


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'DNS over Dedicated QUIC Connections'
  as Proposed Standard

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 2022-01-25. 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 describes the use of QUIC to provide transport privacy
  for DNS.  The encryption provided by QUIC has similar properties to
  that provided by TLS, while QUIC transport eliminates the head-of-
  line blocking issues inherent with TCP and provides more efficient
  packet loss recovery than UDP.  DNS over QUIC (DoQ) has privacy
  properties similar to DNS over TLS (DoT) specified in RFC7858, and
  latency characteristics similar to classic DNS over UDP.  This
  specification describes the use of DNS over QUIC as a general-purpose
  transport for DNS and includes the use of DNS over QUIC for stub to
  recursive, recursive to authoritative, and zone transfer scenarios.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/



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

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?

Proposed Standard. The draft specifies the use of QUIC for transporting DNS exchanges between parties. The document specifies this status in its header.

(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 describes the use of QUIC to provide transport privacy for DNS.  The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet loss recovery than UDP.  DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC7858, and latency characteristics similar to classic DNS over UDP.

Working Group Summary:

There is consensus in the DPRIVE WG for publishing this specification. Additionally, valuable feedback was received from the QUIC WG as they were copied on the start of the WG Last Call.

Document Quality:

This document has undergone review from both DNS experts (implementors and operators) and QUIC experts. The feedback from the QUIC WG was valuable in identifying areas of the specification in need of additional detail.

Personnel:

Brian Haberman is the document shepherd. Éric Vyncke is the responsible Area Director.

(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 document shepherd reviewed both the WGLC version (-05) and the latest version (-07). The review entailed both a critical review of the specification for completeness as well as a review to determine if all WGLC comments were addressed. The current version (-07) does include text related to operating the protocol over UDP port 853, which is currently being reviewed for early allocation via IANA.

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

No.

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

The document was reviewed by members of the QUIC WG, which is broader perspective needed for this specification.

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

The shepherd does not have any concerns with this document.

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

(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?

The shepherd would categorize the consensus as being strong amongst the small (~10), but vocal, WG participants interested in the technology. The WG does have a history of raising concerns with work it sees as problematic and that type of resistance has not appeared with respect to this specification.

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

- The 2119 boilerplate check in id-nits does not seem to recognize the use of BCP 14 / RFC 8174.
- The document contains a normative down-reference to RFC 8094. The reference can be moved to the Informative reference section as it is simply identifying the specification associated with UDP port 853.
- The document contains a normative down-reference to RFC 8467. The WG is requesting a waiver for this down-ref as it is key to implementation guidance for the specification related to EDNS(0) padding.

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

N/A.

(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?

This document has a normative reference to draft-ietf-dnsop-rfc8499bis. This document is actively being worked on in the DNSOP WG.

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

Yes. As noted earlier, the WG is requesting a down-ref waiver for RFC 8467. We could also, potentially, attempt to re-write the text related to RFC 8467 to make it an Informative reference. Interested in guidance.

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

No.

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

The IANA Considerations section is complete and consistent with the body of the document. This document is making a request to associate UDP port 853 with DNS-over-QUIC. We are awaiting a response on an early allocation request for the port from IANA.

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

The document creates a new registry entitled "DNS over QUIC Error Codes Registry", which is split into three ranges of assignment. One of those ranges is for provisional registrations and requires Expert Review. The goal of this range is to facilitate early experimentation/testing with the ability to transition the provisional value to a permanent one when a specification is published as an RFC. As a starting point, it is suggested that the document authors and the WG chairs be the initial set of expert reviewers.

(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

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?

Proposed Standard. The draft specifies the use of QUIC for transporting DNS exchanges between parties. The document specifies this status in its header.

(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 describes the use of QUIC to provide transport privacy for DNS.  The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet loss recovery than UDP.  DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC7858, and latency characteristics similar to classic DNS over UDP.

Working Group Summary:

There is consensus in the DPRIVE WG for publishing this specification. Additionally, valuable feedback was received from the QUIC WG as they were copied on the start of the WG Last Call.

Document Quality:

This document has undergone review from both DNS experts (implementors and operators) and QUIC experts. The feedback from the QUIC WG was valuable in identifying areas of the specification in need of additional detail.

Personnel:

Brian Haberman is the document shepherd. Éric Vyncke is the responsible Area Director.

(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 document shepherd reviewed both the WGLC version (-05) and the latest version (-07). The review entailed both a critical review of the specification for completeness as well as a review to determine if all WGLC comments were addressed. The current version (-07) does include text related to operating the protocol over UDP port 853, which is currently being reviewed for early allocation via IANA.

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

No.

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

The document was reviewed by members of the QUIC WG, which is broader perspective needed for this specification.

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

The shepherd does not have any concerns with this document.

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

(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?

The shepherd would categorize the consensus as being strong amongst the small (~10), but vocal, WG participants interested in the technology. The WG does have a history of raising concerns with work it sees as problematic and that type of resistance has not appeared with respect to this specification.

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

- The 2119 boilerplate check in id-nits does not seem to recognize the use of BCP 14 / RFC 8174.
- The document contains a normative down-reference to RFC 8094. The reference can be moved to the Informative reference section as it is simply identifying the specification associated with UDP port 853.
- The document contains a normative down-reference to RFC 8467. The WG is requesting a waiver for this down-ref as it is key to implementation guidance for the specification related to EDNS(0) padding.

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

N/A.

(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?

This document has a normative reference to draft-ietf-dnsop-rfc8499bis. This document is actively being worked on in the DNSOP WG.

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

Yes. As noted earlier, the WG is requesting a down-ref waiver for RFC 8467. We could also, potentially, attempt to re-write the text related to RFC 8467 to make it an Informative reference. Interested in guidance.

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

No.

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

The IANA Considerations section is complete and consistent with the body of the document. This document is making a request to associate UDP port 853 with DNS-over-QUIC. We are awaiting a response on an early allocation request for the port from IANA.

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

The document creates a new registry entitled "DNS over QUIC Error Codes Registry", which is split into three ranges of assignment. One of those ranges is for provisional registrations and requires Expert Review. The goal of this range is to facilitate early experimentation/testing with the ability to transition the provisional value to a permanent one when a specification is published as an RFC. As a starting point, it is suggested that the document authors and the WG chairs be the initial set of expert reviewers.

(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

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?

Proposed Standard. The draft specifies the use of QUIC for transporting DNS exchanges between parties. The document specifies this status in its header.

(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 describes the use of QUIC to provide transport privacy for DNS.  The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet loss recovery than UDP.  DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC7858, and latency characteristics similar to classic DNS over UDP.

Working Group Summary:

There is consensus in the DPRIVE WG for publishing this specification. Additionally, valuable feedback was received from the QUIC WG as they were copied on the start of the WG Last Call.

Document Quality:

This document has undergone review from both DNS experts (implementors and operators) and QUIC experts. The feedback from the QUIC WG was valuable in identifying areas of the specification in need of additional detail.

Personnel:

Brian Haberman is the document shepherd. Éric Vyncke is the responsible Area Director.

(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 document shepherd reviewed both the WGLC version (-05) and the latest version (-07). The review entailed both a critical review of the specification for completeness as well as a review to determine if all WGLC comments were addressed. The current version (-07) does include text related to operating the protocol over UDP port 853, which is currently being reviewed for early allocation via IANA.

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

No.

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

The document was reviewed by members of the QUIC WG, which is broader perspective needed for this specification.

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

The shepherd does not have any concerns with this document.

(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?

In process.

(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?

The shepherd would categorize the consensus as being strong amongst the small (~10), but vocal, WG participants interested in the technology. The WG does have a history of raising concerns with work it sees as problematic and that type of resistance has not appeared with respect to this specification.

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

- The 2119 boilerplate check in id-nits does not seem to recognize the use of BCP 14 / RFC 8174.
- The document contains a normative down-reference to RFC 8094. The reference can be moved to the Informative reference section as it is simply identifying the specification associated with UDP port 853.
- The document contains a normative down-reference to RFC 8467. The WG is requesting a waiver for this down-ref as it is key to implementation guidance for the specification related to EDNS(0) padding.

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

N/A.

(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?

This document has a normative reference to draft-ietf-dnsop-rfc8499bis. This document is actively being worked on in the DNSOP WG.

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

Yes. As noted earlier, the WG is requesting a down-ref waiver for RFC 8467.

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

No.

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

The IANA Considerations section is complete and consistent with the body of the document. This document is making a request to associate UDP port 853 with DNS-over-QUIC.

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

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

(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?