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

Commentary: Includes : Text adjustments for grammar and clarity Replacing " public " resolver with " external " Changes to references and blockquotes Made diagrams narrower 
 Please review 
 Changes look good to me .
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.
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 RFC8806, RFC6762, and RFC7686.
The protocol in this document allows the domain owner to create a
split-horizon DNS.  Other entities which do not own the domain are
detected by the client.  Thus, DNS filtering is not enabled by this
protocol.
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.
Other local domain hints in DHCP include the "Domain Name" RFC2132,
"Access Network Domain Name" RFC5986, "Client FQDN" RFC4704, and
"Name Service Search" 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.
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 address (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 validating.
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.
Two examples are shown below.  The first example showing an company
with an internal-only DNS server resolving the entire zone for that
company (e.g., *.example.com) the second example resolving only a
subdomain of the company's zone (e.g., *.internal.example.com).
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.,
The host and network first need mutual support one of the mechanisms
described in learning.  Shown in fig-learn is learning using DNR and
PvD.
Validation is then perfomed using either example-verify-public or
example-verify-dnssec.
The figure below shows the steps performed to verify the local claims
of DNS authority using a public resolver.
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.
Validation is then perfomed using either example-verify-external or
example-verify-dnssec.
The figure below shows the steps performed to verify the local claims
of DNS authority using an external resolver.
A subdomain can also be used for all internal DNS names (e.g., the
zone internal.example.com exists only on the internal DNS server).
For successful validation described in this document the the internal
DNS server will need a certificate signed by a CA trusted by the
client.
For such a name internal.example.com the message flow is similar to
internal-only the difference is that queries for hosts not within the
subdomain (www.example.com) are sent to the public resolver rather
than resolver for internal.example.com.
In many split-horizon deployments, all non-public domain names are
placed in a separate child zone (e.g.,
As in internal-only, the internal DNS server will need a certificate
signed by a CA trusted by the client.
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.  It should be noted, however, that this
specification does not leak individual host names (e.g.,
www.internal.example.com) into the Certificate Transparancy logs or
to public DNS resolvers.
If an internal zone name (e.g.,