rfc9704v1.txt		rfc9704.txt
	Internet Engineering Task Force (IETF) T. Reddy.K		Internet Engineering Task Force (IETF) T. Reddy.K
	Request for Comments: 9704 Nokia		Request for Comments: 9704 Nokia
	Category: Standards Track D. Wing		Category: Standards Track D. Wing
	ISSN: 2070-1721 Citrix		ISSN: 2070-1721 Citrix
	K. Smith		K. Smith
	Vodafone		Vodafone
	B. Schwartz		B. Schwartz
	Meta		Meta
	December 2024		January 2025
	Establishing Local DNS Authority in Validated Split-Horizon Environments		Establishing Local DNS Authority in Validated Split-Horizon Environments
	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
	skipping to change at line 40 ¶		skipping to change at line 40 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9704.		https://www.rfc-editor.org/info/rfc9704.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2025 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	skipping to change at line 68 ¶		skipping to change at line 68 ¶
	4. Requirements		4. Requirements
	5. Establishing Local DNS Authority		5. Establishing Local DNS Authority
	5.1. Example		5.1. Example
	5.2. Conveying Authorization Claims		5.2. Conveying Authorization Claims
	5.2.1. Using DHCP		5.2.1. Using DHCP
	5.2.2. Using Provisioning Domains		5.2.2. Using Provisioning Domains
	6. Validating Authority over Local Domain Hints		6. Validating Authority over Local Domain Hints
	6.1. Using a Preconfigured External Resolver		6.1. Using a Preconfigured External Resolver
	6.2. Using DNSSEC		6.2. Using DNSSEC
	7. Delegating DNSSEC Across Split DNS Boundaries		7. Delegating DNSSEC Across Split DNS Boundaries
	8. Examples of Split-Horizon DNS Configuration		8. Example Split-Horizon DNS Configuration
	8.1. Split-Horizon Entire Zone		8.1. Verification Using an External Resolver
	8.1.1. Verification Using an External Resolver		8.2. Verification Using DNSSEC
	8.1.2. Verification Using DNSSEC
	9. Operational Efficiency in Split-Horizon Deployments		9. Operational Efficiency in Split-Horizon Deployments
	10. Validation with IKEv2		10. Validation with IKEv2
	11. Authorization Claim Update		11. Authorization Claim Update
	12. Security Considerations		12. Security Considerations
	13. IANA Considerations		13. IANA Considerations
	13.1. DHCP Split DNS Authentication Algorithm		13.1. New DHCP Authentication Algorithm for Split DNS
	13.2. Provisioning Domains Split DNS Additional Information		13.2. New PvD Additional Information Type for Split DNS
	13.3. New PvD Split DNS Claims Registry		13.3. New PvD Split DNS Claims Registry
	13.3.1. Guidelines for the Designated Experts		13.3.1. Guidelines for the Designated Experts
	13.4. DNS Underscore Name		13.4. DNS Underscore Name
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	14.2. Informative References		14.2. Informative References
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	skipping to change at line 148 ¶		skipping to change at line 147 ¶
	trust and rely on these hints.		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 expects that local DNS servers will be securely		In this specification, network operators securely identify the local
	identified and that each local domain hint will be checked against a		DNS servers, and clients check each local domain hint against a
	globally valid parent 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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 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.
	skipping to change at line 178 ¶		skipping to change at line 177 ¶
	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 the definition of "split DNS" in Section 6		the global DNS. (See the definition of "split DNS" in Section 6
	of [RFC9499].)		of [RFC9499].)
	Validated Split Horizon: Indicates that a split-horizon		Validated Split Horizon: A split-horizon configuration that is
	configuration for some name is considered "validated" if the		authorized by the parents of the affected names and confirmed by
	client has confirmed that a parent of that name has authorized		the client. Such authorization generally extends to the entire
	this resolver to serve its own responses for that name. Such		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.
			Long lines in examples are wrapped using a single backslash ("\") per
			[RFC8792].
	3. Scope		3. Scope
	The protocol described in this document is designed to support the		The protocol described in this document is designed to support the
	ability of a domain owner to create or authorize a split-horizon view		ability of a domain owner to create or authorize a split-horizon view
	of their domain. The protocol does not support split-horizon views		of their domain. The protocol does not support split-horizon views
	created by any other entity. Thus, DNS filtering is not enabled by		created by any other entity. Thus, DNS filtering is not enabled by
	this 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.
	The 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:
	skipping to change at line 260 ¶		skipping to change at line 260 ¶
	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., using
	that identifying name MUST be the name used in any corresponding		DNR), that identifying name MUST be the name used in any
	authorization claim. Otherwise (e.g., DDR using IP addresses), the		corresponding authorization claim. Otherwise (e.g., DDR using IP
	resolver MUST present a validatable certificate containing a		addresses), the resolver MUST present a validatable certificate
	subjectAltName that matches the authorization claim using the		containing a subjectAltName that matches the authorization claim
	validation techniques for matching as described in [RFC9525].		using the 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.
	skipping to change at line 318 ¶		skipping to change at line 319 ¶
	* 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.
	skipping to change at line 408 ¶		skipping to change at line 407 ¶
	below.		below.
	6.1. Using a Preconfigured 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 an 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 timeframe, 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. The client MAY
	client might perform DNSSEC validation for the verification query		perform DNSSEC validation for the verification query even if it has
	even if it has disabled DNSSEC validation for other DNS queries.		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 full		resolvers, performing iterative resolution locally) and performs full
	DNSSEC validation locally [RFC6698]. The result is processed based		DNSSEC validation locally [RFC6698]. The result is processed based
	on its DNSSEC validation state (Section 4.3 of [RFC4035]):		on its DNSSEC validation state (Section 4.3 of [RFC4035]):
	*Secure*: The response is used for validation.		*Secure*: The response is used for validation.
	skipping to change at line 442 ¶		skipping to change at line 441 ¶
	*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 method described in Section 6.1, to		different method, such as the method described in Section 6.1, to
	ensure compatibility with unsigned names. If the client chooses		ensure compatibility with unsigned names. If the client chooses
	not to retry (e.g., no configured policy to validate the		not to retry (e.g., no configured policy to validate the
	authorization claim using an external resolver), it MUST consider		authorization claim using an external resolver), it MUST consider
	validation to 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, encoded in		Record whose value is the RDATA of a single DS record, encoded in
	base64url. This DS record authorizes a DNSKEY whose owner name is		base64url. This DS record authorizes a DNSKEY whose owner name is
	skipping to change at line 466 ¶		skipping to change at line 465 ¶
	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 Resource Record		encrypted resolver. At least one resulting DNSKEY Resource Record
	(RR) MUST match the DS RDATA from the "ds" key in the Verification		(RR) MUST match the DS RDATA from the "ds" key in the Verification
	Record. All local resolution results for subdomains in this claim		Record. All local resolution results for subdomains in this claim
	MUST offer RRSIGs that chain to a DNSKEY whose RDATA is identical to		MUST offer RRSIGs that chain to a DNSKEY whose RDATA is identical to
	one of these 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.
	Verification Record, the client MUST disable DNSSEC validation when
	resolving the claimed subdomains via this local encrypted resolver.
	Note that in this configuration, any claimed subdomains MUST be		Note that when the local resolver does not have a globally trusted
	marked as unsigned in the public DNS. Otherwise, resolution results		DNSKEY, any claimed subdomains MUST be marked as unsigned in the
	would be rejected by validating stubs that do not implement this		public DNS. Otherwise, local resolution results would be rejected by
	specification.		validating stubs that do not implement this specification.
	;; Parent zone.		;; Parent zone.
	$ORIGIN parent.example.		$ORIGIN parent.example.
	; Parent zone's public Key Signing Key (KSK)		; Parent zone's public Key Signing Key (KSK)
	; and Zone Signing Key (ZSK).		; 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
	skipping to change at line 518 ¶		skipping to change at line 515 ¶
	(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		8. Example 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
	server resolves only a subdomain of the company's zone (e.g.,
	*.internal.example.com).
	8.1. Split-Horizon Entire Zone
	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 information.		information from the DNR and the PvD.
	Validation is then performed 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 PvD information (pvd.example.com) using DNR		(dns.example.net) and PvD ID (pvd.example.com) using DNR and a
	[RFC9463] and PvDs [RFC8801], using one of the following: DNR		PvD, along with one of the following: DNR Router Solicitation,
	Router Solicitation, DHCPv4, or DHCPv6.		DHCPv4, or DHCPv6.
	*Steps 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 (Section 8 of [RFC8310]), and		the server to its name using TLS (Section 8 of [RFC8310]), and
	sends 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 PvD JSON information indicated by		certificate, and retrieves the PvD Additional Information
	the associated PvD. The PvD contains:		indicated by the associated PvD. The JSON object 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 line 591 ¶		skipping to change at line 580 ¶
	|-| 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
	skipping to change at line 636 ¶		skipping to change at line 625 ¶
	| | | 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's		*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.
	skipping to change at line 678 ¶		skipping to change at line 667 ¶
	[RFC9463], it will authenticate the server to its name using TLS		[RFC9463], it will authenticate the server to its name using TLS
	(Section 8 of [RFC8310]) and send queries to resolve any names		(Section 8 of [RFC8310]) and send queries to resolve any names
	that 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 | |
	| |-------------------------------| |		| |-------------------------------| |
	skipping to change at line 712 ¶		skipping to change at line 701 ¶
	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 the flow described		this configuration, the message flow is similar to the flow described
	in Section 8.1, except that queries for hosts not within the		in Section 8.1, except that queries for hosts not within the
	subdomain (e.g., www.example.com) are sent to the external resolver		subdomain (e.g., www.example.com) are sent to the external resolver
	rather than the resolver for internal.example.com.		rather than the resolver for internal.example.com.
	As specified in Section 8.1, the internal DNS server will need a		As specified in Section 8.1, the internal DNS server will need a
	certificate signed by a Certification Authority (CA) trusted by the		certificate signed by a Certification Authority (CA) trusted by the
	client.		client.
	Although placing internal domains inside a child domain is		Although placing internal domains inside a child domain is not
	unnecessary to prevent leakage, such placement reduces the frequency		necessary to prevent leakage, such placement reduces the frequency of
	of changes to the Verification Record. This document recommends that		changes to the Verification Record. This document recommends that
	the internal domains be kept in a child zone of the local domain		the internal domains be kept in a child zone of the local domain
	hints advertised by the network. For example, if the PvD "dnsZones"		hints advertised by the network. For example, if the PvD "dnsZones"
	entry is "internal.example.com" and the network-provided DNS resolver		entry is "internal.example.com" and the network-provided DNS resolver
	is "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. Note		Other VPN tunnel types have similar configuration capabilities. Note
	that those capabilities are not discussed in this document.		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 client to dynamically request 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 can 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
	(Section 4.1 of [RFC8801]).		(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 ADNs of authorized local encrypted resolvers are revealed in the		The ADNs of authorized local encrypted resolvers are revealed in the
	owner names of Verification Records. This makes it easier for domain		owner names of Verification Records. This makes it easier for domain
	owners to understand which resolvers they are currently authorizing		owners to understand which resolvers they are currently authorizing
	to implement split DNS. However, this could create a confidentiality		to implement split DNS. However, this could create a confidentiality
	issue if the local encrypted resolver's name contains sensitive		issue if the local encrypted resolver's name contains sensitive
	information or is part of a secret subdomain. To mitigate the impact		information or is part of a secret subdomain. To mitigate the impact
	of such leakage, local resolvers should be given names that do not		of such leakage, local resolvers 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 the flexibility to choose hashing algorithms		implementations with the flexibility to choose hashing algorithms
	from the "ZONEMD Schemes" registry (Section 5.2 of [RFC8976]).		from the "ZONEMD Hash Algorithms" registry (Section 5.3 of
			[RFC8976]).
	The entropy of a salt depends on a high-quality pseudorandom 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 has added the following entry to the "Protocol Name Space		IANA has added the following entry to the "Protocol Name Space
	Values" registry in the "Dynamic Host Configuration Protocol (DHCP)		Values" registry in the "Dynamic Host Configuration Protocol (DHCP)
	Authentication Option Name Spaces" registry group:		Authentication Option Name Spaces" registry group:
	Value: 4		Value: 4
	Description: Split-horizon DNS		Description: Split-horizon DNS
	Reference: RFC 9704		Reference: RFC 9704
	13.2. Provisioning Domains Split DNS Additional Information		13.2. New PvD Additional Information Type for Split DNS
	IANA has added the following entry to the "Additional Information PvD		IANA has added the following entry to the "Additional Information PvD
	Keys" registry in the "Provisioning Domains (PvDs)" registry group:		Keys" registry in the "Provisioning Domains (PvDs)" registry group:
	JSON key: splitDnsClaims		JSON key: splitDnsClaims
	Description: Verifiable locally served domains		Description: Verifiable locally served domains
	Type: Array of Objects		Type: Array of Objects
	skipping to change at line 1106 ¶		skipping to change at line 1096 ¶
	Authors' Addresses		Authors' Addresses
	Tirumaleswar Reddy.K		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
	Santa Clara, CA 95054
	United States of America		United States of America
	Email: danwing@gmail.com		Email: danwing@gmail.com
	Kevin Smith		Kevin Smith
	Vodafone Group		Vodafone Group
	One Kingdom Street		One Kingdom Street
	London		London
	United Kingdom		United Kingdom
	Email: kevin.smith@vodafone.com		Email: kevin.smith@vodafone.com
End of changes. 37 change blocks.
	78 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.48.