Establishing Local DNS Authority in Validated Split-Horizon Environments

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 December 2024.¶

Copyright Notice

Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) 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

1. 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 a 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 Local Root [RFC8806], mDNS [RFC6762], and NXDOMAIN synthesis for .onion [RFC7686].¶

Networks usually offers clients a DNS resolver using means such as (e.g., DHCP OFFER, IPv6 Router Advertisement). Although this server is formally specified as a recursive resolver (e.g., Section 5.1 of [RFC8106]), some networks provide a hybrid resolver instead. If this resolver acts as an authoritative server for some names and provides different answers for those domains depending on the source of the query, it is described as the network having "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 have special treatment in this network (e.g., RDNSS Selection [RFC6731], "Access Network Domain Name" [RFC5986], and "Client FQDN" [RFC4702][RFC4704] in DHCP, "dnsZones" in Provisioning Domains [RFC8801], and INTERNAL_DNS_DOMAIN [RFC8598] in 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 (Section 5). Clients can use this protocol to confirm that a local domain hint was authorized by the domain owner (Section 6), which might influence its processing of that hint. This process requires cooperation between the local DNS zone and the public zone.¶

This specification relies on securely identified local DNS servers, and checks each local domain hint against a globally valid parent zone.¶

2. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document makes use of the terms defined in [RFC9499], e.g., "Global DNS". The following additional terms are used throughout the document:¶

Encrypted DNS

A DNS protocol that provides an encrypted channel between a DNS client and server (e.g., DNS over TLS (DoT) [RFC7858], HTTPS (DoH) [RFC8484], QUIC (DoQ) [RFC9250]).¶

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 "Split DNS" in Section 6 of [RFC9499].)¶

Validated Split-Horizon

A split horizon configuration for some name is considered "validated" if the client has confirmed that a parent of that name has authorized this resolver to serve its own responses for that name. 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.¶

5. Establishing Local DNS Authority

To establish its authority over some DNS zone, a participating network MUST offer one or more encrypted resolvers via DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) [RFC9463], Discovery of Designated Resolvers (DDR) [RFC9462], or an equivalent mechanism (see Section 10).¶

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 (Section 5.3 of [RFC8976]). For interoperability purposes implementations MUST support the "mandatory to implement" hash algorithms defined in Section 2.2.3 of [RFC8976].¶
• A high-entropy salt, up to 255 octets.¶

If the local encrypted resolver is identified by name (e.g., DNR), that identifying name MUST be the one 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 [RFC9525].¶

To establish its authority, the network 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 (Section 6 of [RFC4034]).¶
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 advices such as in Sections 5.1 and 5.2 of [I-D.ietf-dnsop-domain-verification-techniques]:¶

• 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.¶

  resolver17.parent.example._splitdns-challenge.parent.example. \
  IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\
  -KJDv2eFwfJcWQM"

6. 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.¶

9. 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 Section 8.1, 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 in Section 8.1, 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 unnecessary to prevent leakage, such placement reduces the frequency of changes to the Verification Record, this document recommends 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".¶

10. Validation with IKEv2

When the VPN 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 [RFC9464]. The VPN client can use the mechanism defined in Section 6 to validate that the discovered encrypted DNS resolver is authorized to answer for the claimed subdomains.¶

Other VPN tunnel types have similar configuration capabilities, not detailed here.¶

11. 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 the DHCP server to prompt DHCP clients for dynamically requesting 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 will be incremented, requiring clients to fetch PvD additional information from the HTTPS server due to the updated sequence number in the new RA ([RFC8801], Section 4.1).¶
3. The old verification record needs to be maintained until the DHCP lease time or PvD Additional Information expiry.¶

12. Security Considerations

The Authentication Domain Names 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, but it could create a confidentiality problem if the local encrypted resolver's name is inside a secret subdomain. To avoid leakage, local resolvers should be given a name that does not reveal any sensitive information (perhaps in addition to the more sensitive name).¶

The security properties of hashing algorithms are not fixed. Algorithm Agility (see [RFC7696]) is achieved by providing implementations with flexibility to choose hashing algorithms from the ZONEMD Schemes registry ([RFC8976], Section 5.2).¶

The entropy of salt depends on a high-quality pseudo-random number generator. For further discussion on random number generation, see [RFC4086]. The salt MUST be regenerated whenever the authorization claim is updated.¶

13. IANA Considerations

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

Authors' Addresses