rfc9704.original   rfc9704.txt 
ADD T. Reddy Internet Engineering Task Force (IETF) T. Reddy.K
Internet-Draft Nokia Request for Comments: 9704 Nokia
Intended status: Standards Track D. Wing Category: Standards Track D. Wing
Expires: 22 December 2024 Citrix ISSN: 2070-1721 Citrix
K. Smith K. Smith
Vodafone Vodafone
B. Schwartz B. Schwartz
Meta Meta
20 June 2024 December 2024
Establishing Local DNS Authority in Validated Split-Horizon Environments Establishing Local DNS Authority in Validated Split-Horizon Environments
draft-ietf-add-split-horizon-authority-14
Abstract Abstract
When split-horizon DNS is deployed by a network, certain domain names When split-horizon DNS is deployed by a network, certain domain names
can be resolved authoritatively by a network-provided DNS resolver. can be resolved authoritatively by a network-provided DNS resolver.
DNS clients that are not configured to use this resolver by default DNS clients that are not configured to use this resolver by default
can use it for these specific domains only. This specification can use it for these specific domains only. This specification
defines a mechanism for domain owners to inform DNS clients about defines a mechanism for domain owners to inform DNS clients about
local resolvers that are authorized to answer authoritatively for local resolvers that are authorized to answer authoritatively for
certain subdomains. certain subdomains.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Adaptive DNS Discovery
Working Group mailing list (add@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/add/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-
authority.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 December 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9704.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements
5. Establishing Local DNS Authority . . . . . . . . . . . . . . 6 5. Establishing Local DNS Authority
5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Example
5.2. Conveying Authorization Claims . . . . . . . . . . . . . 8 5.2. Conveying Authorization Claims
5.2.1. Using DHCP . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Using DHCP
5.2.2. Using Provisioning Domains . . . . . . . . . . . . . 8 5.2.2. Using Provisioning Domains
6. Validating Authority over Local Domain Hints . . . . . . . . 9 6. Validating Authority over Local Domain Hints
6.1. Using a Pre-configured External Resolver . . . . . . . . 9 6.1. Using a Preconfigured External Resolver
6.2. Using DNSSEC . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Using DNSSEC
7. Delegating DNSSEC across Split DNS Boundaries . . . . . . . . 10 7. Delegating DNSSEC Across Split DNS Boundaries
8. Examples of Split-Horizon DNS Configuration . . . . . . . . . 12 8. Example Split-Horizon DNS Configuration
8.1. Split-Horizon Entire Zone . . . . . . . . . . . . . . . . 13 8.1. Verification Using an External Resolver
8.1.1. Verification Using an External Resolver . . . . . . . 14 8.2. Verification Using DNSSEC
8.1.2. Verification using DNSSEC . . . . . . . . . . . . . . 15 9. Operational Efficiency in Split-Horizon Deployments
9. Operational Efficiency in Split-Horizon Deployments . . . . . 16 10. Validation with IKEv2
10. Validation with IKEv2 . . . . . . . . . . . . . . . . . . . . 17 11. Authorization Claim Update
11. Authorization Claim Update . . . . . . . . . . . . . . . . . 17 12. Security Considerations
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13.1. New DHCP Authentication Algorithm for Split DNS
13.1. DHCP Split DNS Authentication Algorithm . . . . . . . . 18 13.2. New PvD Additional Information Type for Split DNS
13.2. Provisioning Domains Split DNS Additional Information . 18 13.3. New PvD Split DNS Claims Registry
13.3. New PvD Split DNS Claims Registry . . . . . . . . . . . 19 13.3.1. Guidelines for the Designated Experts
13.3.1. Guidelines for the Designated Experts . . . . . . . 20 13.4. DNS Underscore Name
13.4. DNS Underscore Name . . . . . . . . . . . . . . . . . . 20 14. References
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 14.1. Normative References
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.2. Informative References
15.1. Normative References . . . . . . . . . . . . . . . . . . 21 Acknowledgements
15.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
To resolve a DNS query, there are three main behaviors that an To resolve a DNS query, there are three main behaviors that an
implementation can apply: (1) answer from a local database, (2) query implementation can apply: (1) answer from a local database, (2) query
the relevant authorities and their parents, or (3) ask a server to the relevant authorities and their parents, or (3) ask a server to
query those authorities and return the final answer. Implementations query those authorities and return the final answer. Implementations
that use these behaviors are called "authoritative nameservers", that use these behaviors are called "authoritative nameservers",
"full/recursive resolvers", and "forwarders" (or "stub resolvers") "full/recursive resolvers", and "forwarders" (or "stub resolvers"),
respectively. However, an implementation can also implement a respectively. However, an implementation can also implement a
mixture of these behaviors, depending on a local policy, for each mixture of these behaviors, depending on local policy, for each
query. Such an implementation is termed a "hybrid resolver". query. Such an implementation is termed a "hybrid resolver".
Most DNS resolvers are hybrids of some kind. For example, stub Most DNS resolvers are hybrids of some kind. For example, stub
resolvers support a local "hosts file" that preempts query resolvers support a local "hosts file" that preempts query
forwarding, and most DNS forwarders and full resolvers can also serve forwarding, and most DNS forwarders and full resolvers can also serve
responses from a local zone file. Other standardized hybrid responses from a local zone file. Other standardized hybrid
resolution behaviors include Local Root [RFC8806], mDNS [RFC6762], resolution behaviors include using a local root [RFC8806], Multicast
and NXDOMAIN synthesis for .onion [RFC7686]. DNS (mDNS) [RFC6762], and NXDOMAIN synthesis for .onion [RFC7686].
Networks usually offer clients a DNS resolver using means such as Networks usually offer clients a DNS resolver using means such as
(e.g., DHCP OFFER, IPv6 Router Advertisement). Although this DHCP offers or IPv6 Router Advertisements (RAs). Although this
resolver is formally specified as a recursive resolver (e.g., resolver is formally specified as a recursive resolver (e.g., see
Section 5.1 of [RFC8106]), some networks provide a hybrid resolver Section 5.1 of [RFC8106]), some networks provide a hybrid resolver
instead. If this resolver acts as an authoritative server for some instead. If this resolver acts as an authoritative server for some
names and provides different answers for those domains depending on names and -- depending on the source of the query -- provides
the source of the query, it is described as the network having different answers for those domains, the network is said to be using
"split-horizon DNS", because those names resolve in this way only "split-horizon DNS", because those names resolve in this way only
from inside the network. from inside the network.
DNS clients that use pure stub resolution, sending all queries to the DNS clients that use pure stub resolution, sending all queries to the
network-provided resolver, will always receive the split-horizon network-provided resolver, will always receive the split-horizon
results. Conversely, clients that send all queries to a different results. Conversely, clients that send all queries to a different
resolver or implement pure full resolution locally will never receive resolver or implement pure full resolution locally will never receive
them. Clients that strictly implement either of these resolution them. Clients that strictly implement either of these resolution
behaviors are out of scope for this specification. Instead, this behaviors are out of scope for this specification. Instead, this
specification enables hybrid clients to access split-horizon results specification enables hybrid clients to access split-horizon results
from a network-provided hybrid resolver, while using a different from a network-provided hybrid resolver, while using a different
resolution method for some or all other names. resolution method for some or all other names.
There are several existing mechanisms for a network to provide There are several existing mechanisms for a network to provide
clients with "local domain hints", listing domain names that have clients with "local domain hints", listing domain names that are
special treatment in this network (e.g., RDNSS Selection [RFC6731], given special treatment in this network (e.g., "Recursive DNS Server
"Access Network Domain Name" [RFC5986], and "Client FQDN" (RDNSS) selection" [RFC6731], "access network domain name" [RFC5986],
[RFC4702][RFC4704] in DHCP, "dnsZones" in Provisioning Domains and "Client Fully Qualified Domain Name (FQDN)" [RFC4702] [RFC4704]
[RFC8801], and INTERNAL_DNS_DOMAIN [RFC8598] in IKEv2). However, in DHCP; "dnsZones" in Provisioning Domains (PvDs) [RFC8801]; and
none of the local domain hint mechanisms enables clients to determine "INTERNAL_DNS_DOMAIN" [RFC8598] in Internet Key Exchange Protocol
whether this special treatment is authorized by the domain owner. Version 2 (IKEv2)). However, none of the local domain hint
Instead, these specifications require clients to make their own mechanisms enable clients to determine whether this special treatment
determinations about whether to trust and rely on these hints. is authorized by the domain owner. Instead, these specifications
require clients to make their own determinations about whether to
trust and rely on these hints.
This document describes a mechanism between domain names, networks, This document describes a mechanism between domain names, networks,
and clients that allows the network to establish its authority over a and clients that allows the network to establish its authority over a
domain to a client (Section 5). Clients can use this protocol to domain to a client (Section 5). Clients can use this protocol to
confirm that a local domain hint was authorized by the domain owner confirm that a local domain hint was authorized by the domain owner
(Section 6), which might influence its processing of that hint. This (Section 6), which might influence its processing of that hint. This
process requires cooperation between the local DNS zone and the process requires cooperation between the local DNS zone and the
public zone. public zone.
This specification relies on securely identified local DNS servers, This specification expects that local DNS servers will be securely
and checks each local domain hint against a globally valid parent identified and that each local domain hint will be checked against a
zone. globally valid parent zone.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119][RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in [RFC9499], e.g., This document makes use of the terms defined in [RFC9499], e.g.,
"Global DNS". The following additional terms are used throughout the "global DNS". The following additional terms are used throughout
document: this document:
Encrypted DNS A DNS protocol that provides an encrypted channel Encrypted DNS: A DNS protocol that provides an encrypted channel
between a DNS client and server (e.g., DNS over TLS (DoT) between a DNS client and server (e.g., DNS over TLS (DoT)
[RFC7858], HTTPS (DoH) [RFC8484], QUIC (DoQ) [RFC9250]). [RFC7858], DNS (queries) over HTTPS (DoH) [RFC8484], DNS over QUIC
(DoQ) [RFC9250]).
Encrypted DNS resolver Refers to a DNS resolver that supports any Encrypted DNS Resolver: Refers to a DNS resolver that supports any
encrypted DNS scheme. encrypted DNS scheme.
Split-Horizon DNS The DNS service provided by a resolver that also Split-Horizon DNS: The DNS service provided by a resolver that also
acts as an authoritative server for some names, providing acts as an authoritative server for some names, providing
resolution results that are meaningfully different from those in resolution results that are meaningfully different from those in
the Global DNS. (See "Split DNS" in Section 6 of [RFC9499].) the global DNS. (See the definition of "split DNS" in Section 6
of [RFC9499].)
Validated Split-Horizon A split horizon configuration for some name Validated Split Horizon: Indicates that a split-horizon
is considered "validated" if the client has confirmed that a configuration for some name is considered "validated" if the
parent of that name has authorized this resolver to serve its own client has confirmed that a parent of that name has authorized
responses for that name. Such authorization generally extends to this resolver to serve its own responses for that name. Such
the entire subtree of names below the authorization point. authorization generally extends to the entire subtree of names
below the authorization point.
In this document, the terms 'owner' and 'operator' are used In this document, the terms "owner" and "operator" are used
interchangeably and refer to the individual or entity responsible for interchangeably and refer to the individual or entity responsible for
the management and maintenance of domains. the management and maintenance of domains.
Lone lines in examples are wrapped using a single backslash ("\") per
[RFC8792].
3. Scope 3. Scope
The protocol in this document is designed to support the ability of a The protocol described in this document is designed to support the
domain owner to create or authorize a split-horizon view of their ability of a domain owner to create or authorize a split-horizon view
domain. The protocol does not support split-horizon views created by of their domain. The protocol does not support split-horizon views
any other entity. Thus, DNS filtering is not enabled by this created by any other entity. Thus, DNS filtering is not enabled by
protocol. this protocol.
The protocol is applicable to any type of network offering split- The protocol is applicable to any type of network offering split-
horizon DNS configuration. The endpoint does not need any prior horizon DNS configuration. The endpoint does not need any prior
configuration to confirm that a local domain hint was indeed configuration to confirm that a local domain hint was indeed
authorized by the domain. authorized by the domain.
All of the special-use domain names registered with IANA [RFC6761], All of the Special-Use Domain Names registered with IANA [RFC6761],
most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." and most notably "home.arpa.", "resolver.arpa.", "ipv4only.arpa.", and
".local", are never unique to a specific DNS server's authority. All "local.", are never unique to a specific DNS server's authority. All
special-use domain names are outside the scope of this document and Special-Use Domain Names are outside the scope of this document and
MUST NOT be validated using the mechanism described in this document. MUST NOT be validated using the mechanism described in this document.
Use of this specification is limited to DNS servers that support The use of this specification is limited to DNS servers that support
authenticated encryption and split-horizon DNS names that are rooted authenticated encryption and split-horizon DNS names that are rooted
in the global DNS. in the global DNS.
4. Requirements 4. Requirements
This solution seeks to fulfill the following requirements: This solution seeks to fulfill the following requirements:
* No loss of security: No unauthorized party can impersonate a zone No loss of security: No unauthorized party can impersonate a zone
unless they could already do so without use of this specification. unless they could already do so without the use of this
specification.
* Least privilege: Local resolvers do not hold any secrets that Least privilege: Local resolvers do not hold any secrets that could
could weaken the security of the public zone if compromised. weaken the security of the public zone if compromised.
* Local zone confidentiality: The specification does not leak local Local zone confidentiality: The specification does not leak local
network subdomains to anyone outside of the network. network subdomains to anyone outside of the network.
* Flexibility: The specification can represent and authorize a Split Flexibility: The specification can represent and authorize a split
DNS zone structure. DNS zone structure.
* DNSSEC Compatibility: The specification supports DNSSEC-based DNSSEC compatibility: The specification supports DNSSEC-based object
[RFC9364] object security for local zone contents. security for local zone contents per [RFC9364].
5. Establishing Local DNS Authority 5. Establishing Local DNS Authority
A participating network MUST offer one or more encrypted resolvers A participating network MUST offer one or more encrypted resolvers
via DHCP and Router Advertisement Options for the Discovery of via DHCP and Router Advertisement options for the Discovery of
Network-designated Resolvers (DNR) [RFC9463], Discovery of Designated Network-designated Resolvers (DNR) [RFC9463], Discovery of Designated
Resolvers (DDR) [RFC9462], or an equivalent mechanism (see Resolvers (DDR) [RFC9462], or an equivalent mechanism (see
Section 10). Section 10).
To establish local authority, the network MUST convey one or more To establish local authority, the network MUST convey one or more
"Authorization Claims" to the client. An "Authorization Claim" is an "authorization claims" to the client. An authorization claim is an
abstract structure comprising: abstract structure comprising:
* An Authentication Domain Name (ADN) of a local encrypted resolver. * An Authentication Domain Name (ADN) of a local encrypted resolver.
* The DNS name of the authorizing parent zone. * The DNS name of the authorizing parent zone.
* A set of subdomains of this parent zone that are claimed by the * A set of subdomains of this parent zone that are claimed by the
named local resolver (potentially including the entire parent named local resolver (potentially including the entire parent
zone). To claim the entire parent zone, the claimed subdomain zone). To claim the entire parent zone, the claimed subdomain
will be represented as an asterisk symbol "*". will be represented as an asterisk symbol ("*").
* A ZONEMD Hash Algorithm (Section 5.3 of [RFC8976]). For * A ZONEMD Hash Algorithm (Section 5.3 of [RFC8976]). For
interoperability purposes implementations MUST support the interoperability purposes, implementations MUST support the
"mandatory to implement" hash algorithms defined in Section 2.2.3 "mandatory to implement" hash algorithms defined in Section 2.2.3
of [RFC8976]. of [RFC8976].
* A high-entropy salt, up to 255 octets. * A high-entropy salt, up to 255 octets.
If the local encrypted resolver is identified by name (e.g., DNR), If the local encrypted resolver is identified by name (e.g., DNR),
that identifying name MUST be the one used in any corresponding that identifying name MUST be the name used in any corresponding
Authorization Claim. Otherwise (e.g., DDR using IP addresses), the authorization claim. Otherwise (e.g., DDR using IP addresses), the
resolver MUST present a validatable certificate containing a resolver MUST present a validatable certificate containing a
subjectAltName that matches the Authorization Claim using the subjectAltName that matches the authorization claim using the
validation techniques for matching as described in [RFC9525]. validation techniques for matching as described in [RFC9525].
The network then provides each Authorization Claim to the parent zone The network then provides each authorization claim to the parent zone
operator. If the contents are approved, the parent zone operator operator. If the contents are approved, the parent zone operator
computes a "Verification Token" according to the following procedure: computes a "Verification Token" according to the following procedure:
1. Convert all subdomains into canonical form and sort them in 1. Convert all subdomains into canonical form and sort them in
canonical order (Section 6 of [RFC4034]). canonical order (Section 6 of [RFC4034]).
2. Replace the suffix corresponding to the parent zone with a zero 2. Replace the suffix corresponding to the parent zone with a zero
octet. octet.
3. Let $X be the concatenation of the resulting pseudo-FQDNs. 3. Let $X be the concatenation of the resulting pseudo-FQDNs.
4. Let len($SALT) be the number of octets of salt, as a single 4. Let len($SALT) be the number of octets of salt, as a single
octet. octet.
5. Let $TOKEN = hash(len($SALT) || $SALT || $X). Where "||" denotes 5. Let $TOKEN = hash(len($SALT) || $SALT || $X), where "||" denotes
concatenation and hash is the ZONEMD Hash Algorithm. concatenation and hash is the ZONEMD Hash Algorithm.
The zone operator then publishes a "Verification Record" with the The zone operator then publishes a "Verification Record" with the
following structure, following the best practices outlined in following structure, following the best practices outlined in
Sections 5.1 and 5.2 of Sections 5.2 and 5.3 of [DOMAIN-VERIFICATION-TECHNIQUES]:
[I-D.ietf-dnsop-domain-verification-techniques]:
* Type = TXT. * Type = TXT
* Owner Name = Concatenation of the ADN, "_splitdns-challenge", and * Owner Name = Concatenation of the ADN, "_splitdns-challenge", and
the parent zone name. the parent zone name
* Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" * Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)"
(without padding) (without padding)
By publishing this record, the parent zone authorizes the local By publishing this record, the parent zone authorizes the local
encrypted resolver to serve these subdomains authoritatively. encrypted resolver to serve these subdomains authoritatively.
5.1. Example 5.1. Example
Consider the following authorization claim: Consider the following authorization claim:
skipping to change at page 7, line 47 skipping to change at line 320
* Subdomains = "payroll.parent.example", * Subdomains = "payroll.parent.example",
"secret.project.parent.example" "secret.project.parent.example"
* Hash Algorithm = SHA-384 [RFC6234] * Hash Algorithm = SHA-384 [RFC6234]
* Salt = "example salt octets (should be random)" * Salt = "example salt octets (should be random)"
To approve this claim, the zone operator would publish the following To approve this claim, the zone operator would publish the following
record: record:
NOTE: '\' line wrapping per [RFC8792]
resolver17.parent.example._splitdns-challenge.parent.example. \ resolver17.parent.example._splitdns-challenge.parent.example. \
IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\ IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\
-KJDv2eFwfJcWQM" -KJDv2eFwfJcWQM"
5.2. Conveying Authorization Claims 5.2. Conveying Authorization Claims
The Authorization Claim is an abstract structure that must be encoded The authorization claim is an abstract structure that must be encoded
in some concrete syntax in order to convey it from the network to the in some concrete syntax in order to convey it from the network to the
client. This section defines some encodings of the Authorization client. This section defines some encodings of the authorization
Claims. claims.
5.2.1. Using DHCP 5.2.1. Using DHCP
In DHCP, each Authorization Claim is encoded as a DHCP Authentication In DHCP, each authorization claim is encoded as a DHCP Authentication
Option ([RFC3118] and Section 21.11 of [RFC8415]), using the Protocol option ([RFC3118] and Section 21.11 of [RFC8415]), using the Protocol
value $TBD1, "Split DNS Authentication". In DHCPv4 [RFC2131], the value 4, "Split-horizon DNS". In DHCPv4 [RFC2131], the mechanism for
long-options mechanism described in Section 8 of [RFC3396] MUST be splitting long options as described in Section 8 of [RFC3396] MUST be
used if the authentication option exceeds the maximum DHCPv4 option used if the Authentication option exceeds the maximum DHCPv4 option
size of 255 octets. The Algorithm field provides the ZONEMD Hash size of 255 octets. The Algorithm field provides the ZONEMD Hash
Algorithm, represented by its registered Value. The Replay Detection Algorithm, represented by its registered Value. The Replay Detection
Method value MUST be 0x00. The Authentication Information MUST Method value MUST be 0x00. The Authentication Information MUST
contain the following information, concatenated: contain the following information, concatenated:
1. The ADN in canonical form. 1. The ADN in canonical form.
2. The parent name in canonical form. 2. The parent name in canonical form.
3. A one-octet "salt length" field. 3. A one-octet "salt length" field.
4. The salt value. 4. The salt value.
5. The $X value defined in Section 5. 5. The $X value as defined in Section 5.
5.2.2. Using Provisioning Domains 5.2.2. Using Provisioning Domains
When using Provisioning Domains [RFC8801], the Authorization Claims When using PvDs [RFC8801], the authorization claims are represented
are represented by the PvD Additional Information key by the PvD Additional Information key "splitDnsClaims", whose value
"splitDnsClaims", whose value is a JSON Array. Each entry in the is a JSON array. Each entry in the array MUST be a JSON object with
array MUST be a JSON object with the following structure: the following structure:
* "resolver": The ADN as a dot-separated name. "resolver": The ADN as a dot-separated name.
* "parent": The parent zone name as a dot-separated name. "parent": The parent zone name as a dot-separated name.
* "subdomains": An array containing the claimed subdomains, as dot- "subdomains": An array containing the claimed subdomains, as dot-
separated names with the parent suffix already removed, in separated names with the parent suffix already removed, in
canonical order. To claim the entire parent zone, the claimed canonical order. To claim the entire parent zone, the claimed
subdomain will be represented as an asterisk symbol "*". subdomain will be represented as an asterisk symbol ("*").
* "algorithm": The hash algorithm is represented by its "Mnemonic" "algorithm": The hash algorithm, represented by its "Mnemonic"
string from the ZONEMD Hash Algorithms registry ([RFC8976], string from the "ZONEMD Hash Algorithms" registry (Section 5.3 of
Section 5.2). [RFC8976]).
* "salt": The salt, encoded in base64url [RFC4648]. "salt": The salt, encoded in base64url [RFC4648].
Future specifications aiming to define new keys will need to add them Future specifications aiming to define new keys will need to add them
to the IANA registry defined in Section 13. DNS client to the IANA registry defined in Section 13.3. DNS client
implementations will ignore any keys they don't recognize but may implementations will ignore any keys they don't recognize but may
also report about unknown keys. also report unknown keys.
6. Validating Authority over Local Domain Hints 6. Validating Authority over Local Domain Hints
To validate an Authorization Claim provided by the network, DNS To validate an authorization claim provided by the network, DNS
clients MUST resolve the Verification Record for that name. If the clients MUST resolve the Verification Record for that name. If the
resolution produces an RRSet containing the expected token for this resolution produces an RRset containing the expected token for this
Claim, the client SHALL regard the named resolver as authoritative claim, the client SHALL regard the named resolver as authoritative
for the claimed subdomains. Clients MUST ignore any unrecognized for the claimed subdomains. Clients MUST ignore any unrecognized
keys in the Verification Record. keys in the Verification Record.
Each validation of authority applies only to a specific ADN. If a Each validation of authority applies only to a specific ADN. If a
network offers multiple encrypted resolvers, each claimed subdomain network offers multiple encrypted resolvers, each claimed subdomain
may be authorized for a distinct subset of the network-provided may be authorized for a distinct subset of the network-provided
resolvers. resolvers.
A zone is termed a "Validated Split-Horizon zone" after successful A zone is termed a "Validated Split-Horizon zone" after successful
validation using a "tamperproof" DNS resolution method, i.e., a validation using a "tamperproof" DNS resolution method, i.e., a
method that is not subject to interference by the local network method that is not subject to interference by the local network
operator. Two possible tamperproof resolution methods are presented operator. Two possible tamperproof resolution methods are presented
below. below.
6.1. Using a Pre-configured External Resolver 6.1. Using a Preconfigured External Resolver
This method applies only if the client is already configured with a This method applies only if the client is already configured with a
default resolution strategy that sends queries to a resolver outside default resolution strategy that sends queries to a resolver outside
of the network over a encrypted transport. That resolution strategy of the network over an encrypted transport. That resolution strategy
is considered "tamperproof" because any actor who could modify the is considered tamperproof because any actor who could modify the
response could already modify all of the user's other DNS responses. response could already modify all of the user's other DNS responses.
If the client cannot obtain a response from the external resolver If the client cannot obtain a response from the external resolver
within a reasonable timeout period, it MUST consider the verification within a reasonable timeout period, it MUST consider the verification
process to have failed. process to have failed.
To ensure that this assumption holds, clients MUST NOT relax the To ensure that this assumption holds, clients MUST NOT relax the
acceptance rules they would otherwise apply when using this resolver. acceptance rules they would otherwise apply when using this resolver.
For example, if the client would check the Authenticated Data (AD) For example, if the client would check the Authenticated Data (AD)
bit or validate RRSIGs locally when using this resolver, it must also bit or validate RRSIGs locally when using this resolver, it must also
do so when resolving TXT records for this purpose. Alternatively, a do so when resolving TXT records for this purpose. Alternatively, a
client might perform DNSSEC validation for the verification query client might perform DNSSEC validation for the verification query
even if it has disabled DNSSEC validation for other DNS queries. even if it has disabled DNSSEC validation for other DNS queries.
6.2. Using DNSSEC 6.2. Using DNSSEC
The client resolves the Verification Record using any resolution The client resolves the Verification Record using any resolution
method of its choice (e.g., querying one of the network-provided method of its choice (e.g., querying one of the network-provided
resolvers, performing iterative resolution locally), and performs resolvers, performing iterative resolution locally) and performs full
full DNSSEC validation locally [RFC6698]. The result is processed DNSSEC validation locally [RFC6698]. The result is processed based
based on its DNSSEC validation state ([RFC4035], Section 4.3): on its DNSSEC validation state (Section 4.3 of [RFC4035]):
*Secure*: The response is used for validation. *Secure*: The response is used for validation.
*Bogus* or *Indeterminate*: The response is rejected and *Bogus* or *Indeterminate*: The response is rejected, and validation
validation is considered to have failed. is considered to have failed.
*Insecure*: The client SHOULD retry the validation process using a *Insecure*: The client SHOULD retry the validation process using a
different method, such as the one in Section 6.1, to ensure different method, such as the method described in Section 6.1, to
compatibility with unsigned names. If the client chooses not to ensure compatibility with unsigned names. If the client chooses
retry (e.g., no configured policy to validate the authorization not to retry (e.g., no configured policy to validate the
claim using an external resolver), it MUST consider validation to authorization claim using an external resolver), it MUST consider
have failed. validation to have failed.
7. Delegating DNSSEC across Split DNS Boundaries 7. Delegating DNSSEC Across Split DNS Boundaries
When the local zone can be signed with globally trusted keys for the When the local zone can be signed with globally trusted keys for the
parent zone, support for DNSSEC can be accomplished simply by placing parent zone, support for DNSSEC can be accomplished by simply placing
a zone cut at the parent zone and including a suitable DS record for a zone cut at the parent zone and including a suitable DS record for
the local resolver's DNSKEY. Zones in this configuration appear the the local resolver's DNSKEY. Zones in this configuration appear the
same to validating stubs whether or not they implement this same to validating stubs whether or not they implement this
specification. specification.
To enable DNSSEC validation of local DNS names without requiring the To enable DNSSEC validation of local DNS names without requiring the
local resolver to hold DNSSEC private keys that are valid for the local resolver to hold DNSSEC private keys that are valid for the
parent zone, parent zones MAY add a "ds=..." key to the Verification parent zone, parent zones MAY add a "ds=..." key to the Verification
Record whose value is the RDATA of a single DS record, base64url- Record whose value is the RDATA of a single DS record, encoded in
encoded. This DS record authorizes a DNSKEY whose Owner Name is base64url. This DS record authorizes a DNSKEY whose owner name is
"resolver.arpa." "resolver.arpa."
To validate DNSSEC, the client first fetches and validates the To validate DNSSEC, the client first fetches and validates the
Verification Record. If it is valid and contains a "ds" key, the Verification Record. If it is valid and contains a "ds" key, the
client MAY send a DNSKEY query for "resolver.arpa." to the local client MAY send a DNSKEY query for "resolver.arpa." to the local
encrypted resolver. At least one resulting DNSKEY RR MUST match the encrypted resolver. At least one resulting DNSKEY Resource Record
DS RDATA from the "ds" key in the Verification Record. All local (RR) MUST match the DS RDATA from the "ds" key in the Verification
resolution results for subdomains in this claim MUST offer RRSIGs Record. All local resolution results for subdomains in this claim
that chain to a DNSKEY whose RDATA is identical to one of these MUST offer RRSIGs that chain to a DNSKEY whose RDATA is identical to
approved DNSKEYs. one of these approved DNSKEYs.
The "ds" key MAY appear multiple times in a single Verification The "ds" key MAY appear multiple times in a single Verification
Record, in order to authorize multiple DNSKEYs for this local Record, in order to authorize multiple DNSKEYs for this local
encrypted resolver. If the "ds" key is not present in a valid encrypted resolver. If the "ds" key is not present in a valid
Verification Record, the client MUST disable DNSSEC validation when Verification Record, the client MUST disable DNSSEC validation when
resolving the claimed subdomains via this local encrypted resolver. resolving the claimed subdomains via this local encrypted resolver.
Note that in this configuration, any claimed subdomains MUST be Note that in this configuration, any claimed subdomains MUST be
marked as unsigned in the public DNS. Otherwise, resolution results marked as unsigned in the public DNS. Otherwise, resolution results
would be rejected by validating stubs that do not implement this would be rejected by validating stubs that do not implement this
specification. specification.
;; Parent zone. ;; Parent zone.
$ORIGIN parent.example. $ORIGIN parent.example.
; Parent zone's public KSK and ZSK ; Parent zone's public Key Signing Key (KSK)
; and Zone Signing Key (ZSK).
@ IN DNSKEY 257 3 5 ABCD...= @ IN DNSKEY 257 3 5 ABCD...=
@ IN DNSKEY 256 3 5 DCBA...= @ IN DNSKEY 256 3 5 DCBA...=
; Verification Record containing DS RDATA for the local ; Verification Record containing DS RDATA for the local
; resolver's KSK. This is an ordinary public TXT record, ; resolver's KSK. This is an ordinary public TXT record,
; secured by RRSIGs from the public ZSK. ; secured by RRSIGs from the public ZSK.
resolver.example._splitdns-challenge IN TXT "token=abc...,ds=QWE..." resolver.example._splitdns-challenge IN TXT "token=abc...,ds=QWE..."
; NSEC record indicating that unsigned delegations are permitted at ; NSEC record indicating that unsigned delegations are permitted at
; this subdomain. This is required for compatibility with non-split-aware ; this subdomain. This is required for compatibility with
; validating stub resolvers. If the claimed label is confidential, the ; non-split-aware validating stub resolvers. If the claimed label is
; parent zone can conceal it using NSEC3 (with or without "opt-out"). ; confidential, the parent zone can conceal it using NSEC3 (with or
; without "opt-out").
@ IN NSEC subdomain.parent.example. NS @ IN NSEC subdomain.parent.example. NS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Local zone, claiming "subdomain.parent.example". ;; Local zone, claiming "subdomain.parent.example".
; The local resolver's KSK, validated by the Verification Record. ; The local resolver's KSK, validated by the Verification Record.
; It may not have a corresponding RRSIG. ; It may not have a corresponding RRSIG.
resolver.arpa. IN DNSKEY 257 3 5 ASDF...= resolver.arpa. IN DNSKEY 257 3 5 ASDF...=
skipping to change at page 12, line 44 skipping to change at line 516
subdomain.parent.example. IN DNSKEY 256 3 5 FDSA...= subdomain.parent.example. IN DNSKEY 256 3 5 FDSA...=
subdomain.parent.example IN RRSIG DNSKEY 5 3 ... \ subdomain.parent.example IN RRSIG DNSKEY 5 3 ... \
(KSK key tag) subdomain.parent.example. ... (KSK key tag) subdomain.parent.example. ...
subdomain.parent.example. IN AAAA 2001:db8::17 subdomain.parent.example. IN AAAA 2001:db8::17
subdomain.parent.example IN RRSIG AAAA 5 3 ... \ subdomain.parent.example IN RRSIG AAAA 5 3 ... \
(ZSK key tag) subdomain.parent.example. ... (ZSK key tag) subdomain.parent.example. ...
deeper.subdomain.parent.example. IN AAAA 2001:db8::18 deeper.subdomain.parent.example. IN AAAA 2001:db8::18
deeper.subdomain.parent.example IN RRSIG AAAA 5 3 ... \ deeper.subdomain.parent.example IN RRSIG AAAA 5 3 ... \
(ZSK key tag) subdomain.parent.example. ... (ZSK key tag) subdomain.parent.example. ...
Figure 1: Example use of "ds=..." Figure 1: Example Use of "ds=..."
8. Examples of Split-Horizon DNS Configuration
Two examples are shown below. The first example shows a company with
an internal-only DNS server that claims the entire zone for that
company (e.g., *.example.com). In the second example, the internal
servers resolves only a subdomain of the company's zone (e.g.,
*.internal.example.com).
8.1. Split-Horizon Entire Zone 8. Example Split-Horizon DNS Configuration
Consider an organization that operates "example.com", and runs a Consider an organization that operates "example.com" and runs a
different version of its global domain on its internal network. different version of its global domain on its internal network.
First, the host and network both need to support one of the discovery First, the host and network both need to support one of the discovery
mechanisms described in Section 5. Figure 2 shows discovery using mechanisms described in Section 5. Figure 2 shows discovery using
DNR and PvD. DNR and PvD information.
Validation is then perfomed using either an external resolver Validation is then performed using either an external resolver
(Section 8.1.1) or DNSSEC (Section 8.1.2). (Section 8.1) or DNSSEC (Section 8.2).
*Steps 1-2*: The client determines the network's DNS server *Steps 1-2*: The client determines the network's DNS server
(dns.example.net) and Provisioning Domain (pvd.example.com) using (dns.example.net) and PvD information (pvd.example.com) using DNR
DNR [RFC9463] and PvD [RFC8801], using one of DNR Router [RFC9463] and PvDs [RFC8801], using one of the following: DNR
Solicitation, DHCPv4, or DHCPv6. Router Solicitation, DHCPv4, or DHCPv6.
*Step 3-5*: The client connects to dns.example.net using an *Steps 3-5*: The client connects to dns.example.net using an
encrypted transport as indicated in DNR [RFC9463], authenticating encrypted transport as indicated in DNR [RFC9463], authenticating
the server to its name using TLS ([RFC8310], Section 8), and sends the server to its name using TLS (Section 8 of [RFC8310]), and
it a query for the address of pvd.example.com. sends it a query for the address of pvd.example.com.
*Steps 6-7*: The client connects to the PvD server, validates its *Steps 6-7*: The client connects to the PvD server, validates its
certificate, and retrieves the provisioning domain JSON certificate, and retrieves the PvD JSON information indicated by
information indicated by the associated PvD. The PvD contains: the associated PvD. The PvD contains:
{ {
"identifier": "pvd.example.com", "identifier": "pvd.example.com",
"expires": "2025-05-23T06:00:00Z", "expires": "2025-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"splitDnsClaims": [{ "splitDnsClaims": [{
"resolver": "dns.example.net", "resolver": "dns.example.net",
"parent": "example.com", "parent": "example.com",
"subdomains": ["*"], "subdomains": ["*"],
"algorithm": "SHA384", "algorithm": "SHA384",
skipping to change at page 14, line 28 skipping to change at line 583
|-| now knows DNR ADN & | | | | |-| now knows DNR ADN & | | | |
| | PvD FQDN | | | | | | PvD FQDN | | | |
| |---------------------------/ | | | | |---------------------------/ | | |
| | | | | | | |
| TLS connection to dns.example.net (3) | | | TLS connection to dns.example.net (3) | |
|------------------------------------>| | | |------------------------------------>| | |
| ---------------------------\ | | | | ---------------------------\ | | |
|-| validate TLS certificate | | | | |-| validate TLS certificate | | | |
| |--------------------------/ | | | | |--------------------------/ | | |
| | | | | | | |
| resolve pvd.example.com (4) | | | | resolve pvd.example.com (4) | | |
|------------------------------------>| | | |------------------------------------>| | |
| | | | | | | |
| A or AAAA records (5) | | | | A or AAAA records (5) | | |
|<------------------------------------| | | |<------------------------------------| | |
| | | | | | | |
| https://pvd.example.com/.well-known/pvd (6) | | | https://pvd.example.com/.well-known/pvd (6) | |
|---------------------------------------------->| | |---------------------------------------------->| |
| | | | | | | |
| 200 OK (JSON Additional Information) (7) | | | 200 OK (JSON Additional Information) (7) | |
|<----------------------------------------------| | |<----------------------------------------------| |
| ----------------------------------\ | | | | ----------------------------------\ | | |
|-| {..., "splitDnsClaims": [...] } | | | | |-| {..., "splitDnsClaims": [...] } | | | |
| |---------------------------------/ | | | | |---------------------------------/ | | |
Figure 2: An Example of Learning Local Claims of DNS Authority Figure 2: An Example of Learning Local Claims of DNS Authority
8.1.1. Verification Using an External Resolver 8.1. Verification Using an External Resolver
Figure 3 shows the steps performed to verify the local claims of DNS Figure 3 shows the steps performed to verify the local claims of DNS
authority using an external resolver. authority using an external resolver.
*Steps 1-2*: The client uses an encrypted DNS connection to an *Steps 1-2*: The client uses an encrypted DNS connection to an
external resolver to issue TXT queries for the Verification external resolver to issue TXT queries for the Verification
Records. The TXT lookup returns a token that matches the claim. Records. The TXT lookup returns a token that matches the claim.
*Step 3*: The client has validated that example.com has authorized *Step 3*: The client has validated that example.com has authorized
dns.example.net to serve example.com. When the client connects dns.example.net to serve example.com. When the client connects
using an encrypted transport as indicated in DNR [RFC9463], it using an encrypted transport as indicated in DNR [RFC9463], it
will authenticate the server to its name using TLS ([RFC8310], will authenticate the server to its name using TLS (Section 8 of
Section 8), and send queries to resolve any names that fall within [RFC8310]) and send queries to resolve any names that fall within
the claimed zones. the claimed zones.
+---------+ +--------------------+ +----------+ +---------+ +--------------------+ +----------+
| Client | | Network's | | External | | Client | | Network's | | External |
| | | Encrypted Resolver | | Resolver | | | | Encrypted Resolver | | Resolver |
+---------+ +--------------------+ +----------+ +---------+ +--------------------+ +----------+
| | | | | |
| TLS connection | | | TLS connection | |
|--------------------------------------------------->| |--------------------------------------------------->|
| ---------------------------\ | | | ---------------------------\ | |
|-| validate TLS certificate | | | |-| validate TLS certificate | | |
| |--------------------------| | | | |--------------------------| | |
| | | | | |
| TXT? dns.example.net.\ | | | TXT? dns.example.net.\ | |
| _splitdns-challenge.example.com (1) | | | _splitdns-challenge.example.com (1) | |
|--------------------------------------------------->| |--------------------------------------------------->|
| | | | | |
| TXT "token=ABC..." (2) | | | TXT "token=ABC..." (2) | |
|<---------------------------------------------------| |<---------------------------------------------------|
| --------------------------------\ | | | --------------------------------\ | |
|-| dns.example.net is authorized | | | |-| dns.example.net is authorized | | |
| ----------------------\---------| | | | ----------------------\---------| | |
|-| finished validation | | | |-| finished validation | | |
| |---------------------| | | | |---------------------| | |
| | | | | |
| use dns.example.net when | | | use dns.example.net when | |
| resolving example.com (3) | | | resolving example.com (3) | |
|----------------------------------------->| | |----------------------------------------->| |
| | | | | |
Figure 3: Verifying claims using an external resolver Figure 3: Verifying Claims Using an External Resolver
8.1.2. Verification using DNSSEC 8.2. Verification Using DNSSEC
Figure 4 shows the steps performed to verify the local claims of DNS Figure 4 shows the steps performed to verify the local claims of DNS
authority using DNSSEC. authority using DNSSEC.
*Steps 1-2*: The DNSSEC-validating client queries the network *Steps 1-2*: The DNSSEC-validating client queries the network's
encrypted resolver to issue TXT queries for the Verification encrypted resolver to issue TXT queries for the Verification
Records. The TXT lookup will return a signed response containing Records. The TXT lookup will return a signed response containing
the expected token. The client then performs full DNSSEC the expected token. The client then performs full DNSSEC
validation locally. validation locally.
*Step 3*: If the DNSSEC validation is successful and the token *Step 3*: If the DNSSEC validation is successful and the token
matches, then this Authorization Claim is validated. Once the matches, then this authorization claim is validated. Once the
client connects using an encrypted transport as indicated in DNR client connects using an encrypted transport as indicated in DNR
[RFC9463], it will authenticate the server to its name using TLS [RFC9463], it will authenticate the server to its name using TLS
([RFC8310], Section 8), and send queries to resolve any names that (Section 8 of [RFC8310]) and send queries to resolve any names
fall within the claimed zones. that fall within the claimed zones.
+---------+ +--------------------+ +---------+ +--------------------+
| Client | | Network's | | Client | | Network's |
| | | Encrypted Resolver | | | | Encrypted Resolver |
+---------+ +--------------------+ +---------+ +--------------------+
| | | |
| DNSSEC OK (DO), TXT? dns.example.net.\ | | DNSSEC OK (DO), TXT? dns.example.net.\ |
| _splitdns-challenge.example.com (1) | | _splitdns-challenge.example.com (1) |
|-------------------------------------------------------------->| |-------------------------------------------------------------->|
| | | |
| TXT token=DEF..., Signed Answer (RRSIG) (2) | | TXT token=DEF..., Signed Answer (RRSIG) (2) |
|<--------------------------------------------------------------| |<--------------------------------------------------------------|
| -------------------------------------\ | | -------------------------------------\ |
|-| DNSKEY+TXT matches RRSIG, use TXT | | |-| DNSKEY+TXT matches RRSIG, use TXT | |
| |------------------------------------| | | |------------------------------------| |
| --------------------------------\ | | --------------------------------\ |
|-| dns.example.net is authorized | | |-| dns.example.net is authorized | |
| |-------------------------------| | | |-------------------------------| |
| ----------------------\ | | ----------------------\ |
|-| finished validation | | |-| finished validation | |
| |---------------------| | | |---------------------| |
| | | |
| use encrypted network-designated resolver for example.com (3) | | use encrypted network-designated resolver for example.com (3) |
|-------------------------------------------------------------->| |-------------------------------------------------------------->|
| | | |
Figure 4: An Example of Verifying Claims using DNSSEC Figure 4: An Example of Verifying Claims Using DNSSEC
9. Operational Efficiency in Split-Horizon Deployments 9. Operational Efficiency in Split-Horizon Deployments
In many split-horizon deployments, all non-public domain names are In many split-horizon deployments, all non-public domain names are
placed in a separate child zone (e.g., internal.example.com). In placed in a separate child zone (e.g., internal.example.com). In
this configuration, the message flow is similar to Section 8.1, this configuration, the message flow is similar to the flow described
except that queries for hosts not within the subdomain (e.g., in Section 8.1, except that queries for hosts not within the
www.example.com) are sent to the external resolver rather than the subdomain (e.g., www.example.com) are sent to the external resolver
resolver for internal.example.com. rather than the resolver for internal.example.com.
As in Section 8.1, the internal DNS server will need a certificate As specified in Section 8.1, the internal DNS server will need a
signed by a Certification Authority (CA) trusted by the client. certificate signed by a Certification Authority (CA) trusted by the
client.
Although placing internal domains inside a child domain is Although placing internal domains inside a child domain is
unnecessary to prevent leakage, such placement reduces the frequency unnecessary to prevent leakage, such placement reduces the frequency
of changes to the Verification Record, this document recommends the of changes to the Verification Record. This document recommends that
internal domains be kept in a child zone of the local domain hints the internal domains be kept in a child zone of the local domain
advertised by the network. For example, if the PvD "dnsZones" entry hints advertised by the network. For example, if the PvD "dnsZones"
is "internal.example.com" and the network-provided DNS resolver is entry is "internal.example.com" and the network-provided DNS resolver
"ns1.internal.example.com", the network operator can structure the is "ns1.internal.example.com", the network operator can structure the
internal domain names as "private1.internal.example.com", internal domain names as "private1.internal.example.com",
"private2.internal.example.com", etc. The network-designated "private2.internal.example.com", etc. The network-designated
resolver will be used to resolve the subdomains of the local domain resolver will be used to resolve the subdomains of the local domain
hint "*.internal.example.com". hint "*.internal.example.com".
10. Validation with IKEv2 10. Validation with IKEv2
When the endpoint is using a VPN tunnel and the tunnel is IPsec, the When the endpoint is using a VPN tunnel and the tunnel is IPsec, the
encrypted DNS resolver hosted by the VPN service provider can be encrypted DNS resolver hosted by the VPN service provider can be
securely discovered by the endpoint using the ENCDNS_IP*_* IKEv2 securely discovered by the endpoint using the ENCDNS_IP* IKEv2
Configuration Payload Attribute Types defined in [RFC9464]. The VPN Configuration Payload Attribute Types defined in [RFC9464]. The VPN
client can use the mechanism defined in Section 6 to validate that client can use the mechanism defined in Section 6 to validate that
the discovered encrypted DNS resolver is authorized to answer for the the discovered encrypted DNS resolver is authorized to answer for the
claimed subdomains. claimed subdomains.
Other VPN tunnel types have similar configuration capabilities, not Other VPN tunnel types have similar configuration capabilities. Note
detailed here. that those capabilities are not discussed in this document.
11. Authorization Claim Update 11. Authorization Claim Update
A verification record is only valid until it expires. Expiry occurs A Verification Record is only valid until it expires. Expiry occurs
when the Time To Live (TTL) or DNSSEC signature validity period ends. when the Time To Live (TTL) or DNSSEC signature validity period ends.
Shortly before verification record expiry, clients MUST fetch the Shortly before Verification Record expiry, clients MUST fetch the
verification records again and repeat the verification procedure. Verification Records again and repeat the verification procedure.
This ensures the availability of updated and valid verification This ensures the availability of updated and valid Verification
records. Records.
A new verification record must be added to the RRset before the A new Verification Record must be added to the RRset before the
corresponding Authorization Claim is updated. After the claim is corresponding authorization claim is updated. After the claim is
updated, the following procedures can be used: updated, the following procedures can be used:
1. DHCP reconfiguration can be initiated by a DHCP server that has 1. DHCP reconfiguration can be initiated by a DHCP server that has
previously communicated with a DHCP client and negotiated for the previously communicated with a DHCP client and negotiated for the
DHCP client to listen for Reconfigure messages, to prompt the DHCP client to listen for Reconfigure messages, to prompt the
DHCP clients for dynamically requesting the updated Authorization DHCP client to dynamically request the updated authorization
Claim. This process avoids the need for the client to wait for claim. This process avoids the need for the client to wait for
its current lease to complete and request a new one, enabling the its current lease to complete and request a new one, enabling the
lease renewal to be driven by the DHCP server. lease renewal to be driven by the DHCP server.
2. The sequence number in the RA PvD option will be incremented, 2. The sequence number in the RA PvD option will be incremented,
requiring clients to fetch PvD additional information from the requiring clients to fetch PvD Additional Information from the
HTTPS server due to the updated sequence number in the new RA HTTPS server due to the updated sequence number in the new RA
([RFC8801], Section 4.1). (Section 4.1 of [RFC8801]).
3. The old verification record needs to be maintained until the DHCP 3. The old Verification Record needs to be maintained until the DHCP
lease time or PvD Additional Information expiry. lease or PvD Additional Information expires.
12. Security Considerations 12. Security Considerations
The Authentication Domain Names of authorized local encrypted The ADNs of authorized local encrypted resolvers are revealed in the
resolvers are revealed in the Owner Names of Verification Records. owner names of Verification Records. This makes it easier for domain
This makes it easier for domain owners to understand which resolvers owners to understand which resolvers they are currently authorizing
they are currently authorizing to implement Split DNS. However, this to implement split DNS. However, this could create a confidentiality
could create a confidentiality issue if the local encrypted issue if the local encrypted resolver's name contains sensitive
resolver's name contains sensitive information or is part of a secret information or is part of a secret subdomain. To mitigate the impact
subdomain. To mitigate the impact of such leakage, local resolvers of such leakage, local resolvers should be given names that do not
should be given names that do not reveal any sensitive information. reveal any sensitive information.
The security properties of hashing algorithms are not fixed. The security properties of hashing algorithms are not fixed.
Algorithm Agility (see [RFC7696]) is achieved by providing Algorithm agility (see [RFC7696]) is achieved by providing
implementations with flexibility to choose hashing algorithms from implementations with the flexibility to choose hashing algorithms
the ZONEMD Schemes registry ([RFC8976], Section 5.2). from the "ZONEMD Hash Algorithms" registry (Section 5.3 of
[RFC8976]).
The entropy of salt depends on a high-quality pseudo-random number The entropy of a salt depends on a high-quality pseudorandom number
generator. For further discussion on random number generation, see generator. For further discussion on random number generation, see
[RFC4086]. The salt MUST be regenerated whenever the authorization [RFC4086]. The salt MUST be regenerated whenever the authorization
claim is updated. claim is updated.
13. IANA Considerations 13. IANA Considerations
13.1. DHCP Split DNS Authentication Algorithm 13.1. New DHCP Authentication Algorithm for Split DNS
IANA is requested to add the following entry to the "Protocol Name
Space Values" registry on the "Dynamic Host Configuration Protocol
(DHCP) Authentication Option Name Spaces" page:
* Value: $TBD1 IANA has added the following entry to the "Protocol Name Space
Values" registry in the "Dynamic Host Configuration Protocol (DHCP)
Authentication Option Name Spaces" registry group:
* Description: Split-horizon DNS Value: 4
* Reference: (This Document) Description: Split-horizon DNS
13.2. Provisioning Domains Split DNS Additional Information Reference: RFC 9704
IANA is requested to add the following entry to the "Additional 13.2. New PvD Additional Information Type for Split DNS
Information PvD Keys" registry under the "Provisioning Domains
(PvDs)" registry group:
* JSON key: "splitDnsClaims" IANA has added the following entry to the "Additional Information PvD
Keys" registry in the "Provisioning Domains (PvDs)" registry group:
* Description: "Verifiable locally served domains" JSON key: splitDnsClaims
* Type: Array of Objects Description: Verifiable locally served domains
* Example: Type: Array of Objects
Example:
[{ [{
"resolver": "dns.example.net", "resolver": "dns.example.net",
"parent": "example.com", "parent": "example.com",
"subdomains": ["sub"], "subdomains": ["sub"],
"algorithm": "SHA384", "algorithm": "SHA384",
"salt": "abc...123" "salt": "abc...123"
}] }]
* Reference: (This document) Reference: RFC 9704
13.3. New PvD Split DNS Claims Registry 13.3. New PvD Split DNS Claims Registry
IANA is requested to create a new registry "PvD Split DNS Claims" IANA has created a new registry called "PvD Split DNS Claims" within
Registry, within the "Provisioning Domains (PvDs)" registry page. the "Provisioning Domains (PvDs)" registry group. This new registry
This new registry reserves JSON keys for use in sub-dictionaries reserves JSON keys for use in sub-dictionaries under the
under the splitDnsClaims JSON key. The initial contents of this splitDnsClaims JSON key. The initial contents of this registry, as
registry, as discussed in Section 5.2.2, are listed below and will be discussed in Section 5.2.2, are listed below and have been added to
added to the IANA registry: the registry:
+------------+-----------------------+---------+-----------------+-----------+ +==========+================+=======+===================+=========+
| JSON key | Description | Type | Example | Reference | |JSON key | Description |Type | Example |Reference|
+------------+-----------------------+---------+-----------------+-----------+ +==========+================+=======+===================+=========+
| resolver | The Authentication | String |"dns.example.net"| [RFCXXXX] | |resolver | The |String | "dns.example.net" |RFC 9704 |
| | Domain Name | | | | | | Authentication | | | |
| | | | | | | | Domain Name | | | |
| parent | The parent zone name | String | "example.com" | [RFCXXXX] | +----------+----------------+-------+-------------------+---------+
| | | | | | |parent | The parent |String | "example.com" |RFC 9704 |
| subdomains | An array containing | Array of| ["sub"] | | | | zone name | | | |
| | the claimed subdomains| Strings | | [RFCXXXX] | +----------+----------------+-------+-------------------+---------+
| | | | | | |subdomains| An array |Array | ["sub"] |RFC 9704 |
| algorithm | The hash algorithm | String | "SHA384" | [RFCXXXX] | | | containing the |of | | |
| | | | | | | | claimed |Strings| | |
| salt | The salt (base64url) | String | "abc...123" | [RFCXXXX] | | | subdomains | | | |
| | | | | | +----------+----------------+-------+-------------------+---------+
+------------+-----------------------+---------+-----------------+-----------+ |algorithm | The hash |String | "SHA384" |RFC 9704 |
| | algorithm | | | |
+----------+----------------+-------+-------------------+---------+
|salt | The salt |String | "abc...123" |RFC 9704 |
| | (base64url) | | | |
+----------+----------------+-------+-------------------+---------+
Figure 5: Split DNS Claims Table 1: Split DNS Claims
The keys defined in this document are mandatory. Any new assignments The keys defined in this document are mandatory. Any new assignments
of keys will be considered as optional for the purpose of the of keys will be considered as optional for the purpose of the
mechanism described in this document. mechanism described in this document.
New assignments in the "PvD Split DNS Claims Registry" registry will New assignments in the "PvD Split DNS Claims" registry will be
be administered by IANA through Expert Review [RFC8126]. Experts are administered by IANA through Expert Review [RFC8126]. Experts are
requested to ensure that defined keys do not overlap in names or requested to ensure that defined keys do not overlap in names or
semantics. semantics.
13.3.1. Guidelines for the Designated Experts 13.3.1. Guidelines for the Designated Experts
It is suggested that multiple designated experts be appointed for It is suggested that multiple designated experts be appointed for
registry change requests. registry change requests.
Criteria that should be applied by the designated experts include Criteria that should be applied by the designated experts include
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
skipping to change at page 20, line 33 skipping to change at line 877
Registration requests are evaluated within a three-week review period Registration requests are evaluated within a three-week review period
on the advice of one or more designated experts. Within the review on the advice of one or more designated experts. Within the review
period, the designated experts will either approve or deny the period, the designated experts will either approve or deny the
registration request, communicating this decision to IANA. Denials registration request, communicating this decision to IANA. Denials
should include an explanation and, if applicable, suggestions as to should include an explanation and, if applicable, suggestions as to
how to make the request successful. how to make the request successful.
13.4. DNS Underscore Name 13.4. DNS Underscore Name
IANA is requested to add the following entry to the "Underscored and IANA has added the following entry to the "Underscored and Globally
Globally Scoped DNS Node Names" registry under the "Domain Name Scoped DNS Node Names" registry in the "Domain Name System (DNS)
System (DNS) Parameters" registry group: Parameters" registry group:
* RR Type: TXT
* _NODE NAME: _splitdns-challenge
* Reference: (This document)
14. Acknowledgements
Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, RR Type: TXT
Michael Richardson, Bernie Volz, Éric Vyncke and Vinny Parla for the
discussion and comments.
Thanks to Tianran Zhou for the opsdir review, Anthony Somerset for _NODE NAME: _splitdns-challenge
the dnsdir review, Watson Ladd for the secdir review, Bob Halley for
the intdir review and Mallory Knodel for the genart review.
Thanks to Mohamed Boucadair for the Shepherd review. Reference: RFC 9704
15. References 14. References
15.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
skipping to change at page 22, line 38 skipping to change at line 966
[RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
Hardaker, "Message Digest for DNS Zones", RFC 8976, Hardaker, "Message Digest for DNS Zones", RFC 8976,
DOI 10.17487/RFC8976, February 2021, DOI 10.17487/RFC8976, February 2021,
<https://www.rfc-editor.org/info/rfc8976>. <https://www.rfc-editor.org/info/rfc8976>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023, RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>. <https://www.rfc-editor.org/info/rfc9525>.
15.2. Informative References 14.2. Informative References
[I-D.ietf-dnsop-domain-verification-techniques] [DOMAIN-VERIFICATION-TECHNIQUES]
Sahib, S. K., Huque, S., Wouters, P., and E. Nygren, Sahib, S. K., Huque, S., Wouters, P., and E. Nygren,
"Domain Control Validation using DNS", Work in Progress, "Domain Control Validation using DNS", Work in Progress,
Internet-Draft, draft-ietf-dnsop-domain-verification- Internet-Draft, draft-ietf-dnsop-domain-verification-
techniques-04, 3 March 2024, techniques-06, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
domain-verification-techniques-04>. domain-verification-techniques-06>.
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
Configuration Protocol (DHCP) Client Fully Qualified Configuration Protocol (DHCP) Client Fully Qualified
Domain Name (FQDN) Option", RFC 4702, Domain Name (FQDN) Option", RFC 4702,
DOI 10.17487/RFC4702, October 2006, DOI 10.17487/RFC4702, October 2006,
<https://www.rfc-editor.org/info/rfc4702>. <https://www.rfc-editor.org/info/rfc4702>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
skipping to change at page 25, line 5 skipping to change at line 1078
[RFC9464] Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov, [RFC9464] Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov,
"Internet Key Exchange Protocol Version 2 (IKEv2) "Internet Key Exchange Protocol Version 2 (IKEv2)
Configuration for Encrypted DNS", RFC 9464, Configuration for Encrypted DNS", RFC 9464,
DOI 10.17487/RFC9464, November 2023, DOI 10.17487/RFC9464, November 2023,
<https://www.rfc-editor.org/info/rfc9464>. <https://www.rfc-editor.org/info/rfc9464>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024, RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>. <https://www.rfc-editor.org/info/rfc9499>.
Acknowledgements
Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie,
Michael Richardson, Bernie Volz, Éric Vyncke, and Vinny Parla for the
discussion and comments.
Thanks to Tianran Zhou for the opsdir review, Anthony Somerset for
the dnsdir review, Watson Ladd for the secdir review, Bob Halley for
the intdir review, and Mallory Knodel for the genart review.
Thanks to Mohamed Boucadair for the Shepherd review.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy Tirumaleswar Reddy.K
Nokia Nokia
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Dan Wing Dan Wing
Citrix Systems, Inc. Citrix Systems, Inc.
4988 Great America Pkwy 4988 Great America Pkwy
Santa Clara, CA 95054 Santa Clara, CA 95054
United States of America United States of America
Email: danwing@gmail.com Email: danwing@gmail.com
 End of changes. 139 change blocks. 
338 lines changed or deleted 327 lines changed or added

This html diff was produced by rfcdiff 1.48.