Orange

Rennes 35000 France mohamed.boucadair@orange.com

Nokia

India kondtir@gmail.com

Cloud Software Group Holdings, Inc.

United States of America dwing-ietf@fuggles.com

ELVIS-PLUS

Russian Federation svan@elvis.ru

sec ipsecme security name resolution encryption service discovery naming resolver stub-resolver CPE Customer premise equipment VPN Secure discovery DoT DoH DoQ Tunnel connectivity This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ).

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

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 () 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

• .  Introduction
• .  Terminology
• .  IKEv2 Configuration Payload Attribute Types for Encrypted DNS
  • .  ENCDNS_IP* Configuration Payload Attributes
  • .  ENCDNS_DIGEST_INFO Configuration Payload Attribute
• .  IKEv2 Protocol Exchange
• .  Subject Public Key Info (SPKI) Hash
• .  Security Considerations
• .  Privacy Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Configuration Payload Examples
  • .  Configuration of Encrypted IPv6 DNS Resolvers without Suggested Values
  • .  Configuration of Encrypted IPv6 DNS Resolvers with Suggested Values
  • .  Split DNS
• Acknowledgments
• Authors' Addresses

Introduction This document specifies a mechanism for assigning encrypted DNS configurations to an Internet Key Exchange Protocol Version 2 (IKEv2) initiator . Specifically, it assigns one or more Authentication Domain Names (ADNs) of DNS resolvers that support encrypted DNS protocols. The specific protocols supported are described using the Service Parameters format defined in ; supported protocols include DNS over HTTPS (DoH) , DNS over TLS (DoT) , and DNS over QUIC (DoQ) . This document introduces three new IKEv2 Configuration Payload Attribute Types () to add support for encrypted DNS resolvers. The ENCDNS_IP4 and ENCDNS_IP6 attribute types () are used to provision ADNs, a list of IP addresses, and a set of service parameters. The ENCDNS_DIGEST_INFO attribute () additionally allows a specific resolver certificate to be indicated by the IKEv2 responder. The encrypted DNS resolver hosted by a Virtual Private Network (VPN) provider can get a domain-validated certificate from a public Certificate Authority (CA). The VPN client does not need to be provisioned with the root certificate of a private CA to authenticate the certificate of the encrypted DNS resolvers. The encrypted DNS resolver can run on private IP addresses, and its access can be restricted to clients connected to the VPN. For many years, typical designs have often assumed that the DNS resolver was usually located inside the protected domain, but they don't consider implementations where the DNS resolver could be located outside of it. With encrypted DNS, implementing the latter scenario becomes plausible. Note that existing VPN client implementations might not expect the discovered DNS resolver IP addresses to be outside of the covered IP address ranges of the VPN tunnel.

Terminology 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 when, and only when, they appear in all capitals, as shown here. This document uses the terms defined in . Also, this document uses the terms defined in . In particular, readers should be familiar with the terms "initiator" and "responder" as used in that document. This document makes use of the following terms:

Do53:

Refers to unencrypted DNS.

Encrypted DNS:

Refers to a scheme where DNS messages are sent over an encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ.

ENCDNS_IP*:

Refers to any of the IKEv2 Configuration Payload Attribute Types defined in .

IKEv2 Configuration Payload Attribute Types for Encrypted DNS

ENCDNS_IP* Configuration Payload Attributes The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types, ENCDNS_IP4 and ENCDNS_IP6, are used to configure an initiator with encrypted DNS resolvers. Both attribute types share the format shown in . The information included in these attributes adheres to the recommendation in .

Format of ENCDNS_IP4 and ENCDNS_IP6 Configuration Attributes 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-----------------------------+---------------+---------------+ | Service Priority | Num Addresses | ADN Length | +-------------------------------+---------------+---------------+ ~ IP Address(es) ~ +---------------------------------------------------------------+ ~ Authentication Domain Name ~ +---------------------------------------------------------------+ ~ Service Parameters (SvcParams) ~ +---------------------------------------------------------------+

The description of the fields shown in is as follows:

R (Reserved, 1 bit):

This bit MUST be set to zero and MUST be ignored on receipt (see for details).

Attribute Type (15 bits):

Identifier for the Configuration Attribute Type. This is set to 27 for ENCDNS_IP4 or 28 for ENCDNS_IP6, as registered in .

Length (2 octets, unsigned integer):

Length of the enclosed data in octets. In particular, this field is set to:

• 0, if the Configuration payload has type (1) CFG_REQUEST and no specific DNS resolver is requested or (2) CFG_ACK. If the "Length" field is set to 0, then the subsequent fields shown in are not present.
• (4 + 'Length of the ADN' + N * 4 + 'Length of SvcParams') for ENCDNS_IP4 attributes if the Configuration payload has type CFG_REQUEST, CFG_REPLY, or CFG_SET, with N being the number of included IPv4 addresses ("Num Addresses").
• (4 + 'Length of the ADN' + N * 16 + 'Length of SvcParams') for ENCDNS_IP6 attributes if the Configuration payload has type CFG_REQUEST, CFG_REPLY, or CFG_SET, with N being the number of included IPv6 addresses ("Num Addresses").

Service Priority (2 octets):

The priority of this attribute compared to other ENCDNS_IP* instances. This 16-bit unsigned integer is interpreted following the rules specified in . As AliasMode () is not supported, this field MUST NOT be set to 0. Note that AliasMode is not supported because such a mode will trigger additional Do53 queries while the data can be supplied directly in the IKE response.

Num Addresses (1 octet):

Indicates the number of enclosed IPv4 (for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6) addresses. This value MUST NOT be set to 0 if the Configuration payload has type CFG_REPLY or CFG_SET. This may be set to 0 in CFG_REQUEST to indicate that no IP address is encoded in the attribute.

ADN Length (1 octet):

Indicates the length of the "Authentication Domain Name" field in octets. When set to 0, this means that no ADN is enclosed in the attribute.

IP Address(es) (variable):

Includes one or more IP addresses that can be used to reach the encrypted DNS resolver identified by the ADN. For ENCDNS_IP4, this field contains one or more 4-octet IPv4 addresses, and for ENCDNS_IP6, this field contains one or more 16-octet IPv6 addresses.

Authentication Domain Name (variable):

A fully qualified domain name of the encrypted DNS resolver, in DNS presentation format and using an Internationalized Domain Names for Applications (IDNA) A-label . The name MUST NOT contain any terminators (e.g., NULL, CR). An example of a valid ADN for a DoH server is "doh1.example.com".

Service Parameters (SvcParams) (variable):

Specifies a set of service parameters that are encoded following the same rules for encoding SvcParams using the wire format specified in . lists a set of service parameters that are recommended to be supported by implementations. The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, as they are superseded by the included IP addresses. If no "port" service parameter is included, this indicates that default port numbers should be used. As a reminder, the default port number is 853 for DoT (), 443 for DoH (), and 853 for DoQ (). The service parameters apply to all IP addresses in the ENCDNS_IP* Configuration Payload Attribute.

ENCDNS_DIGEST_INFO Configuration Payload Attribute The ENCDNS_DIGEST_INFO Configuration Payload Attribute () allows IKEv2 responders to specify a certificate digest that initiators can use when validating TLS connections to encrypted resolvers. This attribute can also be sent by the initiator to request specific hash algorithms for such digests.

ENCDNS_DIGEST_INFO Attribute Format 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-------------+---------------+-------------------------------+ | Num Hash Algs | ADN Length | | +---------------+---------------+ + ~ Authentication Domain Name ~ +---------------------------------------------------------------+ ~ List of Hash Algorithm Identifiers ~ +---------------------------------------------------------------+ ~ Certificate Digest ~ +---------------------------------------------------------------+

Some of the fields shown in can be omitted, as further detailed below. The format of the ENCDNS_DIGEST_INFO attribute if the Configuration payload has type CFG_REQUEST is shown in .

ENCDNS_DIGEST_INFO Attribute Format in CFG_REQUEST 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-------------+---------------+-------------------------------+ | Num Hash Algs | ADN Length | | +---------------+---------------+ + ~ List of Hash Algorithm Identifiers ~ +---------------------------------------------------------------+

The description of the fields shown in is as follows:

R (Reserved, 1 bit):

This bit MUST be set to zero and MUST be ignored on receipt (see for details).

Attribute Type (15 bits):

Identifier for the Configuration Attribute Type. This is set to 29; see .

Length (2 octets, unsigned integer):

Length of the enclosed data in octets. This field MUST be set to "2 + (2 * 'number of included hash algorithm identifiers')".

Num Hash Algs (1 octet):

Indicates the number of identifiers included in the "List of Hash Algorithm Identifiers" field. This field MUST be set to "(Length - 2)/2".

ADN Length (1 octet):

MUST be set to 0.

List of Hash Algorithm Identifiers (variable):

Specifies a list of 16-bit hash algorithm identifiers that are supported by the encrypted DNS client. This list may be controlled by a local policy. The values of this field are identifiers taken from "IKEv2 Hash Algorithms" on IANA's "Internet Key Exchange Version 2 (IKEv2) Parameters" registry . There is no padding between the hash algorithm identifiers. Note that SHA2-256 is mandatory to implement (see ).

The format of the ENCDNS_DIGEST_INFO attribute if the Configuration payload has type CFG_REPLY or CFG_SET is shown in .

ENCDNS_DIGEST_INFO Attribute Format in CFG_REPLY or CFG_SET 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-------------+---------------+-------------------------------+ | Num Hash Algs | ADN Length | | +---------------+---------------+ + ~ Authentication Domain Name ~ +-------------------------------+-------------------------------+ | Hash Algorithm Identifier | ~ +-------------------------------+ + ~ Certificate Digest ~ +---------------------------------------------------------------+

The description of the fields shown in is as follows:

R (Reserved, 1 bit):

This bit MUST be set to zero and MUST be ignored on receipt (see for details).

Attribute Type (15 bits):

Identifier for the Configuration Attribute Type. This is set to 29; see .

Length (2 octets, unsigned integer):

Length of the data in octets.

Num Hash Algs (1 octet):

MUST be set to 1.

ADN Length (1 octet):

Indicates the length of the "Authentication Domain Name" field in octets. When set to 0, this means that the digest applies on the ADN conveyed in the ENCDNS_IP* Configuration Payload Attribute.

Authentication Domain Name (variable):

A fully qualified domain name of the encrypted DNS resolver following the syntax defined in . The name MUST NOT contain any terminators (e.g., NULL, CR). A name is included only when multiple ADNs are included in the ENCDNS_IP* Configuration Payload Attribute.

Hash Algorithm Identifier (2 octets):

Specifies the 16-bit hash algorithm identifier selected by the DNS resolver to generate the digest of its certificate.

Certificate Digest (variable):

Includes the Subject Public Key Info (SPKI) hash () of the encrypted DNS resolver certificate using the algorithm identified in the "Hash Algorithm Identifier" field. The length of this field is "Length - 4 - 'ADN Length'".

The ENCDNS_DIGEST_INFO attribute may be present in the Configuration payload of CFG_ACK. In such a case, the ENCDNS_DIGEST_INFO MUST be returned with zero-length data. As discussed in , there are no defined uses for the CFG_SET/CFG_ACK exchange. The use of the ENCDNS_DIGEST_INFO attribute for these messages is provided for completeness.

IKEv2 Protocol Exchange This section describes how the attributes defined in are used to configure an IKEv2 initiator with one or more encrypted DNS resolvers. As a reminder, badly formatted attributes or unacceptable fields are handled as per . Initiators first indicate support for encrypted DNS by including ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders supply encrypted DNS configuration by including ENCDNS_IP* attributes in their CFG_REPLY payloads. Concretely:

• If the initiator supports encrypted DNS, it includes either or both of the ENCDNS_IP4 and ENCDNS_IP6 attributes in its CFG_REQUEST. If the initiator does not want to request specific DNS resolvers, it sets the "Length" field to 0 for the attribute. For a given attribute type, the initiator MAY send either an empty attribute or a list of distinct suggested resolvers. The initiator MAY also include the ENCDNS_DIGEST_INFO attribute with a list of hash algorithms that are supported by the encrypted DNS client.
• If the request includes multiple bitwise identical attributes, only the first occurrence is processed, and the rest SHOULD be ignored by the responder. The responder MAY discard the full request if the count of repeated attributes exceeds an (implementation-specific) threshold.
• For each ENCDNS_IP* attribute from the CFG_REQUEST, if the responder supports the corresponding address family, and absent any policy restrictions, the responder sends back one or more ENCDNS_IP* attributes in the CFG_REPLY with an appropriate list of IP addresses, service parameters, and an ADN. The list of IP addresses MUST include at least one IP address. The service parameters SHOULD include at least the "alpn" service parameter. The "alpn" service parameter may not be required in contexts such as a variant of DNS over the Constrained Application Protocol (CoAP) where the messages are encrypted using Object Security for Constrained RESTful Environments (OSCORE) .
• The responder MAY ignore suggested values from the initiator (if any). Multiple instances of the same ENCDNS_IP* attribute MAY be returned if distinct ADNs or service parameters need to be assigned to the initiator. In such instances, the different attributes can have matching or distinct IP addresses. These instances MUST be presented to a local DNS client following their service priority (i.e., a smaller service priority value indicates a higher preference).
• In addition, the responder MAY return the ENCDNS_DIGEST_INFO attribute to convey a digest of the certificate of the encrypted DNS and the identifier of the hash algorithm that is used to generate the digest.
• If the CFG_REQUEST includes an ENCDNS_IP* attribute but the CFG_REPLY does not include an ENCDNS_IP* attribute matching the requested address family, this is an indication that the requested address family is not supported by the responder or the responder is not configured to provide corresponding resolver addresses.
• If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, it is RECOMMENDED that the initiator use the encrypted DNS resolvers.

The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, or DoQ) with the address or addresses conveyed in ENCDNS_IP* and uses the mechanisms discussed in to authenticate the DNS resolver certificate using the ADN conveyed in ENCDNS_IP*. If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the client has to create an SPKI hash () of the DNS resolver certificate received in the TLS handshake using the negotiated hash algorithm in the ENCDNS_DIGEST_INFO attribute. If the computed digest for an ADN matches the digest sent in the ENCDNS_DIGEST_INFO attribute, the encrypted DNS resolver certificate is successfully validated. If so, the client continues with the TLS connection as normal. Otherwise, the client MUST treat the resolver certificate validation failure as a non-recoverable error. This approach is similar to certificate usage PKIX-EE(1) with selector SPKI(1) as defined in , but without PKIX validation. If the IPsec connection is a split-tunnel configuration and the initiator negotiated INTERNAL_DNS_DOMAIN as per , the DNS client resolves the internal names using ENCDNS_IP* DNS resolvers. Note: requires that the INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attribute be present when INTERNAL_DNS_DOMAIN is included. This specification relaxes that constraint in the presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* attributes are supplied, responders are allowed to include INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes.

Subject Public Key Info (SPKI) Hash The SPKI hash of the encrypted DNS resolver certificate is the output of a cryptographic hash algorithm whose input is the DER-encoded ASN.1 representation of the SPKI. Implementations MUST support SHA2-256 .

Security Considerations This document adheres to the security considerations defined in . In particular, this document does not alter the trust that the initiator has placed on the DNS configuration provided by a responder. Networks are susceptible to internal attacks as discussed in . Hosting encrypted DNS resolvers even in the case of split-VPN configuration can minimize the attack vector (e.g., a compromised network device cannot monitor/modify DNS traffic). This specification describes a mechanism for restricting access to the DNS messages to only the parties that need to know. If the IKEv2 responder has used the NULL Authentication method to authenticate itself, the initiator MUST NOT use returned ENCDNS_IP* resolvers configuration unless the initiator is preconfigured, e.g., in the operating system or the application. This specification does not extend the scope of accepting DNSSEC trust anchors beyond the usage guidelines defined in .

Privacy Considerations As discussed in , the use of encrypted DNS does not reduce the data available in the DNS resolver. For example, the reader may refer to or for a discussion on specific privacy considerations for encrypted DNS.

IANA Considerations IANA has assigned the following new IKEv2 Configuration Payload Attribute Types in the "IKEv2 Configuration Payload Attribute Types" namespace available at .

Value	Attribute Type	Multivalued	Length	Reference
27	ENCDNS_IP4	YES	0 or more	RFC 9464
28	ENCDNS_IP6	YES	0 or more	RFC 9464
29	ENCDNS_DIGEST_INFO	YES	0 or more	RFC 9464

References Normative References IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations. Informative References IANA Ericsson Trinity College Dublin Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This memo suggests that the existing RFC 3552 threat model, while important and still valid, is no longer alone sufficient to cater for the pressing security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken and we argue that investigation of these issues is warranted. It is particularly important to ensure that as we continue to develop Internet technology, non-communications security related threats, and privacy issues, are properly understood. Work in Progress This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. Orange Nokia Cloud Software Group Open-Xchange Microsoft

Configuration Payload Examples

Configuration of Encrypted IPv6 DNS Resolvers without Suggested Values depicts an example of a CFG_REQUEST to request the configuration of IPv6 DNS resolvers without providing any suggested values. In this example, the initiator uses the ENCDNS_DIGEST_INFO attribute to indicate that the encrypted DNS client supports SHA2-256 (2), SHA2-384 (3), and SHA2-512 (4) hash algorithms for certificate digests. The label of these algorithms is taken from . The use of INTERNAL_IP6_ADDRESS is explained in and thus is not reiterated here.

Example of a CFG_REQUEST CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6() ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))

depicts an example of a CFG_REPLY that can be sent by a responder as a response to the above CFG_REQUEST. This response indicates the following information to identify the encrypted DNS resolver:

• Its service priority, which is 1.
• Its single (1) IPv6 address (2001:db8:99:88:77:66:55:44).
• Its ADN (doh.example.com). This ADN has a length of 15.
• Its supported HTTP version (h2).
• The relative form of the URI Template (/dns-query{?dns}).
• The SPKI hash of the resolver's certificate using SHA2-256 (8b6e7a5971cc6bb0b4db5a71...).

Example of a CFG_REPLY CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64) ENCDNS_IP6(1, 1, 15, (2001:db8:99:88:77:66:55:44), "doh.example.com", (alpn=h2 dohpath=/dns-query{?dns})) ENCDNS_DIGEST_INFO(0, SHA2-256, 8b6e7a5971cc6bb0b4db5a71...)

In the example depicted in , no ADN is included in the ENCDNS_DIGEST_INFO attribute because only one ADN is provided in the ENCDNS_IP6 attribute. Identifying the encrypted resolver associated with the supplied digest is therefore unambiguous.

Configuration of Encrypted IPv6 DNS Resolvers with Suggested Values An initiator may provide suggested values in the CFG_REQUEST when requesting an encrypted DNS resolver. For example, the initiator may:

• Indicate a preferred resolver that is identified by an IPv6 address (see ).

  Example of a CFG_REQUEST with a Preferred Resolver Identified by Its IP Address CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 1, 0, (2001:db8:99:88:77:66:55:44))

• Indicate a preferred resolver that is identified by an ADN (see ).

  Example of a CFG_REQUEST with a Preferred Resolver Identified by Its ADN CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 0, 15, "doh.example.com")

• Indicate a preferred transport protocol (DoT, in the example depicted in ).

  Example of a CFG_REQUEST with a Preferred Transport Protocol CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 0, 0, (alpn=dot))

• or any combination thereof.

Split DNS An initiator may also indicate that it supports Split DNS by including the INTERNAL_DNS_DOMAIN attribute in a CFG_REQUEST as shown in . In this example, the initiator does not indicate any preference for the requested encrypted DNS server, nor does it indicate which DNS queries will be forwarded through the IPsec tunnel.

Example of a CFG_REQUEST with Support for Split DNS CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6() INTERNAL_DNS_DOMAIN()

shows an example of the responder's reply. Absent any prohibited local policy, the initiator uses the encrypted DNS server (doh.example.com) for any subsequent DNS queries for "example.com" and its subdomains.

Example of a CFG_REPLY with INTERNAL_DNS_DOMAIN CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64) ENCDNS_IP6(1, 1, 15, (2001:db8:99:88:77:66:55:44), "doh.example.com", (alpn=h2 dohpath=/dns-query{?dns})) INTERNAL_DNS_DOMAIN(example.com)

Acknowledgments Many thanks to , , , and for their reviews and comments. and suggested the use of one single attribute carrying both the name and an IP address instead of depending on the existing INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes. Thanks to for the Shepherd review and for the AD review. Thanks to for the gen-art review, for the ops-dir review, and for the dns-dir review. Thanks to , , , and for their comments during the IESG review.

Authors' Addresses Orange

Rennes 35000 France mohamed.boucadair@orange.com

Nokia

India kondtir@gmail.com

Cloud Software Group Holdings, Inc.

United States of America dwing-ietf@fuggles.com

ELVIS-PLUS

Russian Federation svan@elvis.ru