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