RFC 8598

Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)

📅 published May 2019, from ietf

Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) 🎀

okay bestie, this is RFC 8598 💅 It's a Standards Track doc, so it's the real deal, not a draft we're vibing with. It was written by T. Pauly (Apple Inc.) and P. Wouters (Red Hat), and it was published in May 2019. The ISSN is 2070-1721 if you ever wanna look it up 💜 The title block doesn't list anything it obsoletes or updates, so no drama there 🙈

Abstract 🌸

okay so this doc defines two Configuration Payload Attribute Types, INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA, for IKEv2 🦋 They basically add support for private, internal-only DNS domains. Those domains are meant to get resolved by non-public DNS servers that you can only reach through the IPsec connection ✨ DNS lookups for everything else stay exactly the same. And these payloads only apply to split-tunnel configurations, so they're super specific 😌

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚

Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc8598.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License 💜

Table of Contents 📜

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Protocol Exchange . . . . . . . . . . . . . . . . . . . . . .   5
  3.1.  Configuration Request . . . . . . . . . . . . . . . . . .   5
  3.2.  Configuration Reply . . . . . . . . . . . . . . . . . . .   6
  3.3.  Mapping DNS Servers to Domains  . . . . . . . . . . . . .   7
  3.4.  Example Exchanges . . . . . . . . . . . . . . . . . . . .   7
    3.4.1.  Simple Case . . . . . . . . . . . . . . . . . . . . .   7
    3.4.2.  Requesting Domains and DNSSEC Trust Anchors . . . . .   7
4.  Payload Formats . . . . . . . . . . . . . . . . . . . . . . .   9
  4.1.  INTERNAL_DNS_DOMAIN Configuration Attribute Type Request
        and Reply . . . . . . . . . . . . . . . . . . . . . . . .   9
  4.2.  INTERNAL_DNSSEC_TA Configuration Attribute  . . . . . . .   9
5.  INTERNAL_DNS_DOMAIN Usage Guidelines  . . . . . . . . . . . .  11
6.  INTERNAL_DNSSEC_TA Usage Guidelines . . . . . . . . . . . . .  12
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1. Introduction ✨

okay so split-tunnel VPN configurations only send packets with a specific destination IP range, usually picked from [RFC1918], through the VPN 🌸 All the other traffic just doesn't go through the VPN. This lets an enterprise offer remote access VPN services without having to accept and forward all the non-enterprise traffic its remote users make 🙌 Users can get to internal resources through the VPN, and everything else they do stays off it.

These internal resources usually only have internal-only DNS names, and they need special internal-only DNS servers to get resolved 🧚 Split DNS [RFC2775] is commonly set up as part of split-tunnel VPN configurations so remote users can use those special internal-only domain names.

The IKEv2 protocol [RFC7296] negotiates configuration parameters using Configuration Payload Attribute Types ✨ This document defines two of those types that add support for trusted Split DNS domains 💖

The INTERNAL_DNS_DOMAIN attribute type says that the specified DNS domain MUST be resolved using the DNS nameserver IP addresses given in the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS Configuration Payloads, which makes those requests use the IPsec connection 🔥

The INTERNAL_DNSSEC_TA attribute type carries a DNSSEC trust anchor for that kind of domain 🔐 It's required if the external view uses DNSSEC, since that would prove the internal view doesn't exist, or the internal and external versions of the enterprise domain might expect different DNSSEC keys 🙈

If the responder sends an INTERNAL_DNS_DOMAIN, the responder MUST also include one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attributes with the IPv4 or IPv6 address of the internal DNS server 👑

For this doc, DNS resolution servers you can reach through an IPsec connection are called "internal DNS servers," and every other DNS server is called "external DNS servers" 🦋

Other tunnel-establishment protocols already support assigning Split DNS domains. For example, there are proprietary extensions to IKEv1 that let a server assign Split DNS domains to a client 💅

But the IKEv2 standard doesn't have a way to configure this option yet 😭 This document defines a standard way to negotiate it for IKEv2, and that's the whole point 🫶

1.1. Requirements Language 🌈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀

2. Applicability 💜

okay so if the negotiated IPsec connection isn't a split-tunnel configuration, the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA Configuration Payloads MUST be ignored 🛑 This stops generic (non-enterprise) VPN services from overriding the public DNS hierarchy, which could lead to malicious overrides of DNS and DNSSEC 💀

Those configurations SHOULD use only the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS Configuration Payloads instead 🦋 That way all of the user's DNS traffic goes through the IPsec connection and doesn't leak unencrypted info onto the local network, because the local network is often explicitly exempted from IPsec encryption 🔒

For split-tunnel configurations, an enterprise can require one or more DNS domains to be resolved through internal DNS servers 🏢 That could be a special domain like "corp.example.com" for an enterprise that's publicly known to use "example.com" ✨ In that case the remote user has to be told what the internal-only domain names are and what the IP addresses of the internal DNS servers are 🧚 An enterprise can also run a different version of its public domain on its internal network 🌸 When that happens, the VPN client is told to send DNS queries for the enterprise public domain (e.g., "example.com") to the internal DNS servers. A configuration for this setup is called a Split DNS configuration 💖

Split DNS configurations are often better than sending all DNS queries to the enterprise 🙌 The remote user only sends DNS queries for the enterprise to the internal DNS servers, so the enterprise stays unaware of all the user's non-enterprise DNS activity 🫣 It also means the enterprise DNS servers only need to be set up for the enterprise DNS domains. That takes away the legal and technical responsibility of resolving every DNS domain the remote user might ask for 💅

A client using these Configuration Payloads can request and receive Split DNS configurations with the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes ✨ These attributes MUST be accompanied by one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS configuration attributes 🔥 After that, the client device can use the internal DNS server(s) for any DNS queries within the assigned domains 🎀 DNS queries for other domains SHOULD go to the client's regular DNS service, unless it prefers to use the IPsec tunnel for all its DNS queries 🌈 For example, the client might trust the IPsec-provided DNS servers more than the locally provided ones, especially when connecting to unknown or untrusted networks like coffee shops or hotel networks ☕ Or the client might prefer the IPsec-based DNS servers because they have extra features compared to the local DNS servers 🧚

3. Protocol Exchange 🦋

okay so to figure out which domains count as internal to an IKEv2 tunnel, initiators say they support Split DNS in their CFG_REQUEST payloads 💌 Then responders assign internal domains (and DNSSEC trust anchors) in their CFG_REPLY payloads 🫶 Once Split DNS has been negotiated, the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS DNS server configuration attributes get interpreted as internal DNS servers that can resolve hostnames within the internal domains 💜

3.1. Configuration Request 🎀

Okay so, to say "hey, I can do Split DNS!" the initiator tacks one or more INTERNAL_DNS_DOMAIN attributes onto its CFG_REQUEST payload (see Section 4 for the details). If an INTERNAL_DNS_DOMAIN attribute shows up in the CFG_REQUEST, the initiator MUST also include one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attributes in the CFG_REQUEST. No skipping that part, bestie. 💅

The INTERNAL_DNS_DOMAIN attribute from the initiator is usually empty, but it MAY contain a suggested domain name. 🌸

If the CFG_REQUEST has no INTERNAL_DNS_DOMAIN attributes at all, that's the initiator saying it either doesn't support Split DNS or isn't up for accepting that config. Not me... but totally valid. 🙈

Now for DNSSEC trust anchors! ✨ To say "I'd love DNSSEC trust anchors for my Split DNS domains," the initiator adds one or more INTERNAL_DNSSEC_TA attributes (again, see Section 4) to the CFG_REQUEST payload. If there's an INTERNAL_DNSSEC_TA attribute in there, the initiator MUST also include one or more INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. Now here's the plot twist: if the initiator sends an INTERNAL_DNSSEC_TA but forgets the INTERNAL_DNS_DOMAIN, the responder MAY still reply with both INTERNAL_DNSSEC_TA and INTERNAL_DNS_DOMAIN attributes. Responder being generous, iconic. 👑

An initiator MAY share its current DNSSEC trust anchors for the domain in its INTERNAL_DNS_DOMAIN attribute. This helps the responder figure out it doesn't need to send a different trust anchor. 🧠 And if the initiator doesn't want to share that info, it MUST use a length of 0. Simple as that. 🫶

If the CFG_REQUEST has no INTERNAL_DNSSEC_TA attributes, the initiator is basically saying it doesn't support or doesn't want the DNSSEC trust anchor config. Respect. 💀

3.2. Configuration Reply 💌

Responders MAY send one or more INTERNAL_DNS_DOMAIN attributes in their CFG_REPLY payload. 🦋 If one shows up in the CFG_REPLY, the responder MUST also include one or both of INTERNAL_IP4_DNS and INTERNAL_IP6_DNS in the CFG_REPLY. These DNS server configs are the whole point, because they tell the initiator which servers are allowed to get queries for hostnames in internal domains. 🔥

If the CFG_REQUEST had an INTERNAL_DNS_DOMAIN but the CFG_REPLY doesn't, the initiator MUST behave as if the server doesn't support Split DNS configurations. The one exception is if the initiator has been set up with local policy that defines a set of Split DNS domains to use by default. Ugh, the drama, but okay. 😭

Each INTERNAL_DNS_DOMAIN stands for a domain that the DNS servers listed in INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can resolve. Simple, clean, very slay. ✨

If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-zero lengths, the responder MAY ignore that content, or it can treat it as a suggestion. Its call, its vibe. 🌈

For each DNS domain in an INTERNAL_DNS_DOMAIN attribute, the responder MAY include one or more INTERNAL_DNSSEC_TA attributes. Each one carries the matching internal DNSSEC trust anchor info as a DS record (see [RFC4034]). The INTERNAL_DNSSEC_TA attribute MUST immediately follow the INTERNAL_DNS_DOMAIN attribute it belongs to. Order matters, bestie! 🍓

3.3. Mapping DNS Servers to Domains 🗺️

Every DNS server in the CFG_REPLY MUST be able to resolve hostnames within all of the INTERNAL_DNS_DOMAIN domains. In other words, the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload make up one big list of Split DNS domains, and that list applies to the whole group of INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes. Team effort, no one gets left out. 🫂

3.4. Example Exchanges 🧁

3.4.1. Simple Case 🍓

In this example, the initiator asks for INTERNAL_IP4_DNS, INTERNAL_IP6_DNS, and INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST, but doesn't give any value for any of them. That means it supports Split DNS but doesn't have a preference for which DNS requests go through the tunnel. Low-key chill. 🌙

The responder replies with two DNS server addresses and two internal domains, "example.com" and "city.other.test". 💖

Any later DNS queries from the initiator for domains like "www.example.com" SHOULD use 198.51.100.2 or 198.51.100.4 to resolve. 🔍

CP(CFG_REQUEST) =
  INTERNAL_IP4_ADDRESS()
  INTERNAL_IP4_DNS()
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
  INTERNAL_DNS_DOMAIN()

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_DNS(198.51.100.2)
  INTERNAL_IP4_DNS(198.51.100.4)
  INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
  INTERNAL_DNS_DOMAIN(example.com)
  INTERNAL_DNS_DOMAIN(city.other.test)

3.4.2. Requesting Domains and DNSSEC Trust Anchors 🔐

In this one, the initiator asks for INTERNAL_IP4_DNS, INTERNAL_IP6_DNS, INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA attributes in the CFG_REQUEST. Full send! 🚀

Later DNS queries for things like "www.example.com" or "city.other.test" would get DNSSEC validated using the DNSSEC trust anchor that came back in the CFG_REPLY. Secure and serene. 🛡️

Here the initiator has no DNSSEC trust anchors yet for the domains it asked for. The "example.com" domain has DNSSEC trust anchors that get sent back, but the "other.test" domain has none. Some have it, some don't, and that's okay. 🦄

CP(CFG_REQUEST) =
  INTERNAL_IP4_ADDRESS()
  INTERNAL_IP4_DNS()
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
  INTERNAL_DNS_DOMAIN()
  INTERNAL_DNSSEC_TA()

CP(CFG_REPLY) =
  INTERNAL_IP4_ADDRESS(198.51.100.234)
  INTERNAL_IP4_DNS(198.51.100.2)
  INTERNAL_IP4_DNS(198.51.100.4)
  INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
  INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
  INTERNAL_DNS_DOMAIN(example.com)
  INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)
  INTERNAL_DNSSEC_TA(31406,8,2,F78CF3344F72137235098ECBBD08947C...)
  INTERNAL_DNS_DOMAIN(city.other.test)

4. Payload Formats 📦

All multi-octet fields that represent integers are laid out in big-endian order. You might also hear this called "most significant byte first" or "network byte order." 🔢

4.1. INTERNAL_DNS_DOMAIN Configuration Attribute Type Request and Reply 🌐

                    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             |
+-+-----------------------------+-------------------------------+
|                                                               |
~             Domain Name in DNS presentation format            ~
|                                                               |
+---------------------------------------------------------------+
  • Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
  • Attribute Type (15 bits) - set to value 25 for INTERNAL_DNS_DOMAIN.
  • Length (2 octets) - Length of domain name.
  • Domain Name (0 or more octets) - A Fully Qualified Domain Name used for Split DNS rules, such as "example.com", in DNS presentation format and using an Internationalized Domain Names for Applications (IDNA) A-label [RFC5890]. Implementors need to be careful that this value is not null terminated. 🧐

4.2. INTERNAL_DNSSEC_TA Configuration Attribute 🔑

An INTERNAL_DNSSEC_TA Configuration Attribute can be empty, or it can hold one trust anchor by having a non-zero Length, along with DNSKEY Key Tag, DNSKEY Algorithm, Digest Type and Digest Data fields. ✨

An empty INTERNAL_DNSSEC_TA CFG attribute looks like this:

                    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 (set to 0)       |
+-+-----------------------------+-------------------------------+
  • Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
  • Attribute Type (15 bits) - set to value 26 for INTERNAL_DNSSEC_TA.
  • Length (2 octets) - Set to 0 for an empty attribute.

A non-empty INTERNAL_DNSSEC_TA CFG attribute looks like this:

                    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             |
+-+-----------------------------+---------------+---------------+
|        DNSKEY Key Tag         |  DNSKEY Alg   |  Digest Type  |
+-------------------------------+---------------+---------------+
|                                                               |
~                         Digest Data                           ~
|                                                               |
+---------------------------------------------------------------+
  • Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
  • Attribute Type (15 bits) - set to value 26 for INTERNAL_DNSSEC_TA.
  • Length (2 octets) - Length of DNSSEC trust anchor data (4 octets plus the length of the Digest Data).
  • DNSKEY Key Tag (2 octets) - Delegation Signer (DS) Key Tag as specified in Section 5.1 of [RFC4034].
  • DNSKEY Algorithm (1 octet) - DNSKEY algorithm value from the IANA DNS Security Algorithm Numbers Registry.
  • Digest Type (1 octet) - DS algorithm value from the IANA Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms Registry.
  • Digest Data (1 or more octets) - The DNSKEY digest as specified in Section 5.1 of [RFC4034] in presentation format.

Each INTERNAL_DNSSEC_TA attribute in the CFG_REPLY payload MUST immediately follow a matching INTERNAL_DNS_DOMAIN attribute. The INTERNAL_DNSSEC_TA format doesn't include the domain name, so it leans on the INTERNAL_DNS_DOMAIN right before it to say which domain the trust anchor is for. Any INTERNAL_DNSSEC_TA attribute that isn't immediately preceded by an INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute for the same domain name MUST be ignored. Gone, no notes. 🗑️

5. INTERNAL_DNS_DOMAIN Usage Guidelines 💅

okay so if a CFG_REPLY payload has zero INTERNAL_DNS_DOMAIN attributes, the client MAY use the INTERNAL_IP4_DNS or INTERNAL_IP6_DNS servers it got as the default DNS server(s) for all queries 💖

if a client's local policy says it only takes a limited set of INTERNAL_DNS_DOMAIN values, it MUST ignore any other INTERNAL_DNS_DOMAIN values 🙅‍♀️

for each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that local policy doesn't block, the client MUST use the INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only resolvers for the listed domains and their subdomains. it MUST NOT try to resolve those domains with its external DNS servers. other domain names SHOULD go to some other external DNS resolver(s) that are configured separately from IKE. queries for those other domains MAY be sent to the internal DNS resolver(s) from that CFG_REPLY message, but there's no guarantee they'll get answered 🥲

here's the example, bestie 🦋 if INTERNAL_DNS_DOMAIN is "example.test", then "example.test", "www.example.test", and "mail.eng.example.test" MUST be resolved using the internal DNS resolver(s). but "otherexample.test" and "ple.test" MUST NOT be resolved using the internal resolver, and they MUST use the system's external DNS resolver(s). the lookalike domains are NOT going inside the tunnel 🙈

the initiator SHOULD let the DNS domains listed in INTERNAL_DNS_DOMAIN attributes resolve to special IP address ranges, like the ones in [RFC1918], even if the initiator host is otherwise set up to block DNS answers containing those special ranges 🌸

when an IKE Security Association (SA) is terminated, DNS forwarding MUST be unconfigured. that means deleting the DNS forwarding rules 🧹 flushing all cached data for the DNS domains provided by INTERNAL_DNS_DOMAIN, including negative cache entries 🧹 removing any obtained DNSSEC trust anchors from the list of trust anchors 🧹 and clearing the outstanding DNS request queue 🧹 full clean-up, no leftovers ✨

INTERNAL_DNS_DOMAIN attributes SHOULD only be used on split-tunnel configurations, where only a subset of traffic gets routed into a private remote network over the IPsec connection. if all traffic goes over the IPsec connection, the existing global INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can be used without making any specific DNS or DNSSEC exemptions 🎀

6. INTERNAL_DNSSEC_TA Usage Guidelines 🔐

DNS records can be used to publish specific records holding trust anchors for applications. the most common one is the TLSA record from [RFC6698]. this record type publishes which Certification Authority (CA) certificate or End Entity (EE) certificate to expect for a certain host name. these records are protected by DNSSEC, so applications can actually trust them 🫶 whether to trust TLSA records instead of the traditional Web PKI depends on the client's local policy.

ngl this is where it gets spicy 🌶️ by accepting an INTERNAL_DNSSEC_TA trust anchor over IKE from the remote IKE server, the IPsec client might be letting that server override the trusted certificates for TLS 😬 similar override concerns apply to other public key or fingerprint-based DNS records, like OPENPGPKEY, SMIMEA, or IPSECKEY records.

so installing an INTERNAL_DNSSEC_TA trust anchor is basically the same as installing an Enterprise CA certificate 🏢 it lets the remote IKE/IPsec server modify DNS answers, including DNSSEC cryptographic signatures, by overriding existing DNS info with a trust anchor sent over IKE and (temporarily) installed on the IKE client. the big worry is overriding TLSA records from [RFC6698], which confirms or overrides an existing Web PKI TLS certificate. other DNS record types that carry cryptographic material (public keys or fingerprints) are OPENPGPKEY, SMIMEA, SSHP, and IPSECKEY records 💀

IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use a whitelist of one or more domains that can be updated out of band. IKE clients with an empty whitelist MUST NOT use any INTERNAL_DNSSEC_TA attributes received over IKE. such clients MAY read receiving an INTERNAL_DNSSEC_TA attribute for a non-whitelisted domain as a hint that their local configuration may need an out-of-band update 👀

⚠️ whitelist with care, bestie: only put internal or managed domains on it, never generic Internet traffic.

IKE clients should take care to only whitelist domains that apply to internal or managed domains, not generic Internet traffic. the DNS root zone (".") MUST be ignored if it shows up in a whitelist. other generic or public domains, like Top-Level Domains (TLDs), similarly MUST be ignored if they show up in a whitelist, unless the entity actually is the operator of the TLD. to check that, an implementation MAY interactively ask the user when a VPN profile is installed or activated, to confirm. alternatively, it MAY provide a special override keyword in its provisioning configuration, so non-interactive agreement can only come from the party provisioning the VPN client, who presumably is a trusted entity to the end user 🧚 similarly, an entity might use a special domain name, like ".internal", for its internal-only view, and might want to force its provisioning system to accept such a domain in a Split DNS configuration.

any updates to this whitelist MUST happen via explicit human interaction or by a trusted automated provisioning system. this stops malicious invisible installation of trust anchors if an IKE server gets compromised 🚨

IKE clients SHOULD accept any INTERNAL_DNSSEC_TA updates for subdomains of whitelisted domain names. for example, if "example.net" is whitelisted, then INTERNAL_DNSSEC_TA received for "antartica.example.net" SHOULD be accepted 🐧

IKE clients MUST ignore any received INTERNAL_DNSSEC_TA attributes for a Fully Qualified Domain Name (FQDN) for which it did not receive and accept an INTERNAL_DNS_DOMAIN Configuration Payload. no DNSSEC trust anchors for domains you never got a DNS domain for 🙅‍♀️

in most deployments, the IKE client expects to be connecting to one specific organization or enterprise using a split-network setup 🏢 a recommended policy would be to only accept INTERNAL_DNSSEC_TA directives from that organization's DNS names. however, that might not be possible in every deployment, like one where the IKE server is handing out a bunch of domains that aren't all under one parent domain 🫠

7. IANA Considerations 📋

this document defines two new IKEv2 Configuration Payload Attribute Types, which get allocated from the "IKEv2 Configuration Payload Attribute Types" namespace ✨

                                 Multi-
   Value    Attribute Type       Valued  Length      Reference
   ------   -------------------  ------  ----------  ---------------
   25       INTERNAL_DNS_DOMAIN   YES     0 or more  RFC 8598
   26       INTERNAL_DNSSEC_TA    YES     0 or more  RFC 8598

                                 Figure 1

8. Security Considerations 🚨

as stated in Section 2, if the negotiated IPsec connection is not a split-tunnel configuration, the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA Configuration Payloads MUST be ignored. otherwise, generic VPN service providers could maliciously override DNSSEC-based trust anchors of public DNS domains 😤 this is a real red flag, periodt.

an initiator MUST only accept INTERNAL_DNSSEC_TAs for which it has a whitelist 🔒 this is because the mechanism lets the credential used to authenticate an IKEv2 association get leveraged into authenticating credentials for other connections. initiators should ensure they have sufficient trust in the responder when using this mechanism. an initiator MAY treat a received INTERNAL_DNSSEC_TA for a non-whitelisted domain as a signal to update the whitelist via a non-IKE provisioning mechanism. see Section 6 for additional security considerations for DNSSEC trust anchors 🔐

the use of Split DNS configurations assigned by an IKEv2 responder is predicated on the trust established during IKE SA authentication. however, if IKEv2 is being negotiated with an anonymous or unknown endpoint (such as for Opportunistic Security [RFC7435]), the initiator MUST ignore Split DNS configurations assigned by the responder. stranger, no DNS for you 🙅‍♀️

if a host connected to an authenticated IKE peer is connecting to another IKE peer that tries to claim the same domain via the INTERNAL_DNS_DOMAIN attribute, the IKE connection SHOULD only process the DNS information if the two connections are part of the same logical entity. otherwise, the client SHOULD refuse the DNS information and potentially warn the end user ⚠️ for example, if a VPN profile for "Example Corporation" is installed that provides two IPsec connections, one covering 192.168.100.0/24 and one covering 10.13.14.0/24, it could be that both connections negotiate the same INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA values. since these are part of the same remote organization (or provisioning profile), the Configuration Payloads can be used. however, if a user installs two VPN profiles from two different, unrelated, independent entities, both could be configured to use the same domain -- for example, ".internal". these two connections MUST NOT be allowed to be active at the same time 💥

if the initiator is using DNSSEC validation for a domain in its public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure its DNS resolver to allow for an insecure delegation. it SHOULD NOT accept insecure delegations for domains that are DNSSEC signed in the public DNS view, for which it has not explicitly requested such delegation. i.e., for which it has not used an INTERNAL_DNS_DOMAIN request to specify the domain 🙈

deployments that configure INTERNAL_DNS_DOMAIN domains should pay close attention to their use of indirect reference RRtypes in their internal-only domain names. examples of such RRtypes are NS, CNAME, DNAME, MX, or SRV records. for example, if the MX record for "internal.example.com" points to "mx.internal.example.net", then both "internal.example.com" and "internal.example.net" should be sent using an INTERNAL_DNS_DOMAIN Configuration Payload 🧠

IKE clients MAY want to require whitelisted domains for Top-Level Domains (TLDs) and Second-Level Domains (SLDs), to further prevent malicious DNS redirections for well-known domains 🛡️ this stops users from unknowingly handing their DNS queries to third parties. it matters even more if those well-known domains aren't deploying DNSSEC, because then the VPN service provider could modify the DNS answers without anyone noticing 😭

the content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. as with any network input, the content SHOULD be considered untrusted and handled accordingly 🫡

9. References 📚

9.1. Normative References ✨

okay so these are the docs this spec literally can't function without, bestie 🫶 they're the non-negotiable foundations, so go read them if you're building anything with this

9.2. Informative References ✨

these ones are just extra reading, not required, but lowkey worth your time 🧚

Authors' Addresses 💅

meet the people who wrote this, periodt 👑

Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, California  95014
United States of America

Email: tpauly@apple.com


Paul Wouters
Red Hat

Email: pwouters@redhat.com
📦 where this page comes from