| Internet-Draft | Establishing Local DNS Authority | September 2023 |
| Reddy, et al. | Expires 28 March 2024 | [Page] |
When split-horizon DNS is deployed by a network, certain domains can be resolved authoritatively by the network-provided DNS resolver. DNS clients that don't always use this resolver might wish to do so for these domains. This specification defines a mechanism for domain owners to inform clients about local resolvers that are authorized to answer authoritatively for certain subdomains.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Adaptive DNS Discovery Working Group mailing list (add@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/add/.¶
Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority.¶
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 28 March 2024.¶
Copyright (c) 2023 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.¶
To resolve a DNS query, there are three essential 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. We term such an implementation a "hybrid resolver".¶
Most DNS resolvers are hybrids of some kind. For example, stub resolvers frequently 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].¶
In many network environments, the network offers clients a DNS server (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, we say that the network has "split-horizon DNS", because those names resolve in this way only from inside the network.¶
Network 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 specification describes a protocol between domains, 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 (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.¶
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 [RFC8499], e.g. "Global DNS". The following additional terms are used throughout the document:¶
The protocol 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 [IANA-SUDN], 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.¶
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.¶
This solution seeks to fulfill the following requirements:¶
To establish its authority over some DNS zone, a participating network MUST offer one or more encrypted resolvers via DNR [I-D.ietf-add-dnr], DDR [I-D.ietf-add-ddr], or an equivalent mechanism (see Section 9).¶
To establish local authority, the network MUST convey one or more "Authorization Claims" to the client. An "Authorization Claim" is an abstract structure comprising:¶
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.¶
To establish its authority, the network MUST provide 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:¶
The zone operator then publishes a "Verification Record" with the following structure, following the advice in Sections 5.1 and 5.2 of [I-D.ietf-dnsop-domain-verification-techniques]:¶
By publishing this record, the parent zone authorizes the local encrypted resolver to serve these subdomains authoritatively.¶
Consider the following authorization claim:¶
To approve this claim, the zone operator would publish the following record:¶
NOTE: '\' line wrapping per [RFC8792]¶
resolver17.parent.example._splitdns-challenge.parent.example. \ IN TXT "token=6rQ7oOZqdg8qQFRqtxpEhK97mNkgFwzNKTmNOtlxspBscZq\ UwFZZJDDD-Djetw2MCg"¶
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.¶
In DHCP, each Authorization Claim is encoded as a DHCP Authentication Option ([RFC3118] and Section 21.11 of [RFC8415]), using the Protocol value $TBD1, "Split DNS Authentication". In DHCPv4, the long-options mechanism described in Section 8 of [RFC3396] 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 (RDM) value MUST be 0x00. The Authentication Information MUST contain the following information, concatenated:¶
When using Provisioning Domains [RFC8801], 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:¶
To validate an Authorization Claim provided by the network, participating 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 Authentication Domain Name. 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.¶
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 a 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.¶
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 AD bit or validate RRSIGs locally when using this resolver, it must also do so when resolving TXT records for this purpose. Alternatively, a client might perform DNSSEC validation for the verification query even if it has disabled DNSSEC validation for other DNS queries.¶
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 [RFC6698]. The result is processed based on its DNSSEC validation state ([RFC4035], Section 4.3):¶
We wish 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. To support this configuration, parent zones MAY add a "ds=..." key to the Verification Record whose value is the RDATA of a single DS record, base64url-encoded. 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 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 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. If the "ds" key is not present in a valid Verification Record, the client MUST disable DNSSEC validation when resolving the claimed subdomains via this local encrypted resolver.¶
;; Parent zone $ORIGIN parent.example. ; Parent zone's public KSK and 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..." ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Local zone, claiming "subdomain.parent.example". ; The local resolver's KSK, validated by the Verification Record. resolver.arpa. IN DNSKEY 257 3 5 ASDF...= ; Each claimed subdomain has its own ZSK, which is signed by the ; KSK and is used to sign records at that subdomain and below. subdomain.parent.example. IN DNSKEY 256 3 5 FDSA...= subdomain.parent.example. IN AAAA 2001:db8::17 deeper.subdomain.parent.example. IN AAAA 2001:db8::18
Two examples are shown below. The first example shows a company
with an internal-only DNS server that claims the entire zone for that
company (e.g., *.example.com). In the second example, the
internal servers resolves only a
subdomain of the company's zone (e.g., *.internal.example.com).¶
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 Section 5. Figure 2 shows discovery using DNR and PvD.¶
Validation is then perfomed using either an external resolver (Section 8.1.1) or DNSSEC (Section 8.1.2).¶
pvd.example.com.¶
Steps 6-7: The client connects to the PvD server, validates its certificate, and retrieves the provisioning domain JSON information indicated by the associated PvD. The PvD 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 [RFC8801].¶
+---------+ +--------------------+ +------------+ +--------+
| Client | | Network's | | Network | | Router |
| | | Encrypted Resolver | | PvD Server | | |
+---------+ +--------------------+ +------------+ +--------+
| | | |
| Router Solicitation or | | |
| DHCPv4/DHCPv6 (1) | | |
|----------------------------------------------------------->|
| | | |
| Response with DNR hostnames & | | |
| PvD FQDN (2) | | |
|<-----------------------------------------------------------|
| ----------------------------\ | | |
|-| now knows DNR hostnames & | | | |
| | 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": [...] } | | | |
| |---------------------------------/ | | |
The figure below shows the steps performed to verify the local claims of DNS authority using an external resolver.¶
example.com has authorized dns.example.net
to serve example.com. When the client connects using an
encrypted transport as indicated in DNR [I-D.ietf-add-dnr], it will authenticate
the server to its name using TLS ([RFC8310], Section 8), and send queries to resolve
any names that fall within the claimed zones.¶
+---------+ +--------------------+ +----------+
| 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) | |
|----------------------------------------->| |
| | |
The figure below shows the steps performed to verify the local claims of DNS authority 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) | |-------------------------------------------------------------->| | |
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 CA trusted by the client.¶
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 [I-D.ietf-ipsecme-add-ike]. 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.¶
If an internal zone name (e.g., internal.example.com) is used with
this specification and a public certificate is obtained
for validation, that internal zone name will exist in Certificate Transparency
logs [RFC9162]. In order to not leak the internal domains to
an external resolver, the internal domains can 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”. Further, adversaries that monitor
a network such as through passive monitoring or active probing of protocols,
such as DHCP will only learn the local domain hints but not learn the labels below internal.example.com.
However, security by obscurity may not maintain or increase the security of the
internal domain names, as they may be leaked in various other ways
(e.g., browser reload).¶
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).¶
IANA is requested to add the following entry to the "Protocol Name Space Values" registry on the "Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces" page:¶
IANA is requested to add the following entry to the "Additional Information PvD Keys" registry on the "Provisioning Domains (PvDs)" page:¶
IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry on the "Domain Name System (DNS) Parameters" page:¶
Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Michael Richardson, Bernie Volz and Vinny Parla for the discussion and comments.¶