1 Internet Engineering Task Force (IETF) W. Kumari
2 Request for Comments: 8806 Google
3 Obsoletes: 7706 P. Hoffman
4 Category: Informational ICANN
5 ISSN: 2070-1721 June 2020
6
7
8 Running a Root Server Local to a Resolver
9
10 Abstract
11
12 Some DNS recursive resolvers have longer-than-desired round-trip
13 times to the closest DNS root server; those resolvers may have
14 difficulty getting responses from the root servers, such as during a
15 network attack. Some DNS recursive resolver operators want to
16 prevent snooping by third parties of requests sent to DNS root
17 servers. In both cases, resolvers can greatly decrease the round-
18 trip time and prevent observation of requests by serving a copy of
19 the full root zone on the same server, such as on a loopback address
20 or in the resolver software. This document shows how to start and
21 maintain such a copy of the root zone that does not cause problems
22 for other users of the DNS, at the cost of adding some operational
23 fragility for the operator.
24
25 This document obsoletes RFC 7706.
26
27 Status of This Memo
28
29 This document is not an Internet Standards Track specification; it is
30 published for informational purposes.
31
32 This document is a product of the Internet Engineering Task Force
33 (IETF). It represents the consensus of the IETF community. It has
34 received public review and has been approved for publication by the
35 Internet Engineering Steering Group (IESG). Not all documents
36 approved by the IESG are candidates for any level of Internet
37 Standard; see Section 2 of RFC 7841.
38
39 Information about the current status of this document, any errata,
40 and how to provide feedback on it may be obtained at
41 https://www.rfc-editor.org/info/rfc8806.
42
43 Copyright Notice
44
45 Copyright (c) 2020 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
47
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (https://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
57
58 Table of Contents
59
60 1. Introduction
61 1.1. Changes from RFC 7706
62 1.2. Requirements Notation
63 2. Requirements
64 3. Operation of the Root Zone on the Local Server
65 4. Security Considerations
66 5. IANA Considerations
67 6. References
68 6.1. Normative References
69 6.2. Informative References
70 Appendix A. Current Sources of the Root Zone
71 A.1. Root Zone Services
72 Appendix B. Example Configurations of Common Implementations
73 B.1. Example Configuration: BIND 9.12
74 B.2. Example Configuration: Unbound 1.8
75 B.3. Example Configuration: BIND 9.14
76 B.4. Example Configuration: Unbound 1.9
77 B.5. Example Configuration: Knot Resolver
78 B.6. Example Configuration: Microsoft Windows Server 2012
79 Acknowledgements
80 Authors' Addresses
81
82 1. Introduction
83
84 DNS recursive resolvers have to provide answers to all queries from
85 their clients, even those for domain names that do not exist. For
86 each queried name that is within a top-level domain (TLD) that is not
87 in the recursive resolver's cache, the resolver must send a query to
88 a root server to get the information for that TLD or to find out that
89 the TLD does not exist. Research shows that the vast majority of
90 queries going to the root are for names that do not exist in the root
91 zone.
92
93 Many of the queries from recursive resolvers to root servers get
94 answers that are referrals to other servers. Malicious third parties
95 might be able to observe that traffic on the network between the
96 recursive resolver and root servers.
97
98 The primary goals of this design are to provide more reliable answers
99 for queries to the root zone during network attacks that affect the
100 root servers and to prevent queries and responses from being visible
101 on the network. This design will probably have little effect on
102 getting faster responses to the stub resolver for good queries on
103 TLDs, because the TTL for most TLDs is usually long-lived (on the
104 order of a day or two) and is thus usually already in the cache of
105 the recursive resolver; the same is true for the TTL for negative
106 answers from the root servers. (Although the primary goal of the
107 design is for serving the root zone, the method can be used for any
108 zone.)
109
110 This document describes a method for the operator of a recursive
111 resolver to have a complete root zone locally and to hide queries for
112 the root zone from outsiders. The basic idea is to create an up-to-
113 date root zone service on the same host as the recursive server and
114 use that service when the recursive resolver looks up root
115 information. The recursive resolver validates all responses from the
116 root service on the same host, just as it would validate all
117 responses from a remote root server.
118
119 This design explicitly only allows the new root zone service to be
120 run on the same server as the recursive resolver in order to prevent
121 the server from serving authoritative answers to any other system.
122 Specifically, the root service on the local system MUST be configured
123 to only answer queries from resolvers on the same host and MUST NOT
124 answer queries from any other resolver.
125
126 At the time that RFC 7706 [RFC7706] was published, it was considered
127 controversial, because there was not consensus on whether this was a
128 "best practice". In fact, many people felt that it is an excessively
129 risky practice, because it introduced a new operational piece to
130 local DNS operations where there was not one before. Since then, the
131 DNS operational community has largely shifted to believing that local
132 serving of the root zone for an individual resolver is a reasonable
133 practice. The advantages listed above do not come free: if this new
134 system does not work correctly, users can get bad data, or the entire
135 recursive resolution system might fail in ways that are hard to
136 diagnose.
137
138 This design uses an authoritative service running on the same machine
139 as the recursive resolver. Common open source recursive resolver
140 software does not need to add new functionality to act as an
141 authoritative server for some zones, but other recursive resolver
142 software might need to be able to talk to an authoritative server
143 running on the same host. Some resolver software supports being both
144 an authoritative server and a resolver but separated by logical
145 "views", allowing a local root to be implemented within a single
146 process; examples of this can be seen in Appendix B.
147
148 A different approach to solving some of the problems discussed in
149 this document is described in [RFC8198].
150
151 Readers are expected to be familiar with [RFC8499].
152
153 1.1. Changes from RFC 7706
154
155 RFC 7706 explicitly required that a root server instance be run on
156 the loopback interface of the host running the validating resolver.
157 However, RFC 7706 also had examples of how to set up common software
158 that did not use the loopback interface. This document loosens the
159 restriction on using the loopback interface and in fact allows the
160 use of a local service, not necessarily an authoritative server.
161 However, the document keeps the requirement that only systems running
162 on that single host be able to query that authoritative root server
163 or service.
164
165 This document changes the use cases for running a local root service
166 to be more consistent with the reasons operators said they had for
167 using RFC 7706:
168
169 * Removed the prohibition on distribution of recursive DNS servers,
170 including configurations for this design because some already do
171 and others have expressed an interest in doing so.
172
173 * Added the idea that a recursive resolver using this design might
174 switch to using the normal (remote) root servers if the local root
175 server fails.
176
177 * Refreshed the list of where one can get copies of the root zone.
178
179 * Added examples of other resolvers and updated the existing
180 examples.
181
182 1.2. Requirements Notation
183
184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
186 "OPTIONAL" in this document are to be interpreted as described in
187 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
188 capitals, as shown here.
189
190 2. Requirements
191
192 In order to implement the mechanism described in this document:
193
194 * The system MUST be able to validate every signed record in a zone
195 with DNSSEC [RFC4033].
196
197 * The system MUST have an up-to-date copy of the public part of the
198 Key Signing Key (KSK) [RFC4033] used to sign the DNS root.
199
200 * The system MUST be able to retrieve a copy of the entire root zone
201 (including all DNSSEC-related records).
202
203 * The system MUST be able to run an authoritative service for the
204 root zone on the same host. The authoritative root service MUST
205 only respond to queries from the same host. One way to ensure
206 that the authoritative root service does not respond to queries
207 from other hosts is to run an authoritative server for the root
208 that responds only on one of the loopback addresses (that is, an
209 address in the range 127/8 for IPv4 or ::1 in IPv6). Another
210 method is to have the resolver software also act as an
211 authoritative server for the root zone, but only for answering
212 queries from itself.
213
214 A corollary of the above list is that authoritative data in the root
215 zone used on the local authoritative server MUST be identical to the
216 same data in the root zone for the DNS. It is possible to change the
217 unsigned data (the glue records) in the copy of the root zone, but
218 such changes could cause problems for the recursive server that
219 accesses the local root zone, and therefore any changes to the glue
220 records SHOULD NOT be made.
221
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.
222 3. Operation of the Root Zone on the Local Server
223
224 The operation of an authoritative server for the root in the system
225 described here can be done separately from the operation of the
226 recursive resolver, or it might be part of the configuration of the
227 recursive resolver system.
228
229 The steps to set up the root zone are:
230
231 1. Retrieve a copy of the root zone. (See Appendix A for some
232 current locations of sources.)
233
234 2. Start the authoritative service for the root zone in a manner
235 that prevents any system other than a recursive resolver on the
236 same host from accessing it.
237
238 The contents of the root zone MUST be refreshed using the timers from
239 the SOA record in the root zone, as described in [RFC1035]. This
240 inherently means that the contents of the local root zone will likely
241 be a little behind those of the global root servers, because those
242 servers are updated when triggered by NOTIFY messages.
243
244 There is a risk that a system using a local authoritative server for
245 the root zone cannot refresh the contents of the root zone before the
246 expire time in the SOA. A system using a local authoritative server
247 for the root zone MUST NOT serve stale data for the root zone. To
248 mitigate the risk that stale data is served, the local root server
249 MUST immediately switch to using non-local root servers when it
250 detects that it would be serving state data.
251
252 In a resolver that is using an internal service for the root zone, if
253 the contents of the root zone cannot be refreshed before the expire
254 time in the SOA, the resolver MUST immediately switch to using non-
255 local root servers.
256
257 In the event that refreshing the contents of the root zone fails, the
258 results can be disastrous. For example, sometimes all the NS records
259 for a TLD are changed in a short period of time (such as 2 days); if
260 the refreshing of the local root zone is broken during that time, the
261 recursive resolver will have bad data for the entire TLD zone.
262
263 An administrator using the procedure in this document SHOULD have an
264 automated method to check that the contents of the local root zone
265 are being refreshed; this might be part of the resolver software.
266 One way to do this is to have a separate process that periodically
267 checks the SOA of the local root zone and makes sure that it is
268 changing. At the time that this document is published, the SOA for
269 the root zone is the digital representation of the current date with
270 a two-digit counter appended, and the SOA is changed every day even
271 if the contents of the root zone are unchanged. For example, the SOA
272 of the root zone on January 2, 2019 was 2019010201. A process can
273 use this fact to create a check for the contents of the local root
274 zone (using a program not specified in this document).
275
276 4. Security Considerations
277
278 A system that does not follow the DNSSEC-related requirements given
279 in Section 2 can be fooled into giving bad responses in the same way
280 as any recursive resolver that does not do DNSSEC validation on
281 responses from a remote root server. Anyone deploying the method
282 described in this document should be familiar with the operational
283 benefits and costs of deploying DNSSEC [RFC4033].
284
285 As stated in Section 1, this design explicitly requires the local
286 copy of the root zone information to be available only from resolvers
287 on that host. This has the security property of limiting damage to
288 clients of any local resolver that might try to rely on an altered
289 copy of the root.
290
291 5. IANA Considerations
292
293 This document has no IANA actions.
294
295 6. References
296
297 6.1. Normative References
298
299 [RFC1035] Mockapetris, P., "Domain names - implementation and
300 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
301 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
302
303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
304 Requirement Levels", BCP 14, RFC 2119,
305 DOI 10.17487/RFC2119, March 1997,
306 <https://www.rfc-editor.org/info/rfc2119>.
307
308 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
309 Rose, "DNS Security Introduction and Requirements",
310 RFC 4033, DOI 10.17487/RFC4033, March 2005,
311 <https://www.rfc-editor.org/info/rfc4033>.
312
313 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
314 Servers by Running One on Loopback", RFC 7706,
315 DOI 10.17487/RFC7706, November 2015,
316 <https://www.rfc-editor.org/info/rfc7706>.
317
318 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
319 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
320 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
321
322 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
323 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
324 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
325
326 6.2. Informative References
327
328 [Manning2013]
329 Manning, W., "Client Based Naming", May 2013,
330 <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
331
332 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
333 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
334 <https://www.rfc-editor.org/info/rfc5936>.
335
336 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
337 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
338 July 2017, <https://www.rfc-editor.org/info/rfc8198>.
339
340 Appendix A. Current Sources of the Root Zone
341
342 The root zone can be retrieved from anywhere as long as it comes with
343 all the DNSSEC records needed for validation. Currently, one can get
344 the root zone from ICANN by zone transfer AXFR [RFC5936] over TCP
345 from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
346 The root zone file can be obtained using methods described at
347 <https://www.iana.org/domains/root/files>.
348
349 Currently, the root can also be retrieved by AXFR over TCP from the
350 following root server operators:
351
352 * b.root-servers.net
353
354 * c.root-servers.net
355
356 * d.root-servers.net
357
358 * f.root-servers.net
359
360 * g.root-servers.net
361
362 * k.root-servers.net
363
364 It is crucial to note that none of the above services are guaranteed
365 to be available. It is possible that ICANN or some of the root
366 server operators will turn off the AXFR capability on the servers
367 listed above. Using AXFR over TCP to addresses that are likely to be
368 anycast (as the ones above are) may conceivably have transfer
369 problems due to anycast, but current practice shows that to be
370 unlikely.
371
There is a risk that a system using a local authoritative server for the root zone cannot refresh the contents of the root zone before the expire time in the SOA. A system using a local authoritative server for the root zone MUST NOT serve stale data for the root zone. To mitigate the risk that stale data is served, the local root server MUST immediately switch to using non-local root servers when it detects that it would be serving state data.
There is a risk that a system using a local authoritative server for the root zone cannot refresh the contents of the root zone before the expire time in the SOA. A system using a local authoritative server for the root zone MUST NOT serve stale data for the root zone. To mitigate the risk that stale data is served, the local root server MUST immediately switch to using non-local root servers when it detects that it would be serving stale data.
Based on the context, it seems that in the last sentence the intended word is "stale" as in stale data, instead of "state". So, I believe there might be a typo in the text, and the correct interpretation would be to swith back to the non-local root when stale data is detected.
372 A.1. Root Zone Services
373
374 At the time that this document is published, there is one root zone
375 service that is active and one that has been announced as in the
376 planning stages. This section describes all known active services.
377
378 LocalRoot (<https://localroot.isi.edu/>) is an experimental service
379 that embodies many of the ideas in this document. It distributes the
380 root zone by AXFR and also offers DNS NOTIFY messages when the
381 LocalRoot system sees that the root zone has changed.
382
383 Appendix B. Example Configurations of Common Implementations
384
385 This section shows fragments of configurations for some popular
386 recursive server software that is believed to correctly implement the
387 requirements given in this document. The examples have been updated
388 since the publication of [RFC7706].
389
390 The IPv4 and IPv6 addresses in this section were checked in March
391 2020 by testing for AXFR over TCP from each address for the known
392 single-letter names in the root-servers.net zone.
393
394 B.1. Example Configuration: BIND 9.12
395
396 BIND 9.12 acts both as a recursive resolver and an authoritative
397 server. Because of this, there is "fate-sharing" between the two
398 servers in the following configuration. That is, if the root server
399 dies, it is likely that all of BIND is dead.
400
401 Note that a future version of BIND will support a much more robust
402 method for creating a local mirror of the root or other zones; see
403 Appendix B.3.
404
405 Using this configuration, queries for information in the root zone
406 are returned with the Authoritative Answer (AA) bit not set.
407
408 When slaving a zone, BIND 9.12 will treat zone data differently if
409 the zone is slaved into a separate view (or a separate instance of
410 the software) versus slaved into the same view or instance that is
411 also performing the recursion.
412
413 Validation: When using separate views or separate instances, the DS
414 records in the slaved zone will be validated as the zone data is
415 accessed by the recursive server. When using the same view, this
416 validation does not occur for the slaved zone.
417
418 Caching: When using separate views or instances, the recursive
419 server will cache all of the queries for the slaved zone, just as
420 it would using the traditional "root hints" method. Thus, as the
421 zone in the other view or instance is refreshed or updated,
422 changed information will not appear in the recursive server until
423 the TTL of the old record times out. Currently, the TTL for DS
424 and delegation NS records is two days. When using the same view,
425 all zone data in the recursive server will be updated as soon as
426 it receives its copy of the zone.
427
428 view root {
429 match-destinations { 127.12.12.12; };
430 zone "." {
431 type slave;
432 file "rootzone.db";
433 notify no;
434 masters {
435 199.9.14.201; # b.root-servers.net
436 192.33.4.12; # c.root-servers.net
437 199.7.91.13; # d.root-servers.net
438 192.5.5.241; # f.root-servers.net
439 192.112.36.4; # g.root-servers.net
440 193.0.14.129; # k.root-servers.net
441 192.0.47.132; # xfr.cjr.dns.icann.org
442 192.0.32.132; # xfr.lax.dns.icann.org
443 2001:500:200::b; # b.root-servers.net
444 2001:500:2::c; # c.root-servers.net
445 2001:500:2d::d; # d.root-servers.net
446 2001:500:2f::f; # f.root-servers.net
447 2001:500:12::d0d; # g.root-servers.net
448 2001:7fd::1; # k.root-servers.net
449 2620:0:2830:202::132; # xfr.cjr.dns.icann.org
450 2620:0:2d0:202::132; # xfr.lax.dns.icann.org
451 };
452 };
453 };
454
455 view recursive {
456 dnssec-validation auto;
457 allow-recursion { any; };
458 recursion yes;
459 zone "." {
460 type static-stub;
461 server-addresses { 127.12.12.12; };
462 };
463 };
464
465 B.2. Example Configuration: Unbound 1.8
466
467 Similar to BIND, Unbound, starting with version 1.8, can act both as
468 a recursive resolver and an authoritative server.
469
470 auth-zone:
471 name: "."
472 master: 199.9.14.201 # b.root-servers.net
473 master: 192.33.4.12 # c.root-servers.net
474 master: 199.7.91.13 # d.root-servers.net
475 master: 192.5.5.241 # f.root-servers.net
476 master: 192.112.36.4 # g.root-servers.net
477 master: 193.0.14.129 # k.root-servers.net
478 master: 192.0.47.132 # xfr.cjr.dns.icann.org
479 master: 192.0.32.132 # xfr.lax.dns.icann.org
480 master: 2001:500:200::b # b.root-servers.net
481 master: 2001:500:2::c # c.root-servers.net
482 master: 2001:500:2d::d # d.root-servers.net
483 master: 2001:500:2f::f # f.root-servers.net
484 master: 2001:500:12::d0d # g.root-servers.net
485 master: 2001:7fd::1 # k.root-servers.net
486 master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org
487 master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org
488 fallback-enabled: yes
489 for-downstream: no
490 for-upstream: yes
491
492 B.3. Example Configuration: BIND 9.14
493
494 BIND 9.14 can set up a local mirror of the root zone with a small
495 configuration option:
496
497 zone "." {
498 type mirror;
499 };
500
501 The simple "type mirror" configuration for the root zone works for
502 the root zone because a default list of primary servers for the IANA
503 root zone is built into BIND 9.14. In order to set up mirroring of
504 any other zone, an explicit list of primary servers needs to be
505 provided.
506
507 See the documentation for BIND 9.14 for more detail about how to use
508 this simplified configuration.
509
510 B.4. Example Configuration: Unbound 1.9
511
512 Recent versions of Unbound have an "auth-zone" feature that allows
513 local mirroring of the root zone. Configuration looks as follows:
514
515 auth-zone:
516 name: "."
517 master: "b.root-servers.net"
518 master: "c.root-servers.net"
519 master: "d.root-servers.net"
520 master: "f.root-servers.net"
521 master: "g.root-servers.net"
522 master: "k.root-servers.net"
523 fallback-enabled: yes
524 for-downstream: no
525 for-upstream: yes
526 zonefile: "root.zone"
527
528 B.5. Example Configuration: Knot Resolver
529
530 Knot Resolver uses its "prefill" module to load the root zone
531 information. This is described at <https://knot-
532 resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html>.
533
534 B.6. Example Configuration: Microsoft Windows Server 2012
535
536 Windows Server 2012 contains a DNS server in the "DNS Manager"
537 component. When activated, that component acts as a recursive
538 server. The DNS Manager can also act as an authoritative server.
539
540 Using this configuration, queries for information in the root zone
541 are returned with the AA bit set.
542
543 The steps to configure the DNS Manager to implement the requirements
544 in this document are:
545
546 1. Launch the DNS Manager GUI. This can be done from the command
547 line ("dnsmgmt.msc") or from the Service Manager (the "DNS"
548 command in the "Tools" menu).
549
550 2. In the hierarchy under the server on which the service is
551 running, right-click on the "Forward Lookup Zones", and select
552 "New Zone". This brings up a succession of dialog boxes.
553
554 3. In the "Zone Type" dialog box, select "Secondary zone".
555
556 4. In the "Zone Name" dialog box, enter ".".
557
558 5. In the "Master DNS Servers" dialog box, enter
559 "b.root-servers.net". The system validates that it can do a zone
560 transfer from that server. (After this configuration is
561 completed, the DNS Manager will attempt to transfer from all of
562 the root zone servers.)
563
564 6. In the "Completing the New Zone Wizard" dialog box, click
565 "Finish".
566
567 7. Verify that the DNS Manager is acting as a recursive resolver.
568 Right-click on the server name in the hierarchy, choosing the
569 "Advanced" tab in the dialog box. See that "Disable recursion
570 (also disables forwarders)" is not selected and that "Enable
571 DNSSEC validation for remote responses" is selected.
572
573 Acknowledgements
574
575 The authors fully acknowledge that running a copy of the root zone on
576 the loopback address is not a new concept and that we have chatted
577 with many people about that idea over time. For example, Bill
578 Manning described a similar solution to the problems in his doctoral
579 dissertation in 2013 [Manning2013].
580
581 Evan Hunt contributed greatly to the logic in the requirements.
582 Other significant contributors include Wouter Wijngaards, Tony Hain,
583 Doug Barton, Greg Lindsay, and Akira Kato. The authors also received
584 many offline comments about making the document clear that this is
585 just a description of a way to operate a root zone on the same host
586 and not a recommendation to do so.
587
588 People who contributed to this update to [RFC7706] include Florian
589 Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and
590 Leo Vegoda.
591
592 Authors' Addresses
593
594 Warren Kumari
595 Google
596
597 Email: Warren@kumari.net
598
599
600 Paul Hoffman
601 ICANN
602
603 Email: paul.hoffman@icann.org
604
The LocalRootLocalRoot project is marked in this document as experimental, even though the author was informed that the project was being placed into a fully supported service at USC/ISI as part of their root server infrastructure