Draft: draft-ietf-add-split-horizon-authority

Commentary: Based on recent mailing list discussions in ADD , this variant of Validated   draws an explicit distinction between local encrypted resolvers and typical nameservers . The local encrypted resolvers are authorized by publishing records under a special prefix , using hashes to conceal any local - only subdomains . This version offers stronger confidentiality and supports a wider variety of zone structures , at the cost of considerably more complexity . 
 Looks great . This PR describes the solution and also threads the needle with gently describing how to achieve the desired goal . This does make DNSSEC deployment even more complex , which I was certainly hoping to avoid but I understand the goals . 
 In the current draft , it is possible to have a fully signed zone without giving the local resolver the public zone 's private keys , in certain configurations . For example , consider the following arrangement : However , this arrangement requires a live , public - facing nameserver for the internal zone , with the same keys as the internal nameserver . This may be operationally inconvenient in some situations . It 's also not compatible with the prefix - driven approach that some ADD members have been asking for . 
 The problem here is : internal IN NS ns - internal ns - internal IN A 192.0.2.3 These NS and A records are glue records , so it wo n't get signed by DNSSEC , so it can not be trusted ( transport layer security is not data authenticity ) . So the client pulling this record ( eg indirectly via some public DoH server or even if it is iterating / validating itself ) can not trust these records . If you did a DS record , then it would get signed as that is not glue . And using a proper prefix , it could authenticate the name of the internal only zone . When using the DS record , the actual IP of the nameserver or its internal name is irrelevant and does not need to by synchronized . 
 No , the DoH resolver will fetch from 192.0.2.3 and validate RRSIGs . This example does have a DS record , in the public zone ( ) . Notably , in this example both versions of ns- have the same DNSKEYs , in order to share that DS record . ( Perhaps I should change the example to have two DS records instead ... ) I 've a comment highlighting the glue records . 
 I 've described a possible approach to this as part of ( specifically ) .
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 describes how clients can
confirm the local resolver's authority over these domains.
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.
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.  RFC6106), 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.
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.  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.
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 (learning).  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.
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., RFC6731, RFC5986, and
"Client FQDN" RFC4704 in DHCP, "dnsZones" in Provisioning Domains
RFC8801, and 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 (establishing).  Clients can use this protocol to
confirm that a local domain hint was authorized by the domain
(validating), 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.
This specification describes a protocol between domains, networks,
and clients that allows the network to establish its authority over a
domain to a client (establishing).  Clients can use this protocol to
confirm that a local domain hint was authorized by the domain
(validating), 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.  Use of this specification is therefore limited to servers that
support authenticated encryption and split-horizon DNS names that are
rooted in the global DNS.
There 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.
Other local domain hints in DHCP include the RFC2132, RFC5986,
"Client FQDN" RFC4704, and RFC2937 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.
A 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 vpn).  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.,
Because a rogue network can simulate all or most of the above
characteristics, this specification details how to validate these
claims in validating.
Provisioning Domains (PvDs) are defined in RFC7556 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 RFC8801 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.
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.
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-dnr, or an equivalent mechanism (see vpn).
If the encrypted resolver is identified by name (e.g., DNR), at least
one of these resolvers' Authentication Domain Names (ADNs) MUST
appear in an NS record for that zone.  If the encrypted resolver is
identified by IP address (e.g., DDR), then the resolver MUST present
a certificate that can be validated by the client, containing at
least one subjectAltName entry that matches an NS record for that
zone.  This arrangement establishes this resolver's authority over
the zone.
To 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.
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 vpn).
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.
By publishing this record, the parent zone authorizes the local
encrypted resolver to serve these subdomains authoritatively.
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.
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 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.
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 secure 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.
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.
Consider 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 learning. fig-learn shows discovery using DNR
and PvD.
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 establishing. fig-learn shows discovery using
DNR and PvD.
This 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.
This document has no IANA actions.
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).