-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-reddy-add-enterprise-split-dns-10.xml
680 lines (570 loc) · 32.4 KB
/
draft-reddy-add-enterprise-split-dns-10.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-reddy-add-enterprise-split-dns-10"
ipr="trust200902">
<front>
<title abbrev="Establishing Local DNS Authority">Establishing Local DNS
Authority in Split-Horizon Environments</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Akamai</organization>
<address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560071</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization>
<address>
<postal>
<street>4988 Great America Pkwy</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Kevin Smith" initials="K." surname="Smith">
<organization abbrev="Vodafone">Vodafone Group</organization>
<address>
<postal>
<street>One Kingdom Street</street>
<city>London</city>
<country>UK</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Benjamin Schwartz" initials="B." surname="Schwartz">
<organization abbrev="Google">Google LLC</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date />
<workgroup>ADD</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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
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".</t>
<t>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 <xref target="RFC8806"></xref>, mDNS <xref
target="RFC6762"></xref>, and NXDOMAIN synthesis for .onion <xref
target="RFC7686"></xref>.</t>
<t>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 <xref
target="RFC6106"></xref>), 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.</t>
<t>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 with either pure resolution behavior 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.</t>
<t>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 (<xref target="learning"></xref>).
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.</t>
<t>This specification describes a protocol between domains, networks,
and clients that allows the network to establish its authority over a
domain to a client (<xref target="establishing"></xref>). Clients can
use this protocol to confirm that a local domain hint was authorized by
the domain (<xref target="validating"></xref>), which might influence
its processing of that hint.</t>
<t>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.</t>
</section>
<section anchor="notation" title="Terminology">
<t>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
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
only when, they appear in all capitals, as shown here.</t>
<t>This document makes use of the terms defined in <xref
target="RFC8499"></xref>. The term "Global DNS" is defined in <xref
target="RFC8499"></xref>.</t>
<t>'Encrypted DNS' refers to a DNS protocol that provides an encrypted
channel between a DNS client and server (e.g., DoT, DoH, or DoQ).</t>
<t>The term 'Validated Split-Horizon' is also defined.</t>
<section title="Validated Split-Horizon">
<t>A split horizon configuration for some name is considered
"validated" 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.</t>
</section>
</section>
<section title="Scope">
<t>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.</t>
</section>
<section anchor="learning" title="Local Domain Hint Mechanisms">
<t>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.</t>
<section anchor="dhcp" title="DHCP Options">
<t>There are several DHCP options that convey local domain hints of
different kinds. The most directly relevant is "RDNSS Selection" <xref
target="RFC6731"></xref>, 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: <list>
<t>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.</t>
</list></t>
<t>Other local domain hints in DHCP include the "Domain Name" <xref
target="RFC2132"></xref>, "Access Network Domain Name" <xref
target="RFC5986"></xref>, "Client FQDN" <xref
target="RFC4702"></xref><xref target="RFC4704"></xref>, and "Name
Service Search" <xref target="RFC2937"></xref> 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.</t>
<t>The Domain Search option <xref target="RFC3397"></xref> <xref
target="RFC3646"></xref>, 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.)</t>
</section>
<section anchor="hostconfig" title="Host Configuration">
<t>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 <xref
target="vpn"></xref>). 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).</t>
<t>Because a rogue network can simulate all or most of the above
characteristics this specification details how to validate these
claims in <xref target="validating"></xref>.</t>
</section>
<section anchor="dnsZones" title="Provisioning Domains dnsZones">
<t>Provisioning Domains (PvDs) are defined in <xref
target="RFC7556"></xref> 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 <xref target="RFC8801"></xref> 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.</t>
</section>
<!-- provisioning domains -->
<section title="Split DNS Configuration for IKEv2">
<t>In IKEv2 VPNs, the INTERNAL_DNS_DOMAIN configuration attribute can
be used to indicate that a domain is "internal" to the VPN <xref
target="RFC8598"></xref>. To prevent abuse, the specification notes
various possible restrictions on the use of this attribute: <list>
<t>"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."</t>
<t>"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."</t>
</list> 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.</t>
</section>
</section>
<!-- Learning -->
<section anchor="establishing" title="Establishing Local DNS Authority">
<t>To establish its authority over some DNS zone, a participating
network MUST offer one or more encrypted resolvers via DNR <xref
target="I-D.ietf-add-dnr"></xref> or an equivalent mechanism (see <xref
target="vpn"></xref>). 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.</t>
</section>
<section anchor="validating"
title="Validating Authority over Local Domain Hints">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section anchor="validating-public"
title="Using Pre-configured Public Resolver">
<t>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).</t>
</section>
<!-- validating-public -->
<section anchor="validating-dnssec" title="Using DNSSEC">
<t>The 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 <xref target="RFC6698"></xref>. The result is
processed based on its DNSSEC validation state (Section 4.3 of <xref
target="RFC4035"></xref>): <list style="hanging">
<t hangText="Secure:">the response is used for validation.</t>
<t hangText="Bogus or Indeterminate:">the response is rejected and
validation is considered to have failed.</t>
<t hangText="Insecure:">the client SHOULD retry the validation
process using a different method, such as the one in <xref
target="validating-public"></xref>, to ensure compatibility with
unsigned names.</t>
</list></t>
</section>
<!-- validating-DNSSEC -->
</section>
<!-- Validating -->
<section title="Examples of Split-Horizon DNS Configuration">
<t>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).</t>
<section anchor="internal-only" title="Split-Horizon Entire Zone">
<t>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".</t>
<t>The host and network first need mutual support one of the
mechanisms described in <xref target="learning">learning</xref>. Shown
in <xref target="fig-learn"></xref> is learning using DNR and PvD.</t>
<t>Validation is then perfomed using either <xref
target="example-verify-public">Public DNS</xref> or <xref
target="example-verify-dnssec">DNSSEC</xref>.</t>
<t><list style="hanging">
<t hangText="steps 1-2:">The client determines the network's DNS
server (ns1.example.com) and Provisioning Domain (pvd.example.com)
using <xref target="I-D.ietf-add-dnr">DNR</xref> and <xref
target="RFC8801">PvD</xref>, using one of DNR Router Solicitation,
DHCPv4, or DHCPv6.</t>
<t hangText="step 3-5:">The client connects to the DNR-learned DNS
server (ns1.example.com), validates its certificate, and queries
for pvd.example.com.</t>
<t hangText="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:<figure>
<artwork><![CDATA[ {
"identifier": "pvd.example.com",
"expires": "2020-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"dnsZones:": ["example.com"]
}]]></artwork>
</figure>The JSON keys "identifier", "expires", and "prefixes"
are defined in <xref target="RFC8801"></xref>.</t>
</list></t>
<figure anchor="fig-learn"
title="Learning Local Claims of DNS Authority">
<artwork><![CDATA[
+---------+ +--------------------+ +------------+ +--------+
| client | | Network | | 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 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 | | | |
| |----------------------| | | |
]]></artwork>
</figure>
<section anchor="example-verify-public"
title="Verification using Public Resolver">
<t>The figure below shows the steps performed to verify the local
claims of DNS authority using a public resolver.</t>
<t><list style="hanging">
<t hangText="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".</t>
<t hangText="Step 3:">As the network-provided nameservers are
the same as the names retrieved from the public resolver and the
network-designated resolver's certificate includes at least one
of the names retrieved from the public resolver, the client has
finished validation that the nameservers signaled in <xref
target="I-D.ietf-add-dnr"></xref> and <xref
target="RFC8801"></xref> are owned and managed by the same
entity that published the NS records on the Internet. The
endpoint will then use that information from <xref
target="I-D.ietf-add-dnr"></xref> and <xref
target="RFC8801"></xref> to resolve names within dnsZones.</t>
</list></t>
<figure anchor="fig-verify-public"
title="Verifying Claims using Public Resolver">
<artwork><![CDATA[
+---------+ +--------------------+ +----------+
| client | | Network | | public |
| | | encrypted resolver | | resolver |
+---------+ +--------------------+ +----------+
| | |
| TLS connection | |
|--------------------------------------------------->|
| ---------------------------\ | |
|-| validate TLS certificate | | |
| |--------------------------| | |
| | |
| NS? example.com (1) | |
|--------------------------------------------------->|
| | |
| NS=ns1.example.com, ns2.example.com (2) | |
|<---------------------------------------------------|
| -------------------------------\ | |
|-| both DNR ADNs are authorized | | |
| ----------------------\--------| | |
|-| finished validation | | |
| |---------------------| | |
| | |
| use network-designated resolver | |
| for example.com (3) | |
|----------------------------------------->| |
| | |
]]></artwork>
</figure>
</section>
<!-- public -->
<section anchor="example-verify-dnssec"
title="Verification using DNSSEC">
<t>The figure below shows the steps performed to verify the local
claims of DNS authority using DNSSEC.</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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 <xref target="I-D.ietf-add-dnr"></xref>
and <xref target="RFC8801"></xref> are owned and managed by the
same entity that published the NS records on the Internet. The
endpoint will then use that information from <xref
target="I-D.ietf-add-dnr"></xref> and <xref
target="RFC8801"></xref> to resolve names within dnsZones.</t>
</list></t>
<figure anchor="fig-verify-dnssec"
title="Verifying Claims using DNSSEC">
<artwork><![CDATA[
+---------+ +--------------------+
| 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) |
|--------------------------------------------------------------->|
| |
]]></artwork>
</figure>
</section>
</section>
<section title="Split-Horizon Only Subdomain of Zone">
<t>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.</t>
<t>For such a name internal.example.com the message flow is similar to
<xref target="internal-only"></xref> 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.</t>
</section>
</section>
<section anchor="vpn" title="Validation with IKEv2">
<t>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 <xref target="I-D.ietf-ipsecme-add-ike"></xref>.</t>
<t>Other VPN tunnel types have similar configuration capabilities, not
detailed here.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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 <xref
target="RFC9162">Certificate Transparency</xref> 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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul
Wouters and Vinny Parla for the discussion and comments.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.8801'?>
<?rfc include='reference.RFC.6762'?>
<?rfc include='reference.RFC.6698'?>
<?rfc include='reference.RFC.4035'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.8499'?>
<?rfc include='reference.RFC.9162'?>
<?rfc include='reference.RFC.8598'?>
<?rfc include='reference.RFC.7556' ?>
<?rfc include='reference.RFC.7686' ?>
<?rfc include='reference.RFC.8806' ?>
<?rfc include='reference.RFC.6106' ?>
<?rfc include='reference.RFC.3646' ?>
<?rfc include='reference.RFC.3397' ?>
<?rfc include='reference.RFC.4702' ?>
<?rfc include='reference.RFC.4704' ?>
<?rfc include='reference.RFC.6731' ?>
<?rfc include='reference.RFC.2937' ?>
<?rfc include='reference.RFC.2132' ?>
<?rfc include='reference.RFC.5986' ?>
<?rfc include='reference.I-D.ietf-add-dnr'?>
<?rfc include='reference.I-D.ietf-ipsecme-add-ike'?>
<!---->
</references>
</back>
</rfc>