RFC 9464
Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS
RFC 9464: IKEv2 Configuration for Encrypted DNS 🎀
okay bestie, let's get into this one. it's an RFC (a standards doc, the stuff that tells every device how to talk to the internet) called Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS. ✨ It's giving VPN glow-up energy. 💅
Here's the vibe: 🌸
- Category: Standards Track 👑 (the official, real-deal kind of RFC)
- Date: November 2023 🍓
- Status: an IETF Standards Track document, approved by the IESG and reviewed by the whole community 🫶
- Authors: M. Boucadair (Orange), T. Reddy.K (Nokia), D. Wing (Cloud Software Group), and V. Smyslov (ELVIS-PLUS) 💜
- Obsoletes / Updates: the title block doesn't list either, so this doc isn't replacing or patching anything else. 🦋
Abstract ✨
okay so this doc is all about giving VPN clients a list of encrypted DNS resolvers 🔐. it defines new IKEv2 Configuration Payload Attribute Types so a VPN server can hand over resolvers that speak DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ). 💖
Status of This Memo 📜
this is an Internet Standards Track document 🎀. it's a product of the IETF and it represents the consensus of the IETF community. it got public review and was approved by the IESG. 💅 if you want more on Internet Standards, check out Section 2 of RFC 7841 ⭐.
current status, errata, and feedback info lives at https://www.rfc-editor.org/info/rfc9464 🌈.
Copyright Notice ©️
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. go read them, they explain your rights, fr fr. 🧚 Code Components pulled out of this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License. 🙈
Table of Contents 🗺️
1. Introduction
2. Terminology
3. IKEv2 Configuration Payload Attribute Types for Encrypted DNS
3.1. ENCDNS_IP* Configuration Payload Attributes
3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute
4. IKEv2 Protocol Exchange
5. Subject Public Key Info (SPKI) Hash
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Configuration Payload Examples
A.1. Configuration of Encrypted IPv6 DNS Resolvers without
Suggested Values
A.2. Configuration of Encrypted IPv6 DNS Resolvers with
Suggested Values
A.3. Split DNS
Acknowledgments
Authors' Addresses1. Introduction 🌷
okay so this doc is a mechanism for handing encrypted DNS configs to an IKEv2 initiator [RFC7296] 🦋. specifically, it assigns one or more Authentication Domain Names (ADNs) of DNS resolvers that support encrypted DNS protocols. the protocols get described using the Service Parameters format from [RFC9460] 💅, and the supported ones include DoH [RFC8484], DoT [RFC7858], and DoQ [RFC9250]. 🫶
this doc adds three new IKEv2 Configuration Payload Attribute Types (Section 3) for encrypted DNS resolvers ✨. ENCDNS_IP4 and ENCDNS_IP6 (Section 3.1) are used to provision ADNs, a list of IP addresses, and a set of service parameters 💜. ENCDNS_DIGEST_INFO (Section 3.2) lets the IKEv2 responder additionally point at one specific resolver certificate 🔐.
an encrypted DNS resolver run by a VPN provider can grab a domain-validated certificate from a public Certificate Authority (CA) 🌈. the VPN client doesn't need the root certificate of a private CA to check the resolver's cert, which is so convenient 😭. the resolver can also run on private IP addresses, with access limited to clients connected to the VPN 🧚.
ngl, the old mental model was that the DNS resolver lives inside the protected domain, and designs usually didn't account for it being outside 🙈. with encrypted DNS, that outside scenario becomes realistic 🍓. heads up: existing VPN client implementations might not expect the discovered DNS resolver IP addresses to sit outside the covered IP address ranges of the VPN tunnel ⚠️.
⚠️ bestie, that last bit is a warning: a client might not be ready for resolver addresses that fall outside the tunnel's covered ranges.
2. Terminology 📚
okay this part is the key-words bit 🎀. the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" get read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like that 💖.
this doc also uses the terms from [RFC8499] 🦋, and the terms from [RFC7296] too 👑. especially "initiator" and "responder", so go get familiar with those 🧚.
here are a few more terms this doc uses 🌸:
- Do53: just unencrypted DNS 🙈.
- Encrypted DNS: DNS messages sent over an encrypted channel. Examples are DoT, DoH, and DoQ 🔐.
- ENCDNS_IP*: any of the IKEv2 Configuration Payload Attribute Types defined in Section 3.1 💅.
3. IKEv2 Configuration Payload Attribute Types for Encrypted DNS 🎀
3.1. ENCDNS_IP* Configuration Payload Attributes ✨
ENCDNS_IP4 and ENCDNS_IP6 are the ENCDNS_IP* attribute types, used to configure an initiator with encrypted DNS resolvers 💜. both share the format in Figure 1, and the info in them follows the recommendation in Section 3.1.9 of [RFC9463] 🫶.
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) ~
+---------------------------------------------------------------+
Figure 1: Format of ENCDNS_IP4 and ENCDNS_IP6 Configuration
Attributeshere's what each field in Figure 1 means 🌈:
- R (Reserved, 1 bit): this bit MUST be set to zero and MUST be ignored on receipt (see Section 3.15.1 of [RFC7296] for details) 🙈.
- Attribute Type (15 bits): the identifier for the Configuration Attribute Type. it's set to 27 for ENCDNS_IP4 or 28 for ENCDNS_IP6, as registered in Section 8 🦋.
- Length (2 octets, unsigned integer): the length of the enclosed data in octets 📏. specifically, it's set to:
- 0, if the Configuration payload has type (1) CFG_REQUEST and no specific DNS resolver is requested, or type (2) CFG_ACK. if "Length" is 0, the fields after it in Figure 1 aren't 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 read following the rules in Section 2.4.1 of [RFC9460]. AliasMode (Section 2.4.2 of [RFC9460]) isn't supported, so this field MUST NOT be set to 0 🚫. the reason: AliasMode would trigger extra Do53 queries when the data could just come straight over in the IKE response 🙈.
- Num Addresses (1 octet): 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 🫶. it MAY be set to 0 in CFG_REQUEST, to say that no IP address is encoded in the attribute 🧚.
- ADN Length (1 octet): the length of the "Authentication Domain Name" field in octets 📏. when it's 0, no ADN is enclosed in the attribute 🦋.
- IP Address(es) (variable): one or more IP addresses that can be used to reach the encrypted DNS resolver identified by the ADN 🌈. for ENCDNS_IP4 this field holds one or more 4-octet IPv4 addresses, and for ENCDNS_IP6 it holds 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, using an Internationalized Domain Names for Applications (IDNA) A-label [RFC5890] ✨. 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): a set of service parameters, encoded with the same SvcParams rules using the wire format in Section 2.2 of [RFC9460] 💅. Section 3.1.5 of [RFC9463] lists service parameters that implementations are recommended to support 👑.
the service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, since the included IP addresses supersede them 🙅.
if no "port" service parameter is included, default port numbers should be used 🔌. quick reminder, the default ports are 853 for DoT (Section 6 of [RFC7858]), 443 for DoH (Section 8.1 of [RFC8484]), and 853 for DoQ (Section 8 of [RFC9250]) 🎀.
the service parameters apply to all IP addresses in the ENCDNS_IP* Configuration Payload Attribute 🌟.
Part 1 of 4. More parts coming, so keep your eyes peeled! 🦋
3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute 🔐✨
Okay bestie, this one is the certificate fingerprint attribute 🦋. The responder uses it to hand the initiator a digest of the encrypted resolver's certificate, so the client can double-check the TLS connection is legit. The initiator can also use it to ask for specific hash algorithms for those digests, kinda like picking your flavour at the smoothie bar 🍓💅
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 ~
+---------------------------------------------------------------+
Figure 2: ENCDNS_DIGEST_INFO Attribute FormatSome of the fields in Figure 2 can be omitted, as explained below 🙈
The format of the ENCDNS_DIGEST_INFO attribute when the Configuration payload has type CFG_REQUEST is shown in Figure 3 🌸
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 ~
+---------------------------------------------------------------+
Figure 3: ENCDNS_DIGEST_INFO Attribute Format in CFG_REQUESTHere's what the fields in Figure 3 mean 👀
R (Reserved, 1 bit): This bit MUST be set to zero and MUST be ignored on receipt (see Section 3.15.1 of [RFC7296] for details).
Attribute Type (15 bits): Identifier for the Configuration Attribute Type. This is set to 29; see Section 8.
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 [IANA-IKE-HASH] 📋
There is no padding between the hash algorithm identifiers.
Note that SHA2-256 is mandatory to implement (see Section 5). Main character hash, no cap 👑
The format of the ENCDNS_DIGEST_INFO attribute when the Configuration payload has type CFG_REPLY or CFG_SET is shown in Figure 4 ✨
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 ~
+---------------------------------------------------------------+
Figure 4: ENCDNS_DIGEST_INFO Attribute Format in CFG_REPLY or CFG_SETAnd the fields in Figure 4 🎀
R (Reserved, 1 bit): This bit MUST be set to zero and MUST be ignored on receipt (see Section 3.15.1 of [RFC7296] for details).
Attribute Type (15 bits): Identifier for the Configuration Attribute Type. This is set to 29; see Section 8.
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 to 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 [RFC5890]. 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 (Section 5) 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 Section 3.15.1 of [RFC7296], 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. Lowkey a bit of a plot twist, but it's all covered 🧚
4. IKEv2 Protocol Exchange 🦋
This section explains how the attributes defined in Section 3 are used to configure an IKEv2 initiator with one or more encrypted DNS resolvers. Quick reminder: badly formatted attributes or unacceptable fields are handled as per Section 2.21 of [RFC7296] 🫶
Initiators first show they support encrypted DNS by including ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders provide encrypted DNS configuration by including ENCDNS_IP* attributes in their CFG_REPLY payloads. Here's the breakdown 💅
- 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. Spam is not the vibe 🙅♀️
- 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) [RFC8613] 🌈
- 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 sets up 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 Section 8 of [RFC8310] to authenticate the DNS resolver certificate using the ADN conveyed in ENCDNS_IP*. Certificate check, bestie 🔐
If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the client has to create an SPKI hash (Section 5) 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 [RFC7671], but without PKIX validation. No recovery from a bad cert, sorry not sorry 💀
If the IPsec connection is a split-tunnel configuration and the initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS client resolves the internal names using ENCDNS_IP* DNS resolvers. 🧭
Note: [RFC8598] 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. 🎀
5. 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 [RFC6234]. Non-negotiable, periodt 🌈👑
6. Security Considerations 🔒
Okay bestie, this section is the serious one 🫶 It follows the security rules from [RFC7296], and the big thing is that this doc doesn't change how much the initiator trusts the DNS config a responder hands over. Trust stays exactly where it was ✨
Networks can get hit by internal attacks, which is covered in Section 3.2 of [INT-THREAT-MOD] 😭 Running encrypted DNS resolvers can shrink that attack surface, even with split-VPN setups. For example, a compromised network device can't watch or change your DNS traffic 👀 This spec also gives you a way to limit who gets to see the DNS messages, so only the parties that actually need them can read them 🔐
🚨 Heads up: if the IKEv2 responder authenticated itself with the NULL Authentication method [RFC7619], the initiator MUST NOT use the returned ENCDNS_IP* resolver config unless the initiator is preconfigured (for example, in the operating system or the application). Don't skip this one, it's giving "do not get tricked" energy 💀
This spec doesn't stretch how DNSSEC trust anchors get accepted past the usage guidelines in Section 6 of [RFC8598] 🧐 Those limits stay put, no exceptions 💅
7. Privacy Considerations 🦋
Here's the tea 🍵 As [RFC9076] explains, using encrypted DNS doesn't reduce the amount of data the DNS resolver can see 👀 So encryption protects the wire, but the resolver still gets the queries. If you want the deeper privacy details for encrypted DNS, check out Section 8 of [RFC8484] or Section 7 of [RFC9250] ✨
8. IANA Considerations 🌸
IANA has assigned the following new IKEv2 Configuration Payload Attribute Types. They live in the "IKEv2 Configuration Payload Attribute Types" namespace, which you can find at [IANA-IKE-CFG] 🎀
+=======+====================+=============+===========+===========+
| 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 |
+-------+--------------------+-------------+-----------+-----------+
Table 19. References 📚
Here's the full reading list, with every reference kept exactly as written so nothing gets lost in translation 🧚
9.1. Normative References
[IANA-IKE-HASH]
IANA, "IKEv2 Hash Algorithms",
<https://www.iana.org/assignments/ikev2-parameters/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.9.2. Informative References
[IANA-IKE-CFG]
IANA, "IKEv2 Configuration Payload Attribute Types",
<https://www.iana.org/assignments/ikev2-parameters/>.
[INT-THREAT-MOD]
Arkko, J. and S. Farrell, "Challenges and Changes in the
Internet Threat Model", Work in Progress, Internet-Draft,
draft-arkko-farrell-arch-model-t-04, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-arkko-
farrell-arch-model-t-04>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<https://www.rfc-editor.org/info/rfc7619>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
DOI 10.17487/RFC9076, July 2021,
<https://www.rfc-editor.org/info/rfc9076>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>.Appendix A. Configuration Payload Examples 🧚
Now for the fun part, the examples 🎀 Each one shows real payloads you can picture sending back and forth.
A.1. Configuration of Encrypted IPv6 DNS Resolvers without Suggested Values
Figure 5 shows a CFG_REQUEST asking for IPv6 DNS resolvers without giving any suggested values 💖 Here the initiator uses the ENCDNS_DIGEST_INFO attribute to say its encrypted DNS client supports the SHA2-256 (2), SHA2-384 (3), and SHA2-512 (4) hash algorithms for certificate digests ✨ The labels for those algorithms come from [IANA-IKE-HASH]. The INTERNAL_IP6_ADDRESS part is explained in [RFC7296], so I won't repeat it here 🫶
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6()
ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
Figure 5: Example of a CFG_REQUESTFigure 6 is a CFG_REPLY the responder can send back for that CFG_REQUEST 🌈 It tells the initiator the following about 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...).
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...)
Figure 6: Example of a CFG_REPLYIn the Figure 6 example, the ENCDNS_DIGEST_INFO attribute doesn't include an ADN, because only one ADN shows up in the ENCDNS_IP6 attribute 🧠 That means it's totally clear which encrypted resolver the supplied digest belongs to 💅
A.2. Configuration of Encrypted IPv6 DNS Resolvers with Suggested Values
An initiator can include suggested values in the CFG_REQUEST when it asks for an encrypted DNS resolver 💜 For example, the initiator can:
- Indicate a preferred resolver that is identified by an IPv6 address (see Figure 7).
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 1, 0,
(2001:db8:99:88:77:66:55:44))
Figure 7: Example of a CFG_REQUEST with a Preferred Resolver
Identified by Its IP Address- Indicate a preferred resolver that is identified by an ADN (see Figure 8).
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 0, 15, "doh.example.com")
Figure 8: Example of a CFG_REQUEST with a Preferred Resolver
Identified by Its ADN- Indicate a preferred transport protocol (DoT, in the example depicted in Figure 9).
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 0, 0, (alpn=dot))
Figure 9: Example of a CFG_REQUEST with a Preferred Transport
Protocol- or any combination thereof.
A.3. Split DNS
An initiator can also say it supports Split DNS by putting the INTERNAL_DNS_DOMAIN attribute in a CFG_REQUEST, as shown in Figure 10 🦋 In this example, the initiator doesn't pick a preferred encrypted DNS server, and it also doesn't say which DNS queries should go through the IPsec tunnel.
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6()
INTERNAL_DNS_DOMAIN()
Figure 10: Example of a CFG_REQUEST with Support for Split DNSFigure 11 shows the responder's reply 🌸 Unless local policy prohibits it, the initiator uses the encrypted DNS server (doh.example.com) for any later DNS queries for "example.com" and its subdomains 👑
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)
Figure 11: Example of a CFG_REPLY with INTERNAL_DNS_DOMAINOkay bestie, we're finishing strong! 🎀 Here's the last stretch of the document: the thank-yous, who wrote it, and where to find them. 🫶
Acknowledgments ✨
Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy Pauly for their reviews and comments. 💖
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. 🧚 Literally the reason the design is so clean, so iconic. 👑
Thanks to Tero Kivinen for the Shepherd review and Roman Danyliw for the AD review. 🌸
Thanks to Stewart Bryant for the gen-art review, Dhruv Dhody for the ops-dir review, and Patrick Mevzek for the dns-dir review. 🦋
Thanks to Paul Wouters, Zaheduzzaman Sarker, Éric Vyncke, and Robert Wilton for their comments during the IESG review. 💜 So many smart people touched this, it's giving team project energy. 🫶
Authors' Addresses ✨
- Mohamed Boucadair Orange 35000 Rennes France Email: mohamed.boucadair@orange.com 💌
- Tirumaleswar Reddy.K Nokia India Email: kondtir@gmail.com 🍓
- Dan Wing Cloud Software Group Holdings, Inc. United States of America Email: dwing-ietf@fuggles.com 🌈
- Valery Smyslov ELVIS-PLUS Russian Federation Email: svan@elvis.ru ⭐
And that's the whole RFC, babe! 🥹 Four authors, a whole crew of reviewers, and one very serious spec for encrypted DNS in IKEv2 that the internet is lowkey relying on. 💅🔥
📦 where this page comes from
- ietf: rfc9464 2023-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms