< draft-ietf-add-svcb-dns-02.txt   draft-ietf-add-svcb-dns-03.txt >
add B. Schwartz add B. Schwartz
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 1 February 2022 Intended status: Standards Track 22 April 2022
Expires: 5 August 2022 Expires: 24 October 2022
Service Binding Mapping for DNS Servers Service Binding Mapping for DNS Servers
draft-ietf-add-svcb-dns-02 draft-ietf-add-svcb-dns-03
Abstract Abstract
The SVCB DNS record type expresses a bound collection of endpoint The SVCB DNS record type expresses a bound collection of endpoint
metadata, for use when establishing a connection to a named service. metadata, for use when establishing a connection to a named service.
DNS itself can be such a service, when the server is identified by a DNS itself can be such a service, when the server is identified by a
domain name. This document provides the SVCB mapping for named DNS domain name. This document provides the SVCB mapping for named DNS
servers, allowing them to indicate support for new transport servers, allowing them to indicate support for new transport
protocols. protocols.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 5 August 2022. This Internet-Draft will expire on 24 October 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 39 skipping to change at page 2, line 39
5. New SvcParamKeys . . . . . . . . . . . . . . . . . . . . . . 5 5. New SvcParamKeys . . . . . . . . . . . . . . . . . . . . . . 5
5.1. dohpath . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. dohpath . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.1. Adversary on the query path . . . . . . . . . . . . . . . 7 8.1. Adversary on the query path . . . . . . . . . . . . . . . 7
8.1.1. Downgrade attacks . . . . . . . . . . . . . . . . . . 7 8.1.1. Downgrade attacks . . . . . . . . . . . . . . . . . . 7
8.1.2. Redirection attacks . . . . . . . . . . . . . . . . . 7 8.1.2. Redirection attacks . . . . . . . . . . . . . . . . . 7
8.2. Adversary on the transport path . . . . . . . . . . . . . 8 8.2. Adversary on the transport path . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Mapping Summary . . . . . . . . . . . . . . . . . . 10 Appendix A. Mapping Summary . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The SVCB record type [SVCB] provides clients with information about The SVCB record type [SVCB] provides clients with information about
how to reach alternative endpoints for a service, which may have how to reach alternative endpoints for a service, which may have
improved performance or privacy properties. The service is improved performance or privacy properties. The service is
identified by a "scheme" indicating the service type, a hostname, and identified by a "scheme" indicating the service type, a hostname, and
optionally other information such as a port number. A DNS server is optionally other information such as a port number. A DNS server is
often identified only by its IP address (e.g. in DHCP), but in some often identified only by its IP address (e.g. in DHCP), but in some
contexts it can also be identified by a hostname (e.g. "NS" records, contexts it can also be identified by a hostname (e.g. "NS" records,
manual resolver configuration) and sometimes also a non-default port manual resolver configuration) and sometimes also a non-default port
number. number.
Use of the SVCB record type requires a mapping document for each Use of the SVCB record type requires a mapping document for each
service type, indicating how a client for that service can interpret service type, indicating how a client for that service can interpret
the contents of the SVCB SvcParams. This document provides the the contents of the SVCB SvcParams. This document provides the
mapping for the "dns" service type, allowing DNS servers to offer mapping for the "dns" service type, allowing DNS servers to offer
alternative endpoints and transports, including encrypted transports alternative endpoints and transports, including encrypted transports
like DNS over TLS and DNS over HTTPS. like DNS over TLS (DoT) and DNS over HTTPS (DoH).
2. Conventions and Definitions 2. Conventions and Definitions
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. Identities and Names 3. Identities and Names
SVCB record names (i.e. QNAMEs) are formed using Port-Prefix Naming SVCB record names (i.e. QNAMEs) for DNS services are formed using
(Section 2.3 of [SVCB]), with a scheme of "dns". For example, SVCB Port-Prefix Naming (Section 2.3 of [SVCB]), with a scheme of "dns".
records for a DNS service identified as "dns1.example.com" would be For example, SVCB records for a DNS service identified as
queried at "_dns.dns1.example.com". "dns1.example.com" would be queried at "_dns.dns1.example.com".
In some use cases, the name used for retrieving these DNS records is In some use cases, the name used for retrieving these DNS records is
different from the server identity used to authenticate the secure different from the server identity used to authenticate the secure
transport. To distinguish them, we use the following terms: transport. To distinguish between these, this document uses the
following terms:
* Binding authority - The service name (Section 1.4 of [SVCB]) and * Binding authority - The service name (Section 1.4 of [SVCB]) and
optional port number used as input to Port-Prefix Naming. optional port number used as input to Port-Prefix Naming.
* Authentication name - The name used for secure transport * Authentication name - The name used for secure transport
authentication. It must be a DNS hostname or a literal IP authentication. This MUST be a DNS hostname or a literal IP
address. Unless otherwise specified, it is the service name from address. Unless otherwise specified, this is the service name
the binding authority. from the binding authority.
3.1. Special case: non-default ports 3.1. Special case: non-default ports
Normally, a DNS service is identified by an IP address or a domain Normally, a DNS service is identified by an IP address or a domain
name. When connecting to the service using unencrypted DNS over UDP name. When connecting to the service using unencrypted DNS over UDP
or TCP, clients use the default port number for DNS (53). However, or TCP, clients use the default port number for DNS (53). However,
in rare cases, a DNS service might be identified by both a name and a in rare cases, a DNS service might be identified by both a name and a
port number. For example, the dns: URI scheme [DNSURI] optionally port number. For example, the dns: URI scheme [DNSURI] optionally
includes an authority, comprised of a host and a port number (with a includes an authority, comprised of a host and a port number (with a
default of 53). DNS URIs normally omit the authority, or specify an default of 53). DNS URIs normally omit the authority, or specify an
skipping to change at page 5, line 4 skipping to change at page 5, line 4
4.2. port 4.2. port
This key is used to indicate the target port for connection This key is used to indicate the target port for connection
(Section 6.2 of [SVCB]). If omitted, the client SHALL use the (Section 6.2 of [SVCB]). If omitted, the client SHALL use the
default port for each transport protocol (853 for DNS over TLS [DOT], default port for each transport protocol (853 for DNS over TLS [DOT],
443 for DNS over HTTPS). 443 for DNS over HTTPS).
This key is automatically mandatory if present. (See Section 7 of This key is automatically mandatory if present. (See Section 7 of
[SVCB] for the definition of "automatically mandatory".) [SVCB] for the definition of "automatically mandatory".)
Support for the port key can be unsafe if the client has implicit
elevated access to some network service (e.g. a local service that is
inaccessible to remote parties) and that service uses a TCP-based
protocol other than TLS. A hostile DNS server might be able to
manipulate this service by causing the client to send a specially
crafted TLS SNI or session ticket that can be misparsed as a command
or exploit. To avoid such attacks, clients SHOULD NOT support the
port key unless one of the following conditions applies:
* The client is being used with a DNS server that it trusts not
attempt this attack.
* The client is being used in a context where implicit elevated
access cannot apply.
* The client restricts the set of allowed TCP port values to exclude
any ports where a confusion attack is likely to be possible (e.g.
the "bad ports" list from the "Port blocking" section of [FETCH]).
4.3. Other applicable SvcParamKeys 4.3. Other applicable SvcParamKeys
These SvcParamKeys from [SVCB] apply to the "dns" scheme without These SvcParamKeys from [SVCB] apply to the "dns" scheme without
modification: modification:
* mandatory
* ech * ech
* ipv4hint * ipv4hint
* ipv6hint * ipv6hint
Future SvcParamKeys may also be applicable. Future SvcParamKeys may also be applicable.
5. New SvcParamKeys 5. New SvcParamKeys
5.1. dohpath 5.1. dohpath
"dohpath" is a single-valued SvcParamKey whose value (both in "dohpath" is a single-valued SvcParamKey whose value (both in
presentation and wire format) MUST be a URI Template [RFC6570] presentation and wire format) MUST be a URI Template [RFC6570]
encoded in UTF-8 [RFC3629]. If the "alpn" SvcParamKey indicates encoded in UTF-8 [RFC3629]. If the "alpn" SvcParam indicates support
support for HTTP, "dohpath" MUST be present, and clients MAY for HTTP, "dohpath" MUST be present. The URI Template MUST contain a
construct a DNS over HTTPS URI Template as follows: "dns" variable, and MUST be chosen such that the result after DoH
template expansion (Section 6 of [RFC8484]) is always a valid and
1. Let $HOST be the authentication name encoded as a "host" value functional ":path" value ([RFC7540], Section 8.1.2.3).
(Section 3.2.2 of [RFC3986]).
2. Let $PORT be the port from the "port" key if present, otherwise
443. (The binding authority's port number MUST NOT be used.)
3. Let $DOHPATH be the "dohpath" value, decoded from UTF-8.
4. The DNS over HTTPS URI Template is "https://$HOST:$PORT$DOHPATH".
The "dohpath" value MUST be chosen such that the resulting URI When using this SVCB record, the client MUST send any DoH requests to
Template is valid for use with DNS over HTTPS. For example, DNS over the HTTP origin identified by the "https" scheme, the authentication
HTTPS servers are required to support requests using GET and POST name, and the port from the "port" SvcParam (if present). HTTP
methods. The GET method relies on the "dns" URI Template parameter, requests MUST be directed to the resource resulting from DoH template
and the POST method does not use it. Therefore, the URI Template is expansion of the "dohpath" value.
required to make use of a "dns" variable, and result in a valid URI
whether or not "dns" is defined.
Clients SHOULD NOT query for any "HTTPS" RRs when using the Clients SHOULD NOT query for any "HTTPS" RRs when using "dohpath".
constructed URI Template. Instead, the SvcParams and address records Instead, the SvcParams and address records associated with this SVCB
associated with this SVCB record SHOULD be used for the HTTPS record SHOULD be used for the HTTPS connection, with the same
connection, with the same semantics as an HTTPS RR. However, for semantics as an HTTPS RR. However, for consistency, service
consistency, service operators SHOULD publish an equivalent HTTPS RR, operators SHOULD publish an equivalent HTTPS RR, especially if
especially if clients might learn this URI Template through a clients might learn about this DoH service through a different
different channel. channel.
6. Limitations 6. Limitations
This document is concerned exclusively with the DNS transport, and This document is concerned exclusively with the DNS transport, and
does not affect or inform the construction or interpretation of DNS does not affect or inform the construction or interpretation of DNS
messages. For example, nothing in this document indicates whether messages. For example, nothing in this document indicates whether
the service is intended for use as a recursive or authoritative DNS the service is intended for use as a recursive or authoritative DNS
server. Clients must know the intended use in their context. server. Clients need to know the intended use of services based on
their context.
7. Examples 7. Examples
* A resolver at "simple.example" that supports DNS over TLS on port * A resolver at "simple.example" that supports DNS over TLS on port
853 (implicitly, as this is its default port): 853 (implicitly, as this is its default port):
_dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot _dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot
* A resolver at "doh.example" that supports only DNS over HTTPS (DNS * A DoH-only resolver at https://doh.example/dns-query{?dns}. (DNS
over TLS is not supported): over TLS is not supported.):
_dns.doh.example. 7200 IN SVCB 1 doh.example. ( _dns.doh.example. 7200 IN SVCB 1 doh.example. (
alpn=h2 dohpath=/dns-query{?dns} ) alpn=h2 dohpath=/dns-query{?dns} )
* A resolver at "resolver.example" that supports: * A resolver at "resolver.example" that supports:
- DNS over TLS on "resolver.example" ports 853 (implicit in - DoT on "resolver.example" ports 853 (implicit in record 1) and
record 1) and 8530 (explicit in record 2), with 8530 (explicit in record 2), with "resolver.example" as the
"resolver.example" as the Authentication Domain Name, Authentication Domain Name,
- DNS over HTTPS at https://resolver.example/dns-query{?dns} - DoH at https://resolver.example/dns-query{?dns} (record 1), and
(record 1), and
- an experimental protocol on fooexp.resolver.example:5353 - an experimental protocol on fooexp.resolver.example:5353
(record 3): (record 3):
_dns.resolver.example. 7200 IN SVCB 1 resolver.example. ( _dns.resolver.example. 7200 IN SVCB 1 resolver.example. (
alpn=dot,h2,h3 dohpath=/dns-query{?dns} ) alpn=dot,h2,h3 dohpath=/dns-query{?dns} )
_dns.resolver.example. 7200 IN SVCB 2 resolver.example. ( _dns.resolver.example. 7200 IN SVCB 2 resolver.example. (
alpn=dot port=8530 ) alpn=dot port=8530 )
_dns.resolver.example. 7200 IN SVCB 3 fooexp ( _dns.resolver.example. 7200 IN SVCB 3 fooexp (
port=5353 alpn=foo foo-info=... ) port=5353 alpn=foo foo-info=... )
skipping to change at page 7, line 42 skipping to change at page 8, line 8
number, and "dohpath" value, which are controlled by this adversary. number, and "dohpath" value, which are controlled by this adversary.
By changing these values in the SVCB answers, the adversary can By changing these values in the SVCB answers, the adversary can
direct DNS queries for $HOSTNAME to any port on $HOSTNAME, and any direct DNS queries for $HOSTNAME to any port on $HOSTNAME, and any
path on "https://$HOSTNAME". If the DNS client uses shared TLS or path on "https://$HOSTNAME". If the DNS client uses shared TLS or
HTTP state, the client could be correctly authenticated (e.g. using a HTTP state, the client could be correctly authenticated (e.g. using a
TLS client certificate or HTTP cookie). TLS client certificate or HTTP cookie).
This behavior creates a number of possible attacks for certain server This behavior creates a number of possible attacks for certain server
configurations. For example, if "https://$HOSTNAME/upload" accepts configurations. For example, if "https://$HOSTNAME/upload" accepts
any POST request as a public file upload, the adversary could forge a any POST request as a public file upload, the adversary could forge a
SVCB record containing dohpath=/upload. This would cause the client SVCB record containing dohpath=/upload{?dns}. This would cause the
to upload and publish every query, resulting in unexpected storage client to upload and publish every query, resulting in unexpected
costs for the server and privacy loss for the client. Similarly, if storage costs for the server and privacy loss for the client.
two DoH endpoints are available on the same origin, and the service Similarly, if two DoH endpoints are available on the same origin, and
has designated one of them for use with this specification, this the service has designated one of them for use with this
adversary can cause clients to use the other endpoint instead. specification, this adversary can cause clients to use the other
endpoint instead.
To mitigate redirection attacks, a client of this SVCB mapping MUST To mitigate redirection attacks, a client of this SVCB mapping MUST
NOT provide client authentication for DNS queries, except to servers NOT identify or authenticate itself when performing DNS queries,
that it specifically knows are not vulnerable to such attacks. If an except to servers that it specifically knows are not vulnerable to
endpoint sends an invalid response to a DNS query, the client SHOULD such attacks. If an endpoint sends an invalid response to a DNS
NOT send more queries to that endpoint. DNS services that are query, the client SHOULD NOT send more queries to that endpoint.
identified by a hostname (Section 3) MUST ensure that all Multiple DNS services MUST NOT share a hostname identifier
unauthenticated DNS requests to that name receive any promised (Section 3) unless they are so similar that it is safe to allow an
privacy and security guarantees, regardless of transport, port attacker to choose which one is used.
number, or HTTP path.
8.2. Adversary on the transport path 8.2. Adversary on the transport path
This section considers an adversary who can modify network traffic This section considers an adversary who can modify network traffic
between the client and the alternative service (identified by the between the client and the alternative service (identified by the
TargetName). TargetName).
For a SVCB-reliant client, this adversary can only cause a denial of For a SVCB-reliant client, this adversary can only cause a denial of
service. However, because DNS is unencrypted by default, this service. However, because DNS is unencrypted by default, this
adversary can execute a downgrade attack against SVCB-optional adversary can execute a downgrade attack against SVCB-optional
skipping to change at page 9, line 23 skipping to change at page 9, line 38
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/rfc/rfc3629>. 2003, <https://www.rfc-editor.org/rfc/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012, DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/rfc/rfc6570>. <https://www.rfc-editor.org/rfc/rfc6570>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>.
[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/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding
and parameter specification via the DNS (DNS SVCB and and parameter specification via the DNS (DNS SVCB and
HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
dnsop-svcb-https-08, 12 October 2021, dnsop-svcb-https-08, 12 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
svcb-https-08>. svcb-https-08>.
10.2. Informative References 10.2. Informative References
[Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves", Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/rfc/rfc8552>. <https://www.rfc-editor.org/rfc/rfc8552>.
[DNSURI] Josefsson, S., "Domain Name System Uniform Resource [DNSURI] Josefsson, S., "Domain Name System Uniform Resource
Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006,
<https://www.rfc-editor.org/rfc/rfc4501>. <https://www.rfc-editor.org/rfc/rfc4501>.
[FETCH] "Fetch Living Standard", February 2022,
<https://fetch.spec.whatwg.org/>.
Appendix A. Mapping Summary Appendix A. Mapping Summary
This table serves as a non-normative summary of the DNS mapping for This table serves as a non-normative summary of the DNS mapping for
SVCB. SVCB.
+=================+====================================+ +=================+====================================+
+=================+====================================+ +=================+====================================+
| *Mapped scheme* | "dns" | | *Mapped scheme* | "dns" |
+-----------------+------------------------------------+ +-----------------+------------------------------------+
| *RR type* | SVCB (64) | | *RR type* | SVCB (64) |
 End of changes. 24 change blocks. 
72 lines changed or deleted 90 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/