-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-reddy-add-enterprise-split-dns-10.txt
896 lines (587 loc) · 35.5 KB
/
draft-reddy-add-enterprise-split-dns-10.txt
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
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
ADD T. Reddy
Internet-Draft Akamai
Intended status: Standards Track D. Wing
Expires: October 15, 2022 Citrix
K. Smith
Vodafone
B. Schwartz
Google
April 13, 2022
Establishing Local DNS Authority in Split-Horizon Environments
draft-reddy-add-enterprise-split-dns-10
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 15, 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Reddy, et al. Expires October 15, 2022 [Page 1]
Internet-Draft Establishing Local DNS Authority April 2022
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Validated Split-Horizon . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Local Domain Hint Mechanisms . . . . . . . . . . . . . . . . 4
4.1. DHCP Options . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Host Configuration . . . . . . . . . . . . . . . . . . . 5
4.3. Provisioning Domains dnsZones . . . . . . . . . . . . . . 6
4.4. Split DNS Configuration for IKEv2 . . . . . . . . . . . . 6
5. Establishing Local DNS Authority . . . . . . . . . . . . . . 6
6. Validating Authority over Local Domain Hints . . . . . . . . 6
6.1. Using Pre-configured Public Resolver . . . . . . . . . . 7
6.2. Using DNSSEC . . . . . . . . . . . . . . . . . . . . . . 7
7. Examples of Split-Horizon DNS Configuration . . . . . . . . . 7
7.1. Split-Horizon Entire Zone . . . . . . . . . . . . . . . . 8
7.1.1. Verification using Public Resolver . . . . . . . . . 9
7.1.2. Verification using DNSSEC . . . . . . . . . . . . . . 10
7.2. Split-Horizon Only Subdomain of Zone . . . . . . . . . . 11
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
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".
Reddy, et al. Expires October 15, 2022 [Page 2]
Internet-Draft Establishing Local DNS Authority April 2022
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].
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
[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.
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.
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 (Section 4). 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 (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.
Reddy, et al. Expires October 15, 2022 [Page 3]
Internet-Draft Establishing Local DNS Authority April 2022
2. Terminology
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 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document makes use of the terms defined in [RFC8499]. The term
"Global DNS" is defined in [RFC8499].
'Encrypted DNS' refers to a DNS protocol that provides an encrypted
channel between a DNS client and server (e.g., DoT, DoH, or DoQ).
The term 'Validated Split-Horizon' is also defined.
2.1. Validated Split-Horizon
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.
3. Scope
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.
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:
Reddy, et al. Expires October 15, 2022 [Page 4]
Internet-Draft Establishing Local DNS Authority April 2022
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.
Reddy, et al. Expires October 15, 2022 [Page 5]
Internet-Draft Establishing Local DNS Authority April 2022
4.3. Provisioning Domains dnsZones
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.
4.4. Split DNS Configuration for IKEv2
In IKEv2 VPNs, the INTERNAL_DNS_DOMAIN configuration attribute can be
used to indicate that a domain is "internal" to the VPN [RFC8598].
To prevent abuse, the specification notes various possible
restrictions on the use of this attribute:
"If a client is configured by local policy to only accept a
limited set of INTERNAL_DNS_DOMAIN values, the client MUST ignore
any other INTERNAL_DNS_DOMAIN values."
"IKE clients MAY want to require whitelisted domains for Top-Level
Domains (TLDs) and Second-Level Domains (SLDs) to further prevent
malicious DNS redirections for well-known domains."
Within these guidelines, a client could adopt a local policy of
accepting INTERNAL_DNS_DOMAIN values only when it can validate the
local DNS server's authority over those names as described in this
specification.
5. Establishing Local DNS Authority
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.
6. Validating Authority over Local Domain Hints
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
Reddy, et al. Expires October 15, 2022 [Page 6]
Internet-Draft Establishing Local DNS Authority April 2022
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
choice (e.g. querying one of the network-provided resolvers,
performing iterative resolution locally), and performs full DNSSEC
validation locally [RFC6698]. The result is processed based on its
DNSSEC validation state (Section 4.3 of [RFC4035]):
Secure: the response is used for validation.
Bogus or Indeterminate: the response is rejected and validation is
considered to have failed.
Insecure: the client SHOULD retry the validation process using a
different method, such as the one in Section 6.1, to ensure
compatibility with unsigned names.
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).
Reddy, et al. Expires October 15, 2022 [Page 7]
Internet-Draft Establishing Local DNS Authority April 2022
7.1. Split-Horizon Entire Zone
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".
The host and network first need mutual support one of the mechanisms
described in learning (Section 4). Shown in Figure 1 is learning
using DNR and PvD.
Validation is then perfomed using either Public DNS (Section 7.1.1)
or DNSSEC (Section 7.1.2).
steps 1-2: The client determines the network's DNS server
(ns1.example.com) and Provisioning Domain (pvd.example.com) using
DNR [I-D.ietf-add-dnr] and PvD [RFC8801], using one of DNR Router
Solicitation, DHCPv4, or DHCPv6.
step 3-5: The client connects to the DNR-learned DNS server
(ns1.example.com), validates its certificate, and queries for
pvd.example.com.
steps 6-7: The client connects to the PvD server, validates its
certificate, and retrieves the provisioning domain JSON
information indicated by the associated PvD. The PvD contains:
{
"identifier": "pvd.example.com",
"expires": "2020-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"dnsZones:": ["example.com"]
}
The JSON keys "identifier", "expires", and "prefixes" are defined
in [RFC8801].
Reddy, et al. Expires October 15, 2022 [Page 8]
Internet-Draft Establishing Local DNS Authority April 2022
+---------+ +--------------------+ +------------+ +--------+
| 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 | | | |
| |----------------------| | | |
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
Reddy, et al. Expires October 15, 2022 [Page 9]
Internet-Draft Establishing Local DNS Authority April 2022
dnsZones. The NS lookup for "example.com" will return
"ns1.example.com" and "ns2.example.com".
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 [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 | | 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) | |
|----------------------------------------->| |
| | |
Figure 2: Verifying Claims using Public Resolver
7.1.2. Verification using DNSSEC
The figure below shows the steps performed to verify the local claims
of DNS authority using DNSSEC.
Reddy, et al. Expires October 15, 2022 [Page 10]
Internet-Draft Establishing Local DNS Authority April 2022
Steps 1-2: The DNSSEC-validating client queries the network
encrypted resolver to issue NS queries for the domains in
dnsZones. The NS lookup for "example.com" will return a signed
response containing "ns1.example.com" and "ns2.example.com". The
client then performs full DNSSEC validation locally.
Step 3: 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
Reddy, et al. Expires October 15, 2022 [Page 11]
Internet-Draft Establishing Local DNS Authority April 2022
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
the VPN service provider can be securely discovered by the endpoint
using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types
defined in [I-D.ietf-ipsecme-add-ike].
Other VPN tunnel types have similar configuration capabilities, not
detailed here.
9. Security Considerations
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.
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 [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.
11. Acknowledgements
Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul
Wouters and Vinny Parla for the discussion and comments.
12. References
Reddy, et al. Expires October 15, 2022 [Page 12]
Internet-Draft Establishing Local DNS Authority April 2022
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8801] Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/info/rfc8801>.
12.2. Informative References
[I-D.ietf-add-dnr]
Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
Jensen, "DHCP and Router Advertisement Options for the
Discovery of Network-designated Resolvers (DNR)", draft-
ietf-add-dnr-07 (work in progress), April 2022.
[I-D.ietf-ipsecme-add-ike]
Boucadair, M., Reddy, T., Wing, D., and V. Smyslov,
"Internet Key Exchange Protocol Version 2 (IKEv2)
Configuration for Encrypted DNS", draft-ietf-ipsecme-add-
ike-01 (work in progress), March 2022.
[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>.
Reddy, et al. Expires October 15, 2022 [Page 13]
Internet-Draft Establishing Local DNS Authority April 2022
[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,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, DOI 10.17487/RFC6106, November 2010,
<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
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>.
Reddy, et al. Expires October 15, 2022 [Page 14]
Internet-Draft Establishing Local DNS Authority April 2022
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<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
Tirumaleswar Reddy
Akamai
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: [email protected]
Dan Wing
Citrix Systems, Inc.
4988 Great America Pkwy
Santa Clara, CA 95054
USA
Email: [email protected]
Kevin Smith
Vodafone Group
One Kingdom Street
London
UK
Email: [email protected]
Reddy, et al. Expires October 15, 2022 [Page 15]
Internet-Draft Establishing Local DNS Authority April 2022
Benjamin Schwartz
Google LLC
Email: [email protected]
Reddy, et al. Expires October 15, 2022 [Page 16]