Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (26)
INTERNAL_DNSSEC_TA is needed because an enterprise may run a different version of its public domain internally; without it, existing DNSSEC signatures from the public view would cause DNSSEC validation failures for the internal view, making split DNS impossible in DNSSEC-validating environments.
Split DNS is preferred over routing all DNS through the enterprise VPN because it keeps non-enterprise user DNS activity private from the enterprise and removes the enterprise's legal and technical responsibility to resolve every possible DNS query from remote users.
Deployments using INTERNAL_DNS_DOMAIN should include all domains referenced by indirect RRtypes (NS, CNAME, DNAME, MX, SRV) in their internal domain names; for example, if the MX for an internal domain points to a host in a different domain, that second domain also needs its own INTERNAL_DNS_DOMAIN attribute.
All DNS servers provided in CFG_REPLY MUST support resolving hostnames within all INTERNAL_DNS_DOMAIN domains; INTERNAL_DNS_DOMAIN attributes form a single list applying to the entire set of INTERNAL_IP4_DNS and INTERNAL_IP6_DNS addresses.
Any updates to the DNSSEC trust anchor whitelist MUST happen via explicit human interaction or a trusted automated provisioning system to prevent malicious invisible installation of trust anchors.
Each INTERNAL_DNSSEC_TA attribute MUST immediately follow the INTERNAL_DNS_DOMAIN attribute it applies to in the CFG_REPLY payload; any INTERNAL_DNSSEC_TA not immediately preceded by a corresponding INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA for the same domain MUST be ignored.
For each accepted INTERNAL_DNS_DOMAIN in CFG_REPLY, the client MUST use the provided internal DNS servers as the only resolvers for those domains and their subdomains, and MUST NOT attempt to resolve them using external DNS servers.
If an initiator includes INTERNAL_DNS_DOMAIN in CFG_REQUEST, it MUST also include one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attributes in the same request.
If an initiator includes INTERNAL_DNSSEC_TA in CFG_REQUEST, it MUST also include one or more INTERNAL_DNS_DOMAIN attributes; if it does not, the responder MAY still respond with both attributes.
If CFG_REPLY includes an INTERNAL_DNS_DOMAIN, the responder MUST also include one or both of INTERNAL_IP4_DNS and INTERNAL_IP6_DNS in that reply.
If the CFG_REQUEST included INTERNAL_DNS_DOMAIN but the CFG_REPLY does not, the initiator MUST behave as if Split DNS is not supported by the server, unless local policy defines default Split DNS domains.
If the negotiated IPsec connection is not a split-tunnel configuration, the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA Configuration Payloads MUST be ignored to prevent generic VPN services from overriding the public DNS hierarchy.
IKE clients MUST ignore any received INTERNAL_DNSSEC_TA attributes for an FQDN for which they did not receive and accept an INTERNAL_DNS_DOMAIN Configuration Payload.
IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use a whitelist of one or more domains; clients with an empty whitelist MUST NOT use any received INTERNAL_DNSSEC_TA attributes.
Non-split-tunnel configurations SHOULD instead use only INTERNAL_IP4_DNS and INTERNAL_IP6_DNS to ensure all DNS traffic goes through the IPsec connection and does not leak onto the local network.
The DNS root zone (".") MUST be ignored if it appears in a whitelist, and other generic or public domains such as TLDs MUST similarly be ignored unless the entity actually operates the TLD.
When an IKE SA is terminated, DNS forwarding MUST be unconfigured, including deleting forwarding rules, flushing cached data (including negative cache), removing DNSSEC trust anchors, and clearing the outstanding DNS request queue.
INTERNAL_DNS_DOMAIN is a new IKEv2 Configuration Payload Attribute Type (value 25) that conveys one or more private DNS domain names to be resolved exclusively via internal DNS servers reachable through the IPsec connection.
INTERNAL_DNSSEC_TA is a new IKEv2 Configuration Payload Attribute Type (value 26) that conveys a DNSSEC trust anchor (DS record format) for a Split DNS domain, required when the external DNS view uses DNSSEC that would conflict with the internal view.
Two new entries are allocated in the IANA 'IKEv2 Configuration Payload Attribute Types' registry: value 25 for INTERNAL_DNS_DOMAIN (multi-valued, length 0 or more) and value 26 for INTERNAL_DNSSEC_TA (multi-valued, length 0 or more).
An initiator MUST only accept INTERNAL_DNSSEC_TAs for whitelisted domains because the mechanism allows the IKE authentication credential to be leveraged into authenticating credentials for other connections, including overriding TLS trust via TLSA/DANE records.
If IKEv2 is being negotiated with an anonymous or unknown endpoint (e.g., Opportunistic Security per RFC 7435), the initiator MUST ignore Split DNS configurations assigned by the responder.
If two simultaneous IPsec connections from different unrelated entities claim the same INTERNAL_DNS_DOMAIN (e.g., ".internal"), those two connections MUST NOT be allowed to be active at the same time.
The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another program for processing; as network input it SHOULD be considered untrusted and handled accordingly to prevent injection attacks.
INTERNAL_DNS_DOMAIN attribute: 1-bit Reserved, 15-bit Attribute Type (value 25), 2-octet Length, followed by a variable-length Domain Name in DNS presentation format using IDNA A-labels (not null-terminated).
INTERNAL_DNSSEC_TA attribute (non-empty): 1-bit Reserved, 15-bit Attribute Type (value 26), 2-octet Length, 2-octet DNSKEY Key Tag, 1-octet DNSKEY Algorithm, 1-octet Digest Type, variable-length Digest Data matching DS record format from RFC 4034 Section 5.1.