1 Internet Engineering Task Force (IETF) W. Kumari
2 Request for Comments: 7706 Google
3 Category: Informational P. Hoffman
4 ISSN: 2070-1721 ICANN
5 November 2015
6
7
8 Decreasing Access Time to Root Servers by Running One on Loopback
9
10 Abstract
11
12 Some DNS recursive resolvers have longer-than-desired round-trip
13 times to the closest DNS root server. Some DNS recursive resolver
14 operators want to prevent snooping of requests sent to DNS root
15 servers by third parties. Such resolvers can greatly decrease the
16 round-trip time and prevent observation of requests by running a copy
17 of the full root zone on a loopback address (such as 127.0.0.1).
18 This document shows how to start and maintain such a copy of the root
19 zone that does not pose a threat to other users of the DNS, at the
20 cost of adding some operational fragility for the operator.
21
22 Status of This Memo
23
24 This document is not an Internet Standards Track specification; it is
25 published for informational purposes.
26
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Not all documents
31 approved by the IESG are a candidate for any level of Internet
32 Standard; see Section 2 of RFC 5741.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc7706.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Kumari & Hoffman Informational [Page 1]
53 RFC 7706 Running Root on Loopback November 2015
54
55
56 Copyright Notice
57
58 Copyright (c) 2015 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
75 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
76 3. Operation of the Root Zone on the Loopback Address . . . . . 5
77 4. Using the Root Zone Server on the Loopback Address . . . . . 6
78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
80 6.1. Normative References . . . . . . . . . . . . . . . . . . 6
81 6.2. Informative References . . . . . . . . . . . . . . . . . 7
82 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
83 Appendix B. Example Configurations of Common Implementations . . 8
84 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
85 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
86 B.3. Example Configuration: Microsoft Windows Server 2012 . . 11
87 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Kumari & Hoffman Informational [Page 2]
108 RFC 7706 Running Root on Loopback November 2015
109
110
111 1. Introduction
112
113 DNS recursive resolvers have to provide answers to all queries from
114 their customers, even those for domain names that do not exist. For
115 each queried name that has a top-level domain (TLD) that is not in
116 the recursive resolver's cache, the resolver must send a query to a
117 root server to get the information for that TLD, or to find out that
118 the TLD does not exist. Typically, the vast majority of queries
119 going to the root are for names that do not exist in the root zone,
120 and the negative answers are cached for a much shorter period of
121 time. A slow path between the recursive resolver and the closest
122 root server has a negative effect on the resolver's customers.
123
124 Recursive resolvers currently send queries for all TLDs that are not
125 in their caches to root servers, even though most of those queries
126 get answers that are referrals to other servers. Malicious third
127 parties might be able to observe that traffic on the network between
128 the recursive resolver and one or more of the DNS roots.
129
130 This document describes a method for the operator of a recursive
131 resolver to greatly speed these queries and to hide them from
132 outsiders. The basic idea is to create an up-to-date root zone
133 server on a loopback address on the same host as the recursive
134 server, and use that server when the recursive resolver looks up root
135 information. The recursive resolver validates all responses from the
136 root server on the loopback address, just as it would all responses
137 from a remote root server.
138
139 The primary goals of this design are to provide faster negative
140 responses to stub resolver queries that contain junk queries, and to
141 prevent queries and responses from being visible on the network.
142 This design will probably have little effect on getting faster
143 positive responses to stub resolver for good queries on TLDs, because
144 the data for those zones is usually long-lived and already in the
145 cache of the recursive resolver; thus, getting faster positive
146 responses is a non-goal of this design.
147
148 This design explicitly only allows the new root zone server to be run
149 on a loopback address, in order to prevent the server from serving
150 authoritative answers to any system other than the recursive
151 resolver.
152
153 It is important to note that the design being described here is not
154 considered a "best practice". In fact, many people feel that it is
155 an excessively risky practice because it introduces a new operational
156 piece to local DNS operations where there was not one before. The
157
158
159
160
161
162 Kumari & Hoffman Informational [Page 3]
163 RFC 7706 Running Root on Loopback November 2015
164
165
166 advantages listed above do not come free: if this new system does not
167 work correctly, users can get bad data, or the entire recursive
168 resolution system might fail in ways that are hard to diagnose.
169
170 This design requires the addition of authoritative name server
171 software running on the same machine as the recursive resolver.
172 Thus, recursive resolver software such as BIND will not need to add
173 much new functionality, but recursive resolver software such as
174 Unbound will need to be able to talk to an authoritative server (such
175 as NSD) running on the same host.
176
177 Because of the significant operational risks described in this
178 document, distributions of recursive DNS servers MUST NOT include
179 configuration for the design described here. It is acceptable to
180 point to this document, but not to indicate that this configuration
181 is something that should be considered without reading the entire
182 document.
183
184 A different approach to solving the problems discussed in this
185 document is described in [AggressiveNSEC].
186
187 1.1. Requirements Notation
188
189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
191 document are to be interpreted as described in [RFC2119].
192
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
193 2. Requirements
194
195 In order to implement the mechanism described in this document:
196
197 o The system MUST be able to validate a zone with DNSSEC [RFC4033].
198
199 o The system MUST have an up-to-date copy of the DNS root key.
200
201 o The system MUST be able to retrieve a copy of the entire root zone
202 (including all DNSSEC-related records).
203
204 o The system MUST be able to run an authoritative server on one of
205 the IPv4 loopback addresses (that is, an address in the range
206 127/8 for IPv4 or ::1 in IPv6).
207
208 A corollary of the above list is that authoritative data in the root
209 zone used on the local authoritative server MUST be identical to the
210 same data in the root zone for the DNS. It is possible to change the
211 unsigned data (the glue records) in the copy of the root zone, but
212
213
214
215
216
217 Kumari & Hoffman Informational [Page 4]
218 RFC 7706 Running Root on Loopback November 2015
219
220
221 such changes could cause problems for the recursive server that
222 accesses the local root zone, and therefore any changes to the glue
223 records SHOULD NOT be made.
224
225 3. Operation of the Root Zone on the Loopback Address
226
227 The operation of an authoritative server for the root in the system
228 described here can be done separately from the operation of the
229 recursive resolver.
230
231 The steps to set up the root zone are:
232
233 1. Retrieve a copy of the root zone. (See Appendix A for some
234 current locations of sources.)
235
236 2. Start the authoritative server with the root zone on a loopback
237 address that is not in use. For IPv4, this would typically be
238 127.0.0.1, but if that address is in use, any address in 127/8 is
239 acceptable. For IPv6, this would be ::1.
240
241 The contents of the root zone MUST be refreshed using the timers from
242 the SOA record in the root zone, as described in [RFC1035]. This
243 inherently means that the contents of the local root zone will likely
244 be a little behind those of the global root servers because those
245 servers are updated when triggered by NOTIFY messages. If the
246 contents of the zone cannot be refreshed before the expire time, the
247 server MUST return a SERVFAIL error response for all queries until
248 the zone can be successfully be set up again.
249
250 In the event that refreshing the contents of the root zone fails, the
251 results can be disastrous. For example, sometimes all the NS records
252 for a TLD are changed in a short period of time (such as 2 days); if
253 the refreshing of the local root zone is broken during that time, the
254 recursive resolver will have bad data for the entire TLD zone.
255
256 An administrator using the procedure in this document SHOULD have an
257 automated method to check that the contents of the local root zone
258 are being refreshed. One way to do this is to have a separate
259 process that periodically checks the SOA of the root zone from the
260 local root zone and makes sure that it is changing. At the time that
261 this document is published, the SOA for the root zone is the digital
262 representation of the current date with a two-digit counter appended,
263 and the SOA is changed every day even if the contents of the root
264 zone are unchanged. For example, the SOA of the root zone on January
265 2, 2015 was 2015010201. A process can use this fact to create a
266 check for the contents of the local root zone (using a program not
267 specified in this document).
268
269
270
271
272 Kumari & Hoffman Informational [Page 5]
273 RFC 7706 Running Root on Loopback November 2015
274
275
276 4. Using the Root Zone Server on the Loopback Address
277
278 A recursive resolver that wants to use a root zone server operating
279 as described in Section 3 simply specifies the local address as the
280 place to look when it is looking for information from the root. All
281 responses from the root server must be validated using DNSSEC.
282
283 Note that using this configuration will cause the recursive resolver
284 to fail if the local root zone server fails. See Appendix B for more
285 discussion of this for specific software.
286
287 To test the proper operation of the recursive resolver with the local
288 root server, use a DNS client to send a query for the SOA of the root
289 to the recursive server. Make sure the response that comes back has
290 the AA bit in the message header set to 0.
291
292 5. Security Considerations
293
294 A system that does not follow the DNSSEC-related requirements given
295 in Section 2 can be fooled into giving bad responses in the same way
296 as any recursive resolver that does not do DNSSEC validation on
297 responses from a remote root server. Anyone deploying the method
298 described in this document should be familiar with the operational
299 benefits and costs of deploying DNSSEC [RFC4033].
300
301 As stated in Section 1, this design explicitly only allows the new
302 root zone server to be run on a loopback address, in order to prevent
303 the server from serving authoritative answers to any system other
304 than the recursive resolver. This has the security property of
305 limiting damage to any other system that might try to rely on an
306 altered copy of the root.
307
308 6. References
309
310 6.1. Normative References
311
312 [RFC1035] Mockapetris, P., "Domain names - implementation and
313 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
314 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
315
316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
317 Requirement Levels", BCP 14, RFC 2119,
318 DOI 10.17487/RFC2119, March 1997,
319 <http://www.rfc-editor.org/info/rfc2119>.
320
321
322
323
324
325
326
327 Kumari & Hoffman Informational [Page 6]
328 RFC 7706 Running Root on Loopback November 2015
329
330
331 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
332 Rose, "DNS Security Introduction and Requirements",
333 RFC 4033, DOI 10.17487/RFC4033, March 2005,
334 <http://www.rfc-editor.org/info/rfc4033>.
335
336 6.2. Informative References
337
338 [AggressiveNSEC]
339 Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3",
340 Work in Progress, draft-fujiwara-dnsop-nsec-
341 aggressiveuse-02, October 2015.
342
343 [Manning2013]
344 Manning, W., "Client Based Naming", 2013,
345 <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
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 Kumari & Hoffman Informational [Page 7]
383 RFC 7706 Running Root on Loopback November 2015
384
385
386 Appendix A. Current Sources of the Root Zone
387
388 The root zone can be retrieved from anywhere as long as it comes with
389 all the DNSSEC records needed for validation. Currently, one can get
390 the root zone from ICANN by zone transfer (AXFR) over TCP from DNS
391 servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
392
393 Currently, the root can also be retrieved by AXFR over TCP from the
394 following root server operators:
395
396 o b.root-servers.net
397
398 o c.root-servers.net
399
400 o f.root-servers.net
401
402 o g.root-servers.net
403
404 o k.root-servers.net
405
406 It is crucial to note that none of the above services are guaranteed
407 to be available. It is possible that ICANN or some of the root
408 server operators will turn off the AXFR capability on the servers
409 listed above. Using AXFR over TCP to addresses that are likely to be
410 anycast (as the ones above are) may conceivably have transfer
411 problems due to anycast, but current practice shows that to be
412 unlikely.
413
414 To repeat the requirement from earlier in this document: if the
415 contents of the zone cannot be refreshed before the expire time, the
416 server MUST return a SERVFAIL error response for all queries until
417 the zone can be successfully be set up again.
418
419 Appendix B. Example Configurations of Common Implementations
420
421 This section shows fragments of configurations for some popular
422 recursive server software that is believed to correctly implement the
423 requirements given in this document.
424
425 The IPv4 and IPv6 addresses in this section were checked recently by
426 testing for AXFR over TCP from each address for the known single-
427 letter names in the root-servers.net zone.
428
429 The examples here use a loopback address of 127.12.12.12, but typical
430 installations will use 127.0.0.1. The different address is used in
431 order to emphasize that the root server does not need to be on the
432 device at "localhost".
433
434
435
436
437 Kumari & Hoffman Informational [Page 8]
438 RFC 7706 Running Root on Loopback November 2015
439
440
441 B.1. Example Configuration: BIND 9.9
442
443 BIND acts both as a recursive resolver and an authoritative server.
444 Because of this, there is "fate-sharing" between the two servers in
445 the following configuration. That is, if the root server dies, it is
446 likely that all of BIND is dead.
447
448 Using this configuration, queries for information in the root zone
449 are returned with the AA bit not set.
450
451 When slaving a zone, BIND will treat zone data differently if the
452 zone is slaved into a separate view (or a separate instance of the
453 software) versus slaved into the same view or instance that is also
454 performing the recursion.
455
456 Validation: When using separate views or separate instances, the DS
457 records in the slaved zone will be validated as the zone data is
458 accessed by the recursive server. When using the same view, this
459 validation does not occur for the slaved zone.
460
461 Caching: When using separate views or instances, the recursive
462 server will cache all of the queries for the slaved zone, just as
463 it would using the traditional "root hints" method. Thus, as the
464 zone in the other view or instance is refreshed or updated,
465 changed information will not appear in the recursive server until
466 the TTL of the old record times out. Currently, the TTL for DS
467 and delegation NS records is two days. When using the same view,
468 all zone data in the recursive server will be updated as soon as
469 it receives its copy of the zone.
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492 Kumari & Hoffman Informational [Page 9]
493 RFC 7706 Running Root on Loopback November 2015
494
495
496 view root {
497 match-destinations { 127.12.12.12; };
498 zone "." {
499 type slave;
500 file "rootzone.db";
501 notify no;
502 masters {
503 192.228.79.201; # b.root-servers.net
504 192.33.4.12; # c.root-servers.net
505 192.5.5.241; # f.root-servers.net
506 192.112.36.4; # g.root-servers.net
507 193.0.14.129; # k.root-servers.net
508 192.0.47.132; # xfr.cjr.dns.icann.org
509 192.0.32.132; # xfr.lax.dns.icann.org
510 2001:500:84::b; # b.root-servers.net
511 2001:500:2f::f; # f.root-servers.net
512 2001:7fd::1; # k.root-servers.net
513 2620:0:2830:202::132; # xfr.cjr.dns.icann.org
514 2620:0:2d0:202::132; # xfr.lax.dns.icann.org
515 };
516 };
517 };
518
519 view recursive {
520 dnssec-validation auto;
521 allow-recursion { any; };
522 recursion yes;
523 zone "." {
524 type static-stub;
525 server-addresses { 127.12.12.12; };
526 };
527 };
528
529 B.2. Example Configuration: Unbound 1.4 and NSD 4
530
531 Unbound and NSD are separate software packages. Because of this,
532 there is no "fate-sharing" between the two servers in the following
533 configurations. That is, if the root server instance (NSD) dies, the
534 recursive resolver instance (Unbound) will probably keep running but
535 will not be able to resolve any queries for the root zone.
536 Therefore, the administrator of this configuration might want to
537 carefully monitor the NSD instance and restart it immediately if it
538 dies.
539
540 Using this configuration, queries for information in the root zone
541 are returned with the AA bit not set.
542
543
544
545
546
547 Kumari & Hoffman Informational [Page 10]
548 RFC 7706 Running Root on Loopback November 2015
549
550
551 # Configuration for Unbound
552 server:
553 do-not-query-localhost: no
554 stub-zone:
555 name: "."
556 stub-prime: no
557 stub-addr: 127.12.12.12
558
559 # Configuration for NSD
560 server:
561 ip-address: 127.12.12.12
562 zone:
563 name: "."
564 request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
565 request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
566 request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
567 request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
568 request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
569 request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
570 request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
571 request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
572 request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
573 request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
574 request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
575 request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
576
577 B.3. Example Configuration: Microsoft Windows Server 2012
578
579 Windows Server 2012 contains a DNS server in the "DNS Manager"
580 component. When activated, that component acts as a recursive
581 server. DNS Manager can also act as an authoritative server.
582
583 Using this configuration, queries for information in the root zone
584 are returned with the AA bit set.
585
586 The steps to configure DNS Manager to implement the requirements in
587 this document are:
588
589 1. Launch the DNS Manager GUI. This can be done from the command
590 line ("dnsmgmt.msc") or from the Service Manager (the "DNS"
591 command in the "Tools" menu).
592
593 2. In the hierarchy under the server on which the service is
594 running, right-click on the "Forward Lookup Zones", and select
595 "New Zone". This brings up a succession of dialog boxes.
596
597 3. In the "Zone Type" dialog box, select "Secondary zone".
598
599
600
601
602 Kumari & Hoffman Informational [Page 11]
603 RFC 7706 Running Root on Loopback November 2015
604
605
606 4. In the "Zone Name" dialog box, enter ".".
607
608 5. In the "Master DNS Servers" dialog box, enter
609 "b.root-servers.net". The system validates that it can do a zone
610 transfer from that server. (After this configuration is
611 completed, the DNS Manager will attempt to transfer from all of
612 the root zone servers.)
613
614 6. In the "Completing the New Zone Wizard" dialog box, click
615 "Finish".
616
617 7. Verify that the DNS Manager is acting as a recursive resolver.
618 Right-click on the server name in the hierarchy, choosing the
619 "Advanced" tab in the dialog box. See that "Disable recursion
620 (also disables forwarders)" is not selected, and that "Enable
621 DNSSEC validation for remote responses" is selected.
622
623 Acknowledgements
624
625 The authors fully acknowledge that running a copy of the root zone on
626 the loopback address is not a new concept, and that we have chatted
627 with many people about that idea over time. For example, Bill
628 Manning described a similar solution but to a very different problem
629 (intermittent connectivity, instead of constant but slow
630 connectivity) in his doctoral dissertation in 2013 [Manning2013].
631
632 Evan Hunt contributed greatly to the logic in the requirements.
633 Other significant contributors include Wouter Wijngaards, Tony Hain,
634 Doug Barton, Greg Lindsay, and Akira Kato. The authors also received
635 many offline comments about making the document clear that this is
636 just a description of a way to operate a root zone on localhost, and
637 not a recommendation to do so.
638
639 Authors' Addresses
640
641 Warren Kumari
642 Google
643
644 Email: Warren@kumari.net
645
646
647 Paul Hoffman
648 ICANN
649
650 Email: paul.hoffman@icann.org
651
652
653
654
655
656
657 Kumari & Hoffman Informational [Page 12]
658
The system MUST be able to run an authoritative server on one of the IPv4 loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 in IPv6).
The system MUST be able to run an authoritative server on one of the IP loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 in IPv6).
reviewed