rfc9704v2.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 262 ¶		skipping to change at line 262 ¶
	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 525 ¶		skipping to change at line 526 ¶
	Figure 1: Example Use of "ds=..."		Figure 1: Example Use of "ds=..."
	8. Example Split-Horizon DNS Configuration		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 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) or DNSSEC (Section 8.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 one
	[RFC9463] and PvDs [RFC8801], using one of the following: DNR		of the following: DNR Router Solicitation, DHCPv4, or DHCPv6.
	Router Solicitation, 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 750 ¶		skipping to change at line 750 ¶
	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 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
	(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 or PvD Additional Information expires.		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
End of changes. 7 change blocks.
	15 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48.