Nokia

India kondtir@gmail.com

Citrix Systems, Inc.

United States of America danwing@gmail.com

Vodafone Group

One Kingdom Street London United Kingdom kevin.smith@vodafone.com

Meta Platforms, Inc.

ietf@bemasc.net

INT add When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver. DNS clients that are not configured to use this resolver by default can use it for these specific domains only. This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Terminology
• .  Scope
• .  Requirements
• .  Establishing Local DNS Authority
  • .  Example
  • .  Conveying Authorization Claims
    • .  Using DHCP
    • .  Using Provisioning Domains
• .  Validating Authority over Local Domain Hints
  • .  Using a Preconfigured External Resolver
  • .  Using DNSSEC
• .  Delegating DNSSEC Across Split DNS Boundaries
• .  Example Split-Horizon DNS Configuration
  • .  Verification Using an External Resolver
  • .  Verification Using DNSSEC
• .  Operational Efficiency in Split-Horizon Deployments
• . Validation with IKEv2
• . Authorization Claim Update
• . Security Considerations
• . IANA Considerations
  • .  New DHCP Authentication Algorithm for Split DNS
  • .  New PvD Additional Information Type for Split DNS
  • .  New PvD Split DNS Claims Registry
    • .  Guidelines for the Designated Experts
  • .  DNS Underscore Name
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction To resolve a DNS query, there are three main behaviors that an implementation can apply: (1) answer from a local database, (2) query the relevant authorities and their parents, or (3) ask a server to query those authorities and return the final answer. Implementations that use these behaviors are called "authoritative nameservers", "full/recursive resolvers", and "forwarders" (or "stub resolvers"), respectively. However, an implementation can also implement a mixture of these behaviors, depending on local policy, for each query. Such an implementation is termed a "hybrid resolver". Most DNS resolvers are hybrids of some kind. For example, stub resolvers support a local "hosts file" that preempts query forwarding, and most DNS forwarders and full resolvers can also serve responses from a local zone file. Other standardized hybrid resolution behaviors include using a local root, Multicast DNS (mDNS), and NXDOMAIN synthesis for .onion. Networks usually offer clients a DNS resolver using means such as DHCP offers or IPv6 Router Advertisements (RAs). Although this resolver is formally specified as a recursive resolver (e.g., see ), some networks provide a hybrid resolver instead. If this resolver acts as an authoritative server for some names and -- depending on the source of the query -- provides different answers for those domains, the network is said to be using "split-horizon DNS", because those names resolve in this way only from inside the network. DNS clients that use pure stub resolution, sending all queries to the network-provided resolver, will always receive the split-horizon results. Conversely, clients that send all queries to a different resolver or implement pure full resolution locally will never receive them. Clients that strictly implement either of these resolution behaviors are out of scope for this specification. Instead, this specification enables hybrid clients to access split-horizon results from a network-provided hybrid resolver, while using a different resolution method for some or all other names. There are several existing mechanisms for a network to provide clients with "local domain hints", listing domain names that are given special treatment in this network (e.g., "Recursive DNS Server (RDNSS) selection", "access network domain name", and "Client Fully Qualified Domain Name (FQDN)" in DHCP; "dnsZones" in Provisioning Domains (PvDs) ; and "INTERNAL_DNS_DOMAIN" in Internet Key Exchange Protocol Version 2 (IKEv2)). However, none of the local domain hint mechanisms enable clients to determine whether this special treatment 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, and clients that allows the network to establish its authority over a domain to a client (). Clients can use this protocol to confirm that a local domain hint was authorized by the domain owner (), which might influence its processing of that hint. This process requires cooperation between the local DNS zone and the public zone. In this specification, network operators securely identify the local DNS servers, and clients check each local domain hint against a globally valid parent zone.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in , e.g., "global DNS". The following additional terms are used throughout this document:

Encrypted DNS:

A DNS protocol that provides an encrypted channel between a DNS client and server (e.g., DNS over TLS (DoT) , DNS (queries) over HTTPS (DoH) , DNS over QUIC (DoQ) ).

Encrypted DNS Resolver:

Refers to a DNS resolver that supports any encrypted DNS scheme.

Split-Horizon DNS:

The DNS service provided by a resolver that also acts as an authoritative server for some names, providing resolution results that are meaningfully different from those in the global DNS. (See the definition of "split DNS" in .)

Validated Split Horizon:

A split-horizon configuration that is authorized by the parents of the affected names and confirmed by the client. Such authorization generally extends to the entire subtree of names below the authorization point.

In this document, the terms "owner" and "operator" are used interchangeably and refer to the individual or entity responsible for the management and maintenance of domains.

Scope The protocol described in this document is designed to support the ability of a domain owner to create or authorize a split-horizon view of their domain. The protocol does not support split-horizon views created by any other entity. Thus, DNS filtering is not enabled by this protocol. The protocol is applicable to any type of network offering split-horizon DNS configuration. The endpoint does not need any prior configuration to confirm that a local domain hint was indeed authorized by the domain. All of the Special-Use Domain Names registered with IANA , most notably "home.arpa.", "resolver.arpa.", "ipv4only.arpa.", and "local.", are never unique to a specific DNS server's authority. All Special-Use Domain Names are outside the scope of this document and MUST NOT be validated using the mechanism described in this document. The use of this specification is limited to DNS servers that support authenticated encryption and split-horizon DNS names that are rooted in the global DNS.

Requirements This solution seeks to fulfill the following requirements:

No loss of security:

No unauthorized party can impersonate a zone unless they could already do so without the use of this specification.

Least privilege:

Local resolvers do not hold any secrets that could weaken the security of the public zone if compromised.

Local zone confidentiality:

The specification does not leak local network subdomains to anyone outside of the network.

Flexibility:

The specification can represent and authorize a split DNS zone structure.

DNSSEC compatibility:

The specification supports DNSSEC-based object security for local zone contents per .

Establishing Local DNS Authority A participating network MUST offer one or more encrypted resolvers via DHCP and Router Advertisement options for the Discovery of Network-designated Resolvers (DNR) , Discovery of Designated Resolvers (DDR) , or an equivalent mechanism (see ). To establish local authority, the network MUST convey one or more "authorization claims" to the client. An authorization claim is an abstract structure comprising:

• An Authentication Domain Name (ADN) of a local encrypted resolver.
• The DNS name of the authorizing parent zone.
• A set of subdomains of this parent zone that are claimed by the named local resolver (potentially including the entire parent zone). To claim the entire parent zone, the claimed subdomain will be represented as an asterisk symbol ("*").
• A ZONEMD Hash Algorithm (). For interoperability purposes, implementations MUST support the "mandatory to implement" hash algorithms defined in .
• A high-entropy salt, up to 255 octets.

If the local encrypted resolver is identified by name (e.g., using DNR), that identifying name MUST be the name used in any corresponding authorization claim. Otherwise (e.g., DDR using IP addresses), the resolver MUST present a validatable certificate containing a subjectAltName that matches the authorization claim using the validation techniques for matching as described in . The network then provides each authorization claim to the parent zone operator. If the contents are approved, the parent zone operator computes a "Verification Token" according to the following procedure:

1. Convert all subdomains into canonical form and sort them in canonical order ().
2. Replace the suffix corresponding to the parent zone with a zero octet.
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 octet.
5. Let $TOKEN = hash(len($SALT) || $SALT || $X), where "||" denotes concatenation and hash is the ZONEMD Hash Algorithm.

The zone operator then publishes a "Verification Record" with the following structure, following the best practices outlined in Sections  and of :

• Type = TXT
• Owner Name = Concatenation of the ADN, "_splitdns-challenge", and the parent zone name
• Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" (without padding)

By publishing this record, the parent zone authorizes the local encrypted resolver to serve these subdomains authoritatively.

Example Consider the following authorization claim:

• ADN = "resolver17.parent.example"
• Parent = "parent.example"
• Subdomains = "payroll.parent.example", "secret.project.parent.example"
• Hash Algorithm = SHA-384
• Salt = "example salt octets (should be random)"

To approve this claim, the zone operator would publish the following record: NOTE: '\' line wrapping per RFC 8792 resolver17.parent.example._splitdns-challenge.parent.example. \ IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\ -KJDv2eFwfJcWQM"

Conveying Authorization Claims 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 client. This section defines some encodings of the authorization claims.

Using DHCP In DHCP, each authorization claim is encoded as a DHCP Authentication option ( and ), using the Protocol value 4, "Split-horizon DNS". In DHCPv4 , the mechanism for splitting long options as described in MUST be used if the Authentication option exceeds the maximum DHCPv4 option size of 255 octets. The Algorithm field provides the ZONEMD Hash Algorithm, represented by its registered Value. The Replay Detection Method value MUST be 0x00. The Authentication Information MUST contain the following information, concatenated:

1. The ADN in canonical form.
2. The parent name in canonical form.
3. A one-octet "salt length" field.
4. The salt value.
5. The $X value as defined in .

Using Provisioning Domains When using PvDs, the authorization claims are represented by the PvD Additional Information key "splitDnsClaims", whose value is a JSON array. Each entry in the array MUST be a JSON object with the following structure:

"resolver":

The ADN as a dot-separated name.

"parent":

The parent zone name as a dot-separated name.

"subdomains":

An array containing the claimed subdomains, as dot-separated names with the parent suffix already removed, in canonical order. To claim the entire parent zone, the claimed subdomain will be represented as an asterisk symbol ("*").

"algorithm":

The hash algorithm, represented by its "Mnemonic" string from the "ZONEMD Hash Algorithms" registry ().

"salt":

The salt, encoded in base64url .

Future specifications aiming to define new keys will need to add them to the IANA registry defined in . DNS client implementations will ignore any keys they don't recognize but may also report unknown keys.

Validating Authority over Local Domain Hints To validate an authorization claim provided by the network, DNS clients MUST resolve the Verification Record for that name. If the resolution produces an RRset containing the expected token for this claim, the client SHALL regard the named resolver as authoritative for the claimed subdomains. Clients MUST ignore any unrecognized keys in the Verification Record. Each validation of authority applies only to a specific ADN. If a network offers multiple encrypted resolvers, each claimed subdomain may be authorized for a distinct subset of the network-provided resolvers. A zone is termed a "Validated Split-Horizon zone" after successful validation using a "tamperproof" DNS resolution method, i.e., a method that is not subject to interference by the local network operator. Two possible tamperproof resolution methods are presented below.

Using a Preconfigured External Resolver This method applies only if the client is already configured with a default resolution strategy that sends queries to a resolver outside of the network over an encrypted transport. That resolution strategy is considered tamperproof because any actor who could modify the response could already modify all of the user's other DNS responses. If the client cannot obtain a response from the external resolver within a reasonable timeframe, it MUST consider the verification process to have failed. To ensure that this assumption holds, clients MUST NOT relax the acceptance rules they would otherwise apply when using this resolver. For example, if the client would check the Authenticated Data (AD) bit or validate RRSIGs locally when using this resolver, it must also do so when resolving TXT records for this purpose. The client MAY perform DNSSEC validation for the verification query even if it has disabled DNSSEC validation for other DNS queries.

Using DNSSEC The client resolves the Verification Record using any resolution method of its choice (e.g., querying one of the network-provided resolvers, performing iterative resolution locally) and performs full DNSSEC validation locally . The result is processed based on its DNSSEC validation state ():

Secure:

The response is used for validation.

Bogus or Indeterminate:

The response is rejected, and validation is considered to have failed.

Insecure:

The client SHOULD retry the validation process using a different method, such as the method described in , to ensure compatibility with unsigned names. If the client chooses not to retry (e.g., no configured policy to validate the authorization claim using an external resolver), it MUST consider validation to have failed.

Delegating DNSSEC Across Split DNS Boundaries When the local zone can be signed with globally trusted keys for the 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 the local resolver's DNSKEY. Zones in this configuration appear the same to validating stubs whether or not they implement this specification. To enable DNSSEC validation of local DNS names without requiring 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 Record whose value is the RDATA of a single DS record, encoded in base64url. This DS record authorizes a DNSKEY whose owner name is "resolver.arpa." To validate DNSSEC, the client first fetches and validates 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 encrypted resolver. At least one resulting DNSKEY Resource Record (RR) MUST match the DS RDATA from the "ds" key in the Verification Record. All local resolution results for subdomains in this claim MUST offer RRSIGs that chain to a DNSKEY whose RDATA is identical to one of these approved DNSKEYs. The "ds" key MAY appear multiple times in a single Verification Record, in order to authorize multiple DNSKEYs for this local encrypted resolver. Note that when the local resolver does not have a globally trusted DNSKEY, any claimed subdomains MUST be marked as unsigned in the public DNS. Otherwise, local resolution results would be rejected by validating stubs that do not implement this specification.

Example Use of "ds=..." NOTE: '\' line wrapping per RFC 8792 ;; Parent zone. $ORIGIN parent.example. ; Parent zone's public Key Signing Key (KSK) ; and Zone Signing Key (ZSK). @ IN DNSKEY 257 3 5 ABCD...= @ IN DNSKEY 256 3 5 DCBA...= ; Verification Record containing DS RDATA for the local ; resolver's KSK. This is an ordinary public TXT record, ; secured by RRSIGs from the public ZSK. resolver.example._splitdns-challenge IN TXT "token=abc...,ds=QWE..." ; NSEC record indicating that unsigned delegations are permitted at ; this subdomain. This is required for compatibility with ; non-split-aware validating stub resolvers. If the claimed label is ; confidential, the parent zone can conceal it using NSEC3 (with or ; without "opt-out"). @ IN NSEC subdomain.parent.example. NS ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Local zone, claiming "subdomain.parent.example". ; The local resolver's KSK, validated by the Verification Record. ; It may not have a corresponding RRSIG. resolver.arpa. IN DNSKEY 257 3 5 ASDF...= ; Each claimed subdomain duplicates the local resolver's KSK at its ; zone apex and uses it to sign the ZSK. subdomain.parent.example. IN DNSKEY 257 3 5 ASDF...= subdomain.parent.example. IN DNSKEY 256 3 5 FDSA...= subdomain.parent.example IN RRSIG DNSKEY 5 3 ... \ (KSK key tag) subdomain.parent.example. ... subdomain.parent.example. IN AAAA 2001:db8::17 subdomain.parent.example IN RRSIG AAAA 5 3 ... \ (ZSK key tag) subdomain.parent.example. ... deeper.subdomain.parent.example. IN AAAA 2001:db8::18 deeper.subdomain.parent.example IN RRSIG AAAA 5 3 ... \ (ZSK key tag) subdomain.parent.example. ...

Example Split-Horizon DNS Configuration Consider an organization that operates "example.com" and runs a different version of its global domain on its internal network. First, the host and network both need to support one of the discovery mechanisms described in . shows discovery using information from the DNR and the PvD. Validation is then performed using either an external resolver or DNSSEC.

Steps 1-2:

The client determines the network's DNS server (dns.example.net) and PvD ID (pvd.example.com) using DNR and a PvD, along with one of the following: DNR Router Solicitation, DHCPv4, or DHCPv6.

Steps 3-5:

The client connects to dns.example.net using an encrypted transport as indicated in DNR, authenticating the server to its name using TLS (), and sends it a query for the address of pvd.example.com.

Steps 6-7:

The client connects to the PvD server, validates its certificate, and retrieves the PvD Additional Information indicated by the associated PvD. The JSON object contains: { "identifier": "pvd.example.com", "expires": "2025-05-23T06:00:00Z", "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], "splitDnsClaims": [{ "resolver": "dns.example.net", "parent": "example.com", "subdomains": ["*"], "algorithm": "SHA384", "salt": "abc...123" }] } The JSON keys "identifier", "expires", and "prefixes" are defined in .

An Example of Learning Local Claims of DNS Authority +---------+ +--------------------+ +------------+ +--------+ | Client | | Network's | | Network | | Router | | | | Encrypted Resolver | | PvD Server | | | +---------+ +--------------------+ +------------+ +--------+ | | | | | Router Solicitation or | | | | DHCPv4/DHCPv6 (1) | | | |----------------------------------------------------------->| | | | | | Response with DNR ADN & | | | | PvD FQDN (2) | | | |<-----------------------------------------------------------| | ----------------------------\ | | | |-| now knows DNR ADN & | | | | | | PvD FQDN | | | | | |---------------------------/ | | | | | | | | TLS connection to dns.example.net (3) | | |------------------------------------>| | | | ---------------------------\ | | | |-| validate TLS certificate | | | | | |--------------------------/ | | | | | | | | resolve pvd.example.com (4) | | | |------------------------------------>| | | | | | | | A or AAAA records (5) | | | |<------------------------------------| | | | | | | | https://pvd.example.com/.well-known/pvd (6) | | |---------------------------------------------->| | | | | | | 200 OK (JSON Additional Information) (7) | | |<----------------------------------------------| | | ----------------------------------\ | | | |-| {..., "splitDnsClaims": [...] } | | | | | |---------------------------------/ | | |

Verification Using an External Resolver shows the steps performed to verify the local claims of DNS authority using an external resolver.

Steps 1-2:

The client uses an encrypted DNS connection to an external resolver to issue TXT queries for the Verification Records. The TXT lookup returns a token that matches the claim.

Step 3:

The client has validated that example.com has authorized dns.example.net to serve example.com. When the client connects using an encrypted transport as indicated in DNR, it will authenticate the server to its name using TLS () and send queries to resolve any names that fall within the claimed zones.

Verifying Claims Using an External Resolver +---------+ +--------------------+ +----------+ | Client | | Network's | | External | | | | Encrypted Resolver | | Resolver | +---------+ +--------------------+ +----------+ | | | | TLS connection | | |--------------------------------------------------->| | ---------------------------\ | | |-| validate TLS certificate | | | | |--------------------------| | | | | | | TXT? dns.example.net.\ | | | _splitdns-challenge.example.com (1) | | |--------------------------------------------------->| | | | | TXT "token=ABC..." (2) | | |<---------------------------------------------------| | --------------------------------\ | | |-| dns.example.net is authorized | | | | ----------------------\---------| | | |-| finished validation | | | | |---------------------| | | | | | | use dns.example.net when | | | resolving example.com (3) | | |----------------------------------------->| | | | |

Verification Using DNSSEC shows the steps performed to verify the local claims of DNS authority using DNSSEC.

Steps 1-2:

The DNSSEC-validating client queries the network's encrypted resolver to issue TXT queries for the Verification Records. The TXT lookup will return a signed response containing the expected token. The client then performs full DNSSEC validation locally.

Step 3:

If the DNSSEC validation is successful and the token matches, then this authorization claim is validated. Once the client connects using an encrypted transport as indicated in DNR, it will authenticate the server to its name using TLS () and send queries to resolve any names that fall within the claimed zones.

An Example of Verifying Claims Using DNSSEC +---------+ +--------------------+ | Client | | Network's | | | | Encrypted Resolver | +---------+ +--------------------+ | | | DNSSEC OK (DO), TXT? dns.example.net.\ | | _splitdns-challenge.example.com (1) | |-------------------------------------------------------------->| | | | TXT token=DEF..., Signed Answer (RRSIG) (2) | |<--------------------------------------------------------------| | -------------------------------------\ | |-| DNSKEY+TXT matches RRSIG, use TXT | | | |------------------------------------| | | --------------------------------\ | |-| dns.example.net is authorized | | | |-------------------------------| | | ----------------------\ | |-| finished validation | | | |---------------------| | | | | use encrypted network-designated resolver for example.com (3) | |-------------------------------------------------------------->| | |

Operational Efficiency in Split-Horizon Deployments In many split-horizon deployments, all non-public domain names are placed in a separate child zone (e.g., internal.example.com). In this configuration, the message flow is similar to the flow described in , except that queries for hosts not within the subdomain (e.g., www.example.com) are sent to the external resolver rather than the resolver for internal.example.com. As specified in , the internal DNS server will need a certificate signed by a Certification Authority (CA) trusted by the client. Although placing internal domains inside a child domain is not necessary to prevent leakage, such placement reduces the frequency of changes to the Verification Record. This document recommends that the internal domains be kept in a child zone of the local domain hints advertised by the network. For example, if the PvD "dnsZones" entry is "internal.example.com" and the network-provided DNS resolver is "ns1.internal.example.com", the network operator can structure the internal domain names as "private1.internal.example.com", "private2.internal.example.com", etc. The network-designated resolver will be used to resolve the subdomains of the local domain hint "*.internal.example.com".

Validation with IKEv2 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 securely discovered by the endpoint using the ENCDNS_IP* IKEv2 Configuration Payload Attribute Types defined in . The VPN client can use the mechanism defined in to validate that the discovered encrypted DNS resolver is authorized to answer for the claimed subdomains. Other VPN tunnel types have similar configuration capabilities. Note that those capabilities are not discussed in this document.

Authorization Claim Update A Verification Record is only valid until it expires. Expiry occurs when the Time To Live (TTL) or DNSSEC signature validity period ends. Shortly before Verification Record expiry, clients MUST fetch the Verification Records again and repeat the verification procedure. This ensures the availability of updated and valid Verification Records. A new Verification Record must be added to the RRset before the corresponding authorization claim is updated. After the claim is updated, the following procedures can be used:

1. DHCP reconfiguration can be initiated by a DHCP server that has previously communicated with a DHCP client and negotiated for the DHCP client to listen for Reconfigure messages, to prompt the DHCP client to dynamically request the updated authorization claim. This process avoids the need for the client to wait for its current lease to complete and request a new one, enabling the lease renewal to be driven by the DHCP server.
2. The sequence number in the RA PvD Option can be incremented, requiring clients to fetch PvD Additional Information from the HTTPS server due to the updated sequence number in the new RA ().
3. The old Verification Record needs to be maintained until the DHCP lease or PvD Additional Information expires.

Security Considerations The ADNs of authorized local encrypted resolvers are revealed in the owner names of Verification Records. This makes it easier for domain owners to understand which resolvers they are currently authorizing to implement split DNS. However, this could create a confidentiality issue if the local encrypted resolver's name contains sensitive information or is part of a secret subdomain. To mitigate the impact of such leakage, local resolvers should be given names that do not reveal any sensitive information. The security properties of hashing algorithms are not fixed. Algorithm agility (see ) is achieved by providing implementations with the flexibility to choose hashing algorithms from the "ZONEMD Hash Algorithms" registry (). The entropy of a salt depends on a high-quality pseudorandom number generator. For further discussion on random number generation, see . The salt MUST be regenerated whenever the authorization claim is updated.

IANA Considerations

New DHCP Authentication Algorithm for Split DNS 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:

Value:

4

Description:

Split-horizon DNS

Reference:

RFC 9704

New PvD Additional Information Type for Split DNS IANA has added the following entry to the "Additional Information PvD Keys" registry in the "Provisioning Domains (PvDs)" registry group:

JSON key:

splitDnsClaims

Description:

Verifiable locally served domains

Type:

Array of Objects

Example:

[{ "resolver": "dns.example.net", "parent": "example.com", "subdomains": ["sub"], "algorithm": "SHA384", "salt": "abc...123" }]

Reference:

RFC 9704

New PvD Split DNS Claims Registry IANA has created a new registry called "PvD Split DNS Claims" within the "Provisioning Domains (PvDs)" registry group. This new registry reserves JSON keys for use in sub-dictionaries under the splitDnsClaims JSON key. The initial contents of this registry, as discussed in , are listed below and have been added to the registry: Split DNS Claims

JSON key	Description	Type	Example	Reference
resolver	The Authentication Domain Name	String	"dns.example.net"	RFC 9704
parent	The parent zone name	String	"example.com"	RFC 9704
subdomains	An array containing the claimed subdomains	Array of Strings	["sub"]	RFC 9704
algorithm	The hash algorithm	String	"SHA384"	RFC 9704
salt	The salt (base64url)	String	"abc...123"	RFC 9704

The keys defined in this document are mandatory. Any new assignments of keys will be considered as optional for the purpose of the mechanism described in this document. New assignments in the "PvD Split DNS Claims" registry will be administered by IANA through Expert Review . Experts are requested to ensure that defined keys do not overlap in names or semantics.

Guidelines for the Designated Experts It is suggested that multiple designated experts be appointed for registry change requests. Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing entries and whether the registration description is clear and fits the purpose of this registry. Registration requests are evaluated within a three-week review period on the advice of one or more designated experts. Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.

DNS Underscore Name IANA has added the following entry to the "Underscored and Globally Scoped DNS Node Names" registry in the "Domain Name System (DNS) Parameters" registry group:

RR Type:

TXT

_NODE NAME:

_splitdns-challenge

Reference:

RFC 9704

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider. This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS. This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Informative References Brave Software Salesforce Aiven Akamai Technologies Work in Progress This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK] This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK] Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. [STANDARDS-TRACK] As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document registers the ".onion" Special-Use Domain Name. Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. This document obsoletes RFC 7706. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ). The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.

Acknowledgements Thanks to , , , , , , , and for the discussion and comments. Thanks to for the opsdir review, for the dnsdir review, for the secdir review, for the intdir review, and for the genart review. Thanks to for the Shepherd review.

Authors' Addresses Nokia

India kondtir@gmail.com

Citrix Systems, Inc.

United States of America danwing@gmail.com

Vodafone Group

One Kingdom Street London United Kingdom kevin.smith@vodafone.com

Meta Platforms, Inc.

ietf@bemasc.net