Establishing Local DNS
Authority in Split-Horizon EnvironmentsAkamaiEmbassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comCitrix Systems, Inc.4988 Great America PkwySanta ClaraCA95054USAdanwing@gmail.comVodafone GroupOne Kingdom StreetLondonUKkevin.smith@vodafone.comGoogle LLCbemasc@google.comADDWhen 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 describes how clients can confirm the
local resolver's authority over these domains.Discussion of this document takes place on the
Adaptive DNS Discovery Working Group mailing list (add@ietf.org),
which is archived at .Source for this draft and an issue tracker can be found at
.IntroductionTo 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
resolvers", and "forwarders" (or "stub resolvers"). 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, mDNS, and NXDOMAIN
synthesis for .onion.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. ), 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 ().
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 (). Clients can
use this protocol to confirm that a local domain hint was authorized by
the domain (), which might influence
its processing of that hint.This specification relies on securely identified local DNS servers
and globally valid NS records. Use of this specification is therefore
limited to servers that support authenticated encryption and
split-horizon DNS names that are properly rooted in the global DNS.TerminologyThe 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 the document:
Encrypted DNS
A DNS protocol that provides an encrypted
channel between a DNS client and server (e.g., DoT, DoH, or DoQ).
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 .)
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.
ScopeThe 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.Local Domain Hint MechanismsThere are various mechanisms by which a network client might learn
"local domain hints", which indicate a special treatment for particular
domain names upon joining a network. This section provides a review of
some common and standardized mechanisms for receiving domain hints.DHCP OptionsThere are several DHCP options that convey local domain hints of
different kinds. The most directly relevant is
RDNSS Selection, which provides "a list of domains ... about
which the RDNSS has special knowledge", along with a "High", "Medium",
or "Low" preference for each name. The specification notes the
difficulty of relying on these hints without validation:
Trustworthiness of an interface and configuration information
received over the interface is implementation and/or node
deployment dependent, and the details of determining that trust
are beyond the scope of this specification.
Other local domain hints in DHCP include the "Domain Name",
"Access Network Domain Name", "Client FQDN" , and
"Name Service Search" options. This
specification may help clients to interpret these hints. For example,
a rogue DHCP server could use the "Client FQDN" option to assign a
client the name "www.example.com" in order to prevent the client from
reaching the true "www.example.com". A client could use this
specification to check the network's authority over this name, and
adjust its behavior to avoid this attack if authority is not
established.The Domain Search option , which offers clients a way to expand short
names into Fully Qualified Domain Names, is not a "local domain hint"
by this definition, because it does not modify the processing of any
specific domain. (The specification notes that this option can be a
"fruitful avenue of attack for a rogue DHCP server", and provides a
number of cautions against accepting it unconditionally.)Host ConfigurationA host can be configured with DNS information when it joins a
network, including when it brings up VPN (which is also considered
joining a(n additional) network, detailed in ). Existing implementations determine the host has
joined a certain network via SSID, IP subnet assigned, DNS server IP
address or name, and other similar mechanisms. For example, one
existing implementation determines the host has joined an internal
network because the DHCP-assigned IP address belongs to the company's
IP range (as assigned by the regional IP addressing authority) and
the DHCP-advertised DNS IP address is one used by IT at that network.
Other mechanisms exist in other products but are not interesting to
this specification; rather what is interesting is this step to
determine "we have joined the internal corporate network" occurred and
the DNS server is configured as authoritative for certain DNS zones
(e.g., *.example.com).Because a rogue network can simulate all or most of the above
characteristics, this specification details how to validate these
claims in .Provisioning Domains dnsZonesProvisioning Domains (PvDs) are defined in as sets of network configuration information
that clients can use to access networks, including rules for DNS
resolution and proxy configuration. The PvD Key "dnsZones" is defined
in as a list of "DNS zones searchable
and accessible" in this provisioning domain. Attempting to resolve
these names via another resolver might fail or return results that are
not correct for this network.Split DNS Configuration for IKEv2In IKEv2 VPNs, the INTERNAL_DNS_DOMAIN configuration attribute can
be used to indicate that a domain is "internal" to the VPN . To prevent abuse, the specification notes
various possible restrictions on the use of this attribute:
If a client is configured by local policy to only accept a
limited set of INTERNAL_DNS_DOMAIN values, the client MUST ignore
any other INTERNAL_DNS_DOMAIN values.
()IKE clients MAY want to require whitelisted domains for
Top-Level Domains (TLDs) and Second-Level Domains (SLDs) to
further prevent malicious DNS redirections for well-known
domains.
()
Within these guidelines, a client could adopt a local policy
of accepting INTERNAL_DNS_DOMAIN values only when it can validate the
local DNS server's authority over those names as described in this
specification.Establishing Local DNS AuthorityTo establish its authority over some DNS zone, a participating
network MUST offer one or more encrypted resolvers via DNR or an equivalent mechanism (see ). At least one of these resolvers' Authentication
Domain Names (ADNs) MUST appear in an NS record for that zone. This
arrangement establishes this resolver's authority over the zone.Validating Authority over Local Domain HintsTo validate the network's authority over a domain name, participating
clients MUST resolve the NS record for that name. If the resolution
result is NODATA, the client MUST remove the last label and repeat the
query until a response other than NODATA is received.Once the NS record has been resolved, the client MUST check if each
local encrypted resolver's Authentication Domain Name appears in the NS
record. The client SHALL regard each such resolver as authoritative for
the zone of this NS record.Each validation of authority applies only to the specific resolvers
whose names appear in the NS RRSet. If a network offers multiple
encrypted resolvers, each DNS entry 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" NS 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 Pre-configured External ResolverThis 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 secure transport. That resolution strategy is
considered "tamperproof" because any actor who could modify the NS
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 NS records for this purpose. Alternatively, a client might
perform DNSSEC validation for the NS query used for this purpose
even if it has disabled DNSSEC validation for other DNS queries.Using DNSSECThe client resolves the NS 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 one in , to ensure compatibility with
unsigned names.
Examples of Split-Horizon DNS ConfigurationTwo 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).Split-Horizon Entire ZoneConsider an organization that operates "example.com", and runs a
different version of its global domain on its internal network. Today,
on the Internet it publishes two NS records, "ns1.example.com" and
"ns2.example.com".First, the host and network both need to support one of the discovery
mechanisms described in .
shows discovery using DNR and PvD.Validation is then perfomed using either an external resolver or DNSSEC.
Steps 1-2: The client determines the network's DNS
server (ns1.example.com) and Provisioning Domain (pvd.example.com)
using DNR and PvD, using one of DNR Router Solicitation,
DHCPv4, or DHCPv6.
Step 3-5: The client connects to ns1.example.com
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 provisioning domain
JSON information indicated by the associated PvD. The PvD
contains:The JSON keys "identifier", "expires", and "prefixes"
are defined in .
Verification using an external resolverThe figure below 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 (e.g., 1.1.1.1) to issue NS
queries for the domains in dnsZones. The NS lookup for
"example.com" will return "ns1.example.com" and
"ns2.example.com".
Step 3: The network-provided DNS servers are
listed in the NS record for example.com, which was
retrieved from an external resolver over a secure transport,
so these ADNs are authorized. 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 dnsZones from PvD.
Verification using DNSSECThe figure below shows the steps performed to verify the local
claims of DNS authority using DNSSEC.
Steps 1-2: The DNSSEC-validating client queries
the network encrypted resolver to issue NS queries for the
domains in dnsZones. The NS lookup for "example.com" will return
a signed response containing "ns1.example.com" and
"ns2.example.com". The client then performs full DNSSEC
validation locally.
Step 3: The DNSSEC validation is successful and
the network-provided DNS servers are listed in the signed NS
record for example.com, so these ADNs are authorized.
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 dnsZones from PvD.
Internal-only SubdomainsIn 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 , except that queries for hosts not within the
subdomain (e.g., www.example.com) are sent to the
external resolver rather than resolver for internal.example.com.As in , the internal DNS
server will need a certificate signed by a CA trusted by the
client.Validation with IKEv2When 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 .Other VPN tunnel types have similar configuration capabilities, not
detailed here.Security ConsiderationsThis specification does not alter DNSSEC validation behaviour. To
ensure compatibility with validating clients, network operators MUST
ensure that names under the split-horizon are correctly signed or place
them in an unsigned zone.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 . 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).IANA ConsiderationsThis document has no IANA actions.AcknowledgementsThanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul
Wouters, Michael Richardson and Vinny Parla for the discussion and comments.ReferencesNormative ReferencesInformative References