idnits 2.17.00 (12 Aug 2021) /tmp/idnits47680/draft-ietf-dnsop-7706bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 19 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC7706, but the abstract doesn't seem to directly say this. It does mention RFC7706 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2019) is 1051 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Updates: 7706 (if approved) P. Hoffman 5 Intended status: Informational ICANN 6 Expires: January 6, 2020 July 5, 2019 8 Running a Root Server Local to a Resolver 9 draft-ietf-dnsop-7706bis-04 11 Abstract 13 Some DNS recursive resolvers have longer-than-desired round-trip 14 times to the closest DNS root server. Some DNS recursive resolver 15 operators want to prevent snooping of requests sent to DNS root 16 servers by third parties. Such resolvers can greatly decrease the 17 round-trip time and prevent observation of requests by running a copy 18 of the full root zone on the same server, such as on a loopback 19 address. This document shows how to start and maintain such a copy 20 of the root zone that does not pose a threat to other users of the 21 DNS, at the cost of adding some operational fragility for the 22 operator. 24 This draft will update RFC 7706. See Section 1.1 for a list of 25 topics that will be added in the update. 27 [ Ed note: Text inside square brackets ([]) is additional background 28 information, answers to freqently asked questions, general musings, 29 etc. They will be removed before publication.] 31 [ This document is being collaborated on in Github at: 32 https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent 33 version of the document, open issues, and so on should all be 34 available there. The authors gratefully accept pull requests. ] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 6, 2020. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Updates from RFC 7706 . . . . . . . . . . . . . . . . . . 4 72 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 73 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Operation of the Root Zone on the Local Server . . . . . . . 5 75 4. Using the Root Zone Server on the Same Host . . . . . . . . . 7 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 6.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8 81 A.1. Root Zone Services . . . . . . . . . . . . . . . . . . . 9 82 Appendix B. Example Configurations of Common Implementations . . 9 83 B.1. Example Configuration: BIND 9.12 . . . . . . . . . . . . 9 84 B.2. Example Configuration: Unbound 1.8 . . . . . . . . . . . 11 85 B.3. Example Configuration: BIND 9.14 . . . . . . . . . . . . 12 86 B.4. Example Configuration: Unbound 1.9 . . . . . . . . . . . 12 87 B.5. Example Configuration: Knot Resolver . . . . . . . . . . 13 88 B.6. Example Configuration: Microsoft Windows Server 2012 . . 13 89 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 DNS recursive resolvers have to provide answers to all queries from 95 their customers, even those for domain names that do not exist. For 96 each queried name that has a top-level domain (TLD) that is not in 97 the recursive resolver's cache, the resolver must send a query to a 98 root server to get the information for that TLD, or to find out that 99 the TLD does not exist. Research shows that the vast majority of 100 queries going to the root are for names that do not exist in the root 101 zone because negative answers are sometimes cached for a much shorter 102 period of time. 104 Many of the queries from recursive resolvers to root servers get 105 answers that are referrals to other servers. Malicious third parties 106 might be able to observe that traffic on the network between the 107 recursive resolver and root servers. 109 The primary goals of this design are to provide more reliable answers 110 for queries to the root zone during network attacks, and to prevent 111 queries and responses from being visible on the network. This design 112 will probably have little effect on getting faster responses to stub 113 resolver for good queries on TLDs, because the TTL for most TLDs is 114 usually long-lived (on the order of a day or two) and is thus usually 115 already in the cache of the recursive resolver; the same is true for 116 the TTL for negative answers from the root servers. (Although the 117 primary goal of the design is for serving the root zone, the method 118 can be used for any zone.) 120 This document describes a method for the operator of a recursive 121 resolver to have a complete root zone locally, and to hide these 122 queries from outsiders. The basic idea is to create an up-to-date 123 root zone server on the same host as the recursive server, and use 124 that server when the recursive resolver looks up root information. 125 The recursive resolver validates all responses from the root server 126 on the same host, just as it would all responses from a remote root 127 server. 129 This design explicitly only allows the new root zone server to be run 130 on the same server as the recursive resolver, in order to prevent the 131 server from serving authoritative answers to any other system. 132 Specifically, the root server on the local system MUST be configured 133 to only answer queries from the resolvers on the same host, and MUST 134 NOT answer queries from any other resolver. 136 At the time that RFC 7706 was published, it was considered 137 controversial: there was not consensus on whether this was a "best 138 practice". In fact, many people felt that it is an excessively risky 139 practice because it introduced a new operational piece to local DNS 140 operations where there was not one before. Since then, the DNS 141 operational community has largely shifted to believing that local 142 serving of the root zone for an individual resolver is a reasonable 143 practice. The advantages listed above do not come free: if this new 144 system does not work correctly, users can get bad data, or the entire 145 recursive resolution system might fail in ways that are hard to 146 diagnose. 148 This design uses authoritative name server software running on the 149 same machine as the recursive resolver. Thus, recursive resolver 150 software such as BIND or modern versions of common open source 151 recursive resolver software do not need to add new functionality, but 152 other recursive resolver software might need to be able to talk to an 153 authoritative server running on the same host. 155 A different approach to solving some of the problems discussed in 156 this document is described in [RFC8198]. 158 1.1. Updates from RFC 7706 160 RFC 7706 explicitly required that the root server instance be run on 161 the loopback interface of the host running the validating resolver. 162 However, RFC 7706 also had examples of how to set up common software 163 that did not use the loopback interface. Thus, this document loosens 164 the restriction on the interface but keeps the requirement that only 165 systems running on that single host be able to query that root server 166 instance. 168 Removed the prohibition on distribution of recursive DNS servers 169 including configurations for this design because some already do, and 170 others have expressed an interest in doing so. 172 Added the idea that a recursive resolver using this design might 173 switch to using the normal (remote) root servers if the local root 174 server fails. 176 Refreshed the list of where one can get copies of the root zone. 178 Added examples of other resolvers and updated the existing examples. 180 [ This section will list all the changes from RFC 7706. For this 181 draft, it is also the list of changes that we will make in future 182 versions of the daft. ] 184 [ Make the use cases explicit. Be clearer that a real use case is 185 folks who are worried that root server unavailabilty due to DDoS 186 against them is a reason some people would use the mechanisms here. 187 ] 189 [ Describe how slaving the root zone from root zone servers does not 190 fully remove the reliance on the root servers being available. ] 192 [ Other new topics might go here. ] 194 1.2. Requirements Notation 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 2. Requirements 202 In order to implement the mechanism described in this document: 204 o The system MUST be able to validate a zone with DNSSEC [RFC4033]. 206 o The system MUST have an up-to-date copy of the key used to sign 207 the DNS root. 209 o The system MUST be able to retrieve a copy of the entire root zone 210 (including all DNSSEC-related records). 212 o The system MUST be able to run an authoritative server for the 213 root zone on the same host. The root server instance MUST only 214 respond to queries from the same host. One way to assure not 215 responding to queries from other hosts is to make the address of 216 the authoritative server one of the loopback addresses (that is, 217 an address in the range 127/8 for IPv4 or ::1 in IPv6). 219 A corollary of the above list is that authoritative data in the root 220 zone used on the local authoritative server MUST be identical to the 221 same data in the root zone for the DNS. It is possible to change the 222 unsigned data (the glue records) in the copy of the root zone, but 223 such changes could cause problems for the recursive server that 224 accesses the local root zone, and therefore any changes to the glue 225 records SHOULD NOT be made. 227 3. Operation of the Root Zone on the Local Server 229 The operation of an authoritative server for the root in the system 230 described here can be done separately from the operation of the 231 recursive resolver, or it might be part of the configuration of the 232 recursive resolver system. 234 The steps to set up the root zone are: 236 1. Retrieve a copy of the root zone. (See Appendix A for some 237 current locations of sources.) 239 2. Start the authoritative server with the root zone on an address 240 on the host that is not in use. For IPv4, this could be 241 127.0.0.1, but if that address is in use, any address in 127/8 is 242 acceptable. For IPv6, this would be ::1. It can also be a 243 publicly-visible address on the host, but only if the 244 authoritative server software allows restricting the addresses 245 that can access the authoritative server, and the software is 246 configured to only allow access from addresses on this single 247 host. 249 The contents of the root zone MUST be refreshed using the timers from 250 the SOA record in the root zone, as described in [RFC1035]. This 251 inherently means that the contents of the local root zone will likely 252 be a little behind those of the global root servers because those 253 servers are updated when triggered by NOTIFY messages. 255 If the contents of the root zone cannot be refreshed before the 256 expire time in the SOA, the local root server MUST return a SERVFAIL 257 error response for all queries sent to it until the zone can be 258 successfully be set up again. Because this would cause a recursive 259 resolver on the same host that is relying on this root server to also 260 fail, a resolver might be configured to immediatly switch to using 261 other (non-local) root servers if the resolver receives a SERVFAIL 262 response from a local root server. 264 In the event that refreshing the contents of the root zone fails, the 265 results can be disastrous. For example, sometimes all the NS records 266 for a TLD are changed in a short period of time (such as 2 days); if 267 the refreshing of the local root zone is broken during that time, the 268 recursive resolver will have bad data for the entire TLD zone. 270 An administrator using the procedure in this document SHOULD have an 271 automated method to check that the contents of the local root zone 272 are being refreshed; this might be part of the resolver software. 273 One way to do this is to have a separate process that periodically 274 checks the SOA of the root zone from the local root zone and makes 275 sure that it is changing. At the time that this document is 276 published, the SOA for the root zone is the digital representation of 277 the current date with a two-digit counter appended, and the SOA is 278 changed every day even if the contents of the root zone are 279 unchanged. For example, the SOA of the root zone on January 2, 2018 280 was 2018010201. A process can use this fact to create a check for 281 the contents of the local root zone (using a program not specified in 282 this document). 284 4. Using the Root Zone Server on the Same Host 286 A recursive resolver that wants to use a root zone server operating 287 as described in Section 3 simply specifies the local address as the 288 place to look when it is looking for information from the root. All 289 responses from the root server MUST be validated using DNSSEC. 291 Note that using this simplistic configuration will cause the 292 recursive resolver to fail if the local root zone server fails. A 293 more robust configuration would cause the resolver to start using the 294 normal remote root servers when the local root server fails (such as 295 if it does not respond or gives SERVFAIL responses). 297 See Appendix B for more discussion of this for specific software. 299 To test the proper operation of the recursive resolver with the local 300 root server, use a DNS client to send a query for the SOA of the root 301 to the recursive server. Make sure the response that comes back has 302 the AA bit in the message header set to 0. 304 5. Security Considerations 306 A system that does not follow the DNSSEC-related requirements given 307 in Section 2 can be fooled into giving bad responses in the same way 308 as any recursive resolver that does not do DNSSEC validation on 309 responses from a remote root server. Anyone deploying the method 310 described in this document should be familiar with the operational 311 benefits and costs of deploying DNSSEC [RFC4033]. 313 As stated in Section 1, this design explicitly only allows the new 314 root zone server to be run on the same host, answering queries only 315 from resolvers on that host, in order to prevent the server from 316 serving authoritative answers to any system other than the recursive 317 resolver. This has the security property of limiting damage to any 318 other system that might try to rely on an altered copy of the root. 320 6. References 322 6.1. Normative References 324 [RFC1035] Mockapetris, P., "Domain names - implementation and 325 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 326 November 1987, . 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 334 Rose, "DNS Security Introduction and Requirements", 335 RFC 4033, DOI 10.17487/RFC4033, March 2005, 336 . 338 6.2. Informative References 340 [Manning2013] 341 Manning, W., "Client Based Naming", 2013, 342 . 344 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 345 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 346 July 2017, . 348 Appendix A. Current Sources of the Root Zone 350 The root zone can be retrieved from anywhere as long as it comes with 351 all the DNSSEC records needed for validation. Currently, one can get 352 the root zone from ICANN by zone transfer (AXFR) over TCP from DNS 353 servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org. One can 354 also get the root zone from ICANN as a text file over HTTP (not 355 HTTPS) at . 357 Currently, the root can also be retrieved by AXFR over TCP from the 358 following root server operators: 360 o b.root-servers.net 362 o c.root-servers.net 364 o d.root-servers.net 366 o f.root-servers.net 368 o g.root-servers.net 370 o k.root-servers.net 372 It is crucial to note that none of the above services are guaranteed 373 to be available. It is possible that ICANN or some of the root 374 server operators will turn off the AXFR capability on the servers 375 listed above. Using AXFR over TCP to addresses that are likely to be 376 anycast (as the ones above are) may conceivably have transfer 377 problems due to anycast, but current practice shows that to be 378 unlikely. 380 To repeat the requirement from earlier in this document: if the 381 contents of the zone cannot be refreshed before the expire time, the 382 server MUST return a SERVFAIL error response for all queries until 383 the zone can be successfully be set up again. 385 A.1. Root Zone Services 387 At the time that this document is published, there is one root zone 388 service that is active, and one that has been announced as in the 389 planning stages. This section describes all known active services. 391 LocalRoot () is an experimental service 392 that embodies many of the ideas in this document. It distributes the 393 root zone by AXFR, and also offers DNS NOTIFY messages when the 394 LocalRoot system sees that the root zone has changed. 396 Appendix B. Example Configurations of Common Implementations 398 This section shows fragments of configurations for some popular 399 recursive server software that is believed to correctly implement the 400 requirements given in this document. The examples have been updated 401 since the publication of RFC 7706. 403 The IPv4 and IPv6 addresses in this section were checked recently by 404 testing for AXFR over TCP from each address for the known single- 405 letter names in the root-servers.net zone. 407 B.1. Example Configuration: BIND 9.12 409 BIND 9.12 acts both as a recursive resolver and an authoritative 410 server. Because of this, there is "fate-sharing" between the two 411 servers in the following configuration. That is, if the root server 412 dies, it is likely that all of BIND is dead. 414 Note that a future version of BIND will support a much more robust 415 method for creating a local mirror of the root or other zones; see 416 Appendix B.3. 418 Using this configuration, queries for information in the root zone 419 are returned with the AA bit not set. 421 When slaving a zone, BIND 9.12 will treat zone data differently if 422 the zone is slaved into a separate view (or a separate instance of 423 the software) versus slaved into the same view or instance that is 424 also performing the recursion. 426 Validation: When using separate views or separate instances, the DS 427 records in the slaved zone will be validated as the zone data is 428 accessed by the recursive server. When using the same view, this 429 validation does not occur for the slaved zone. 431 Caching: When using separate views or instances, the recursive 432 server will cache all of the queries for the slaved zone, just as 433 it would using the traditional "root hints" method. Thus, as the 434 zone in the other view or instance is refreshed or updated, 435 changed information will not appear in the recursive server until 436 the TTL of the old record times out. Currently, the TTL for DS 437 and delegation NS records is two days. When using the same view, 438 all zone data in the recursive server will be updated as soon as 439 it receives its copy of the zone. 441 view root { 442 match-destinations { 127.12.12.12; }; 443 zone "." { 444 type slave; 445 file "rootzone.db"; 446 notify no; 447 masters { 448 199.9.14.201; # b.root-servers.net 449 192.33.4.12; # c.root-servers.net 450 199.7.91.13; # d.root-servers.net 451 192.5.5.241; # f.root-servers.net 452 192.112.36.4; # g.root-servers.net 453 193.0.14.129; # k.root-servers.net 454 192.0.47.132; # xfr.cjr.dns.icann.org 455 192.0.32.132; # xfr.lax.dns.icann.org 456 2001:500:200::b; # b.root-servers.net 457 2001:500:2::c; # c.root-servers.net 458 2001:500:2d::d; # d.root-servers.net 459 2001:500:2f::f; # f.root-servers.net 460 2001:500:12::d0d; # g.root-servers.net 461 2001:7fd::1; # k.root-servers.net 462 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 463 2620:0:2d0:202::132; # xfr.lax.dns.icann.org 464 }; 465 }; 466 }; 468 view recursive { 469 dnssec-validation auto; 470 allow-recursion { any; }; 471 recursion yes; 472 zone "." { 473 type static-stub; 474 server-addresses { 127.12.12.12; }; 475 }; 476 }; 478 B.2. Example Configuration: Unbound 1.8 480 Similar to BIND, Unbound starting with version 1.8 can act both as a 481 recursive resolver and an authoritative server. 483 auth-zone: 484 name: "." 485 master: 199.9.14.201 # b.root-servers.net 486 master: 192.33.4.12 # c.root-servers.net 487 master: 199.7.91.13 # d.root-servers.net 488 master: 192.5.5.241 # f.root-servers.net 489 master: 192.112.36.4 # g.root-servers.net 490 master: 193.0.14.129 # k.root-servers.net 491 master: 192.0.47.132 # xfr.cjr.dns.icann.org 492 master: 192.0.32.132 # xfr.lax.dns.icann.org 493 master: 2001:500:200::b # b.root-servers.net 494 master: 2001:500:2::c # c.root-servers.net 495 master: 2001:500:2d::d # d.root-servers.net 496 master: 2001:500:2f::f # f.root-servers.net 497 master: 2001:500:12::d0d # g.root-servers.net 498 master: 2001:7fd::1 # k.root-servers.net 499 master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org 500 master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org 501 fallback-enabled: yes 502 for-downstream: no 503 for-upstream: yes 505 B.3. Example Configuration: BIND 9.14 507 BIND 9.14 (which, at the time of publication of this document is a 508 future release) can set up a local mirror of the root zone with a 509 small configuration option: 511 zone "." { 512 type mirror; 513 }; 515 The simple "type mirror" configuration for the root zone works for 516 the root zone because a default list of primary servers for the IANA 517 root zone is built into BIND 9.14. In order to set up mirroring of 518 any other zone, an explicit list of primary servers needs to be 519 provided. 521 See the documentation for BIND 9.14 (when it is released) for more 522 detail about how to use this simplified configuration 524 B.4. Example Configuration: Unbound 1.9 526 Recent versions of Unbound have a "auth-zone" feature that allows 527 local mirroring of the root zone. Configuration looks like: 529 auth-zone: 530 name: "." 531 master: "b.root-servers.net" 532 master: "c.root-servers.net" 533 master: "d.root-servers.net" 534 master: "f.root-servers.net" 535 master: "g.root-servers.net" 536 master: "k.root-servers.net" 537 fallback-enabled: yes 538 for-downstream: no 539 for-upstream: yes 540 zonefile: "root.zone" 542 B.5. Example Configuration: Knot Resolver 544 Knot Resolver uses its "prefill" module to load the root zone 545 information. This is described at . 549 B.6. Example Configuration: Microsoft Windows Server 2012 551 Windows Server 2012 contains a DNS server in the "DNS Manager" 552 component. When activated, that component acts as a recursive 553 server. DNS Manager can also act as an authoritative server. 555 Using this configuration, queries for information in the root zone 556 are returned with the AA bit set. 558 The steps to configure DNS Manager to implement the requirements in 559 this document are: 561 1. Launch the DNS Manager GUI. This can be done from the command 562 line ("dnsmgmt.msc") or from the Service Manager (the "DNS" 563 command in the "Tools" menu). 565 2. In the hierarchy under the server on which the service is 566 running, right-click on the "Forward Lookup Zones", and select 567 "New Zone". This brings up a succession of dialog boxes. 569 3. In the "Zone Type" dialog box, select "Secondary zone". 571 4. In the "Zone Name" dialog box, enter ".". 573 5. In the "Master DNS Servers" dialog box, enter 574 "b.root-servers.net". The system validates that it can do a zone 575 transfer from that server. (After this configuration is 576 completed, the DNS Manager will attempt to transfer from all of 577 the root zone servers.) 579 6. In the "Completing the New Zone Wizard" dialog box, click 580 "Finish". 582 7. Verify that the DNS Manager is acting as a recursive resolver. 583 Right-click on the server name in the hierarchy, choosing the 584 "Advanced" tab in the dialog box. See that "Disable recursion 585 (also disables forwarders)" is not selected, and that "Enable 586 DNSSEC validation for remote responses" is selected. 588 Acknowledgements 590 The authors fully acknowledge that running a copy of the root zone on 591 the loopback address is not a new concept, and that we have chatted 592 with many people about that idea over time. For example, Bill 593 Manning described a similar solution to the problems in his doctoral 594 dissertation in 2013 [Manning2013]. 596 Evan Hunt contributed greatly to the logic in the requirements. 597 Other significant contributors include Wouter Wijngaards, Tony Hain, 598 Doug Barton, Greg Lindsay, and Akira Kato. The authors also received 599 many offline comments about making the document clear that this is 600 just a description of a way to operate a root zone on the same host, 601 and not a recommendation to do so. 603 People who contributed to this update to RFC 7706 include: Florian 604 Obser, nusenu, Wouter Wijngaards, [[ others go here ]]. 606 Authors' Addresses 608 Warren Kumari 609 Google 611 Email: Warren@kumari.net 613 Paul Hoffman 614 ICANN 616 Email: paul.hoffman@icann.org