<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --><!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-ipsecme-add-ike-14"ipr="trust200902">number="9464" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.17.1 --> <front> <title abbrev="IKEv2 for Encrypted DNS">Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS</title> <seriesInfo name="RFC" value="9464"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <postal><street></street><street/> <city>Rennes</city> <code>35000</code> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="TirumaleswarReddy"Reddy.K" initials="T."surname="Reddy">surname="Reddy.K"> <organization>Nokia</organization> <address> <postal><street></street> <city></city> <region></region> <code></code><street/> <city/> <region/> <code/> <country>India</country> </postal> <email>kondtir@gmail.com</email> </address> </author> <author fullname="Dan Wing" initials="D." surname="Wing"> <organizationabbrev="Citrix">Citrix Systems,abbrev="Cloud Software Group">Cloud Software Group Holdings, Inc.</organization> <address> <postal><street></street> <country>USA</country><street/> <country>United States of America</country> </postal> <email>dwing-ietf@fuggles.com</email> </address> </author> <author fullname="Valery Smyslov" initials="V." surname="Smyslov"> <organization>ELVIS-PLUS</organization> <address> <postal><street></street> <city></city> <region></region> <code></code> <country>RU</country><street/> <city/> <region/> <code/> <country>Russian Federation</country> </postal> <email>svan@elvis.ru</email> </address> </author> <date year="2023" month="November" /> <area>sec</area> <workgroup>ipsecme</workgroup> <keyword>security</keyword> <keyword>name resolution</keyword> <keyword>encryption</keyword> <keyword>service discovery</keyword> <keyword>naming</keyword> <keyword>resolver</keyword> <keyword>stub-resolver</keyword> <keyword>CPE</keyword> <keyword>Customer premise equipment</keyword> <keyword>VPN</keyword> <keyword>Secure discovery</keyword> <keyword>DoT</keyword> <keyword>DoH</keyword> <keyword>DoQ</keyword> <keyword>Tunnel</keyword> <keyword>connectivity</keyword> <abstract> <t>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 asDNS-over-HTTPSDNS over HTTPS (DoH),DNS-over-TLSDNS over TLS (DoT), andDNS-over-QUICDNS over QUIC (DoQ).</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>This document specifies a mechanismto assignfor assigning encrypted DNS configurations to an Internet Key Exchange Protocol Version 2 (IKEv2) initiator <xreftarget="RFC7296"></xref> initiator.target="RFC7296" format="default"/>. 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 <xreftarget="I-D.ietf-dnsop-svcb-https"></xref>;target="RFC9460" format="default"/>; supported protocols includeDNS-over-HTTPSDNS over HTTPS (DoH) <xreftarget="RFC8484"></xref>, DNS-over-TLStarget="RFC8484" format="default"/>, DNS over TLS (DoT) <xreftarget="RFC7858"></xref>,target="RFC7858" format="default"/>, andDNS-over-QUICDNS over QUIC (DoQ) <xreftarget="RFC9250"></xref>.</t>target="RFC9250" format="default"/>.</t> <t>This document introduces three new IKEv2 Configuration Payload Attribute Types (<xreftarget="RI"></xref>)target="RI" format="default"/>) to add support for encrypted DNS resolvers. The ENCDNS_IP4 and ENCDNS_IP6 attribute types (<xreftarget="RIIP"></xref>)target="RIIP" format="default"/>) are used to provision ADNs, a list of IP addresses, and a set of service parameters. The ENCDNS_DIGEST_INFO attribute (<xreftarget="digest"></xref>)target="digest" format="default"/>) additionally allows a specific resolver certificate to be indicated by the IKEv2 responder.</t> <t>The encrypted DNS resolver hosted by a Virtual Private Network (VPN) provider can get adomain-validatedomain-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 IPaddressesaddresses, and its access can be restricted to clients connected to the VPN.</t> <t>For many years, typical designs have oftenconsideredassumed 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 latteroptionscenario becomes plausible. Note that existing VPN client implementations might not expectthatthe discovered DNS resolver IP addresses to be outside of the covered IP address ranges of the VPN tunnel.</t> </section> <section anchor="notation"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>This document uses the terms defined in <xreftarget="RFC8499"></xref>.</t>target="RFC8499" format="default"/>.</t> <t>Also, this document uses the terms defined in <xreftarget="RFC7296"></xref>.target="RFC7296" format="default"/>. In particular, readers should be familiar with the terms "initiator" and "responder"termsas used in that document.</t> <t>This document makes use of the following terms:<list style="hanging"> <t hangText="Do53:">refers</t> <dl newline="false" spacing="normal"> <dt>Do53:</dt> <dd>Refers to unencryptedDNS.</t> <t hangText="Encrypted DNS:">refersDNS.</dd> <dt>Encrypted DNS:</dt> <dd>Refers to a scheme where DNS messages are sent over an encrypted channel. Examples of encrypted DNS are DoT, DoH, andDoQ.</t> <t hangText="ENCDNS_IP*:">refersDoQ.</dd> <dt>ENCDNS_IP*:</dt> <dd>Refers to any of the IKEv2 Configuration Payload Attribute Types defined in <xreftarget="RIIP"></xref>.</t> </list></t> <t></t>target="RIIP" format="default"/>.</dd> </dl> </section> <section anchor="RI"title="IKEv2numbered="true" toc="default"> <name>IKEv2 Configuration Payload Attribute Types for EncryptedDNS">DNS</name> <section anchor="RIIP"title="ENCDNS_IP*numbered="true" toc="default"> <name>ENCDNS_IP* Configuration PayloadAttributes">Attributes</name> <t>The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types, ENCDNS_IP4 and ENCDNS_IP6, are used to configure an initiator with encrypted DNSresolvers to an initiator.resolvers. Both attribute types share the formatthat isshown in <xreftarget="ri_attr"></xref>.target="ri_attr" format="default"/>. The information included in these attributes adheres to the recommendation in <xref section="3.1.9"target="I-D.ietf-add-dnr"></xref>.</t> <t><figure anchor="ri_attr" title="Attributes Format"> <artwork><![CDATA[target="RFC9463" format="default"/>.</t> <figure anchor="ri_attr"> <name>Format of ENCDNS_IP4 and ENCDNS_IP6 Configuration Attributes</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 | +-------------------------------+---------------+---------------+ ~ IPAddressesAddress(es) ~ +---------------------------------------------------------------+ ~ Authentication Domain Name ~ +---------------------------------------------------------------+ ~ Service Parameters (SvcParams) ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++---------------------------------------------------------------+ ]]></artwork></figure></t></figure> <t>The description of the fieldsof the attributeshown in <xreftarget="ri_attr"></xref>target="ri_attr" format="default"/> is as follows:</t><t><list style="symbols"> <t>R<dl newline="false" spacing="normal"> <dt>R (Reserved, 1bit) - Thisbit):</dt><dd>This bitMUST<bcp14>MUST</bcp14> be set to zero andMUST<bcp14>MUST</bcp14> be ignored on receipt (see <xref section="3.15.1"target="RFC7296"></xref>target="RFC7296" format="default"/> fordetails).</t> <t>Attributedetails).</dd> <dt>Attribute Type (15bits) - Identifierbits):</dt><dd>Identifier for the Configuration Attribute Type. This is set toTBA127 for ENCDNS_IP4 orTBA228 for ENCDNS_IP6, as registered in <xreftarget="IANA1"></xref>.</t> <t>Lengthtarget="IANA1" format="default"/>.</dd> <dt>Length (2 octets, unsignedinteger) - Lengthinteger):</dt><dd><t>Length of the enclosed data in octets. In particular, this field is setto:<list style="symbols"> <t>0,to:</t> <ul spacing="normal"> <li>0, if the Configuration payload has(i)type (1) CFG_REQUEST and no specific DNS resolver is requested or(ii) type(2) CFG_ACK. If the'Length'"Length" field is set to 0, thenlaterthe subsequent fields shown in <xreftarget="ri_attr"></xref>target="ri_attr" format="default"/> are notpresent.</t> <t>(4present.</li> <li>(4 + 'Length of the ADN' + N * 4 +Length'Length ofSvcParams)SvcParams') for ENCDNS_IP4 attributes if the Configuration payload hastypes CFG_REQUEST or CFG_REPLYtype CFG_REQUEST, CFG_REPLY, orCFG_SET;CFG_SET, with N being the number of included IPv4 addresses('Num addresses').</t> <t>(4("Num Addresses").</li> <li>(4 + 'Length of the ADN' + N * 16 +Length'Length ofSvcParams)SvcParams') for ENCDNS_IP6 attributes if the Configuration payload hastypes CFG_REQUEST or CFG_REPLYtype CFG_REQUEST, CFG_REPLY, orCFG_SET;CFG_SET, with N being the number of included IPv6 addresses('Num addresses').</t> </list></t> <t>Service("Num Addresses").</li> </ul> </dd> <dt>Service Priority (2octets) - Theoctets):</dt><dd>The priority of this attribute compared to other ENCDNS_IP* instances. This 16-bit unsigned integer is interpreted following the rules specified in <xref section="2.4.1"target="I-D.ietf-dnsop-svcb-https"></xref>.target="RFC9460" format="default"/>. As AliasMode (<xref section="2.4.2"target="I-D.ietf-dnsop-svcb-https"></xref>)target="RFC9460" format="default"/>) is not supported, this fieldMUST NOT<bcp14>MUST NOT</bcp14> 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 IKEresponse.</t> <t>Numresponse.</dd> <dt>Num Addresses (1octet) - Indicatesoctet):</dt><dd>Indicates the number of enclosed IPv4 (for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6) addresses. This valueMUST NOT<bcp14>MUST NOT</bcp14> be set to 0 if the Configuration payloadis ofhas type CFG_REPLY or CFG_SET. This may be set to 0 in CFG_REQUEST to indicate that no IP address is encoded in theattribute.</t> <t>ADNattribute.</dd> <dt>ADN Length (1octet) - Indicatesoctet):</dt><dd>Indicates the length of the "Authentication Domain Name" field in octets. When set to'0',0, this means that no ADN is enclosed in theattribute.</t> <t>IPattribute.</dd> <dt>IP Address(es)(variable) - Includes(variable):</dt><dd>Includes one or more IP addresses that can be used to reach the encrypted DNS resolver identified by theAuthentication Domain Name.ADN. ForENCDNS_IP4ENCDNS_IP4, this field contains one or more 4-octet IPv4 addresses, and forENCDNS_IP6ENCDNS_IP6, this field contains one or more 16-octet IPv6addresses.</t> <t>Authenticationaddresses.</dd> <dt>Authentication Domain Name(variable) - A(variable):</dt><dd><t>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 <xreftarget="RFC5890"></xref>.target="RFC5890" format="default"/>. The nameMUST NOT<bcp14>MUST NOT</bcp14> contain any terminators (e.g., NULL, CR).<vspace blankLines="1" />An</t> <t>An example of a valid ADN for a DoH server is"doh1.example.com".</t> <t>Service"doh1.example.com".</t></dd> <dt>Service Parameters (SvcParams)(variable) - Specifies(variable):</dt><dd><t>Specifies a set of service parameters that are encoded following the same rules for encoding SvcParams using the wire format specified in <xrefsection="2.1" target="I-D.ietf-dnsop-svcb-https"></xref>. Section 3.1.5 of <xref target="I-D.ietf-add-dnr"></xref>section="2.2" target="RFC9460" format="default"/>. <xref section="3.1.5" target="RFC9463" format="default"/> lists a set of service parameters that are recommended to be supported by implementations.<vspace blankLines="1" />The</t> <t>The service parametersMUST NOT<bcp14>MUST NOT</bcp14> include "ipv4hint" or "ipv6hint"SvcParamsSvcParams, as they are superseded by the included IP addresses.<vspace blankLines="1" />If</t> <t>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(Section 6 of <xref target="RFC7858"></xref>),(<xref section="6" target="RFC7858" format="default"/>), 443 for DoH(Section 8.1 of <xref target="RFC8484"></xref>),(<xref section="8.1" target="RFC8484" format="default"/>), and 853 for DoQ(Section 8 of <xref target="RFC9250"></xref>). <vspace blankLines="1" />The(<xref section="8" target="RFC9250" format="default"/>). </t> <t>The service parameters apply to all IP addresses in the ENCDNS_IP* Configuration PayloadAttribute.</t> </list></t>Attribute.</t></dd> </dl> </section> <section anchor="digest"title="ENCDNS_DIGEST_INFOnumbered="true" toc="default"> <name>ENCDNS_DIGEST_INFO Configuration PayloadAttribute">Attribute</name> <t>The ENCDNS_DIGEST_INFOconfiguration payload attributeConfiguration Payload Attribute (<xreftarget="digest_attr_full"></xref>)target="digest_attr_full" format="default"/>) 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.</t><t><figure anchor="digest_attr_full" title="ENCDNS_DIGEST_INFO<figure anchor="digest_attr_full"> <name>ENCDNS_DIGEST_INFO AttributeFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 ~ +---------------------------------------------------------------+ ]]></artwork></figure>Some</figure> <t>Some of the fields shown in <xreftarget="digest_attr_full"></xref>target="digest_attr_full" format="default"/> can beomittedomitted, as further detailed below.</t> <t>The format of the ENCDNS_DIGEST_INFO attribute if the Configuration payload has type CFG_REQUEST is shown in <xreftarget="digest_attr"></xref>.</t> <t><figure anchor="digest_attr" title="ENCDNS_DIGEST_INFOtarget="digest_attr" format="default"/>.</t> <figure anchor="digest_attr"> <name>ENCDNS_DIGEST_INFO Attribute Format inCFG_REQUEST"> <artwork><![CDATA[CFG_REQUEST</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 ~ +---------------------------------------------------------------+ ]]></artwork></figure></t></figure> <t>The description of the fieldsof the attributeshown in <xreftarget="digest_attr"></xref>target="digest_attr" format="default"/> is asfollows:<list style="symbols"> <t>Rfollows:</t> <dl newline="false" spacing="normal"> <dt>R (Reserved, 1bit) - Thisbit):</dt><dd>This bitMUST<bcp14>MUST</bcp14> be set to zero andMUST<bcp14>MUST</bcp14> be ignored on receipt (see <xref section="3.15.1"target="RFC7296"></xref>target="RFC7296" format="default"/> fordetails).</t> <t>Attributedetails).</dd> <dt>Attribute Type (15bits) - Identifierbits):</dt><dd>Identifier for the Configuration AttributeType;Type. This is set toTBA3 value listed in29; see <xreftarget="IANA1"></xref>.</t> <t>Lengthtarget="IANA1" format="default"/>.</dd> <dt>Length (2 octets, unsignedinteger) - Lengthinteger):</dt><dd>Length of the enclosed data in octets. This fieldMUST<bcp14>MUST</bcp14> be set to "2 + (2 * 'number of included hash algorithmidentifiers')".</t> <t>Numidentifiers')".</dd> <dt>Num Hash Algs (1octet) - Indicatesoctet):</dt><dd>Indicates the number of identifiers included'Hashin the "List of Hash AlgorithmIdentifiers'.Identifiers" field. This fieldMUST<bcp14>MUST</bcp14> be set to "(Length– 2)/2".</t> <t>ADN- 2)/2".</dd> <dt>ADN Length (1octet) - MUSToctet):</dt><dd><bcp14>MUST</bcp14> be set to0.</t> <t>List0.</dd> <dt>List of Hash Algorithm Identifiers(variable) - Specifies(variable):</dt><dd><t>Specifies a list of 16-bit hash algorithm identifiers that are supported by the encrypted DNS client. This list may be controlled by a localpolicy.<vspace blankLines="1" />Thepolicy.</t> <t>The values of this field are identifiers taken fromthe"IKEv2 HashAlgorithm Identifiers ofAlgorithms" on IANA's "Internet Key Exchange Version 2 (IKEv2) Parameters" registry <xreftarget="IANA-IKE-HASH"></xref>. <vspace blankLines="1" />Theretarget="IANA-IKE-HASH" format="default"/>. </t> <t>There is no padding between the hash algorithm identifiers.<vspace blankLines="1" />Note</t> <t>Note that SHA2-256 is mandatory to implement (see <xreftarget="hash"></xref>).</t> </list></t>target="hash" format="default"/>).</t> </dd> </dl> <t>The format of the ENCDNS_DIGEST_INFO attribute if the Configuration payload hastypestype CFG_REPLY or CFG_SET is shown in <xreftarget="digest_attr_res"></xref>.</t> <t><figure anchor="digest_attr_res" title="ENCDNS_DIGEST_INFOtarget="digest_attr_res" format="default"/>.</t> <figure anchor="digest_attr_res"> <name>ENCDNS_DIGEST_INFO Attribute Format in CFG_REPLY orCFG_SET"> <artwork><![CDATA[CFG_SET</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++---------------------------------------------------------------+ ]]></artwork></figure>The</figure> <t>The description of the fieldsof the attributeshown in <xreftarget="digest_attr"></xref>target="digest_attr_res" format="default"/> is as follows:</t><t><list style="symbols"> <t>R<dl newline="false" spacing="normal"> <dt>R (Reserved, 1bit) - Thisbit):</dt><dd>This bitMUST<bcp14>MUST</bcp14> be set to zero andMUST<bcp14>MUST</bcp14> be ignored on receipt (see <xref section="3.15.1"target="RFC7296"></xref>target="RFC7296" format="default"/> fordetails).</t> <t>Attributedetails).</dd> <dt>Attribute Type (15bits) - Identifierbits):</dt><dd>Identifier for the Configuration AttributeType;Type. This is set toTBA3 value listed in29; see <xreftarget="IANA1"></xref>.</t> <t>Lengthtarget="IANA1" format="default"/>.</dd> <dt>Length (2 octets, unsignedinteger) - Lengthinteger):</dt><dd>Length of the data inoctets.</t> <t>Numoctets.</dd> <dt>Num Hash Algs (1octet) - MUSToctet):</dt><dd><bcp14>MUST</bcp14> be set to1.</t> <t>ADN1.</dd> <dt>ADN Length (1octet) - Indicatesoctet):</dt><dd>Indicates the length of the "Authentication Domain Name" field in octets. When set to'0',0, this means that the digest applies on the ADN conveyed in the ENCDNS_IP* Configuration PayloadAttribute(s).</t> <t>AuthenticationAttribute.</dd> <dt>Authentication Domain Name(variable) - A(variable):</dt><dd>A fully qualified domain name of the encrypted DNS resolver following the syntax defined in <xreftarget="RFC5890"></xref>.target="RFC5890" format="default"/>. The nameMUST NOT<bcp14>MUST NOT</bcp14> contain any terminators (e.g., NULL, CR). A name is included only when multiple ADNs are included in the ENCDNS_IP* Configuration PayloadAttributes.</t> <t>HashAttribute.</dd> <dt>Hash Algorithm Identifier (2octets) - Specifiesoctets):</dt><dd>Specifies the 16-bit hash algorithm identifier selected by the DNS resolver to generate the digest of itscertificate.</t> <t>Certificatecertificate.</dd> <dt>Certificate Digest(variable) - This field includes(variable):</dt><dd>Includes the Subject Public Key Info (SPKI) hash (<xreftarget="hash"></xref>)target="hash" format="default"/>) of the encrypted DNS resolver certificate using the algorithm identified in the'Hash"Hash AlgorithmIdentifier'Identifier" field. The length of this field is "Length–- 4–- 'ADNLength'".</t> </list></t>Length'".</dd> </dl> <t>The ENCDNS_DIGEST_INFO attribute may be present in the Configuration payload of CFG_ACK. In such a case, the ENCDNS_DIGEST_INFOMUST<bcp14>MUST</bcp14> be returned with zero-length data.</t> <t>As discussed in <xref section="3.15.1"target="RFC7296"></xref>,target="RFC7296" format="default"/>, 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.</t> </section> </section> <section anchor="protocol"title="IKEv2numbered="true" toc="default"> <name>IKEv2 ProtocolExchange">Exchange</name> <t>This section describes how the attributes defined in <xreftarget="RI"></xref>target="RI" format="default"/> 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 perSection 2.21 of<xreftarget="RFC7296"></xref>.</t>section="2.21" target="RFC7296" format="default"/>.</t> <t>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:</t><t><list style="empty"> <t>If<ul spacing="normal"> <li>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 theLength"Length" field to 0 for the attribute. For a given attribute type, the initiatorMAY<bcp14>MAY</bcp14> send either an empty attribute or a list of distinct suggested resolvers. The initiatorMAY<bcp14>MAY</bcp14> also include the ENCDNS_DIGEST_INFO attribute with a list of hash algorithms that are supported by the encrypted DNSclient.</t> <t>Ifclient.</li> <li>If the request includes multiple bitwise identical attributes, only the first occurrence is processed, and the restSHOULD<bcp14>SHOULD</bcp14> be ignored by the responder. The responderMAY<bcp14>MAY</bcp14> discard the full request if the count of repeated attributes exceeds an(implementation specific) threshold.</t> <t>For(implementation-specific) threshold.</li> <li>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*attribute(s)attributes in the CFG_REPLY with an appropriate list of IP addresses, service parameters, and an ADN. The list of IP addressesMUST<bcp14>MUST</bcp14> include at least one IP address. The service parametersSHOULD<bcp14>SHOULD</bcp14> include at least the "alpn" service parameter. The "alpn" service parameter may not be required in contexts such as a variant of DNS overCoAPthe Constrained Application Protocol (CoAP) where the messages are encrypted using Object Security for Constrained RESTful Environments (OSCORE) <xreftarget="RFC8613"></xref>.</t> <t>Thetarget="RFC8613" format="default"/>.</li> <li>The responderMAY<bcp14>MAY</bcp14> ignore suggested values from the initiator (if any). Multiple instances of the same ENCDNS_IP* attributeMAY<bcp14>MAY</bcp14> 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 instancesMUST<bcp14>MUST</bcp14> be presented to a local DNS client following their service priority (i.e., a smaller service priorityvaluesvalue indicates a higherpreference).</t> <t>Inpreference).</li> <li>In addition, the responderMAY<bcp14>MAY</bcp14> 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 thedigest.</t> <t>Ifdigest.</li> <li>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 resolveraddresses.</t> <t>Ifaddresses.</li> <li>If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the initiatorusesuse the encrypted DNSresolvers.</t> </list></t>resolvers.</li> </ul> <t>The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, or DoQ) with theaddress(es)address or addresses conveyed in ENCDNS_IP* and uses themechanismmechanisms discussed inSection 8 of<xreftarget="RFC8310"></xref>section="8" target="RFC8310" format="default"/> to authenticate the DNS resolver certificate using theauthentication domain nameADN conveyed in ENCDNS_IP*.</t> <t>If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the client has to create an SPKI hash (<xreftarget="hash"></xref>)target="hash" format="default"/>) 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 theonedigest 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 clientMUST<bcp14>MUST</bcp14> 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 <xreftarget="RFC7671"></xref>target="RFC7671" format="default"/>, but without PKIX validation.</t> <t>If the IPsec connection is a split-tunnel configuration and the initiator negotiated INTERNAL_DNS_DOMAIN as per <xreftarget="RFC8598"></xref>,target="RFC8598" format="default"/>, the DNS client resolves the internal names using ENCDNS_IP* DNS resolvers.</t><t><list style="empty"> <t>Note:<t indent="3">Note: <xreftarget="RFC8598"></xref>target="RFC8598" format="default"/> requires that the INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributetobemandatorypresent 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,it is allowed forresponders are allowed to include INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes.</t></list></t></section> <section anchor="hash"title="Subjectnumbered="true" toc="default"> <name>Subject Public Key Info (SPKI)Hash">Hash</name> <t>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.</t> <t>ImplementationsMUST<bcp14>MUST</bcp14> support SHA2-256 <xreftarget="RFC6234"></xref>.</t>target="RFC6234" format="default"/>.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document adheres to the security considerations defined in <xreftarget="RFC7296"></xref>.target="RFC7296" format="default"/>. In particular, this document does not alter the trust that the initiator has placed on the DNS configuration provided by a responder.</t> <t>Networks are susceptible to internal attacks as discussed in <xref section="3.2"target="I-D.arkko-farrell-arch-model-t"></xref>.target="I-D.arkko-farrell-arch-model-t" format="default"/>. 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 mechanismto restrictfor restricting access to the DNS messages to only the parties that need to know.</t> <t>If the IKEv2 responder has used the NULL Authentication method <xreftarget="RFC7619"></xref>target="RFC7619" format="default"/> to authenticate itself, the initiatorMUST NOT<bcp14>MUST NOT</bcp14> use returned ENCDNS_IP* resolvers configuration unlessitthe initiator ispre-configured,preconfigured, e.g., in the operating system or the application.</t> <t>This specification does not extend the scope of accepting DNSSEC trust anchors beyond the usage guidelines defined in <xref section="6"target="RFC8598"></xref>.</t>target="RFC8598" format="default"/>.</t> </section> <sectiontitle="Privacy Considerations">numbered="true" toc="default"> <name>Privacy Considerations</name> <t>As discussed in <xreftarget="RFC9076"></xref>,target="RFC9076" format="default"/>, the use of encrypted DNS does not reduce the data available in the DNS resolver. For example, the reader may refer to <xref section="8"target="RFC8484"></xref>target="RFC8484" format="default"/> or <xref section="7"target="RFC9250"></xref>target="RFC9250" format="default"/> for a discussion on specific privacy considerationstofor encrypted DNS.</t> </section> <section anchor="IANA1"title="IANA Considerations"> <t>This document requests IANA to assignnumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has assigned the following new IKEv2 Configuration Payload Attribute Typesfromin the "IKEv2 Configuration Payload Attribute Types" namespace available at <xreftarget="IANA-IKE-CFG"></xref>.</t> <t><figure> <artwork><![CDATA[ Multi- Value Attribute Type Valued Length Reference ------ ------------------ ----- --------- --------- TBA1 ENCDNS_IP4 YES 0target="IANA-IKE-CFG" format="default"/>.</t> <table anchor="tab-1"> <thead> <tr> <th>Value</th> <th>Attribute Type</th> <th>Multivalued</th> <th>Length</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>27</td> <td>ENCDNS_IP4</td> <td>YES</td> <td>0 ormore RFC XXXX TBA2 ENCDNS_IP6 YES 0more</td> <td>RFC 9464</td> </tr> <tr> <td>28</td> <td>ENCDNS_IP6</td> <td>YES</td> <td>0 ormore RFC XXXX TBA3 ENCDNS_DIGEST_INFO YES 0more</td> <td>RFC 9464</td> </tr> <tr> <td>29</td> <td>ENCDNS_DIGEST_INFO</td> <td>YES</td> <td>0 ormore RFC XXXX ]]></artwork> </figure></t> </section> <section title="Acknowledgements"> <t>Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy Pauly for the review and comments.</t> <t>Yoav and Paul 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.</t> <t>Thanks to Tero Kivinen for the Shepherd review and Roman Danyliw for the AD review.</t> <t>Thanks to Stewart Bryant for the gen-art review, Dhruv Dhody for the ops-dir review, and Patrick Mevzek for the dns-dir review.</t> <t>Thanks to Paul Wouters, Zaheduzzaman Sarker, Eric Vyncke, and Robert Wilton for the comments during the IESG review.</t>more</td> <td>RFC 9464</td> </tr> </tbody> </table> </section> </middle> <back> <displayreference target="I-D.arkko-farrell-arch-model-t" to="INTERNET-THREAT-MODEL"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/> <!--*****BACK MATTER *****draft-ietf-dnsop-svcb-https (RFC 9460) --><back> <references title="Normative References"> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.8174'?> <?rfc include='reference.RFC.7296'?> <?rfc include='reference.RFC.8310'?> <?rfc include='reference.RFC.5890'?> <?rfc include='reference.RFC.6234'?> <?rfc include='reference.I-D.ietf-dnsop-svcb-https'?> <?rfc include='reference.RFC.8598'?><reference anchor='RFC9460' target='https://www.rfc-editor.org/info/rfc9460'> <front> <title>Service Binding and Parameter Specification via the DNS (DNS SVCB and HTTPS Resource Records)</title> <author initials='B' surname='Schwartz' fullname='Benjamin Schwartz'> <organization /> </author> <author initials='M' surname='Bishop' fullname='Mike Bishop'> <organization /> </author> <author initials='E' surname='Nygren' fullname='Erik Nygren'> <organization /> </author> <date year='2023' month='November' /> </front> <seriesInfo name="RFC" value="9460"/> <seriesInfo name="DOI" value="10.17487/RFC9460"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8598.xml"/> <reference anchor="IANA-IKE-HASH"target="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#hash-algorithms">target="https://www.iana.org/assignments/ikev2-parameters/"> <front> <title>IKEv2 Hash Algorithms</title> <author><organization></organization><organization>IANA</organization> </author><date /><date/> </front> </reference> </references><references title="Informative References"> <?rfc include='reference.RFC.8499'?> <?rfc include='reference.RFC.7858'?> <?rfc include='reference.RFC.9250'?> <?rfc include='reference.RFC.8484'?> <?rfc include='reference.RFC.7619'?> <?rfc include='reference.RFC.7671'?> <?rfc include='reference.RFC.9076'?> <?rfc include='reference.RFC.8613'?> <?rfc include='reference.I-D.ietf-add-dnr'?> <?rfc include='reference.I-D.arkko-farrell-arch-model-t'?><references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7619.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7671.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9076.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/> <!-- draft-ietf-add-dnr (RFC 9463) --> <reference anchor='RFC9463' target='https://www.rfc-editor.org/info/rfc9463'> <front> <title> DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) </title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" role="editor"> <organization>Orange</organization> </author> <author initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K" role="editor"> <organization>Nokia</organization> </author> <author initials="D." surname="Wing" fullname="Dan Wing"> <organization>Cloud Software Group</organization> </author> <author initials="N." surname="Cook" fullname="Neil Cook"> <organization>Open-Xchange</organization> </author> <author initials="T." surname="Jensen" fullname="Tommy Jensen"> <organization>Microsoft</organization> </author> <date month="November" year="2023"/> </front> <seriesInfo name="RFC" value="9463"/> <seriesInfo name="DOI" value="10.17487/RFC9463"/> </reference> <!-- draft-arkko-farrell-arch-model-t (Expired) Had to add "draft-" and "-04" per Robert Sparks in order to get the link to work --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-arkko-farrell-arch-model-t-04.xml"/> <reference anchor="IANA-IKE-CFG"target="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21">target="https://www.iana.org/assignments/ikev2-parameters/"> <front> <title>IKEv2 Configuration Payload Attribute Types</title> <author><organization></organization><organization>IANA</organization> </author><date /><date/> </front> </reference> </references> </references> <sectiontitle="Configurationnumbered="true" toc="default"> <name>Configuration PayloadExamples"> <t></t>Examples</name> <sectiontitle="Configurationnumbered="true" toc="default"> <name>Configuration of Encrypted IPv6 DNS Resolvers without SuggestedValues">Values</name> <t><xreftarget="ex1"></xref>target="ex1" format="default"/> 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 <xreftarget="IANA-IKE-HASH"></xref>.target="IANA-IKE-HASH" format="default"/>. The use of INTERNAL_IP6_ADDRESS is explained in <xreftarget="RFC7296"></xref>; it istarget="RFC7296" format="default"/> and thus is not reiterated here.</t><t><figure anchor="ex1" title="Example<figure anchor="ex1"> <name>Example ofCFG_REQUEST"> <artwork><![CDATA[CP(CFG_REQUEST)a CFG_REQUEST</name> <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6() ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384,SHA2-512))]]></artwork> </figure></t>SHA2-512)) ]]></artwork> </figure> <t><xreftarget="ex2"></xref>target="ex2" format="default"/> 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:</t><t><list style="symbols"> <t>Its Service Priority<ul spacing="normal"> <li>Its service priority, which is1</t> <t>Its1.</li> <li>Its single (1) IPv6 address(2001:db8:99:88:77:66:55:44)</t> <t>Its authentication domain name(2001:db8:99:88:77:66:55:44).</li> <li>Its ADN (doh.example.com). This ADN has a length of15.</t> <t>Its15.</li> <li>Its supported HTTP version(h2)</t> <t>The(h2).</li> <li>The relative form of the URI Template(/dns-query{?dns})</t> <t>The(/dns-query{?dns}).</li> <li>The SPKI hash of the resolver's certificate using SHA2-256(8b6e7a5971cc6bb0b4db5a71...)</t> </list><figure anchor="ex2" title="Example(8b6e7a5971cc6bb0b4db5a71...).</li> </ul> <figure anchor="ex2"> <name>Example ofCFG_REPLY"> <artwork><![CDATA[CP(CFG_REPLY)a CFG_REPLY</name> <artwork name="" type="" align="left" alt=""><![CDATA[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...) ]]></artwork></figure></t></figure> <t>In the example depicted in <xreftarget="ex2"></xref>,target="ex2" format="default"/>, no ADN is included in the ENCDNS_DIGEST_INFO attribute because only one ADN is provided in the ENCDNS_IP6 attribute.There is no ambiguity to identifyIdentifying the encrypted resolver associated with the supplieddigest.</t>digest is therefore unambiguous.</t> </section> <sectiontitle="Configurationnumbered="true" toc="default"> <name>Configuration of Encrypted IPv6 DNS Resolvers with SuggestedValues">Values</name> <t>An initiator may provide suggested values in the CFG_REQUEST when requesting an encrypted DNS resolver. For example, the initiator may:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Indicate a preferred resolver that is identified by an IPv6 address (see <xreftarget="ex3"></xref>).<figure anchor="ex3" title="Exampletarget="ex3" format="default"/>).</t> <figure anchor="ex3"> <name>Example of a CFG_REQUEST with a Preferred Resolver Identified by Its IPAddress"> <artwork><![CDATA[CP(CFG_REQUEST)Address</name> <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 1, 0, (2001:db8:99:88:77:66:55:44)) ]]></artwork></figure></t></figure> </li> <li> <t>Indicate a preferred resolver that is identified by an ADN (see <xreftarget="ex4"></xref>).<figure anchor="ex4" title="Exampletarget="ex4" format="default"/>).</t> <figure anchor="ex4"> <name>Example of a CFG_REQUEST with a Preferred Resolver Identified by ItsADN"> <artwork><![CDATA[CP(CFG_REQUEST)ADN</name> <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 0, 15, "doh.example.com") ]]></artwork></figure></t></figure> </li> <li> <t>Indicate a preferred transport protocol (DoT, in the example depicted in <xreftarget="ex5"></xref>)<figure anchor="ex5" title="Exampletarget="ex5" format="default"/>).</t> <figure anchor="ex5"> <name>Example of a CFG_REQUEST with a Preferred TransportProtocol"> <artwork><![CDATA[CP(CFG_REQUEST)Protocol</name> <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 0, 0, (alpn=dot)) ]]></artwork></figure></t> <t>or</figure> </li> <li>or any combinationthereof.</t> </list></t>thereof.</li> </ul> </section> <sectiontitle="Split DNS">numbered="true" toc="default"> <name>Split DNS</name> <t>An initiator may also indicate that it supports Split DNS by including the INTERNAL_DNS_DOMAIN attribute in a CFG_REQUEST as shown in <xreftarget="ex6"></xref>.target="ex6" format="default"/>. In this example, the initiator does not indicate any preference for the requested encrypted DNSserverserver, nor does it indicate which DNS queries will be forwarded through the IPsec tunnel.</t><t><figure anchor="ex6" title="Example<figure anchor="ex6"> <name>Example of a CFG_REQUEST with Supportoffor SplitDNS"> <artwork><![CDATA[CP(CFG_REQUEST)DNS</name> <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6() INTERNAL_DNS_DOMAIN() ]]></artwork></figure></t></figure> <t><xreftarget="ex7"></xref>target="ex7" format="default"/> shows an example ofa reply oftheresponder.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.</t><t><figure anchor="ex7" title="Example<figure anchor="ex7"> <name>Example of a CFG_REPLY withINTERNAL_DNS_DOMAIN"> <artwork><![CDATA[CP(CFG_REPLY)INTERNAL_DNS_DOMAIN</name> <artwork name="" type="" align="left" alt=""><![CDATA[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) ]]></artwork></figure></t> <t></t></figure> </section> </section> <section numbered="false" toc="default"> <name>Acknowledgments</name> <t>Many thanks to <contact fullname="Yoav Nir"/>, <contact fullname="Christian Jacquenet"/>, <contact fullname="Paul Wouters"/>, and <contact fullname="Tommy Pauly"/> for their reviews and comments.</t> <t><contact fullname="Yoav"/> and <contact fullname="Paul"/> 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.</t> <t>Thanks to <contact fullname="Tero Kivinen"/> for the Shepherd review and <contact fullname="Roman Danyliw"/> for the AD review.</t> <t>Thanks to <contact fullname="Stewart Bryant"/> for the gen-art review, <contact fullname="Dhruv Dhody"/> for the ops-dir review, and <contact fullname="Patrick Mevzek"/> for the dns-dir review.</t> <t>Thanks to <contact fullname="Paul Wouters"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/> for their comments during the IESG review.</t> </section> </back> </rfc>