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