Establishing Local DNS Authority in Validated Split-Horizon Environments
Extracted elements (30)
Placing internal domains inside a child zone (e.g., internal.example.com) reduces the frequency of Verification Record changes; the document recommends this structure as an operational best practice for split-horizon deployments.
The 'ds=...' key in the Verification Record enables DNSSEC validation of local DNS names without requiring the local resolver to hold DNSSEC private keys valid for the public parent zone, satisfying the 'least privilege' requirement while enabling DNSSEC chain of trust.
The 'least privilege' requirement ensures local resolvers hold no secrets that could weaken the security of the public zone if compromised; only the public parent zone holds cryptographic authority over the split-horizon authorization.
The protocol scope is intentionally limited to split-horizon views authorized by the domain owner; DNS filtering by any other entity is explicitly not enabled, preserving the principle that only the domain owner can authorize alternative resolution of their names.
When the endpoint is using an IPsec VPN tunnel, the encrypted DNS resolver can be securely discovered using ENCDNS_IP* IKEv2 Configuration Payload Attribute Types (RFC 9464), and the Section 6 validation mechanism applies to confirm authorization for claimed subdomains.
When using DNSSEC delegation across split DNS boundaries, any claimed subdomains that lack a globally trusted DNSKEY MUST be marked as unsigned in the public DNS; otherwise local resolution results would be rejected by validating stubs not implementing this specification.
A participating network MUST offer one or more encrypted resolvers via DHCP and Router Advertisement options for DNR, DDR, or an equivalent mechanism.
All Special-Use Domain Names (e.g., 'home.arpa.', 'local.') are outside the scope of this document and MUST NOT be validated using the mechanism described herein.
If the client cannot obtain a response from the external resolver within a reasonable timeframe, it MUST consider the verification process to have failed.
If the local encrypted resolver is identified by name (e.g., using DNR), that identifying name MUST be the name used in any corresponding authorization claim; otherwise the resolver MUST present a validatable certificate with a matching subjectAltName.
Implementations MUST support the 'mandatory to implement' ZONEMD hash algorithms defined in Section 2.2.3 of RFC 8976 for interoperability purposes.
In DHCPv4, the mechanism for splitting long options (RFC 3396) MUST be used if the Authentication option exceeds the maximum DHCPv4 option size of 255 octets, and the Replay Detection Method value MUST be 0x00.
Shortly before Verification Record expiry (TTL or DNSSEC signature validity period end), clients MUST fetch the Verification Records again and repeat the verification procedure.
The salt MUST be regenerated whenever the authorization claim is updated.
To validate an authorization claim, DNS clients MUST resolve the Verification Record; if the RRset contains the expected token, the client SHALL regard the named resolver as authoritative for the claimed subdomains.
When DNSSEC validation yields an Insecure result, the client SHOULD retry validation using a different method (e.g., external resolver); if not retrying, it MUST consider validation to have failed.
When using a preconfigured external resolver for tamperproof validation, clients MUST NOT relax the acceptance rules (e.g., AD bit checking, RRSIG validation) they would otherwise apply when using that resolver.
When using DNSSEC delegation across split DNS boundaries, at least one DNSKEY RR returned by the local encrypted resolver for 'resolver.arpa.' MUST match the DS RDATA from the Verification Record, and all local resolution results MUST offer RRSIGs chaining to an approved DNSKEY.
A 'Verification Record' is a TXT record published by the parent zone operator whose owner name is the concatenation of the ADN, '_splitdns-challenge', and the parent zone name, with content containing key/value pairs including 'token=base64url($TOKEN)'.
An 'authorization claim' is an abstract structure comprising: the ADN of a local encrypted resolver, the DNS name of the authorizing parent zone, a set of claimed subdomains (or '*' for the entire parent zone), a ZONEMD Hash Algorithm, and a high-entropy salt of up to 255 octets.
The Verification Token is computed as hash(len($SALT) || $SALT || $X), where $X is the concatenation of claimed subdomains in canonical form with their parent zone suffix replaced by a zero octet, and hash is the ZONEMD Hash Algorithm.
When using PvD (RFC 8801), authorization claims are conveyed as a JSON array under the 'splitDnsClaims' key, where each entry is a JSON object with fields: 'resolver' (ADN), 'parent', 'subdomains', 'algorithm', and 'salt' (base64url-encoded).
IANA added '_splitdns-challenge' (RR Type: TXT) to the 'Underscored and Globally Scoped DNS Node Names' registry in the DNS Parameters registry group.
IANA added the JSON key 'splitDnsClaims' (type: Array of Objects, description: 'Verifiable locally served domains') to the 'Additional Information PvD Keys' registry in the Provisioning Domains registry group.
IANA added value 4 ('Split-horizon DNS') to the 'Protocol Name Space Values' registry in the DHCP Authentication Option Name Spaces registry group.
IANA created a new 'PvD Split DNS Claims' registry within the Provisioning Domains registry group, with five mandatory initial entries: resolver, parent, subdomains, algorithm, and salt. New assignments use Expert Review.
Algorithm agility is achieved by allowing implementations to choose hashing algorithms from the 'ZONEMD Hash Algorithms' registry; the salt MUST be regenerated whenever the authorization claim is updated, and high-quality pseudorandom number generation is required per RFC 4086.
The ADNs of authorized local encrypted resolvers are revealed in the owner names of Verification Records, potentially exposing sensitive resolver names or secret subdomain information; local resolvers should be given names that do not reveal sensitive information to mitigate this.
DNSSEC-based Verification Record validation transitions through states: Secure (response used for validation), Bogus or Indeterminate (response rejected, validation fails), and Insecure (client SHOULD retry with external resolver; if not, validation fails).
The DHCP Authentication Information field for Split-horizon DNS (Protocol value 4) contains, concatenated: the ADN in canonical form, the parent name in canonical form, a one-octet salt length, the salt value, and the $X value (canonicalized subdomain list with parent suffix replaced by zero octets).