Why does RFC 8598 make an IKEv2 client ignore split-DNS attributes on a full tunnel and accept DNSSEC trust anchors only for whitelisted domains?

## Two attributes that change how a client sees names RFC 8598 (Standards Track, 2019) adds two IKEv2 configuration attributes that a VPN gateway can send in its `CFG_REPLY`: | Attribute | Type | Carries | Power it gives the gateway | |---|---|---|---| | `INTERNAL_DNS_DOMAIN` | 25 | a domain name, such as `corp.example.com` | decides which resolver answers every name under that domain | | `INTERNAL_DNSSEC_TA` | 26 | key tag, algorithm, digest type and digest of a DS record | decides which DNSSEC key the client trusts for that domain | The first exists so internal names resolve on internal servers; the second exists because an organisation often runs an internal view of a domain it also publishes, signed, on the internet. A validating client that sees the internal answers would otherwise find that the public, signed view "would prove the internal view does not exist" or expects a different key. Both attributes are useful, and both let whoever runs the gateway rewrite what the client believes about names. Much of RFC 8598 is about limiting that. ## Rule 1: only on split tunnels 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." The reasoning is about who runs full tunnels: a consumer VPN service routes all of a user's traffic and has no business claiming that it is authoritative for public domains. Such deployments should send only `INTERNAL_IP4_DNS` and `INTERNAL_IP6_DNS`, so all queries go through the tunnel, rather than redirecting individual domains. Split DNS is an enterprise tool for internal names, and the RFC keeps it there. ## Rule 2: a trust anchor is a certificate authority Section 6 makes the comparison explicitly: installing an `INTERNAL_DNSSEC_TA` "can be seen as the equivalent of installing an Enterprise CA certificate". A DNSSEC trust anchor lets the gateway's resolvers produce answers the client will treat as authenticated, including records that carry keys or certificate data: - **TLSA** records (DANE) say which certificate to expect for a TLS service, so a forged one could override certificate trust; - **OPENPGPKEY**, **SMIMEA** and **IPSECKEY** records carry keys for mail encryption, signed mail and IPsec. So a compromised or malicious IKE server with an accepted trust anchor could redirect more than names. The client-side rules follow from that: 1. A client willing to accept trust anchors MUST use a **whitelist** of domains that can be updated out of band; with an empty whitelist it MUST NOT use any received anchor. 2. The root zone MUST be ignored if it appears in the whitelist, and so must TLDs and other generic public domains unless the entity really operates them. 3. Updates to the whitelist MUST come from explicit human action or a trusted provisioning system, never silently over IKE. 4. Anchors for subdomains of a whitelisted domain SHOULD be accepted; anchors for a name with no accepted `INTERNAL_DNS_DOMAIN` MUST be ignored. ## Rule 3: trust comes from IKE authentication Section 8 ties all of this to the IKE SA's authentication. If IKEv2 runs with an anonymous or unknown peer, as in opportunistic security, the client MUST ignore split-DNS configuration. If two connections claim the same domain, the client SHOULD use the information only when both belong to the same logical entity; two profiles from unrelated organisations both claiming, say, `.internal` MUST NOT be active at once. It also covers the case without an anchor: a client that validates a publicly signed domain and receives `INTERNAL_DNS_DOMAIN` for it with no `INTERNAL_DNSSEC_TA` needs to allow an insecure delegation, and SHOULD NOT accept one for a publicly signed domain it did not request. ## What the operator does with this - Ship the whitelist of internal domains with the VPN profile, through the same provisioning that installs it, so anchors received over IKE can be accepted. - Send `INTERNAL_DNSSEC_TA` when the internal view of a publicly signed domain differs from the public one; otherwise validating clients reject internal answers. - List every internal domain that internal records point into through CNAME, MX or SRV targets, so resolver choice and anchors cover them too. - Expect clients to refuse anchors for domains their provisioned whitelist lacks; RFC 8598 lets a client treat such an anchor as a signal to update the whitelist out of band, never as the update itself. - On a full tunnel, rely on the gateway's resolvers for everything instead of per-domain attributes, which the client will ignore anyway.