< draft-ietf-dprive-dnsoquic-10.txt   draft-ietf-dprive-dnsoquic-11.txt >
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Standards Track S. Dickinson Intended status: Standards Track S. Dickinson
Expires: 1 September 2022 Sinodun IT Expires: 22 September 2022 Sinodun IT
A. Mankin A. Mankin
Salesforce Salesforce
28 February 2022 21 March 2022
DNS over Dedicated QUIC Connections DNS over Dedicated QUIC Connections
draft-ietf-dprive-dnsoquic-10 draft-ietf-dprive-dnsoquic-11
Abstract Abstract
This document describes the use of QUIC to provide transport privacy This document describes the use of QUIC to provide transport
for DNS. The encryption provided by QUIC has similar properties to confidentiality for DNS. The encryption provided by QUIC has similar
that provided by TLS, while QUIC transport eliminates the head-of- properties to those provided by TLS, while QUIC transport eliminates
line blocking issues inherent with TCP and provides more efficient the head-of-line blocking issues inherent with TCP and provides more
packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy efficient packet loss recovery than UDP. DNS over QUIC (DoQ) has
properties similar to DNS over TLS (DoT) specified in RFC7858, and privacy properties similar to DNS over TLS (DoT) specified in
latency characteristics similar to classic DNS over UDP. This RFC7858, and latency characteristics similar to classic DNS over UDP.
specification describes the use of DNS over QUIC as a general-purpose This specification describes the use of DNS over QUIC as a general-
transport for DNS and includes the use of DNS over QUIC for stub to purpose transport for DNS and includes the use of DNS over QUIC for
recursive, recursive to authoritative, and zone transfer scenarios. stub to recursive, recursive to authoritative, and zone transfer
scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 September 2022. This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5
4.1. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5 4.1. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5
4.2. Design for Minimum Latency . . . . . . . . . . . . . . . 5 4.2. Design for Minimum Latency . . . . . . . . . . . . . . . 5
4.3. Middlebox Considerations . . . . . . . . . . . . . . . . 6 4.3. Middlebox Considerations . . . . . . . . . . . . . . . . 6
4.4. No Server-Initiated Transactions . . . . . . . . . . . . 6 4.4. No Server-Initiated Transactions . . . . . . . . . . . . 6
5. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6 5. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Connection Establishment . . . . . . . . . . . . . . . . 7 5.1. Connection Establishment . . . . . . . . . . . . . . . . 7
5.1.1. Draft Version Identification . . . . . . . . . . . . 7 5.1.1. Draft Version Identification . . . . . . . . . . . . 7
5.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7 5.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7
5.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7 5.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7
5.2.1. DNS Message IDs . . . . . . . . . . . . . . . . . . . 8 5.2.1. DNS Message IDs . . . . . . . . . . . . . . . . . . . 9
5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 9 5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9 5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 10
5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 10 5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 11
5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10 5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 11
5.3.4. Alternative error codes . . . . . . . . . . . . . . . 11 5.3.4. Alternative error codes . . . . . . . . . . . . . . . 12
5.4. Connection Management . . . . . . . . . . . . . . . . . . 11 5.4. Connection Management . . . . . . . . . . . . . . . . . . 12
5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 12 5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 13
5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 14
6. Implementation Requirements . . . . . . . . . . . . . . . . . 13 6. Implementation Requirements . . . . . . . . . . . . . . . . . 14
6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 13 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 14
6.2. Fallback to Other Protocols on Connection Failure . . . . 14 6.2. Fallback to Other Protocols on Connection Failure . . . . 15
6.3. Address Validation . . . . . . . . . . . . . . . . . . . 14 6.3. Address Validation . . . . . . . . . . . . . . . . . . . 15
6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 15 6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 16
6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 15 6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 17
6.5.2. Resource Management . . . . . . . . . . . . . . . . . 16 6.5.2. Resource Management . . . . . . . . . . . . . . . . . 17
6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16 6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 18
6.5.4. Controlling Connection Migration For Privacy . . . . 17 6.5.4. Controlling Connection Migration For Privacy . . . . 18
6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17 6.6. Processing Queries in Parallel . . . . . . . . . . . . . 19
6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17 6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 19
6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18 6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 19
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
7.1. Performance Measurements . . . . . . . . . . . . . . . . 19 7.1. Performance Measurements . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 21 9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 22
9.2. Privacy Issues With Session Resumption . . . . . . . . . 21 9.2. Privacy Issues With Session Resumption . . . . . . . . . 23
9.3. Privacy Issues With Address Validation Tokens . . . . . . 22 9.3. Privacy Issues With Address Validation Tokens . . . . . . 24
9.4. Privacy Issues With Long Duration Sessions . . . . . . . 23 9.4. Privacy Issues With Long Duration Sessions . . . . . . . 24
9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23 9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Registration of DoQ Identification String . . . . . . . 23 10.1. Registration of DoQ Identification String . . . . . . . 25
10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 24 10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 25
10.3. Reservation of Extended DNS Error Code Too Early . . . . 25 10.3. Reservation of Extended DNS Error Code Too Early . . . . 26
10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 25 10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 31 Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 33
Appendix B. Notable Changes From Previous Versions . . . . . . . 32 Appendix B. Notable Changes From Previous Versions . . . . . . . 33
B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 32 B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Domain Name System (DNS) concepts are specified in "Domain names - Domain Name System (DNS) concepts are specified in "Domain names -
concepts and facilities" [RFC1034]. The transmission of DNS queries concepts and facilities" [RFC1034]. The transmission of DNS queries
and responses over UDP and TCP is specified in "Domain names - and responses over UDP and TCP is specified in "Domain names -
implementation and specification" [RFC1035]. implementation and specification" [RFC1035].
This document presents a mapping of the DNS protocol over the QUIC This document presents a mapping of the DNS protocol over the QUIC
transport [RFC9000] [RFC9001]. DNS over QUIC is referred here as transport [RFC9000] [RFC9001]. DNS over QUIC is referred to here as
DoQ, in line with "DNS Terminology" [I-D.ietf-dnsop-rfc8499bis]. DoQ, in line with "DNS Terminology" [I-D.ietf-dnsop-rfc8499bis].
The goals of the DoQ mapping are: The goals of the DoQ mapping are:
1. Provide the same DNS privacy protection as DNS over TLS (DoT) 1. Provide the same DNS privacy protection as DNS over TLS (DoT)
[RFC7858]. This includes an option for the client to [RFC7858]. This includes an option for the client to
authenticate the server by means of an authentication domain name authenticate the server by means of an authentication domain name
as specified in "Usage Profiles for DNS over TLS and DNS over as specified in "Usage Profiles for DNS over TLS and DNS over
DTLS" [RFC8310]. DTLS" [RFC8310].
2. Provide an improved level of source address validation for DNS 2. Provide an improved level of source address validation for DNS
servers compared to classic DNS over UDP. servers compared to classic DNS over UDP.
3. Provide a transport that is not constrained by path MTU 3. Provide a transport that does not impose path MTU limitations on
limitations on the size of DNS responses it can send. the size of DNS responses it can send.
In order to achieve these goals, and to support ongoing work on In order to achieve these goals, and to support ongoing work on
encryption of DNS, the scope of this document includes encryption of DNS, the scope of this document includes
* the "stub to recursive resolver" scenario * the "stub to recursive resolver" scenario
* the "recursive resolver to authoritative nameserver" scenario and * the "recursive resolver to authoritative nameserver" scenario and
* the "nameserver to nameserver" scenario (mainly used for zone * the "nameserver to nameserver" scenario (mainly used for zone
transfers (XFR) [RFC1995], [RFC5936]). transfers (XFR) [RFC1995], [RFC5936]).
skipping to change at page 5, line 8 skipping to change at page 5, line 8
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Document work via GitHub 3. Document work via GitHub
(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The
Github repository for this document is at https://github.com/huitema/ GitHub repository for this document is at https://github.com/huitema/
dnsoquic. Proposed text and editorial changes are very much welcomed dnsoquic. Proposed text and editorial changes are very much welcomed
there, but any functional changes should always first be discussed on there, but any functional changes should always first be discussed on
the IETF DPRIVE WG (dns-privacy) mailing list. the IETF DPRIVE WG (dns-privacy) mailing list.
4. Design Considerations 4. Design Considerations
This section and its subsections present the design guidelines that This section and its subsections present the design guidelines that
were used for DoQ. Whilst all other sections in this document are were used for DoQ. Whilst all other sections in this document are
normative, this section is informative in nature. normative, this section is informative in nature.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
for in order delivery of responses previously posted by the for in order delivery of responses previously posted by the
server. server.
These considerations are reflected in the mapping of DNS traffic to These considerations are reflected in the mapping of DNS traffic to
QUIC streams in Section 5.2. QUIC streams in Section 5.2.
4.3. Middlebox Considerations 4.3. Middlebox Considerations
Using QUIC might allow a protocol to disguise its purpose from Using QUIC might allow a protocol to disguise its purpose from
devices on the network path using encryption and traffic analysis devices on the network path using encryption and traffic analysis
resistance techniques like padding. This specification does not resistance techniques like padding, traffic pacing, and traffic
include any measures that are designed to avoid such classification. shaping. This specification does not include any measures that are
Consequently, firewalls and other middleboxes might be able to designed to avoid such classification -- the padding mechanisms
distinguish DoQ from other protocols that use QUIC, like HTTP, and defined in Section 6.4 are intended to obfuscate the specific records
apply different treatment. contained in DNS queries and responses, but not the fact that this is
DNS traffic. Consequently, firewalls and other middleboxes might be
able to distinguish DoQ from other protocols that use QUIC, like
HTTP, and apply different treatment.
The lack of measures in this specification to avoid protocol The lack of measures in this specification to avoid protocol
classification is not an endorsement of such practices. classification is not an endorsement of such practices.
4.4. No Server-Initiated Transactions 4.4. No Server-Initiated Transactions
As stated in Section 1, this document does not specify support for As stated in Section 1, this document does not specify support for
server-initiated transactions within established DoQ connections. server-initiated transactions within established DoQ connections.
That is, only the initiator of the DoQ connection may send queries That is, only the initiator of the DoQ connection may send queries
over the connection. over the connection.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
DSO does support server-initiated transactions within existing DSO does support server-initiated transactions within existing
connections. However, DoQ as defined here does not meet the criteria connections. However, DoQ as defined here does not meet the criteria
for an applicable transport for DSO because it does not guarantee in- for an applicable transport for DSO because it does not guarantee in-
order delivery of messages, see Section 4.2 of [RFC8490]. order delivery of messages, see Section 4.2 of [RFC8490].
5. Specifications 5. Specifications
5.1. Connection Establishment 5.1. Connection Establishment
DoQ connections are established as described in the QUIC transport DoQ connections are established as described in the QUIC transport
specification [RFC9000]. During connection establishment, DoQ specification [RFC9000]. During connection establishment, DoQ
support is indicated by selecting the ALPN token "doq" in the crypto support is indicated by selecting the Application-Layer Protocol
handshake. Negotiation (ALPN) token "doq" in the crypto handshake.
5.1.1. Draft Version Identification 5.1.1. Draft Version Identification
(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only (RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only
implementations of the final, published RFC can identify themselves implementations of the final, published RFC can identify themselves
as "doq". Until such an RFC exists, implementations MUST NOT as "doq". Until such an RFC exists, implementations MUST NOT
identify themselves using this string. identify themselves using this string.
Implementations of draft versions of the protocol MUST add the string Implementations of draft versions of the protocol MUST add the string
"-" and the corresponding draft number to the identifier. For "-" and the corresponding draft number to the identifier. For
skipping to change at page 7, line 36 skipping to change at page 7, line 36
QUIC connections on the dedicated UDP port TBD (number to be defined QUIC connections on the dedicated UDP port TBD (number to be defined
in Section 10), unless there is a mutual agreement to use another in Section 10), unless there is a mutual agreement to use another
port. port.
By default, a DNS client desiring to use DoQ with a particular server By default, a DNS client desiring to use DoQ with a particular server
MUST establish a QUIC connection to UDP port TBD on the server, MUST establish a QUIC connection to UDP port TBD on the server,
unless there is a mutual agreement to use another port. unless there is a mutual agreement to use another port.
DoQ connections MUST NOT use UDP port 53. This recommendation DoQ connections MUST NOT use UDP port 53. This recommendation
against use of port 53 for DoQ is to avoid confusion between DoQ and against use of port 53 for DoQ is to avoid confusion between DoQ and
the use of DNS over UDP [RFC1035]. the use of DNS over UDP [RFC1035]. The risk of confusion exists even
if two parties agreed on port 53, as other parties without knowledge
of that agreement might still try to use that port.
In the stub to recursive scenario, the use of port 443 as a mutually In the stub to recursive scenario, the use of port 443 as a mutually
agreed alternative port can be operationally beneficial, since port agreed alternative port can be operationally beneficial, since port
443 is less likely to be blocked than other ports. Several 443 is used by many services using QUIC and HTTP-3 and thus less
mechanisms for stubs to discover recursives offering encrypted likely to be blocked than other ports. Several mechanisms for stubs
transports, including the use of custom ports, are the subject of to discover recursives offering encrypted transports, including the
ongoing work. use of custom ports, are the subject of ongoing work.
5.2. Stream Mapping and Usage 5.2. Stream Mapping and Usage
The mapping of DNS traffic over QUIC streams takes advantage of the The mapping of DNS traffic over QUIC streams takes advantage of the
QUIC stream features detailed in Section 2 of [RFC9000], the QUIC QUIC stream features detailed in Section 2 of [RFC9000], the QUIC
transport specification. transport specification.
DNS traffic follows a simple pattern in which the client sends a DNS query/response traffic [RFC1034], [RFC1035] follows a simple
query, and the server provides one or more responses (multiple pattern in which the client sends a query, and the server provides
responses can occur in zone transfers). one or more responses (multiple responses can occur in zone
transfers).
The mapping specified here requires that the client selects a The mapping specified here requires that the client selects a
separate QUIC stream for each query. The server then uses the same separate QUIC stream for each query. The server then uses the same
stream to provide all the response messages for that query. In order stream to provide all the response messages for that query. In order
that multiple responses can be parsed, a 2-octet length field is used that multiple responses can be parsed, a 2-octet length field is used
in exactly the same way as the 2-octet length field defined for DNS in exactly the same way as the 2-octet length field defined for DNS
over TCP [RFC1035]. The practical result of this is that the content over TCP [RFC1035]. The practical result of this is that the content
of each QUIC stream is exactly the same as the content of a TCP of each QUIC stream is exactly the same as the content of a TCP
connection that would manage exactly one query. connection that would manage exactly one query.
All DNS messages (queries and responses) sent over DoQ connections All DNS messages (queries and responses) sent over DoQ connections
MUST be encoded as a 2-octet length field followed by the message MUST be encoded as a 2-octet length field followed by the message
content as specified in [RFC1035]. content as specified in [RFC1035].
The client MUST select the next available client-initiated The client MUST select the next available client-initiated
bidirectional stream for each subsequent query on a QUIC connection, bidirectional stream for each subsequent query on a QUIC connection,
in conformance with the QUIC transport specification [RFC9000]. in conformance with the QUIC transport specification [RFC9000].
Packet losses and other network events might cause queries to arrive
in a different order. Servers SHOULD process queries as they arrive,
as not doing so would cause unnecessary delays.
The client MUST send the DNS query over the selected stream, and MUST The client MUST send the DNS query over the selected stream, and MUST
indicate through the STREAM FIN mechanism that no further data will indicate through the STREAM FIN mechanism that no further data will
be sent on that stream. be sent on that stream.
The server MUST send the response(s) on the same stream and MUST The server MUST send the response(s) on the same stream and MUST
indicate, after the last response, through the STREAM FIN mechanism indicate, after the last response, through the STREAM FIN mechanism
that no further data will be sent on that stream. that no further data will be sent on that stream.
Therefore, a single DNS transaction consumes a single bidirectional Therefore, a single DNS transaction consumes a single bidirectional
client-initiated stream. This means that the client's first query client-initiated stream. This means that the client's first query
occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1 occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1
of [RFC9000]. of [RFC9000].
Servers MAY defer processing of a query until the STREAM FIN has been Servers MAY defer processing of a query until the STREAM FIN has been
indicated on the stream selected by the client. Servers and clients indicated on the stream selected by the client.
MAY monitor the number of "dangling" streams for which the expected
queries or responses have been received but not the STREAM FIN. Servers and clients MAY monitor the number of "dangling" streams.
These are open streams where the following events have not occurred
after implementation defined timeouts:
* the expected queries or responses have not been received or,
* the expected queries or responses have been received but not the
STREAM FIN
Implementations MAY impose a limit on the number of such dangling Implementations MAY impose a limit on the number of such dangling
streams. If limits are encountered, implementations MAY close the streams. If limits are encountered, implementations MAY close the
connection. connection.
5.2.1. DNS Message IDs 5.2.1. DNS Message IDs
When sending queries over a QUIC connection, the DNS Message ID MUST When sending queries over a QUIC connection, the DNS Message ID MUST
be set to zero. The stream mapping for DoQ allows for unambiguous be set to zero. The stream mapping for DoQ allows for unambiguous
correlation of queries and responses and so the Message ID field is correlation of queries and responses and so the Message ID field is
not required. not required.
skipping to change at page 9, line 20 skipping to change at page 9, line 33
ID of 0 is recommended. ID of 0 is recommended.
When forwarding a DNS message from DoQ over another transport, a DNS When forwarding a DNS message from DoQ over another transport, a DNS
Message ID MUST be generated according to the rules of the protocol Message ID MUST be generated according to the rules of the protocol
that is in use. When forwarding a DNS message from another transport that is in use. When forwarding a DNS message from another transport
over DoQ, the Message ID MUST be set to zero. over DoQ, the Message ID MUST be set to zero.
5.3. DoQ Error Codes 5.3. DoQ Error Codes
The following error codes are defined for use when abruptly The following error codes are defined for use when abruptly
terminating streams, aborting reading of streams, or immediately terminating streams, and used as application protocol error codes
closing connections: when aborting reading of streams, or immediately closing connections:
DOQ_NO_ERROR (0x0): No error. This is used when the connection or DOQ_NO_ERROR (0x0): No error. This is used when the connection or
stream needs to be closed, but there is no error to signal. stream needs to be closed, but there is no error to signal.
DOQ_INTERNAL_ERROR (0x1): The DoQ implementation encountered an DOQ_INTERNAL_ERROR (0x1): The DoQ implementation encountered an
internal error and is incapable of pursuing the transaction or the internal error and is incapable of pursuing the transaction or the
connection. connection.
DOQ_PROTOCOL_ERROR (0x2): The DoQ implementation encountered an DOQ_PROTOCOL_ERROR (0x2): The DoQ implementation encountered a
protocol error and is forcibly aborting the connection. protocol error and is forcibly aborting the connection.
DOQ_REQUEST_CANCELLED (0x3): A DoQ client uses this to signal that DOQ_REQUEST_CANCELLED (0x3): A DoQ client uses this to signal that
it wants to cancel an outstanding transaction. it wants to cancel an outstanding transaction.
DOQ_EXCESSIVE_LOAD (0x4): A DoQ implementation uses this to signal DOQ_EXCESSIVE_LOAD (0x4): A DoQ implementation uses this to signal
when closing a connection due to excessive load. when closing a connection due to excessive load.
DOQ_UNSPECIFIED_ERROR (0x5): A DoQ implementation uses this in the
absence of a more specific error code.
DOQ_ERROR_RESERVED (0xd098ea5e): Alternative error code used for DOQ_ERROR_RESERVED (0xd098ea5e): Alternative error code used for
tests. tests.
See Section 10.4 for details on registering new error codes. See Section 10.4 for details on registering new error codes.
5.3.1. Transaction Cancellation 5.3.1. Transaction Cancellation
In QUIC, sending STOP_SENDING requests that a peer cease transmission In QUIC, sending STOP_SENDING requests that a peer cease transmission
on a stream. If a DoQ client wishes to cancel an outstanding on a stream. If a DoQ client wishes to cancel an outstanding
request, it MUST issue a QUIC STOP_SENDING with error code request, it MUST issue a QUIC STOP_SENDING, and it SHOULD use the
DOQ_REQUEST_CANCELLED. This may be sent at any time but will be error code DOQ_REQUEST_CANCELLED. It MAY use a more specific error
ignored if the server response has already been acknowledged. The code registered according to Section 10.4. The STOP_SENDING request
corresponding DNS transaction MUST be abandoned. may be sent at any time but will have no effect if the server
response has already been sent, in which case the client will simply
discard the incoming response. The corresponding DNS transaction
MUST be abandoned.
Servers that receive STOP_SENDING act in accordance with Section 3.5 Servers that receive STOP_SENDING act in accordance with Section 3.5
of [RFC9000]. Servers MAY impose implementation limits on the total of [RFC9000]. Servers SHOULD NOT continue processing a DNS
number or rate of request cancellations. If limits are encountered, transaction if they receive a STOP_SENDING.
servers MAY close the connection. In this case, servers wanting to
help client debugging MAY use the error code DOQ_EXCESSIVE_LOAD. Servers MAY impose implementation limits on the total number or rate
There is always a trade-off between helping good faith clients debug of request cancellations. If limits are encountered, servers MAY
issues and allowing denial-of-service attackers to test server close the connection. In this case, servers wanting to help client
defenses, so depending on circumstances servers might very well chose debugging MAY use the error code DOQ_EXCESSIVE_LOAD. There is always
to send different error codes. a trade-off between helping good faith clients debug issues and
allowing denial-of-service attackers to test server defenses, so
depending on circumstances servers might very well choose to send
different error codes.
Note that this mechanism provides a way for secondaries to cancel a Note that this mechanism provides a way for secondaries to cancel a
single zone transfer occurring on a given stream without having to single zone transfer occurring on a given stream without having to
close the QUIC connection. close the QUIC connection.
Servers MUST NOT continue processing a DNS transaction if they
receive a RESET_STREAM request from the client before the client
indicates the STREAM FIN. The server MUST issue a RESET_STREAM to
indicate that the transaction is abandoned unless
* it has already done so for another reason or
* it has already both sent the response and indicated the STREAM
FIN.
5.3.2. Transaction Errors 5.3.2. Transaction Errors
Servers normally complete transactions by sending a DNS response (or Servers normally complete transactions by sending a DNS response (or
responses) on the transaction's stream, including cases where the DNS responses) on the transaction's stream, including cases where the DNS
response indicates a DNS error. For example, a Server Failure response indicates a DNS error. For example, a Server Failure
(SERVFAIL, [RFC1035]) SHOULD be notified to the client by sending (SERVFAIL, [RFC1035]) SHOULD be notified to the client by sending
back a response with the Response Code set to SERVFAIL. back a response with the Response Code set to SERVFAIL.
If a server is incapable of sending a DNS response due to an internal If a server is incapable of sending a DNS response due to an internal
error, it SHOULD issue a QUIC Stream Reset. The error code SHOULD be error, it SHOULD issue a QUIC RESET_STREAM frame. The error code
set to DOQ_INTERNAL_ERROR. The corresponding DNS transaction MUST be SHOULD be set to DOQ_INTERNAL_ERROR. The corresponding DNS
abandoned. Clients MAY limit the number of unsolicited QUIC Stream transaction MUST be abandoned. Clients MAY limit the number of
Resets received on a connection before choosing to close the unsolicited QUIC Stream Resets received on a connection before
connection. choosing to close the connection.
Note that this mechanism provides a way for primaries to abort a Note that this mechanism provides a way for primaries to abort a
single zone transfer occurring on a given stream without having to single zone transfer occurring on a given stream without having to
close the QUIC connection. close the QUIC connection.
5.3.3. Protocol Errors 5.3.3. Protocol Errors
Other error scenarios can occur due to malformed, incomplete or Other error scenarios can occur due to malformed, incomplete or
unexpected messages during a transaction. These include (but are not unexpected messages during a transaction. These include (but are not
limited to) limited to)
skipping to change at page 11, line 4 skipping to change at page 11, line 39
* a client or server receives a message with a non-zero Message ID * a client or server receives a message with a non-zero Message ID
* a client or server receives a STREAM FIN before receiving all the * a client or server receives a STREAM FIN before receiving all the
bytes for a message indicated in the 2-octet length field bytes for a message indicated in the 2-octet length field
* a client receives a STREAM FIN before receiving all the expected * a client receives a STREAM FIN before receiving all the expected
responses responses
* a server receives more than one query on a stream * a server receives more than one query on a stream
* a client receives a different number of responses on a stream than * a client receives a different number of responses on a stream than
expected (e.g. multiple responses to a query for an A record) expected (e.g., multiple responses to a query for an A record)
* a client receives a STOP_SENDING request * a client receives a STOP_SENDING request
* the client or server does not indicate the expected STREAM FIN * the client or server does not indicate the expected STREAM FIN
after sending requests or responses (see Section 5.2). after sending requests or responses (see Section 5.2).
* an implementation receives a message containing the edns-tcp- * an implementation receives a message containing the edns-tcp-
keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2) keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2)
* a client or a server attempts to open a unidirectional QUIC stream * a client or a server attempts to open a unidirectional QUIC stream
skipping to change at page 11, line 16 skipping to change at page 12, line 4
* a client receives a STOP_SENDING request * a client receives a STOP_SENDING request
* the client or server does not indicate the expected STREAM FIN * the client or server does not indicate the expected STREAM FIN
after sending requests or responses (see Section 5.2). after sending requests or responses (see Section 5.2).
* an implementation receives a message containing the edns-tcp- * an implementation receives a message containing the edns-tcp-
keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2) keepalive EDNS(0) Option [RFC7828] (see Section 6.5.2)
* a client or a server attempts to open a unidirectional QUIC stream * a client or a server attempts to open a unidirectional QUIC stream
* a server attempts to open a server-initiated bidirectional QUIC * a server attempts to open a server-initiated bidirectional QUIC
stream stream
* receiving a "replayable" transaction in O-RTT data (for servers
not willing to handle this case - see section Section 5.5)
If a peer encounters such an error condition it is considered a fatal If a peer encounters such an error condition it is considered a fatal
error. It SHOULD forcibly abort the connection using QUIC's error. It SHOULD forcibly abort the connection using QUIC's
CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code
DOQ_PROTOCOL_ERROR. DOQ_PROTOCOL_ERROR. In some cases, it MAY instead silently abandon
the connection, which uses fewer of the local resources but makes
debugging at the offending node more difficult.
It is noted that the restrictions on use of the above EDNS(0) options 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. has implications for proxying message from TCP/DoT/DoH over DoQ.
5.3.4. Alternative error codes 5.3.4. Alternative error codes
This specification suggests specific error codes in Section 5.3.1, This specification suggests specific error codes in Section 5.3.1,
Section 5.3.2, and Section 5.3.3. These error codes are meant to Section 5.3.2, and Section 5.3.3. These error codes are meant to
facilitate investigation of failures and other incidents. New error facilitate investigation of failures and other incidents. New error
codes may be defined in future versions of DoQ, or registered as codes may be defined in future versions of DoQ, or registered as
specified in Section 10.4. specified in Section 10.4.
Because new error codes can be defined without negotiation, use of an Because new error codes can be defined without negotiation, use of an
error code in an unexpected context or receipt of an unknown error error code in an unexpected context or receipt of an unknown error
code MUST be treated as equivalent to DOQ_NO_ERROR. code MUST be treated as equivalent to DOQ_UNSPECIFIED_ERROR.
Implementations MAY wish to test the support for the error code Implementations MAY wish to test the support for the error code
extension mechanism by using error codes not listed in this document, extension mechanism by using error codes not listed in this document,
or they MAY use DOQ_ERROR_RESERVED. or they MAY use DOQ_ERROR_RESERVED.
5.4. Connection Management 5.4. Connection Management
Section 10 of [RFC9000], the QUIC transport specification, specifies Section 10 of [RFC9000], the QUIC transport specification, specifies
that connections can be closed in three ways: that connections can be closed in three ways:
* idle timeout * idle timeout
* immediate close * immediate close
* stateless reset
* stateless reset
Clients and servers implementing DoQ SHOULD negotiate use of the idle Clients and servers implementing DoQ SHOULD negotiate use of the idle
timeout. Closing on idle timeout is done without any packet timeout. Closing on idle timeout is done without any packet
exchange, which minimizes protocol overhead. Per Section 10.1 of exchange, which minimizes protocol overhead. Per Section 10.1 of
[RFC9000], the QUIC transport specification, the effective value of [RFC9000], the QUIC transport specification, the effective value of
the idle timeout is computed as the minimum of the values advertised the idle timeout is computed as the minimum of the values advertised
by the two endpoints. Practical considerations on setting the idle by the two endpoints. Practical considerations on setting the idle
timeout are discussed in Section 6.5.2. timeout are discussed in Section 6.5.2.
Clients SHOULD monitor the idle time incurred on their connection to Clients SHOULD monitor the idle time incurred on their connection to
the server, defined by the time spent since the last packet from the 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 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 query to the server, it SHOULD check whether the idle time is
sufficiently lower than the idle timer. If it is, the client will sufficiently lower than the idle timer. If it is, the client SHOULD
send the DNS query over the existing connection. If not, the client send the DNS query over the existing connection. If not, the client
will establish a new connection and send the query over that SHOULD establish a new connection and send the query over that
connection. connection.
Clients MAY discard their connections to the server before the idle Clients MAY discard their connections to the server before the idle
timeout expires. A client that has outstanding queries SHOULD close timeout expires. A client that has outstanding queries SHOULD close
the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and
the DoQ error code DOQ_NO_ERROR. the DoQ error code DOQ_NO_ERROR.
Clients and servers MAY close the connection for a variety of other Clients and servers MAY close the connection for a variety of other
reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers
that send packets over a connection discarded by their peer MAY that send packets over a connection discarded by their peer might
receive a stateless reset indication. If a connection fails, all the receive a stateless reset indication. If a connection fails, all the
in progress transaction on that connection MUST be abandoned. in progress transaction on that connection MUST be abandoned.
5.5. Session Resumption and 0-RTT 5.5. Session Resumption and 0-RTT
A client MAY take advantage of the session resumption mechanisms A client MAY take advantage of the session resumption and 0-RTT
supported by QUIC transport [RFC9000] and QUIC TLS [RFC9001]. mechanisms supported by QUIC transport [RFC9000] and QUIC TLS
Clients SHOULD consider potential privacy issues associated with [RFC9001], if the server supports them. Clients SHOULD consider
session resumption before deciding to use this mechanism. These potential privacy issues associated with session resumption before
privacy issues are detailed in Section 9.1 and Section 9.2, and the deciding to use this mechanism and specifically evaluate the trade-
offs presented in the various sections of this document. The privacy
issues are detailed in Section 9.1 and Section 9.2, and the
implementation considerations are discussed in Section 6.5.3. implementation considerations are discussed in Section 6.5.3.
The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are The 0-RTT mechanism MUST NOT be used to send DNS requests that are
not "replayable" transactions. In this specification, only not "replayable" transactions. In this specification, only
transactions that have an OPCODE of QUERY or NOTIFY are considered 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 replayable and therefore other OPCODES MUST NOT be sent in 0-RTT
detailed discussion of why NOTIFY is included here. data. See Appendix A for a detailed discussion of why NOTIFY is
included here.
Servers MUST NOT execute non replayable transactions received in Servers MAY support session resumption, and MAY do that with or
0-RTT data. Servers MUST adopt one of the following behaviors: without supporting 0-RTT, using the mechanisms described in
Section 4.6.1 of [RFC9001]. Servers supporting 0-RTT MUST NOT
immediately process non-replayable transactions received in 0-RTT
data, but instead MUST adopt one of the following behaviours:
* Queue the offending transaction and only execute it after the QUIC * Queue the offending transaction and only process it after the QUIC
handshake has been completed, as defined in Section 4.1.1 of handshake has been completed, as defined in Section 4.1.1 of
[RFC9001]. [RFC9001].
* Reply to the offending transaction with a response code REFUSED * Reply to the offending transaction with a response code REFUSED
and an Extended DNS Error Code (EDE) "Too Early", see and an Extended DNS Error Code (EDE) "Too Early", using the
Section 10.3. extended RCODE mechanisms defined in [RFC6891] and the extended
DNS errros defined in [RFC8914]; see Section 10.3.
* Close the connection with the error code DOQ_PROTOCOL_ERROR. * Close the connection with the error code DOQ_PROTOCOL_ERROR.
5.6. Message Sizes 5.6. Message Sizes
DoQ Queries and Responses are sent on QUIC streams, which in theory DoQ Queries and Responses are sent on QUIC streams, which in theory
can carry up to 2^62 bytes. However, DNS messages are restricted in can carry up to 2^62 bytes. However, DNS messages are restricted in
practice to a maximum size of 65535 bytes. This maximum size is practice to a maximum size of 65535 bytes. This maximum size is
enforced by the use of a two-octet message length field in DNS over enforced by the use of a two-octet message length field in DNS over
TCP [RFC1035] and DNS over TLS [RFC7858], and by the definition of TCP [RFC1035] and DNS over TLS [RFC7858], and by the definition of
skipping to change at page 13, line 43 skipping to change at page 14, line 50
For the stub to recursive resolver scenario, the authentication For the stub to recursive resolver scenario, the authentication
requirements are the same as described in DoT [RFC7858] and "Usage requirements are the same as described in DoT [RFC7858] and "Usage
Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932] Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. [RFC8932]
states that DNS privacy services SHOULD provide credentials that states that DNS privacy services SHOULD provide credentials that
clients can use to authenticate the server. Given this, and to align clients can use to authenticate the server. Given this, and to align
with the authentication model for DoH, DoQ stubs SHOULD use a Strict with the authentication model for DoH, DoQ stubs SHOULD use a Strict
authentication profile. Client authentication for the encrypted stub authentication profile. Client authentication for the encrypted stub
to recursive scenario is not described in any DNS RFC. to recursive scenario is not described in any DNS RFC.
For zone transfer, the requirements are the same as described in For zone transfer, the authentication requirements are the same as
[RFC9103]. described in [RFC9103].
For the recursive resolver to authoritative nameserver scenario, For the recursive resolver to authoritative nameserver scenario,
authentication requirements are unspecified at the time of writing authentication requirements are unspecified at the time of writing
and are the subject on ongoing work in the DPRIVE WG. and are the subject on ongoing work in the DPRIVE WG.
6.2. Fallback to Other Protocols on Connection Failure 6.2. Fallback to Other Protocols on Connection Failure
If the establishment of the DoQ connection fails, clients MAY attempt If the establishment of the DoQ connection fails, clients MAY attempt
to fall back to DoT and then potentially clear text, as specified in to fall back to DoT and then potentially clear text, as specified in
DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS" DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS"
[RFC8310], depending on their privacy profile. [RFC8310], depending on their privacy profile.
DNS clients SHOULD remember server IP addresses that don't support DNS clients SHOULD remember server IP addresses that don't support
DoQ. Timeouts, connection refusals, and QUIC handshake failures are DoQ. Mobile clients might also remember the lack of DoQ support by
valid indicators that a server does not support DoQ. Clients SHOULD given IP addresses on a per-context basis (e.g.per network or
NOT attempt DoQ queries to a server that does not support DoQ for a provisioning domain).
Timeouts, connection refusals, and QUIC handshake failures are
indicators that a server does not support DoQ. Clients SHOULD NOT
attempt DoQ queries to a server that does not support DoQ for a
reasonable period (such as one hour per server). DNS clients reasonable period (such as one hour per server). DNS clients
following an out-of-band key-pinned privacy profile ([RFC7858]) MAY following an out-of-band key-pinned privacy profile ([RFC7858]) MAY
be more aggressive about retrying DoQ connection failures. be more aggressive about retrying after DoQ connection failures.
6.3. Address Validation 6.3. Address Validation
Section 8 of [RFC9000], the QUIC transport specification, defines Section 8 of [RFC9000], the QUIC transport specification, defines
Address Validation procedures to avoid servers being used in address Address Validation procedures to avoid servers being used in address
amplification attacks. DoQ implementations MUST conform to this amplification attacks. DoQ implementations MUST conform to this
specification, which limits the worst case amplification to a factor specification, which limits the worst case amplification to a factor
3. 3.
DoQ implementations SHOULD consider configuring servers to use the DoQ implementations SHOULD consider configuring servers to use the
skipping to change at page 14, line 49 skipping to change at page 16, line 11
frames to clients after the client address is validated, in order to frames to clients after the client address is validated, in order to
avoid the 1-RTT penalty during subsequent connections by the client avoid the 1-RTT penalty during subsequent connections by the client
from the same address. from the same address.
6.4. Padding 6.4. Padding
Implementations MUST protect against the traffic analysis attacks Implementations MUST protect against the traffic analysis attacks
described in Section 9.5 by the judicious injection of padding. This described in Section 9.5 by the judicious injection of padding. This
could be done either by padding individual DNS messages using the could be done either by padding individual DNS messages using the
EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see
Section 8.6 of [RFC9000], the QUIC transport specification. Section 19.1 of [RFC9000].
In theory, padding at the QUIC level could result in better In theory, padding at the QUIC packet level could result in better
performance for the equivalent protection, because the amount of performance for the equivalent protection, because the amount of
padding can take into account non-DNS frames such as acknowledgements padding can take into account non-DNS frames such as acknowledgements
or flow control updates, and also because QUIC packets can carry or flow control updates, and also because QUIC packets can carry
multiple DNS messages. However, applications can only control the multiple DNS messages. However, applications can only control the
amount of padding in QUIC packets if the implementation of QUIC amount of padding in QUIC packets if the implementation of QUIC
exposes adequate APIs. This leads to the following recommendation: exposes adequate APIs. This leads to the following recommendation:
* if the implementation of QUIC exposes APIs to set a padding * if the implementation of QUIC exposes APIs to set a padding
policy, DNS over QUIC SHOULD use that API to align the packet policy, DNS over QUIC SHOULD use that API to align the packet
length to a small set of fixed sizes. length to a small set of fixed sizes.
* if padding at the QUIC level is not available or not used, DNS * if padding at the QUIC packet level is not available or not used,
over QUIC MUST ensure that all DNS queries and responses are DNS over QUIC MUST ensure that all DNS queries and responses are
padded to a small set of fixed sizes, using the EDNS(0) padding padded to a small set of fixed sizes, using the EDNS(0) padding
extension as specified in [RFC7830]. extension as specified in [RFC7830].
Implementation might choose not to use a QUIC API for padding if it Implementation might choose not to use a QUIC API for padding if it
is significantly simpler to re-use existing DNS message padding logic is significantly simpler to re-use existing DNS message padding logic
which is applied to other encrypted transports. which is applied to other encrypted transports.
In the absence of a standard policy for padding sizes, In the absence of a standard policy for padding sizes,
implementations SHOULD follow the recommendations of the Experimental implementations SHOULD follow the recommendations of the Experimental
status "Padding Policies for Extension Mechanisms for DNS (EDNS(0))" status "Padding Policies for Extension Mechanisms for DNS (EDNS(0))"
skipping to change at page 16, line 46 skipping to change at page 18, line 16
Using 0-RTT for DNS over QUIC has many compelling advantages. Using 0-RTT for DNS over QUIC has many compelling advantages.
Clients can establish connections and send queries without incurring Clients can establish connections and send queries without incurring
a connection delay. Servers can thus negotiate low values of the a connection delay. Servers can thus negotiate low values of the
connection timers, which reduces the total number of connections that connection timers, which reduces the total number of connections that
they need to manage. They can do that because the clients that use they need to manage. They can do that because the clients that use
0-RTT will not incur latency penalties if new connections are 0-RTT will not incur latency penalties if new connections are
required for a query. required for a query.
Session resumption and 0-RTT data transmission create privacy risks Session resumption and 0-RTT data transmission create privacy risks
detailed in detailed in Section 9.2 and Section 9.1. The following detailed in Section 9.2 and Section 9.1. The following
recommendations are meant to reduce the privacy risks while enjoying recommendations are meant to reduce the privacy risks while enjoying
the performance benefits of 0-RTT data, with the restriction the performance benefits of 0-RTT data, subject to the restrictions
specified in Section 5.5. specified in Section 5.5.
Clients SHOULD use resumption tickets only once, as specified in Clients SHOULD use resumption tickets only once, as specified in
Appendix C.4 to [RFC8446]. By default, clients SHOULD NOT use Appendix C.4 to [RFC8446]. By default, clients SHOULD NOT use
session resumption if the client's connectivity has changed. session resumption if the client's connectivity has changed.
Clients could receive address validation tokens from the server using Clients could receive address validation tokens from the server using
the NEW_TOKEN mechanism; see Section 8 of [RFC9000]. The associated the NEW_TOKEN mechanism; see Section 8 of [RFC9000]. The associated
tracking risks are mentioned in Section 9.3. Clients SHOULD only use tracking risks are mentioned in Section 9.3. Clients SHOULD only use
the address validation tokens when they are also using session the address validation tokens when they are also using session
resumption, thus avoiding additional tracking risks. resumption, thus avoiding additional tracking risks.
Servers SHOULD issue session resumption tickets with a sufficiently Servers SHOULD issue session resumption tickets with a sufficiently
long life time (e.g., 6 hours), so that clients are not tempted to long lifetime (e.g., 6 hours), so that clients are not tempted to
either keep connection alive or frequently poll the server to renew either keep connection alive or frequently poll the server to renew
session resumption tickets. Servers SHOULD implement the anti-replay session resumption tickets. Servers SHOULD implement the anti-replay
mechanisms specified in Section 8 of [RFC8446]. mechanisms specified in Section 8 of [RFC8446].
6.5.4. Controlling Connection Migration For Privacy 6.5.4. Controlling Connection Migration For Privacy
DoQ implementation might consider using the connection migration DoQ implementations might consider using the connection migration
features defined in Section 9 of [RFC9000]. These features enable features defined in Section 9 of [RFC9000]. These features enable
connections to continue operating as the client's connectivity connections to continue operating as the client's connectivity
changes. As detailed in Section 9.4, these features trade off changes. As detailed in Section 9.4, these features trade off
privacy for latency. By default, clients SHOULD be configured to privacy for latency. By default, clients SHOULD be configured to
prioritize privacy and start new sessions if their connectivity prioritize privacy and start new sessions if their connectivity
changes. changes.
6.6. Processing Queries in Parallel 6.6. Processing Queries in Parallel
As specified in Section 7 of [RFC7766] "DNS Transport over TCP - As specified in Section 7 of [RFC7766] "DNS Transport over TCP -
skipping to change at page 17, line 45 skipping to change at page 19, line 19
the preparing of responses in parallel and sending them out of order. the preparing of responses in parallel and sending them out of order.
In DoQ, they do that by sending responses on their specific stream as In DoQ, they do that by sending responses on their specific stream as
soon as possible, without waiting for availability of responses for soon as possible, without waiting for availability of responses for
previously opened streams. previously opened streams.
6.7. Zone transfer 6.7. Zone transfer
[RFC9103] specifies zone transfer over TLS (XoT) and includes updates [RFC9103] specifies zone transfer over TLS (XoT) and includes updates
to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766]. Considerations to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766]. Considerations
relating to the re-use of XoT connections described there apply relating to the re-use of XoT connections described there apply
analogously to zone transfers performed using DoQ connections. For analogously to zone transfers performed using DoQ connections. One
example: reason for re-iterating such specific guidance is the lack of
effective connection re-use in existing TCP/TLS zone transfer
implementations today. The following recommendations apply:
* DoQ servers MUST be able to handle multiple concurrent IXFR * DoQ servers MUST be able to handle multiple concurrent IXFR
requests on a single QUIC connection requests on a single QUIC connection
* DoQ servers MUST be able to handle multiple concurrent AXFR * DoQ servers MUST be able to handle multiple concurrent AXFR
requests on a single QUIC connection requests on a single QUIC connection
* DoQ implementations SHOULD * DoQ implementations SHOULD
- use the same QUIC connection for both AXFR and IXFR requests to - use the same QUIC connection for both AXFR and IXFR requests to
the same primary the same primary
- pipeline such requests (if they pipeline XFR requests in - send those requests in parallel as soon as they are queued i.e.
general) and MAY intermingle them do not wait for a response before sending the next query on the
connection (this is analogous to pipelining requests on a TCP/
TLS connection)
- send the response(s) for each request as soon as they are - send the response(s) for each request as soon as they are
available i.e. responses MAY be sent intermingled available i.e. response streams MAY be sent intermingled
6.8. Flow Control Mechanisms 6.8. Flow Control Mechanisms
Servers and Clients manage flow control using the mechanisms defined Servers and Clients manage flow control using the mechanisms defined
in Section 4 of [RFC9000]. These mechanisms allow clients and in Section 4 of [RFC9000]. These mechanisms allow clients and
servers to specify how many streams can be created, how much data can servers to specify how many streams can be created, how much data can
be sent on a stream, and how much data can be sent on the union of be sent on a stream, and how much data can be sent on the union of
all streams. For DNS over QUIC, controlling how many streams are all streams. For DNS over QUIC, controlling how many streams are
created allows servers to control how many new requests the client created allows servers to control how many new requests the client
can send on a given connection. can send on a given connection.
skipping to change at page 20, line 13 skipping to change at page 21, line 39
less per message overhead when compared to DoH). less per message overhead when compared to DoH).
* Performs better in mobile environments due to the increased * Performs better in mobile environments due to the increased
resilience to packet loss resilience to packet loss
* Can maintain connections as users move between mobile networks via * Can maintain connections as users move between mobile networks via
its connection management its connection management
8. Security Considerations 8. Security Considerations
A general Threat Analysis of the Domain Name System is found in A Threat Analysis of the Domain Name System is found in [RFC3833].
[RFC3833]. This analysis was written before the development of DoT, This analysis was written before the development of DoT, DoH and DoQ,
DoH and DoQ, and probably needs to be updated. and probably needs to be updated.
The security considerations of DoQ should be comparable to those of The security considerations of DoQ should be comparable to those of
DoT [RFC7858]. DoT as specified in [RFC7858] only addresses the stub DoT [RFC7858]. DoT as specified in [RFC7858] only addresses the stub
to recursive resolver scenario, but the considerations about person- to recursive resolver scenario, but the considerations about person-
in-the-middle attacks, middleboxes and caching of data from clear in-the-middle attacks, middleboxes and caching of data from clear
text connections also apply for DoQ to the resolver to authoritative text connections also apply for DoQ to the resolver to authoritative
server scenario. As stated in Section 6.1 the authentication server scenario. As stated in Section 6.1 the authentication
requirements for securing zone transfer using DoQ are the same as requirements for securing zone transfer using DoQ are the same as
those for zone transfer over DoT, therefore the general security those for zone transfer over DoT, therefore the general security
considerations are entirely analogous to those described in considerations are entirely analogous to those described in
skipping to change at page 21, line 32 skipping to change at page 23, line 8
clock skew and network transmission. clock skew and network transmission.
The recommendation for TLS 1.3 [RFC8446] is that the capability to The recommendation for TLS 1.3 [RFC8446] is that the capability to
use 0-RTT data should be turned off by default, and only enabled if use 0-RTT data should be turned off by default, and only enabled if
the user clearly understands the associated risks. In the case of the user clearly understands the associated risks. In the case of
DoQ, allowing 0-RTT data provides significant performance gains, and DoQ, allowing 0-RTT data provides significant performance gains, and
there is a concern that a recommendation to not use it would simply there is a concern that a recommendation to not use it would simply
be ignored. Instead, a set of practical recommendations is provided be ignored. Instead, a set of practical recommendations is provided
in Section 5.5 and Section 6.5.3. in Section 5.5 and Section 6.5.3.
The prevention on allowing replayable transactions in 0-RTT data The specifications in Section 5.5 block the most obvious risks of
expressed in Section 5.5 blocks the most obvious risks of replay replay attacks, as they only allows for transactions that will not
attacks, as it only allows for transactions that will not change the change the long-term state of the server.
long-term state of the server.
The attacks described above apply to the stub resolver to recursive The attacks described above apply to the stub resolver to recursive
resolver scenario, but similar attacks might be envisaged in the resolver scenario, but similar attacks might be envisaged in the
recursive resolver to authoritative resolver scenario, and the same recursive resolver to authoritative resolver scenario, and the same
mitigations apply. mitigations apply.
9.2. Privacy Issues With Session Resumption 9.2. Privacy Issues With Session Resumption
The QUIC session resumption mechanism reduces the cost of re- The QUIC session resumption mechanism reduces the cost of re-
establishing sessions and enables 0-RTT data. There is a linkability establishing sessions and enables 0-RTT data. There is a linkability
skipping to change at page 22, line 16 skipping to change at page 23, line 37
resumed sessions with the initial sessions, and thus to track the resumed sessions with the initial sessions, and thus to track the
client. This creates a virtual long duration session. The series of client. This creates a virtual long duration session. The series of
queries in that session can be used by the server to identify the queries in that session can be used by the server to identify the
client. Servers can most probably do that already if the client client. Servers can most probably do that already if the client
address remains constant, but session resumption tickets also enable address remains constant, but session resumption tickets also enable
tracking after changes of the client's address. tracking after changes of the client's address.
The recommendations in Section 6.5.3 are designed to mitigate these The recommendations in Section 6.5.3 are designed to mitigate these
risks. Using session tickets only once mitigates the risk of risks. Using session tickets only once mitigates the risk of
tracking by third parties. Refusing to resume a session if addresses tracking by third parties. Refusing to resume a session if addresses
change mitigates the risk of tracking by the server. change mitigates the incremental risk of tracking by the server (but
the risk of tracking by IP address remains).
The privacy trade-offs here may be context specific. Stub resolvers The privacy trade-offs here may be context specific. Stub resolvers
will have a strong motivation to prefer privacy over latency since will have a strong motivation to prefer privacy over latency since
they often change location. However, recursive resolvers that use a they often change location. However, recursive resolvers that use a
small set of static IP addresses are more likely to prefer the small set of static IP addresses are more likely to prefer the
reduced latency provided by session resumption and may consider this reduced latency provided by session resumption and may consider this
a valid reason to use resumption tickets even if the IP address a valid reason to use resumption tickets even if the IP address
changed between sessions. changed between sessions.
Encrypted zone transfer (RFC9103) explicitly does not attempt to hide Encrypted zone transfer (RFC9103) explicitly does not attempt to hide
skipping to change at page 22, line 47 skipping to change at page 24, line 26
are typically tied to an IP address. QUIC clients normally only use are typically tied to an IP address. QUIC clients normally only use
these tokens when setting up a new connection from a previously used these tokens when setting up a new connection from a previously used
address. However, clients are not always aware that they are using a address. However, clients are not always aware that they are using a
new address. This could be due to NAT, or because the client does new address. This could be due to NAT, or because the client does
not have an API available to check if the IP address has changed not have an API available to check if the IP address has changed
(which can be quite often for IPv6). There is a linkability risk if (which can be quite often for IPv6). There is a linkability risk if
clients mistakenly use address validation tokens after unknowingly clients mistakenly use address validation tokens after unknowingly
moving to a new location. moving to a new location.
The recommendations in Section 6.5.3 mitigates this risk by tying the The recommendations in Section 6.5.3 mitigates this risk by tying the
usage of the NEW_TOKEN to that of session resumption. usage of the NEW_TOKEN to that of session resumption, though this
recommendation does not cover the case where the client is unaware of
the address change.
9.4. Privacy Issues With Long Duration Sessions 9.4. Privacy Issues With Long Duration Sessions
A potential alternative to session resumption is the use of long A potential alternative to session resumption is the use of long
duration sessions: if a session remains open for a long time, new duration sessions: if a session remains open for a long time, new
queries can be sent without incurring connection establishment queries can be sent without incurring connection establishment
delays. It is worth pointing out that the two solutions have similar delays. It is worth pointing out that the two solutions have similar
privacy characteristics. Session resumption may allow servers to privacy characteristics. Session resumption may allow servers to
keep track of the IP addresses of clients, but long duration sessions keep track of the IP addresses of clients, but long duration sessions
have the same effect. have the same effect.
skipping to change at page 23, line 32 skipping to change at page 25, line 11
The recommendation in Section 6.5.4 mitigates the privacy concerns The recommendation in Section 6.5.4 mitigates the privacy concerns
related to long duration sessions using multiple client addresses. related to long duration sessions using multiple client addresses.
9.5. Traffic Analysis 9.5. Traffic Analysis
Even though QUIC packets are encrypted, adversaries can gain Even though QUIC packets are encrypted, adversaries can gain
information from observing packet lengths, in both queries and information from observing packet lengths, in both queries and
responses, as well as packet timing. Many DNS requests are emitted responses, as well as packet timing. Many DNS requests are emitted
by web browsers. Loading a specific web page may require resolving by web browsers. Loading a specific web page may require resolving
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
query or response per packet, or "one QUIC STREAM frame per packet", one query or response per packet, or "one QUIC STREAM frame per
then the succession of packet lengths may provide enough information packet", then the succession of packet lengths may provide enough
to identify the requested site. information to identify the requested site.
Implementations SHOULD use the mechanisms defined in Section 6.4 to Implementations SHOULD use the mechanisms defined in Section 6.4 to
mitigate this attack. mitigate this attack.
10. IANA Considerations 10. IANA Considerations
10.1. Registration of DoQ Identification String 10.1. Registration of DoQ Identification String
This document creates a new registration for the identification of This document creates a new registration for the identification of
DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol
skipping to change at page 24, line 4 skipping to change at page 25, line 32
This document creates a new registration for the identification of This document creates a new registration for the identification of
DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol
IDs" registry [RFC7301]. IDs" registry [RFC7301].
The "doq" string identifies DoQ: The "doq" string identifies DoQ:
Protocol: DoQ Protocol: DoQ
Identification Sequence: 0x64 0x6F 0x71 ("doq") Identification Sequence: 0x64 0x6F 0x71 ("doq")
Specification: This document Specification: This document
10.2. Reservation of Dedicated Port 10.2. Reservation of Dedicated Port
For both TCP and UDP port 853 is currently reserved for 'DNS query- For both TCP and UDP port 853 is currently reserved for 'DNS query-
response protocol run over TLS/DTLS' [RFC7858]. response protocol run over TLS/DTLS' [RFC7858].
However, the specification for DNS over DTLS (DoD) [RFC8094] is However, the specification for DNS over DTLS (DoD) [RFC8094] is
experimental, limited to stub to resolver, and no implementations or experimental, limited to stub to resolver, and no implementations or
deployments currently exist to the authors' knowledge (even though deployments currently exist to the authors' knowledge (even though
several years have passed since the specification was published). several years have passed since the specification was published).
This specification proposes to additionally reserve the use of UDP This specification proposes to additionally reserve the use of UDP
port 853 for DoQ. QUIC version 1 was designed to be able to co-exist port 853 for DoQ. QUIC version 1 was designed to be able to co-exist
with other protocols on the same port, including DTLS , see with other protocols on the same port, including DTLS , see
Section 17.2 of [RFC9000]. This means that deployments that serve Section 17.2 of [RFC9000]. This means that deployments that serve
DNS over DTLS and DNS over QUIC (QUIC version 1) on the same port DNS over DTLS and DNS over QUIC (QUIC version 1) on the same port
will be able to demultiplex the two due to the second most will be able to demultiplex the two due to the second most
significant bit in each UDP payload. Such deployments ought to check significant bit in each UDP payload. Such deployments ought to check
the signatures of future versions or extensions (e.g. the signatures of future versions or extensions (e.g.,
[I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to [I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to
serve DNS on the same port. serve DNS on the same port.
IANA is requested to update the following value in the "Service Name IANA is requested to update the following value in the "Service Name
and Transport Protocol Port Number Registry" in the System Range. and Transport Protocol Port Number Registry" in the System Range.
The registry for that range requires IETF Review or IESG Approval The registry for that range requires IETF Review or IESG Approval
[RFC6335]. [RFC6335].
Service Name: domain-s Service Name: domain-s
skipping to change at page 26, line 7 skipping to change at page 27, line 40
aligned with the principles set in Section 22 of [RFC9000].) aligned with the principles set in Section 22 of [RFC9000].)
Registrations in this registry MUST include the following fields: Registrations in this registry MUST include the following fields:
Value: The assigned codepoint. Value: The assigned codepoint.
Status: "Permanent" or "Provisional". Status: "Permanent" or "Provisional".
Contact: Contact details for the registrant. Contact: Contact details for the registrant.
Notes: Supplementary notes about the registration.
In addition, permanent registrations MUST include: In addition, permanent registrations MUST include:
Error: A short mnemonic for the parameter. Error: A short mnemonic for the parameter.
Specification: A reference to a publicly available specification for Specification: A reference to a publicly available specification for
the value (optional for provisional registrations). the value (optional for provisional registrations).
Description: A brief description of the error code semantics, which Description: A brief description of the error code semantics, which
MAY be a summary if a specification reference is provided. MAY be a summary if a specification reference is provided.
skipping to change at page 26, line 30 skipping to change at page 28, line 16
private use and experimentation with extensions to DNS over QUIC. private use and experimentation with extensions to DNS over QUIC.
However, provisional registrations could be reclaimed and reassigned However, provisional registrations could be reclaimed and reassigned
for another purpose. In addition to the parameters listed above, for another purpose. In addition to the parameters listed above,
provisional registrations MUST include: provisional registrations MUST include:
Date: The date of last update to the registration. Date: The date of last update to the registration.
A request to update the date on any provisional registration can be A request to update the date on any provisional registration can be
made without review from the designated expert(s). made without review from the designated expert(s).
The initial contents of this registry are shown in Table 1. The initial contents of this registry are shown in Table 1 and all
entries share the following fields:
+==========+=======================+================+===============+ Status: Permanent
|Value | Error |Description | Specification |
+==========+=======================+================+===============+
|0x0 | DOQ_NO_ERROR |No error | Section 5.3 |
+----------+-----------------------+----------------+---------------+
|0x1 | DOQ_INTERNAL_ERROR |Implementation | Section 5.3 |
| | |error | |
+----------+-----------------------+----------------+---------------+
|0x2 | DOQ_PROTOCOL_ERROR |Generic protocol| Section 5.3 |
| | |violation | |
+----------+-----------------------+----------------+---------------+
|0x3 | DOQ_REQUEST_CANCELLED |Request | Section 5.3 |
| | |cancelled by | |
| | |client | |
+----------+-----------------------+----------------+---------------+
|0x4 | DOQ_EXCESSIVE_LOAD |Closing a | Section 5.3 |
| | |connection for | |
| | |excessive load | |
+----------+-----------------------+----------------+---------------+
|0xd098ea5e| DOQ_ERROR_RESERVED |Alternative | Section 5.3 |
| | |error code used | |
| | |for tests | |
+----------+-----------------------+----------------+---------------+
Table 1: Initial DNS over QUIC Error Codes Entries Contact: DPRIVE WG
Specification: Section 5.3
+============+=======================+=============================+
| Value | Error | Description |
+============+=======================+=============================+
| 0x0 | DOQ_NO_ERROR | No error |
+------------+-----------------------+-----------------------------+
| 0x1 | DOQ_INTERNAL_ERROR | Implementation error |
+------------+-----------------------+-----------------------------+
| 0x2 | DOQ_PROTOCOL_ERROR | Generic protocol violation |
+------------+-----------------------+-----------------------------+
| 0x3 | DOQ_REQUEST_CANCELLED | Request cancelled by client |
+------------+-----------------------+-----------------------------+
| 0x4 | DOQ_EXCESSIVE_LOAD | Closing a connection for |
| | | excessive load |
+------------+-----------------------+-----------------------------+
| 0x5 | DOQ_UNSPECIFIED_ERROR | No error reason specified |
+------------+-----------------------+-----------------------------+
| 0xd098ea5e | DOQ_ERROR_RESERVED | Alternative error code used |
| | | for tests |
+------------+-----------------------+-----------------------------+
Table 1: Initial DNS over QUIC Error Codes Entries
11. Acknowledgements 11. Acknowledgements
This document liberally borrows text from the HTTP-3 specification This document liberally borrows text from the HTTP-3 specification
[I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT [I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT
specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann,
Allison Mankin, Duane Wessels, and Paul Hoffman. Allison Mankin, Duane Wessels, and Paul Hoffman.
The privacy issue with 0-RTT data and session resumption were The privacy issue with 0-RTT data and session resumption were
analyzed by Daniel Kahn Gillmor (DKG) in a message to the IETF analyzed by Daniel Kahn Gillmor (DKG) in a message to the IETF
skipping to change at page 28, line 9 skipping to change at page 29, line 25
Thanks also to Martin Thomson and Martin Duke for their later reviews Thanks also to Martin Thomson and Martin Duke for their later reviews
focussing on the low level QUIC details which helped clarify several focussing on the low level QUIC details which helped clarify several
aspects of DoQ. Thanks to Andrey Meshkov, Loganaden Velvindron, aspects of DoQ. Thanks to Andrey Meshkov, Loganaden Velvindron,
Lucas Pardue, Matt Joras, Mirja Kuelewind, Brian Trammell and Phillip Lucas Pardue, Matt Joras, Mirja Kuelewind, Brian Trammell and Phillip
Hallam-Baker for their reviews and contributions. Hallam-Baker for their reviews and contributions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dnsop-rfc8499bis]
Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,
28 September 2021, <https://www.ietf.org/archive/id/draft-
ietf-dnsop-rfc8499bis-03.txt>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, DOI 10.17487/RFC1995, August 1996,
skipping to change at page 29, line 5 skipping to change at page 30, line 15
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016,
<https://www.rfc-editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, DOI 10.17487/RFC7830, May 2016,
<https://www.rfc-editor.org/info/rfc7830>. <https://www.rfc-editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
October 2018, <https://www.rfc-editor.org/info/rfc8467>. October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914, Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020, DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>. <https://www.rfc-editor.org/info/rfc8914>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
skipping to change at page 30, line 30 skipping to change at page 31, line 35
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, March 2021. 1.1", BCP 195, RFC 8996, March 2021.
<https://www.rfc-editor.org/info/bcp195> <https://www.rfc-editor.org/info/bcp195>
[DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG
mailing list, 6 April 2016, <https://www.ietf.org/mail- mailing list, 6 April 2016, <https://www.ietf.org/mail-
archive/web/dns-privacy/current/msg01276.html>. archive/web/dns-privacy/current/msg01276.html>.
[I-D.ietf-dnsop-rfc8499bis]
Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in
Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,
28 September 2021, <https://www.ietf.org/archive/id/draft-
ietf-dnsop-rfc8499bis-03.txt>.
[I-D.ietf-quic-bit-grease] [I-D.ietf-quic-bit-grease]
Thomson, M., "Greasing the QUIC Bit", Work in Progress, Thomson, M., "Greasing the QUIC Bit", Work in Progress,
Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November
2021, <https://www.ietf.org/archive/id/draft-ietf-quic- 2021, <https://www.ietf.org/archive/id/draft-ietf-quic-
bit-grease-02.txt>. bit-grease-02.txt>.
[I-D.ietf-quic-http] [I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
skipping to change at page 31, line 12 skipping to change at page 32, line 20
Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
2004, <https://www.rfc-editor.org/info/rfc3833>. 2004, <https://www.rfc-editor.org/info/rfc3833>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016,
<https://www.rfc-editor.org/info/rfc7828>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019, RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>. <https://www.rfc-editor.org/info/rfc8490>.
[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
 End of changes. 73 change blocks. 
200 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/