< draft-ietf-dprive-dnsoquic-06.txt   draft-ietf-dprive-dnsoquic-07.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: 23 April 2022 Sinodun IT Expires: 4 June 2022 Sinodun IT
A. Mankin A. Mankin
Salesforce Salesforce
20 October 2021 1 December 2021
DNS over Dedicated QUIC Connections DNS over Dedicated QUIC Connections
draft-ietf-dprive-dnsoquic-06 draft-ietf-dprive-dnsoquic-07
Abstract Abstract
This document describes the use of QUIC to provide transport privacy This document describes the use of QUIC to provide transport privacy
for DNS. The encryption provided by QUIC has similar properties to for DNS. The encryption provided by QUIC has similar properties to
that provided by TLS, while QUIC transport eliminates the head-of- that provided by TLS, while QUIC transport eliminates the head-of-
line blocking issues inherent with TCP and provides more efficient line blocking issues inherent with TCP and provides more efficient
packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy packet loss recovery than UDP. DNS over QUIC (DoQ) has privacy
properties similar to DNS over TLS (DoT) specified in RFC7858, and properties similar to DNS over TLS (DoT) specified in RFC7858, and
latency characteristics similar to classic DNS over UDP. latency characteristics similar to classic DNS over UDP.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 23 April 2022. This Internet-Draft will expire on 4 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Document work via GitHub . . . . . . . . . . . . . . . . . . 4 3. Document work via GitHub . . . . . . . . . . . . . . . . . . 5
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 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. No Specific Middlebox Bypass Mechanism . . . . . . . . . 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 . . . . . . . . . . . . . . . . 6 5.1. Connection Establishment . . . . . . . . . . . . . . . . 6
5.1.1. Draft Version Identification . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 8
5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 8 5.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9 5.3.1. Transaction Cancellation . . . . . . . . . . . . . . 9
5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 9 5.3.2. Transaction Errors . . . . . . . . . . . . . . . . . 10
5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10 5.3.3. Protocol Errors . . . . . . . . . . . . . . . . . . . 10
5.3.4. Alternative error codes . . . . . . . . . . . . . . . 11 5.3.4. Alternative error codes . . . . . . . . . . . . . . . 11
5.4. Connection Management . . . . . . . . . . . . . . . . . . 11 5.4. Connection Management . . . . . . . . . . . . . . . . . . 11
5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 12 5.5. Session Resumption and 0-RTT . . . . . . . . . . . . . . 12
5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 12 5.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 13
6. Implementation Requirements . . . . . . . . . . . . . . . . . 13 6. Implementation Requirements . . . . . . . . . . . . . . . . . 13
6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 13 6.1. Authentication . . . . . . . . . . . . . . . . . . . . . 13
6.2. Fallback to Other Protocols on Connection Failure . . . . 13 6.2. Fallback to Other Protocols on Connection Failure . . . . 14
6.3. Address Validation . . . . . . . . . . . . . . . . . . . 13 6.3. Address Validation . . . . . . . . . . . . . . . . . . . 14
6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 15 6.5. Connection Handling . . . . . . . . . . . . . . . . . . . 15
6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 15 6.5.1. Connection Reuse . . . . . . . . . . . . . . . . . . 15
6.5.2. Resource Management . . . . . . . . . . . . . . . . . 15 6.5.2. Resource Management . . . . . . . . . . . . . . . . . 15
6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16 6.5.3. Using 0-RTT and Session Resumption . . . . . . . . . 16
6.5.4. Controlling Connection Migration For Privacy . . . . 16 6.5.4. Controlling Connection Migration For Privacy . . . . 17
6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17 6.6. Processing Queries in Parallel . . . . . . . . . . . . . 17
6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17 6.7. Zone transfer . . . . . . . . . . . . . . . . . . . . . . 17
6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 17 6.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
7.1. Performance Measurements . . . . . . . . . . . . . . . . 19 7.1. Performance Measurements . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 20 9.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 20
9.2. Privacy Issues With Session Resumption . . . . . . . . . 20 9.2. Privacy Issues With Session Resumption . . . . . . . . . 21
9.3. Privacy Issues With Address Validation Tokens . . . . . . 21 9.3. Privacy Issues With Address Validation Tokens . . . . . . 22
9.4. Privacy Issues With Long Duration Sessions . . . . . . . 22 9.4. Privacy Issues With Long Duration Sessions . . . . . . . 22
9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 22 9.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.1. Registration of DoQ Identification String . . . . . . . 22 10.1. Registration of DoQ Identification String . . . . . . . 23
10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 23 10.2. Reservation of Dedicated Port . . . . . . . . . . . . . 23
10.2.1. Port number 784 for experimentations . . . . . . . . 23 10.2.1. Port number 784 for experimentations . . . . . . . . 24
10.3. Reservation of Extended DNS Error Code Too Early . . . . 23 10.3. Reservation of Extended DNS Error Code Too Early . . . . 24
10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 24 10.4. DNS over QUIC Error Codes Registry . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 29 Appendix A. The NOTIFY Service . . . . . . . . . . . . . . . . . 30
Appendix B. Notable Changes From Previous Versions . . . . . . . 30 Appendix B. Notable Changes From Previous Versions . . . . . . . 30
B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 30 B.1. Stream Mapping Incompatibility With Draft-02 . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 here as
skipping to change at page 4, line 27 skipping to change at page 4, line 27
2. No attempt to support server initiated transactions, which are 2. No attempt to support server initiated transactions, which are
used only in DNS Stateful Operations (DSO) [RFC8490]. used only in DNS Stateful Operations (DSO) [RFC8490].
Specifying the transmission of an application over QUIC requires Specifying the transmission of an application over QUIC requires
specifying how the application's messages are mapped to QUIC streams, specifying how the application's messages are mapped to QUIC streams,
and generally how the application will use QUIC. This is done for and generally how the application will use QUIC. This is done for
HTTP in "Hypertext Transfer Protocol Version 3 HTTP in "Hypertext Transfer Protocol Version 3
(HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to (HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to
define the way DNS messages can be transmitted over QUIC. define the way DNS messages can be transmitted over QUIC.
DNS over HTTP [RFC8484] can be used with HTTP/3 to get some of the
benefits of QUIC. However, a lightweight direct mapping for DNS over
QUIC can be regarded as a more natural fit for both the recursive to
authoritative and zone transfer scenarios which rarely involve
intermediaries. In these scenarios, the additional overhead of HTTP
is not offset by, e.g., benefits of HTTP proxying and caching
behavior.
In this document, Section 4 presents the reasoning that guided the In this document, Section 4 presents the reasoning that guided the
proposed design. Section 5 specifies the actual mapping of DoQ. proposed design. Section 5 specifies the actual mapping of DoQ.
Section 6 presents guidelines on the implementation, usage and Section 6 presents guidelines on the implementation, usage and
deployment of DoQ. deployment of DoQ.
2. Key Words 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC8174]. document are to be interpreted as described in BCP 14 [RFC8174].
skipping to change at page 6, line 8 skipping to change at page 6, line 19
3. Mapping of each DNS Query/Response transaction to a separate 3. Mapping of each DNS Query/Response transaction to a separate
stream, to mitigate head-of-line blocking. This enables servers stream, to mitigate head-of-line blocking. This enables servers
to respond to queries "out of order". It also enables clients to to respond to queries "out of order". It also enables clients to
process responses as soon as they arrive, without having to wait process responses as soon as they arrive, without having to wait
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. No Specific Middlebox Bypass Mechanism 4.3. Middlebox Considerations
The mapping of DoQ is defined for minimal overhead and maximum Using QUIC might allow a protocol to disguise its purpose from
performance. This means a different traffic profile than HTTP3 over devices on the network path using encryption and traffic analysis
QUIC. This difference can be noted by firewalls and middleboxes. resistance techniques like padding. This specification does not
There may be environments in which HTTP3 over QUIC will be able to include any measures that are designed to avoid such classification.
pass through, but DoQ will be blocked by these middle boxes. 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
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.
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
skipping to change at page 8, line 32 skipping to change at page 8, line 45
indicated on the stream selected by the client. Servers and clients indicated on the stream selected by the client. Servers and clients
MAY monitor the number of "dangling" streams for which the expected MAY monitor the number of "dangling" streams for which the expected
queries or responses have been received but not the STREAM FIN. 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. be set to zero. The stream mapping for DoQ allows for unambiguous
correlation of queries and responses and so the Message ID field is
not required.
This has implications for proxying DoQ message to and from other This has implications for proxying DoQ message to and from other
transports. For example, proxies may have to manage the fact that transports. For example, proxies may have to manage the fact that
DoQ can support a larger number of outstanding queries on a single DoQ can support a larger number of outstanding queries on a single
connection than e.g., DNS over TCP because DoQ is not limited by the connection than e.g., DNS over TCP because DoQ is not limited by the
Message ID space. Message ID space. This issue already exists for DoH, where a Message
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, aborting reading of streams, or immediately
skipping to change at page 11, line 12 skipping to change at page 11, line 33
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.
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 Section 5.3.1, This specification suggests specific error codes 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
facilitates 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_NO_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.
skipping to change at page 28, line 5 skipping to change at page 28, line 37
[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>.
[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>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[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
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
skipping to change at page 29, line 14 skipping to change at page 29, line 43
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<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
A. Mankin, "Recommendations for DNS Privacy Service A. Mankin, "Recommendations for DNS Privacy Service
Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
October 2020, <https://www.rfc-editor.org/info/rfc8932>. October 2020, <https://www.rfc-editor.org/info/rfc8932>.
 End of changes. 29 change blocks. 
45 lines changed or deleted 61 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/