< draft-reddy-add-enterprise-split-dns-09.txt   draft-reddy-add-enterprise-split-dns-10.txt >
ADD T. Reddy ADD T. Reddy
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: 3 September 2022 Citrix Expires: 15 October 2022 Citrix
K. Smith K. Smith
Vodafone Vodafone
B. Schwartz B. Schwartz
Google Google
2 March 2022 13 April 2022
Split-Horizon DNS Configuration Establishing Local DNS Authority in Split-Horizon Environments
draft-reddy-add-enterprise-split-dns-09 draft-reddy-add-enterprise-split-dns-10
Abstract Abstract
When split-horizon DNS is deployed by a network, certain domains can When split-horizon DNS is deployed by a network, certain domains can
be resolved authoritatively by the network-provided DNS resolver. be resolved authoritatively by the network-provided DNS resolver.
DNS clients that don't always use this resolver might wish to do so DNS clients that don't always use this resolver might wish to do so
for these domains. This specification enables networks to inform DNS for these domains. This specification describes how clients can
clients about domains that are inside the split-horizon DNS, and confirm the local resolver's authority over these domains.
describes how clients can confirm the local resolver's authority over
these domains.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 September 2022. This Internet-Draft will expire on 15 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Authorized Split Horizon . . . . . . . . . . . . . . . . 4 2.1. Validated Split-Horizon . . . . . . . . . . . . . . . . . 4
2.2. Domain Camping . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Provisioning Domains dnsZones . . . . . . . . . . . . . . . . 4 4. Local Domain Hint Mechanisms . . . . . . . . . . . . . . . . 4
4.1. Confirming Authority over the Domains . . . . . . . . . . 5 4.1. DHCP Options . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Confirmation using a pre-configured public 4.2. Host Configuration . . . . . . . . . . . . . . . . . . . 5
resolver . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Provisioning Domains dnsZones . . . . . . . . . . . . . . 6
4.1.2. Confirmation using DNSSEC . . . . . . . . . . . . . . 6 4.4. Split DNS Configuration for IKEv2 . . . . . . . . . . . . 6
5. An example of Split-Horizon DNS Configuration . . . . . . . . 6 5. Establishing Local DNS Authority . . . . . . . . . . . . . . 6
6. Split DNS Configuration for IKEv2 . . . . . . . . . . . . . . 8 6. Validating Authority over Local Domain Hints . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.1. Using Pre-configured Public Resolver . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.2. Using DNSSEC . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Examples of Split-Horizon DNS Configuration . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Split-Horizon Entire Zone . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1.1. Verification using Public Resolver . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10 7.1.2. Verification using DNSSEC . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Split-Horizon Only Subdomain of Zone . . . . . . . . . . 12
8. Validation with IKEv2 . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
To resolve a DNS query, there are three essential behaviors that an To resolve a DNS query, there are three essential behaviors that an
implementation can apply: (1) answer from a local database, (2) query implementation can apply: (1) answer from a local database, (2) query
the relevant authorities and their parents, or (3) ask a server to the relevant authorities and their parents, or (3) ask a server to
query those authorities and return the final answer. Implementations query those authorities and return the final answer. Implementations
that use these behaviors are called "authoritative nameservers", that use these behaviors are called "authoritative nameservers",
"full resolvers", and "forwarders" (or "stub resolvers"). However, "full resolvers", and "forwarders" (or "stub resolvers"). However,
an implementation can also implement a mixture of these behaviors, an implementation can also implement a mixture of these behaviors,
skipping to change at page 3, line 30 skipping to change at page 3, line 30
Network clients that use pure stub resolution, sending all queries to Network clients that use pure stub resolution, sending all queries to
the network-provided resolver, will always receive the split-horizon the network-provided resolver, will always receive the split-horizon
results. Conversely, clients that send all queries to a different results. Conversely, clients that send all queries to a different
resolver or implement pure full resolution locally will never receive resolver or implement pure full resolution locally will never receive
them. Clients with either pure resolution behavior are out of scope them. Clients with either pure resolution behavior are out of scope
for this specification. Instead, this specification enables hybrid for this specification. Instead, this specification enables hybrid
clients to access split-horizon results from a network-provided clients to access split-horizon results from a network-provided
hybrid resolver, while using a different resolution method for some hybrid resolver, while using a different resolution method for some
or all other names. or all other names.
To achieve the required security properties, clients must be able to There are several existing mechanisms for a network to provide
authenticate the DNS servers provided by the network, for example clients with "local domain hints", listing domain names that have
using the techniques proposed in [I-D.ietf-add-dnr] and special treatment in this network (Section 4). However, none of the
[I-D.ietf-add-ddr], and prove that they are authorized to serve the local domain hint mechanisms enable clients to determine whether this
offered split-horizon DNS names. As a result, use of this special treatment is authorized by the domain owner. Instead, these
specification is limited to servers that support authenticated specifications require clients to make their own determinations about
encryption and split-horizon DNS names that are properly rooted in whether to trust and rely on these hints.
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 (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 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in [RFC8499]. The terms This document makes use of the terms defined in [RFC8499]. The term
"Private DNS", "Global DNS" and "Split DNS" are defined in [RFC8499]. "Global DNS" is defined in [RFC8499].
'Encrypted DNS' refers to a DNS protocol that provides an encrypted 'Encrypted DNS' refers to a DNS protocol that provides an encrypted
channel between a DNS client and server (e.g., DoT, DoH, or DoQ). channel between a DNS client and server (e.g., DoT, DoH, or DoQ).
The terms 'Authorized Split Horizon' and 'Domain Camping' are also The term 'Validated Split-Horizon' is also defined.
defined.
2.1. Authorized Split Horizon
A split horizon configuration for some name is considered
"authorized" if any parent of that name has given the local network
permission to serve its own responses for that name. Such
authorizations generally extend to the entire subtree of names below
the authorization point.
2.2. Domain Camping
Domain Camping refers to operating a nameserver which claims to be
authoritative for a zone, but actually isn't. For example, a domain
called example.com on the Internet and an internal DNS server also
claims to be authoritative for example.com, but has no delegation
from example.com on the Internet. Someone might domain camp on a
popular domain name providing the ability to monitor queries and
modify answers for that domain.
A common variation on domain camping is "NXDOMAIN camping", in which 2.1. Validated Split-Horizon
a nameserver claims a zone that does not exist in the global DNS.
This is a form of domain camping because it seizes a portion of the
parent zone without permission. The use of nonexistent TLDs for
local services is a form of NXDOMAIN camping on the root zone.
Any form of domain camping likely violates the IAB's guidance A split horizon configuration for some name is considered "validated"
regarding "the Unique DNS Root" [RFC2826]. if the network client has confirmed that a parent of that name has
authorized the local network to serve its own responses for that
name. Such authorization generally extends to the entire subtree of
names below the authorization point.
3. Scope 3. Scope
The protocol in this document allows the domain owner to create a The protocol in this document allows the domain owner to create a
split-horizon DNS. Other entities which do not own the domain are split-horizon DNS. Other entities which do not own the domain are
detected by the client. Thus, DNS filtering is not enabled by this detected by the client. Thus, DNS filtering is not enabled by this
protocol. protocol.
4. Provisioning Domains dnsZones 4. Local Domain Hint Mechanisms
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.
4.1. DHCP Options
There are several DHCP options that convey local domain hints of
different kinds. The most directly relevant is "RDNSS Selection"
[RFC6731], 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" [RFC2132],
"Access Network Domain Name" [RFC5986], "Client FQDN"
[RFC4702][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.
The Domain Search option [RFC3397] [RFC3646], 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.)
4.2. Host Configuration
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 Section 8). 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 Section 6.
4.3. Provisioning Domains dnsZones
Provisioning Domains (PvDs) are defined in [RFC7556] as sets of Provisioning Domains (PvDs) are defined in [RFC7556] as sets of
network configuration information that clients can use to access network configuration information that clients can use to access
networks, including rules for DNS resolution and proxy configuration. networks, including rules for DNS resolution and proxy configuration.
The PvD Key dnsZones is defined in [RFC8801]. The PvD Key dnsZones The PvD Key "dnsZones" is defined in [RFC8801] as a list of "DNS
notifies clients of names for which one of the network-provided zones searchable and accessible" in this provisioning domain.
resolvers is authoritative. Attempting to resolve these names via Attempting to resolve these names via another resolver might fail or
another resolver might fail or return results that are not correct return results that are not correct for this network.
for this network.
Each dnsZones entry indicates a claim of authority over a domain and 4.4. Split DNS Configuration for IKEv2
its subdomains. For example, if the dnsZones entry is
"example.test", this covers "example.test", "www.example.test", and
"mail.eng.example.test", but not "otherexample.test" or
"example.test.net".
[RFC8801] defines a mechanism for discovering multiple Explicit PvDs In IKEv2 VPNs, the INTERNAL_DNS_DOMAIN configuration attribute can be
on a single network and their Additional Information by means of an used to indicate that a domain is "internal" to the VPN [RFC8598].
HTTP-over-TLS query using a URI derived from the PvD ID. This set of To prevent abuse, the specification notes various possible
additional configuration information is referred to as a Web restrictions on the use of this attribute:
Provisioning Domain (Web PvD). The PvD RA option defined in
[RFC8801] SHOULD set the H-flag to indicate that Additional
Information is available. This Additional Information JSON object
SHOULD include the "dnsZones" key to define the DNS domains for which
the network claims authority.
4.1. Confirming Authority over the Domains "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."
To comply with [RFC2826], each dnsZones entry must be authorized in "IKE clients MAY want to require whitelisted domains for Top-Level
the global DNS hierarchy. To prevent domain camping, clients must Domains (TLDs) and Second-Level Domains (SLDs) to further prevent
confirm this authorization before making use of the entry. malicious DNS redirections for well-known domains."
To enable confirmation, the client must discover and validate the Within these guidelines, a client could adopt a local policy of
Authentication Domain Names (ADNs) of the network-designated accepting INTERNAL_DNS_DOMAIN values only when it can validate the
resolvers using a method such as DNR [I-D.ietf-add-dnr]. The client local DNS server's authority over those names as described in this
must also perform an NS query for each dnsZones entry and confirm specification.
that at least one of the ADNs appears in each NS RRSet. This NS
query must be conducted in a manner that is not vulnerable to
tampering by the local network. Suitable tamperproof resolution
strategies are described in Section 4.1.1 and Section 4.1.2.
Note that each dnsZones entry is authorized only for the specific 5. Establishing Local DNS Authority
resolvers whose ADNs appear in its NS RRSet. If a network offers
multiple encrypted resolvers via DNR, each dnsZones entry may be
authorized for a distinct subset of the network-provided resolvers.
4.1.1. Confirmation using a pre-configured public resolver 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] or an equivalent mechanism (see Section 8). 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.
The client sends an NS query for the domain in dnsZones to a pre- 6. Validating Authority over Local Domain Hints
configured resolver that is external to the network, over a secure
transport. Clients SHOULD apply whatever acceptance rules they would
otherwise apply when using this resolver (e.g. checking the AD bit,
validating RRSIGs).
4.1.2. Confirmation using DNSSEC 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.
6.1. Using Pre-configured Public Resolver
The client sends the NS query to a pre-configured resolver that is
external to the network, over a secure transport. Clients SHOULD
apply whatever acceptance rules they would otherwise apply when using
this resolver (e.g. checking the AD bit, validating RRSIGs).
6.2. Using DNSSEC
The client resolves the NS record using any resolution method of its The client resolves the NS record using any resolution method of its
choice (e.g. querying one of the network-provided resolvers, choice (e.g. querying one of the network-provided resolvers,
performing iterative resolution locally), and performs full DNSSEC performing iterative resolution locally), and performs full DNSSEC
validation locally [RFC6698]. The result is processed based on its validation locally [RFC6698]. The result is processed based on its
DNSSEC validation state (Section 4.3 of [RFC4035]): DNSSEC validation state (Section 4.3 of [RFC4035]):
* "Secure": the NS record is used for confirmation. Secure: the response is used for validation.
* "Bogus" or "Indeterminate": the record is rejected and Bogus or Indeterminate: the response is rejected and validation is
confirmation is considered to have failed. considered to have failed.
* "Insecure": the client SHOULD retry the confirmation process using Insecure: the client SHOULD retry the validation process using a
a different method, such as the one in Section 4.1.1, to ensure different method, such as the one in Section 6.1, to ensure
compatibility with unsigned names. compatibility with unsigned names.
5. An example of Split-Horizon DNS Configuration 7. Examples of Split-Horizon DNS Configuration
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).
7.1. Split-Horizon Entire Zone
Consider an organization that operates "example.com", and runs a Consider an organization that operates "example.com", and runs a
different version of its global domain on its internal network. different version of its global domain on its internal network.
Today, on the Internet it publishes two NS records, "ns1.example.com" Today, on the Internet it publishes two NS records, "ns1.example.com"
and "ns2.example.com". and "ns2.example.com".
To add support for the mechanism described in this document, the The host and network first need mutual support one of the mechanisms
network and endpoints first need to support [I-D.ietf-add-dnr] and described in learning (Section 4). Shown in Figure 1 is learning
[RFC8801]. Then, for each site, the administrator would add DNS using DNR and PvD.
servers named "ns1.example.com" or "ns2.example.com" (the names
published on the Internet). Those names would be advertised to the
endpoints as described in [I-D.ietf-add-dnr].
The endpoints compliant with this specification can then determine Validation is then perfomed using either Public DNS (Section 7.1.1)
the network's internal nameservers are owned and managed by the same or DNSSEC (Section 7.1.2).
entity that has published the NS records on the Internet as shown in
Figure 1:
Steps 1-2: The client joins the network, obtains an IP address, and steps 1-2: The client determines the network's DNS server
discovers the resolvers "ns1.example.com" and "ns2.example.com" (ns1.example.com) and Provisioning Domain (pvd.example.com) using
and their IP addresses using DNR [I-D.ietf-add-dnr]. Using DNR [I-D.ietf-add-dnr] and PvD [RFC8801], using one of DNR Router
[RFC8801], the client also discovers the PvD FQDN is Solicitation, DHCPv4, or DHCPv6.
"pvd.example.com".
Steps 3-7: The client establishes an encrypted DNS connection with step 3-5: The client connects to the DNR-learned DNS server
"ns1.example.com", validates its TLS certificate, and queries it (ns1.example.com), validates its certificate, and queries for
for "pvd.example.com" to retrieve the PvD JSON object. Note that pvd.example.com.
[RFC8801] in Section 4.1 mandates the PvD FQDN MUST be resolved
using the DNS servers indicated by the associated PvD. The PvD steps 6-7: The client connects to the PvD server, validates its
contains: certificate, and retrieves the provisioning domain JSON
information indicated by the associated PvD. The PvD contains:
{ {
"identifier": "pvd.example.com", "identifier": "pvd.example.com",
"expires": "2020-05-23T06:00:00Z", "expires": "2020-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"dnsZones:": ["example.com"] "dnsZones:": ["example.com"]
} }
The JSON keys "identifier", "expires", and "prefixes" are defined The JSON keys "identifier", "expires", and "prefixes" are defined
in [RFC8801]. in [RFC8801].
Steps 8-9: The client then uses an encrypted DNS connection to a +---------+ +--------------------+ +------------+ +--------+
public resolver (e.g., 1.1.1.1) to issue NS queries for the | client | | Network | | Network | | Router |
domains in dnsZones. The NS lookup for "example.com" will return | | | 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 ns1.example.com (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) | |
|<----------------------------------------------| |
| -----------------------\ | | |
|-| dnsZones=example.com | | | |
| |----------------------| | | |
Figure 1: Learning Local Claims of DNS Authority
7.1.1. Verification using Public Resolver
The figure below shows the steps performed to verify the local claims
of DNS authority using a public resolver.
Steps 1-2: The client uses an encrypted DNS connection to a public
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". "ns1.example.com" and "ns2.example.com".
Step 10: As the network-provided nameservers are the same as the Step 3: As the network-provided nameservers are the same as the
names retrieved from the public resolver and the network- names retrieved from the public resolver and the network-
designated resolver's certificate includes at least one of the designated resolver's certificate includes at least one of the
names retrieved from the public resolver, the client has finished names retrieved from the public resolver, the client has finished
validation that the nameservers signaled in [I-D.ietf-add-dnr] and validation that the nameservers signaled in [I-D.ietf-add-dnr] and
[RFC8801] are owned and managed by the same entity that published [RFC8801] are owned and managed by the same entity that published
the NS records on the Internet. The endpoint will then use that the NS records on the Internet. The endpoint will then use that
information from [I-D.ietf-add-dnr] and [RFC8801] to resolve names information from [I-D.ietf-add-dnr] and [RFC8801] to resolve names
within dnsZones. within dnsZones.
+---------+ +---------------------+ +------------+ +---------+ +---------+ +---------+ +--------------------+ +----------+
| client | | Network | | Network | | Router | | public | | client | | Network | | public |
| | | encrypted resolvr | | PvD server | | | | resolvr | | | | encrypted resolver | | resolver |
+---------+ +---------------------+ +------------+ +---------+ +---------+ +---------+ +--------------------+ +----------+
| | | | | | | |
| Router Solicitation (1) | | | | | TLS connection | |
|-------------------------------------------------------------->| | |--------------------------------------------------->|
| | | | | | ---------------------------\ | |
| Router Advertisement with DNR hostnames & PvD FQDN (2) | | |-| validate TLS certificate | | |
|<--------------------------------------------------------------| | | |--------------------------| | |
| -------------------------------------\ | | | | | | |
|-| now knows DNR hostnames & PvD FQDN | | | | | | NS? example.com (1) | |
| |------------------------------------| | | | | |--------------------------------------------------->|
| | | | | | | |
| TLS connection to ns1.example.com (3) | | | | | NS=ns1.example.com, ns2.example.com (2) | |
|----------------------------------------->| | | | |<---------------------------------------------------|
| ---------------------------\ | | | | | -------------------------------\ | |
|-| validate TLS certificate | | | | | |-| both DNR ADNs are authorized | | |
| |--------------------------| | | | | | ----------------------\--------| | |
| | | | | |-| finished validation | | |
| resolve pvd.example.com (4) | | | | | |---------------------| | |
|----------------------------------------->| | | | | | |
| | | | | | use network-designated resolver | |
| AAAA records (5) | | | | | for example.com (3) | |
|<-----------------------------------------| | | | |----------------------------------------->| |
| | | | | | | |
| https://pvd.example.com/.well-known/pvd (6) | | |
|--------------------------------------------------->| | |
| | | | |
| 200 OK (JSON Additional Information) (7) | | |
|<---------------------------------------------------| | |
| -----------------------\ | | | |
|-| dnsZones=example.com | | | | |
| |----------------------| | | | |
| | | | |
| TLS connection | | | |
|-------------------------------------------------------------------------->|
| ---------------------------\ | | | |
|-| validate TLS certificate | | | | |
| |--------------------------| | | | |
| | | | |
| NS? example.com (8) | | | |
|-------------------------------------------------------------------------->|
| | | | |
| NS=ns1.example.com, ns2.example.com (9) |
|<--------------------------------------------------------------------------|
| -------------------------------\ | | | |
|-| both DNR ADNs are authorized | | | | |
| ----------------------\--------| | | | |
|-| finished validation | | | | |
| |---------------------| | | | |
| | | | |
| use network-designated resolver | | | |
| for example.com (10) | | | |
|----------------------------------------->| | | |
| | | | |
Figure 1: An Example of Split-Horizon DNS Configuration Figure 2: Verifying Claims using Public Resolver
6. Split DNS Configuration for IKEv2 7.1.2. Verification using DNSSEC
The split-tunnel Virtual Private Network (VPN) configuration allows The figure below shows the steps performed to verify the local claims
the endpoint to access resources that reside in the VPN [RFC8598] via of DNS authority using DNSSEC.
the tunnel; other traffic not destined to the VPN does not traverse
the tunnel. In contrast, a non-split-tunnel VPN configuration causes Steps 1-2: The DNSSEC-validating client queries the network
all traffic to traverse the tunnel into the VPN. 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: As the DNSSEC validation is successful and the network-
provided nameservers are the same as the names in the DNSSEC
response, and the network-designated resolver's certificate
includes at least one of the names returned in the DNSSEC
response, the client has finished validation that the nameservers
signaled in [I-D.ietf-add-dnr] and [RFC8801] are owned and managed
by the same entity that published the NS records on the Internet.
The endpoint will then use that information from
[I-D.ietf-add-dnr] and [RFC8801] to resolve names within dnsZones.
+---------+ +--------------------+
| client | | Network |
| | | encrypted resolver |
+---------+ +--------------------+
| |
| DNSSEC OK (DO), NS? example.com (1) |
|--------------------------------------------------------------->|
| |
| NS=ns1.example.com,ns2.example.com, Signed Answer (RRSIG) (2) |
|<---------------------------------------------------------------|
| -----------------------------------\ |
|-| DNSKEY+NS matches RRSIG, use NS | |
| |----------------------------------| |
| -------------------------------\ |
|-| both DNR ADNs are authorized | |
| |------------------------------| |
| ----------------------\ |
|-| finished validation | |
| |---------------------| |
| |
| use encrypted network-designated resolver for example.com (3) |
|--------------------------------------------------------------->|
| |
Figure 3: Verifying Claims using DNSSEC
7.2. Split-Horizon Only Subdomain of Zone
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
Section 7.1 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.
8. Validation with IKEv2
When the VPN tunnel is IPsec, the encrypted DNS resolver hosted by When the VPN tunnel is IPsec, the encrypted DNS resolver hosted by
the VPN service provider can be securely discovered by the endpoint the VPN service provider can be securely discovered by the endpoint
using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types
defined in [I-D.ietf-ipsecme-add-ike]. For split-tunnel VPN defined in [I-D.ietf-ipsecme-add-ike].
configurations, the endpoint uses the discovered encrypted DNS server
to resolve domain names for which the VPN provider claims authority.
For non-split-tunnel VPN configurations, the endpoint uses the
discovered encrypted DNS server to resolve both global and private
domain names. For split-tunnel VPN configurations, the IKE client
can use any one of the mechanisms discussed in Section 4.1 to
determine if the VPN service provider is authoritative over the Split
Horizon DNS domains.
Other VPN tunnel types have similar configuration capabilities, not Other VPN tunnel types have similar configuration capabilities, not
detailed here. detailed here.
7. Security Considerations 9. Security Considerations
The content of dnsZones may be passed to another (DNS) program for
processing. As with any network input, the content SHOULD be
considered untrusted and handled accordingly. The client must
perform the mechanisms discussed in Section 4.1 to determine if the
network-designated encrypted resolvers are authoritative over the
domains in dnsZones. If they are not, the client must ignore those
dnsZones.
This specification does not alter DNSSEC validation behaviour. To This specification does not alter DNSSEC validation behaviour. To
ensure compatibility with validating clients, network operators MUST ensure compatibility with validating clients, network operators MUST
ensure that names under the split horizon are correctly signed or ensure that names under the split-horizon are correctly signed or
place them in an unsigned zone. place them in an unsigned zone.
8. IANA Considerations If an internal zone name (e.g., internal.example.com) is used with in
conjunction with this specification and a public certificate is
obtained for validation, that internal zone name will exist in
Certificate Transparency [RFC9162] logs. 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.
10. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Acknowledgements 11. Acknowledgements
Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul
Wouters and Vinny Parla for the discussion and comments. Wouters and Vinny Parla for the discussion and comments.
10. References 12. References
12.1. Normative References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <https://www.rfc-editor.org/info/rfc2826>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
skipping to change at page 10, line 28 skipping to change at page 13, line 34
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data", Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020, RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/info/rfc8801>. <https://www.rfc-editor.org/info/rfc8801>.
10.2. Informative References 12.2. Informative References
[I-D.ietf-add-ddr]
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", Work in
Progress, Internet-Draft, draft-ietf-add-ddr-05, 31
January 2022, <https://www.ietf.org/archive/id/draft-ietf-
add-ddr-05.txt>.
[I-D.ietf-add-dnr] [I-D.ietf-add-dnr]
Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
Jensen, "DHCP and Router Advertisement Options for the Jensen, "DHCP and Router Advertisement Options for the
Discovery of Network-designated Resolvers (DNR)", Work in Discovery of Network-designated Resolvers (DNR)", Work in
Progress, Internet-Draft, draft-ietf-add-dnr-05, 13 Progress, Internet-Draft, draft-ietf-add-dnr-06, 22 March
December 2021, <https://www.ietf.org/archive/id/draft- 2022, <https://www.ietf.org/archive/id/draft-ietf-add-dnr-
ietf-add-dnr-05.txt>. 06.txt>.
[I-D.ietf-ipsecme-add-ike] [I-D.ietf-ipsecme-add-ike]
Boucadair, M., Reddy, T., Wing, D., and V. Smyslov, Boucadair, M., Reddy, T., Wing, D., and V. Smyslov,
"Internet Key Exchange Protocol Version 2 (IKEv2) "Internet Key Exchange Protocol Version 2 (IKEv2)
Configuration for Encrypted DNS", Work in Progress, Configuration for Encrypted DNS", Work in Progress,
Internet-Draft, draft-ietf-ipsecme-add-ike-00, 17 December Internet-Draft, draft-ietf-ipsecme-add-ike-01, 22 March
2021, <https://www.ietf.org/archive/id/draft-ietf-ipsecme- 2022, <https://www.ietf.org/archive/id/draft-ietf-ipsecme-
add-ike-00.txt>. add-ike-01.txt>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
[RFC2937] Smith, C., "The Name Service Search Option for DHCP",
RFC 2937, DOI 10.17487/RFC2937, September 2000,
<https://www.rfc-editor.org/info/rfc2937>.
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
Protocol (DHCP) Domain Search Option", RFC 3397,
DOI 10.17487/RFC3397, November 2002,
<https://www.rfc-editor.org/info/rfc3397>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>.
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
Configuration Protocol (DHCP) Client Fully Qualified
Domain Name (FQDN) Option", RFC 4702,
DOI 10.17487/RFC4702, October 2006,
<https://www.rfc-editor.org/info/rfc4702>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<https://www.rfc-editor.org/info/rfc4704>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
DOI 10.17487/RFC5986, September 2010,
<https://www.rfc-editor.org/info/rfc5986>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, DOI 10.17487/RFC6106, November 2010, RFC 6106, DOI 10.17487/RFC6106, November 2010,
<https://www.rfc-editor.org/info/rfc6106>. <https://www.rfc-editor.org/info/rfc6106>.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
<https://www.rfc-editor.org/info/rfc6731>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>. <https://www.rfc-editor.org/info/rfc7556>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>. 2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
skipping to change at page 11, line 31 skipping to change at page 15, line 22
[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)", Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019, RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>. <https://www.rfc-editor.org/info/rfc8598>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>. <https://www.rfc-editor.org/info/rfc8806>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy Tirumaleswar Reddy
Akamai Akamai
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore 560071 Bangalore 560071
Karnataka Karnataka
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
 End of changes. 49 change blocks. 
242 lines changed or deleted 408 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/