ADD J. Todd Internet-Draft Quad9 Intended status: Standards Track T. Jensen Expires: 24 April 2024 Microsoft C. Mosher Innate, Inc. 22 October 2023 Handling Encrypted DNS Server Redirection draft-jt-add-dns-server-redirection-02 Abstract This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jt-add-dns-server- redirection/. Discussion of this document takes place on the WG Working Group mailing list (mailto:add@ietf.org), which is archived at https://example.com/WG. Subscribe at https://www.ietf.org/mailman/listinfo/add/. Source for this draft and an issue tracker can be found at https://github.com/johnhtodd/draft-DOH-redirect. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Todd, et al. Expires 24 April 2024 [Page 1] Internet-Draft EDSR October 2023 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DNS client behavior . . . . . . . . . . . . . . . . . . . . . 4 3.1. Discovering redirections . . . . . . . . . . . . . . . . 4 3.1.1. Strict Origin Redirection . . . . . . . . . . . . . . 4 3.1.2. Overlapping Origin Redirection . . . . . . . . . . . 4 3.1.3. Redirection away from DDR-discovered servers . . . . 7 3.2. Scope of Overlapping Origin Redirection . . . . . . . . . 7 3.3. Identifying self-redirections . . . . . . . . . . . . . . 8 3.4. Waiting for redirections . . . . . . . . . . . . . . . . 8 3.5. Refreshing redirections . . . . . . . . . . . . . . . . . 8 3.6. Multiple redirections . . . . . . . . . . . . . . . . . . 8 3.7. Network changes . . . . . . . . . . . . . . . . . . . . . 9 4. DNS server behavior . . . . . . . . . . . . . . . . . . . . . 9 4.1. Ensuring compatibility . . . . . . . . . . . . . . . . . 9 4.2. Dealing with persistent clients . . . . . . . . . . . . . 10 4.3. Strict versus Overlapping Domain Redirection . . . . . . 10 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 5.1. Large trees of redirections . . . . . . . . . . . . . . . 10 5.2. Redirection TTLs . . . . . . . . . . . . . . . . . . . . 11 5.3. Including IP addresses in EDSR responses . . . . . . . . 11 5.4. Delegated Credentials vs Overlapping Origin Redirection . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Trusting the redirected connection . . . . . . . . . . . 11 Todd, et al. Expires 24 April 2024 [Page 2] Internet-Draft EDSR October 2023 6.2. Use with unencrypted DNS . . . . . . . . . . . . . . . . 12 6.3. Use with DDR-discovered resolvers . . . . . . . . . . . . 12 6.4. Delegated Credentials . . . . . . . . . . . . . . . . . . 13 6.5. Overlapping Origin Redirection . . . . . . . . . . . . . 13 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 8. Data Flow Considerations . . . . . . . . . . . . . . . . . . 13 8.1. Data Scope . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Data Visibility . . . . . . . . . . . . . . . . . . . . . 13 8.3. Data centralization . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Introduction Encrypted DNS Server Redirection (EDSR) is a protocol that allows an encrypted DNS resolver whose configuration is well known to clients to redirect them to other, more desirable resolvers without having to support anycast and without having to configure clients with these other resolvers ahead of time. It uses the mechanism defined by DDR [I-D.ietf-add-ddr] to redirect an encrypted DNS client from one encrypted DNS resolver to another encrypted DNS resolver. Where DDR uses a threat model that presumes the initial DNS traffic is unencrypted, EDSR applies when the initial DNS traffic is already encrypted. One example of what makes redirection to another resolver desirable is geolocation. A DNS service may document one or a few well known resolver configurations even though it routes traffic to hundreds or thousands of resolvers that are closer to the client, reducing latency and making DNS resolutions more applicable to the client. This document describes two modes of redirection - Strict Origin Redirection and Overlapping Origin Redirection. The latter enables additional use cases such as transitions between organizations, but may have security trade-offs explored later. Todd, et al. Expires 24 April 2024 [Page 3] Internet-Draft EDSR October 2023 3. DNS client behavior 3.1. Discovering redirections When a DNS client first opens a connection to an encrypted DNS server, it MUST send a SVCB query for the name of the resolver to discover its encrypted DNS configuration. The DNS client SHOULD open a connection to the server returned in the SVCB query using the TargetName and one of the IP addresses returned in additional A/AAAA records for the same name. Once a connection has been successfully opened, as subsequently described by reaching a suitable server at the end of the redirection chain, the client SHOULD close the first connection. There are two methods defined to determine whether the redirection was suitable. 3.1.1. Strict Origin Redirection The default method of redirection EDSR-compliant clients and servers MUST support is Strict Origin Redirection. Using this method, if the returned SVCB record indicates a server with a different domain name than the current encrypted DNS connection, the redirection MUST NOT be followed by the client. Clients MAY choose to treat this as an upstream attack, though consideration should be taken in case the server is using Overlapping Origin Redirection as defined in the next section. The destination server MAY use delegated credentials (TODO: ref here). This is valid so long as the delegated credential is valid for the same domain name used by the referring server. This is an encouraged practice for servers which need to redirect clients to servers owned by other entities, as is the case with CDN contracts, when the clients and server do not have a pre-existing relationship that would justify other custom behavior such as use of the optional Overlapping Origin Redirection mechanism described in the next subsection. 3.1.2. Overlapping Origin Redirection An alternative method of redirection EDSR-compliant clients and servers MAY choose to support is Overlapping Origin Redirection. Using this method, the domain name associated with a redirection can change so long as each redirection hop is authoritative for both the new name and the previous name. Normative language in this section applies only to Overlapping Origin Redirection, meaning it only applies if the client chooses to implement this optional mode of EDSR operation. Todd, et al. Expires 24 April 2024 [Page 4] Internet-Draft EDSR October 2023 Overlapping Origin Redirection can facilitate changes in ultimate resolution endpoints for those unable to implement Delegated Credentials, so as to retain configuration agility while still retaining encryption security. The intended use cases are to support temporary configuration during transition or migration periods when immediate reconfiguration of all client endpoints is not feasible, or to retain long term support of statically configured endpoints such as through an organizational acquisition. Organizations should evaluate their specific needs and capabilities carefully when choosing to implement/enable Overlapping Origin. The client checks the server's SVCB response for the presence of SVCB keys "edsr-domain" or "edsr-apex-domain" defined by this document. The presence of the "edsr-domain" key indicates that the redirection is going to a server with a different domain name than the current server. For DoT and DoQ redirection, this is sufficient. For DoH, the "dohpath" MUST also be present as it is not guaranteed that simple swapping the domain name into the current server's DoH template will work. The presence of the "edsr-apex-domain" key indicates that the domain name of the redirection destination is not specifically known but will be a child of a given domain name. If both "edsr-domain" and "edsr-apex-domain" are present, clients supporting Overlapping Origin Redirection MUST prefer the "edsr-domain" value and validate the redirection accordingly. If only "edsr-apex-domain" is present between these two, but there is also a "dohpath" value, the client can use the DoH template with whatever child domain is discovered upon redirection assuming it passes the validation described later in this section. Let's say a client is configured to use a DoH server with template "https://first.doh.server.example/doh-query". In this example, Overlapping Origin Redirection would enable a redirection to a server with domain name "second.doh.server.example": 1. Client establishes a DoH connection to first.doh.server.example 2. Client sends a SVCB query for "first.doh.server.example" 3. Server replies with "edsr-domain" = "second.doh.server.example" with accompanying DoH template and additional A/AAAA records 4. Client initiates a TLS handshake with the second.doh.server.example server 5. Server sends a certificate that claims both domain names in its SAN field Todd, et al. Expires 24 April 2024 [Page 5] Internet-Draft EDSR October 2023 6. Client accepts the redirection and considers the new server to be identified as "second.doh.server.example" 7. Client sends a SVCB query for "second.doh.server.example" 8. Server replies with no "edsr-domain" value with accompanying DoH template and additional A/AAAA records 9. Client initiates a TLS handshake with the second.doh.server.example server (on a different IP address) 10. Server sends a certificate that claims only "second.doh.server.example" in its SAN field 11. Client accepts the redirection because this exactly matches the domain name of the previous resolver Clients MUST reject redirections using this method if the redirection points to a server with a different domain name than the current server and the destination server presents a certificate that cannot claim both the domain name of the server that offered the redirection and the name the redirecting server indicated in its SVCB response. Clients implementing only Strict Origin Redirection will safely avoid accidentally validating Overlapping Origin Redirection SVCB responses by the nature of ignoring SVCB keys it does not support per guidance in (TODO: SVCB doc ref). The first redirection will still work as expected (because Overlapping Domain Redirection requires the first hop to be valid for the original domain name) but will not change the domain name treated as the server's identity. Additional redirections that try to use the edsr-domain value that the client ignored will fail Strict Origin Redirection at that point. 3.1.2.1. Example Use Cases Mergers or acquisitions between organizations may require immediate transition of DNS services to the acquiring company, but reconfiguring all client devices may not be feasible in a given timeframe. Overlapping Origin Redirection allows the acquired company's DNS servers to redirect clients to the acquirer's servers while clients gradually update their configurations, preventing service interruptions during the transition period. Todd, et al. Expires 24 April 2024 [Page 6] Internet-Draft EDSR October 2023 Home devices or those managed under bring-your-own-device corporate policies may not be easily updatable by IT groups. Overlapping Origin Redirection allows legacy client configurations on these devices to be maintained through organizational transitions with the EDSR server redirecting traffic without needing to modify individual devices. Smaller organizations or DNS/CDN service providers may lack the expertise or resources to implement Delegated Credentials for secure redirection between organizations. Overlapping Origin Redirection gives these organizations a simpler mechanism to redirect traffic to partners when immediate reconfiguration of the client base is infeasible. 3.1.3. Redirection away from DDR-discovered servers Both Strict Origin Redirection and Overlapping Origin Redirection assume that the original server is identified by domain name from the client's perspective. Examples include when the client was configured with the resolver through endpoint management or DNR discovery (TODO: ref). However, when server was discovered using DDR (TODO: ref), this is not the case. Due to the threat model DDR operates under, where it has to start from an unencrypted resolver, the identity of the server used for verification is its IP address. The risks involved with using the domain name of a DDR-discovered resolver are further explored in the Security Considerations section (TODO: self ref). When clients use Strict Origin redirection discovery with a DDR discovered resolver, the only difference is that the destination server it was redirected to MUST be able to claim the IP address of the previous server in its SAN field. This is the equivalent of not changing origins in the DDR threat model. Clients MUST NOT use Overlapping Origin Redirection with resolvers discovered using DDR, even if they otherwise support Overlapping Origin Redirection. 3.2. Scope of Overlapping Origin Redirection Clients SHOULD NOT use Overlapping Origin Redirection unless they have a policy configuration that indicates this is acceptable behavior. Such a client, if it is human-facing, MUST have an indication that the DNS server in use has a different identity than the one that was originally configured. Todd, et al. Expires 24 April 2024 [Page 7] Internet-Draft EDSR October 2023 3.3. Identifying self-redirections If the set of IP addresses that are valid for the server being redirected to include the IP address of the current server, the client SHOULD ignore the redirection, treating it the same as receiving no response or a NODATA response from the SVCB query. However, clients receiving preferable encryption parameters as part of the SVCB response MAY choose to reconnect to negotiate to upgrade to the preferred encryption method. When doing so, there is no need for the client to repeat EDSR as the redirection from the server to itself has terminated the redirection chain. 3.4. Waiting for redirections The client does not need to wait for the results of the redirection discovery query before sending other DNS queries on the connection, though they SHOULD gracefully close the connection as soon as it has successfully established a connection to the server it was redirected to and received or timed out the outstanding queries on the original connection. See the considerations section for reasons a client MAY choose to decline a redirection. 3.5. Refreshing redirections EDSR allows a client to be redirected from an encrypted DNS resolver it was somehow configured to use. When the redirection TTL expires, the client SHOULD return to using its originally configured server unless it can refresh the redirection beforehand. This allows the client to honor the intention of whatever configuration method was used to instruct it to use the original encrypted DNS resolver. If a chain of redirections was followed, the effective TTL of the redirection is the minimum of the TTLs encountered along the chain. Clients SHOULD however cap this value to some minimum value at their discretion to avoid frequent redirection checking when latency plus an incidentally low TTL along the chain results in near-zero effective TTLs. 3.6. Multiple redirections When clients receive more than one valid SVCB response, they SHOULD prefer using the redirections that match their configuration (such as supported IP address family or desired encrypted DNS protocol) in ascending order of the SVCB priority. Once a successful connection is made to a redirected destination, clients MAY choose to discard other results in favor of restarting EDSR with the originally Todd, et al. Expires 24 April 2024 [Page 8] Internet-Draft EDSR October 2023 configured resolver. Redirections are considered to be a one-to-one relationship (starting with one recursive resolver and following its redirections should result in one replacement recursive resolver). It is not expected that a stub resolver ends up using more recursive resolvers than it was originally configured with when using EDSR. 3.7. Network changes When a client device changes what network it is connected to, it SHOULD forget pre-existing redirections and start EDSR over with the originally configured resolvers. This ensures that a resolver which redirects clients based on their source network can behave accordingly. Note that this is unrelated to what resolvers a client is originally configured with. For example, a client which is configured to always used the resolvers advertised by DHCP will likely start with different original resolvers when changing networks. How a client is configured with DNS resolvers is out of scope for this document. EDSR only provides a mechanism for clients to discover redirections from resolvers they were previously configured to use. 4. DNS server behavior DNS resolvers who want to redirect clients to other resolvers MUST respond to SVCB [I-D.ietf-add-svcb-dns] queries for their own domain names with records that describe the configuration of the destination server. Guidance in Section 5 of [I-D.ietf-dnsop-svcb-https] to improve performance by including additional A/AAAA records with the SVCB response SHOULD be followed. 4.1. Ensuring compatibility Redirections MUST only redirect to resolvers which support at least the same protocol, address family, port, and TLS minimum versions as the referring resolver. This ensures that redirections do not lead clients to resolvers that are not compatible with the client. In addition, servers SHOULD avoid redirecting to servers which will also redirect clients unless they are actively coordinating to ensure a positive client experience. See the Deployment Considerations section for more details. Todd, et al. Expires 24 April 2024 [Page 9] Internet-Draft EDSR October 2023 Servers SHOULD be prepared for clients to reject Overlapping Origin redirections which is an optional redirection mode (whereas support for Strict Origin Redirection is REQUIRED). 4.2. Dealing with persistent clients Servers SHOULD be prepared for clients to not follow the redirection immediately as connection failures, other technical issues, or even client policy affecting server choice may lead to clients being unable to follow the redirection promptly or at all. Servers who are redirecting due to being overloaded MAY respond as they normally would to overwhelming traffic. 4.3. Strict versus Overlapping Domain Redirection Servers SHOULD only offer Overlapping Domain Redirection when they reasonably expect clients will have been configured to use it, implying an out-of-band relationship between the server operator and the client operator. Server operators ought to consider using delegated credentials (TODO: ref) when they wish to redirect general clients to other servers operated by other entities. This allows the server operator to avoid giving access to their domain's private key to third parties but also ensure general clients have a secured, same-origin redirection experience. Overlapping Domain Redirection is only defined for the limited scenarios where the server and client administrators are either the same or have an out-of-band relationship and redirection is needed to server operators who do not support TLS delegated credentials (TODO: ref). 5. Deployment Considerations 5.1. Large trees of redirections It is possible for DNS servers to redirect clients to DNS servers which also redirect clients. Clients which are presented with long chains of redirections MAY choose to stop following redirections to reduce connection thrashing. DNS server operators SHOULD deploy redirection behavior mindfully to avoid long chains of redirection. Servers SHOULD ensure their redirections do not create loops, where clients are redirected to a server it already encountered earlier in the process. Clients MAY stop following redirections when they detect this, but may also take a simpler approach, following only a maximum number of redirections. Todd, et al. Expires 24 April 2024 [Page 10] Internet-Draft EDSR October 2023 5.2. Redirection TTLs Servers SHOULD provide sufficiently long TTLs for clients to avoid the need to constantly repeat EDSR queries. Server operators should be mindful of redirection chains because unless they collaboratively control the TTLs of one another's redirections, redirection chains will end up with greatly reduced effective TTLs because the client will always use the lowest. 5.3. Including IP addresses in EDSR responses If a recursive resolver does not include additional A/AAAA records per Section 5 of [I-D.ietf-dnsop-svcb-https], stub resolvers might end up failing the redirection if the redirection destination name cannot be resolved. Additionally, the recursive resolver SHOULD ensure records conntaining the same IP version as the existing connection are returned (if the stub is currently connected over IPv4, one or more A records SHOULD be included, and if the stub is currently connected over IPv6, one or more AAAA records SHOULD be included). 5.4. Delegated Credentials vs Overlapping Origin Redirection Delegated Credentials with SOR should be used preferentially where feasible to reduce risks. Use of OOR should be time-bound to the period where Delegated Credentials are not feasible, if possible. 6. Security Considerations 6.1. Trusting the redirected connection EDSR does not provide novel authentication or security mechanisms. Redirection is trusted by virtue of the server authentication via PKI through TLS [RFC5280]. The DNS stub resolver implementing EDSR SHOULD use whatever policies it uses for other TLS connections for encrypted DNS traffic to determine if a given TLS cert chain is trustworthy before proceeding with EDSR. EDSR MUST NOT be used with encrypted DNS protocols that are not based on TLS. This scenario will require future standards work. EDSR should not introduce any additional security considerations beyond use of the original encrypted resolver prior to redirection. Because the original connection was trusted, information sent over it about a new connection to use should be as trusted. However, clients that wish to time bound vulnerabilities to attackers who compromise the original resolver MAY choose to implement a maximum TTL to honor on SVCB records that redirect to other servers. Todd, et al. Expires 24 April 2024 [Page 11] Internet-Draft EDSR October 2023 6.2. Use with unencrypted DNS EDSR MUST NOT be used to redirect unencrypted DNS traffic to any other resolver. This use case is called designation and is covered by Discovery of Designated Resolvers (DDR) as defined in [I-D.ietf-add-ddr]. Not following DDR opens up a DNS client to malicious redirection to an attacker-controlled DNS server. For more information, see Section 7 of [I-D.ietf-add-ddr]. EDSR also MUST NOT be used to redirect encrypted DNS traffic to a resolver that advertises support for unencrypted DNS. This would reduce the security posture of the client. Clients MUST NOT follow an encrypted DNS redirection and then send unencrypted DNS traffic to the new resolver. 6.3. Use with DDR-discovered resolvers When a resolver is discovered using DDR (todo: ref), the server's identity used for TLS purposes is its IP address, not its domain name. This means servers and clients MUST use the original server's IP address, not the IP address of the previous server in the event of redirection chains, in the SAN field of destination servers to validate the redirection. The reason for this is due to an attack where the DDR SVCB query response is modified by an active attacker to have a different domain name in its "dohpath" SVCB key. When the client uses it to issue the EDSR query to the (valid) DDR-designated resolver, it will innocently forward the query upstream and return the result. The result may even be DNSSEC signed since it was issued by the valid owner of the attacker's domain name. If this redirection is then followed and validated with the attacker's domain name, it will succeed and the client will have been maliciously redirected to use an attacker's server at the low cost of a port 53 attack without breaking encryption or compromising the encrypted DNS server DDR designated. There is no harm in using the name of the server for the EDSR query so long as the validation of the destination server is performed using the original IP address and not the name. This ensures EDSR clients can consistently use the domain name of a server for redirection discovery. Use of the DDR-defined SUDN "resolver.arpa" was considered and rejected because this would conflate DDR configuration and EDSR configuration by placing them in the same zone, using the same DNS record type. Todd, et al. Expires 24 April 2024 [Page 12] Internet-Draft EDSR October 2023 6.4. Delegated Credentials Delegated Credentials are a more secure transition mechanism for redirection than Overlapping Origin Redirection, and may be further secured by additional practices such as using a trimmed certificate authority (CA) database. 6.5. Overlapping Origin Redirection Overlapping Origin Redirection provides an alternative when Delegated Credentials are not feasible, but has less protection against malicious redirections during domain transition. Clients concerned about these risks can disable or restrict Overlapping Origin Redirection through local policy. 7. Privacy Considerations A client MAY choose to not send other name queries until redirection is complete, but there should be no issue with sending queries to intermediate resolvers before redirection takes place. This is because the intermediate resolvers are considered to be appropriate destinations by the client even if the resolver wants to substitute another resolver for reasons other than name resolution results such as latency optimization or load balancing. 8. Data Flow Considerations 8.1. Data Scope EDSR does not result in any additional data being shared by the end user, as the DNS queries going to the new resolver were already going to go to the original resolver. 8.2. Data Visibility EDSR results in a 1:1 replacement of DNS resolvers used (future queries sent to the new resolver will not be sent to the original resolver anymore). This means the number of servers which see any given query remain the same. This is only true if clients only use one redirected DNS server per original DNS server. If the DNS server offers more than one redirection, and the client validates and uses two or more of those redirections, then there will be greater data visibility (more destinations). This is however entirely within the client's choice following their own policy as a redundancy versus volume of exhausted data trade-off. Todd, et al. Expires 24 April 2024 [Page 13] Internet-Draft EDSR October 2023 EDSR requires the redirection to another server to also use encrypted DNS, so no third-party will be introduced to the data flow unless the encryption is broken. 8.3. Data centralization EDSR can only increase data centralization if multiple resolver operators choose to redirect DNS clients to the same, other DNS resolver. To prevent the reduction of their resolution redundancy, DNS clients MAY choose to ignore redirections if they find that they point to resolvers they are already configured to use, by a previous redirection or some other configuration. 9. IANA Considerations (TODO: request the addition of "edsr-domain" and "edsr-apex-domain" to the SVCB DNS registry) 10. References 10.1. Normative References [I-D.ietf-add-ddr] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", Work in Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August 2022, . [I-D.ietf-add-svcb-dns] Schwartz, B. M., "Service Binding Mapping for DNS Servers", Work in Progress, Internet-Draft, draft-ietf- add-svcb-dns-09, 26 June 2023, . [I-D.ietf-dnsop-svcb-https] Schwartz, B. M., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft- ietf-dnsop-svcb-https-12, 11 March 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Todd, et al. Expires 24 April 2024 [Page 14] Internet-Draft EDSR October 2023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . Appendix A. Acknowledgments The authors would like to thank the following individuals for their invaluable feedback to this document: Ben Schwartz, Eric Orth, Erik Nygren, Ralph Weber, Ted Hardie, Tommy Pauly, Viktor Dukhovni, and Vittorio Bertola. Authors' Addresses J. Todd Quad9 Email: jtodd@quad9.net T. Jensen Microsoft Email: tojens@microsoft.com C. Mosher Innate, Inc. Email: cmosher@gmail.com Todd, et al. Expires 24 April 2024 [Page 15]