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