idnits 2.17.1 draft-ietf-dnsop-rfc7816bis-06.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 307 has weird spacing: '...ple.org exam...' == Line 324 has weird spacing: '...ple.org exam...' -- The document date (28 September 2020) is 1305 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Obsoletes: 7816 (if approved) R. Dolmans 5 Intended status: Standards Track NLnet Labs 6 Expires: 1 April 2021 P. Hoffman 7 ICANN 8 28 September 2020 10 DNS Query Name Minimisation to Improve Privacy 11 draft-ietf-dnsop-rfc7816bis-06 13 Abstract 15 This document describes techniques called "QNAME minimisation" to 16 improve DNS privacy, where the DNS resolver no longer always sends 17 the full original QNAME to the upstream name server. This document 18 obsoletes RFC 7816. 20 This document is part of the IETF DNSOP (DNS Operations) Working 21 Group. The source of the document, as well as a list of open issues, 22 is at 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 1 April 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Background . . . . . . . . . . . . . . . . . 2 58 1.1. Experience From RFC 7816 . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Description of QNAME Minimisation . . . . . . . . . . . . . . 3 61 3. Algorithm to Perform Aggressive Method QNAME Minimisation . . 5 62 4. QNAME Minimisation Examples . . . . . . . . . . . . . . . . . 6 63 5. Limit Number of Queries . . . . . . . . . . . . . . . . . . . 7 64 6. Performance Considerations . . . . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Changes from RFC 7816 . . . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction and Background 75 The problem statement for this document is described in [RFC7626]. 76 This specific solution is not intended to fully solve the DNS privacy 77 problem; instead, it should be viewed as one tool amongst many. 79 QNAME minimisation follows the principle explained in Section 6.1 of 80 [RFC6973]: the less data you send out, the fewer privacy problems 81 you have. 83 Before QNAME minimisation, when a resolver received the query "What 84 is the AAAA record for www.example.com?", it sent to the root 85 (assuming a resolver whose cache is empty) the very same question. 86 Sending the full QNAME to the authoritative name server was a 87 tradition, not a protocol requirement. In a conversation with the 88 author in January 2015, Paul Mockapetris explained that this 89 tradition comes from a desire to optimise the number of requests, 90 when the same name server is authoritative for many zones in a given 91 name (something that was more common in the old days, where the same 92 name servers served .com and the root) or when the same name server 93 is both recursive and authoritative (something that is strongly 94 discouraged now). Whatever the merits of this choice at this time, 95 the DNS is quite different now. 97 QNAME minimisation is compatible with the current DNS system and 98 therefore can easily be deployed. Because it is only a change to the 99 way that the resolver operates, it does not change the DNS protocol 100 itself. The behaviour suggested here (minimising the amount of data 101 sent in QNAMEs from the resolver) is allowed by Section 5.3.3 of 102 [RFC1034] and Section 7.2 of [RFC1035]. 104 1.1. Experience From RFC 7816 106 This document obsoletes [RFC7816]. RFC 7816 was labelled 107 "experimental", but ideas from it were widely deployed since its 108 publicaiton. Many resolver implementations now support QNAME 109 minimisation. The lessons learned from implementing QNAME 110 minimisation were used to create this new revision. 112 Data from DNSThought [dnsthought-qnamemin] and Verisign 113 [verisign-qnamemin] shows that a large percentage of the resolvers 114 deployed on the Internet already support QNAME minimisation in some 115 way. 117 Academic research has been performed on QNAME minimisation 118 [devries-qnamemin]. This work shows that QNAME minimisation in 119 relaxed mode causes almost no problems. The paper recommends using 120 the A QTYPE, and limiting the number of queries in some way. 122 1.2. Terminology 124 The terminology used in this document is defined in [RFC8499]. 126 In this document, a "cold" cache is one that is empty, having 127 literally no entries in it. A "warm" cache is one that has some 128 entries in it. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Description of QNAME Minimisation 138 The idea behind QNAME minimisation is to minimise the amount of 139 privacy sensitive data sent from the DNS resolver to the 140 authoritative name server. This section describes the RECOMMENDED 141 way to do QNAME minimisation -- the way that maximises privacy 142 benefits. That algorithm is summarised in Section 3. 144 When a resolver is not able to answer a query from cache it has to 145 send a query to an authoritative nameserver. Traditionally these 146 queries would contain the full QNAME and the original QTYPE as 147 received in the client query. 149 The full QNAME and original QTYPE are only needed at the nameserver 150 that is authoritative for the record requested by the client. All 151 other nameservers queried while resolving the query only need to 152 receive enough of the QNAME to be able to answer with a delegation. 153 The QTYPE in these queries is not relevant, as the nameserver is not 154 able to authoritatively answer the records the client is looking for. 155 Sending the full QNAME and original QTYPE to these nameservers 156 therefore exposes more privacy sensitive data than necessary to 157 resolve the client's request. 159 A resolver that implements QNAME minimisation changes the QNAME and 160 QTYPE in queries to an authoritative nameserver that is not known to 161 be responsible for the original QNAME. These queries contain: 163 * a QTYPE selected by the resolver to hide the original QTYPE 165 * the QNAME that is the original QNAME, stripped to just one label 166 more than the longest matching domain name for which the 167 nameserver is known to be authoritative 169 This method is called the "aggressive method" in this document 170 because the resolver won't expose the original QTYPE to nameservers 171 that are not known to be responsible for the desired name. This 172 method is the safest from a privacy point of view, and is thus the 173 RECOMMENDED method for this document. 175 Note that this document relaxes the recommendation in RFC 7816 to use 176 the NS QTYPE to hide the original QTYPE. Using the NS QTYPE is still 177 allowed. The authority of NS records lies at the child side. The 178 parent side of the delegation will answer using a referral, like it 179 will do for queries with other QTYPEs. Using the NS QTYPE therefore 180 has no added value over other QTYPEs. 182 The QTYPE to use while minimising queries can be any possible data 183 type (as defined in [RFC6895] Section 3.1) for which the authority 184 always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG, 185 TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no 186 relation between the incoming QTYPE and the selection of the QTYPE to 187 use while minimising. A good candidate is to always use the "A" 188 QTYPE because this is the least likely to raise issues in DNS 189 software and middleboxes that do not properly support all QTYPEs. 190 The QTYPE=A queries will also blend into traffic from non-minimising 191 resolvers, making it in some cases harder to observe that the 192 resolver is using QNAME minimisation. Using the QTYPE that occurs 193 most in incoming queries will slightly reduce the number of queries, 194 as there is no extra check needed for delegations on non-apex 195 records. Another potential benefit of using QTYPE=A is that 196 [RFC8305] clients that need answers for both the A and AAAA types 197 will send the AAAA query first. When minimising using QTYPE=A the 198 minimised query might be useful, and now already in the cache, for 199 the happy eyeballs query for the A QTYPE. 201 The minimising resolver works perfectly when it knows the zone cut 202 (zone cuts are described in Section 6 of [RFC2181]). But zone cuts 203 do not necessarily exist at every label boundary. In the name 204 www.foo.bar.example, it is possible that there is a zone cut between 205 "foo" and "bar" but not between "bar" and "example". So, assuming 206 that the resolver already knows the name servers of example, when it 207 receives the query "What is the AAAA record of www.foo.bar.example?", 208 it does not always know where the zone cut will be. To find the 209 zone cut, it will query the example name servers for a record for 210 bar.example. It will get a non-referral answer, it has to query the 211 example name servers again with one more label, and so on. 212 (Section 3 describes this algorithm in deeper detail.) 214 Stub and forwarding resolvers MAY implement QNAME minimisation. 215 Minimising queries that will be sent to an upstream resolver does not 216 help in hiding data from the upstream resolver because all 217 information will end up there anyway. It might, however, limit the 218 data exposure between the upstream resolver and the authoritative 219 nameserver in the situation where the upstream resolver does not 220 support QNAME minimisation. Using QNAME minimisation in a stub or 221 forwarding resolvers that does not have a mechanism to find and cache 222 zone cuts will drastically increase the number of outgoing queries. 224 3. Algorithm to Perform Aggressive Method QNAME Minimisation 226 This algorithm performs name resolution with aggressive method QNAME 227 minimisation in the presence of zone cuts that are not yet known. 229 Although a validating resolver already has the logic to find the 230 zone cuts, implementers of other resolvers may want to use this 231 algorithm to locate the zone cuts. 233 (0) If the query can be answered from the cache, do so; otherwise, 234 iterate as follows: 236 (1) Get the closest delegation point that can be used for the 237 original QNAME/QTYPE combination from the cache. 239 (1a) For queries with QTYPE=DS this is the NS RRset with the 240 owner matching the most labels with the QNAME stripped by 241 one label. The QNAME will be a subdomain of (but not equal 242 to) this NS RRset. Call this ANCESTOR. 244 (1b) For queries with other original QTYPEs this is the NS RRset 245 with the owner matching the most labels with the QNAME. The 246 QNAME will be equal to or a subdomain of this NS RRset. 247 Call this ANCESTOR. 249 (2) Initialise CHILD to the same as ANCESTOR. 251 (3) If CHILD is the same as the QNAME, or if the CHILD is one label 252 shorter than the QNAME and the original QTYPE is DS, resolve the 253 original query using ANCESTOR's name servers, and finish. 255 (4) Otherwise, add a label from the QNAME to the start of CHILD. 257 (5) Look for a cache entry for the RRset at CHILD with hidden QTYPE. 258 If this entry is for an NXDOMAIN and the resolver has support for 259 RFC8020 the NXDOMAIN can be used in response to the original 260 query, and stop. If the entry is for a NOERROR answer go back to 261 step 3. If the entry is for an NXDOMAIN answer and the resolver 262 does not support RFC8020, go back to step 3. 264 (6) Query for CHILD with the minimised QTYPE using ANCESTOR's 265 name servers. The response can be: 267 (6a) A referral. Cache the NS RRset from the authority section, 268 and go back to step 1. 270 (6b) A NOERROR answer. Cache this answer, and go back to step 271 3. 273 (6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response 274 to the original query, and stop. 276 (6d) An answer with another RCODE, or no answer. Try another 277 name server at the same delegation point. Stop if none of 278 them are able to return a valid answer. 280 4. QNAME Minimisation Examples 282 Assume that a resolver receives a request to resolve 283 foo.bar.baz.example. Assume that the resolver already knows that 284 ns1.nic.example is authoritative for .example, and that the resolver 285 does not know a more specific authoritative name server. It will 286 send the query with QNAME=baz.example and the QTYPE selected to hide 287 the original QTYPE to ns1.nic.example. 289 Here are more detailed examples of queries with the aggressive method 290 of QNAME minimisation: 292 Cold cache, traditional resolution algorithm without QNAME 293 minimisation, request for MX record of a.b.example.org: 295 QTYPE QNAME TARGET NOTE 296 MX a.b.example.org root nameserver 297 MX a.b.example.org org nameserver 298 MX a.b.example.org example.org nameserver 300 Cold cache, aggressive QNAME minimisation method, request for MX 301 record of a.b.example.org, using the A QTYPE to hide the original 302 QTYPE: 304 QTYPE QNAME TARGET NOTE 305 A org root nameserver 306 A example.org org nameserver 307 A b.example.org example.org nameserver 308 A a.b.example.org example.org nameserver "a" may be delegated 309 MX a.b.example.org example.org nameserver 311 Note that in above example one query would have been saved if the 312 incoming QTYPE would have been the same as the QTYPE selected by the 313 resolver to hide the original QTYPE. Only one query needed with as 314 QTYPE a.b.example.org would have been needed if the original QTYPE 315 would have been A. Using the most used QTYPE to hide the original 316 QTYPE therefore slightly reduces the number of outgoing queries. 318 Warm cache with only org delegation known, (example.org's NS RRset is 319 not known), aggressive QNAME minimisation method, request for MX 320 record of a.b.example.org, using A QTYPE to hide the original QTYPE: 322 QTYPE QNAME TARGET NOTE 323 A example.org org nameserver 324 A b.example.org example.org nameserver 325 A a.b.example.org example.org nameserver "a" may be delegated 326 MX a.b.example.org example.org nameserver 328 5. Limit Number of Queries 330 When using QNAME minimisation, the number of labels in the received 331 QNAME can influence the number of queries sent from the resolver. 332 This opens an attack vector and can decrease performance. Resolvers 333 supporting QNAME minimisation MUST implement a mechanism to limit the 334 number of outgoing queries per user request. 336 Take for example an incoming QNAME with many labels, like 337 www.host.group.department.example.com, where 338 host.group.department.example.com is hosted on example.com's 339 name servers. Assume a resolver that knows only the name servers of 340 example.com. Without QNAME minimisation, it would send these 341 example.com name servers a query for 342 www.host.group.department.example.com and immediately get a specific 343 referral or an answer, without the need for more queries to probe for 344 the zone cut. For such a name, a cold resolver with QNAME 345 minimisation will, depending on how QNAME minimisation is 346 implemented, send more queries, one per label. Once the cache is 347 warm, there will be no difference with a traditional resolver. 348 Actual testing is described in [Huque-QNAME-Min]. Such deep domains 349 are especially common under ip6.arpa. 351 This behaviour can be exploited by sending queries with a large 352 number of labels in the QNAME that will be answered using a wildcard 353 record. Take for example a record for *.example.com, hosted on 354 example.com's name servers. An incoming query containing a QNAME 355 with more than 100 labels, ending in example.com, will result in a 356 query per label. By using random labels the attacker can bypass the 357 cache and always require the resolver to send many queries upstream. 358 Note that [RFC8198] can limit this attack in some cases. 360 One mechanism to reduce this attack vector is by appending more than 361 one label per iteration for QNAMEs with a large number of labels. To 362 do this a maximum number of QNAME minimisation iterations has to be 363 selected (MAX_MINIMISE_COUNT), a good value is 10. Optionally a 364 value for the number of queries that should only have one label 365 appended can be selected (MINIMISE_ONE_LAB), a good value is 4. The 366 assumption here is that the number of labels on delegations higher in 367 the hierarchy are rather small, therefore not exposing too may labels 368 early on has the most privacy benefit. 370 When a resolver needs to send out a query if will look for the 371 closest known delegation point in its cache. The number of QNAME 372 minimisation iterations is the difference between this closest 373 nameserver and the incoming QNAME. The first MINIMISE_ONE_LAB 374 iterations will be handles as described in Section 2. The number of 375 labels that are not exposed yet now need to be divided over the 376 iterations that are left (MAX_MINIMISE_COUNT - MINIMISE_ONE_LAB). 377 The remainder of the division should be added to the last iterations. 378 For example, when resolving a QNAME with 18 labels, the number of 379 labels added per iteration are: 1,1,1,1,2,2,2,2,3,3. 381 6. Performance Considerations 383 The main goal of QNAME minimisation is to improve privacy by sending 384 less data. However, it may have other advantages. For instance, if 385 a resolver sends a root name server queries for A.example followed by 386 B.example followed by C.example, the result will be three NXDOMAINs, 387 since .example does not exist in the root zone. When using QNAME 388 minimisation, the resolver would send only one question (for .example 389 itself) to which they could answer NXDOMAIN. The resolver can cache 390 this answer and use it as to prove that nothing below .example exists 391 ([RFC8020]). A resolver now knows a priori that neither B.example 392 nor C.example exist. Thus, in this common case, the total number of 393 upstream queries under QNAME minimisation could counterintuitively be 394 less than the number of queries under the traditional iteration (as 395 described in the DNS standard). 397 QNAME minimisation may also improve lookup performance for TLD 398 operators. For a TLD that is delegation-only, a two-label QNAME 399 query may be optimal for finding the delegation owner name, depending 400 on the way domain matching is implemented. 402 QNAME minimisation can increase the number of queries based on the 403 incoming QNAME. This is described in Section 5. 405 7. Security Considerations 407 QNAME minimisation's benefits are clear in the case where you want to 408 decrease exposure to the authoritative name server. But minimising 409 the amount of data sent also, in part, addresses the case of a wire 410 sniffer as well as the case of privacy invasion by the servers. 411 (Encryption is of course a better defense against wire sniffers, but, 412 unlike QNAME minimisation, it changes the protocol and cannot be 413 deployed unilaterally. Also, the effect of QNAME minimisation on 414 wire sniffers depends on whether the sniffer is on the DNS path.) 416 QNAME minimisation offers no protection against the recursive 417 resolver, which still sees the full request coming from the stub 418 resolver. 420 8. References 422 8.1. Normative References 424 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 425 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 426 . 428 [RFC1035] Mockapetris, P., "Domain names - implementation and 429 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 430 November 1987, . 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 438 Morris, J., Hansen, M., and R. Smith, "Privacy 439 Considerations for Internet Protocols", RFC 6973, 440 DOI 10.17487/RFC6973, July 2013, 441 . 443 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 444 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 8.2. Informative References 453 [devries-qnamemin] 454 "A First Look at QNAME Minimization in the Domain Name 455 System", March 2019, 456 . 459 [dnsthought-qnamemin] 460 "DNSThought QNAME minimisation results. Using Atlas 461 probes", March 2020, 462 . 464 [Huque-QNAME-Min] 465 Huque, S., "Query name minimization and authoritative 466 server behavior", May 2015, 467 . 469 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 470 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 471 . 473 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 474 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 475 April 2013, . 477 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 478 DOI 10.17487/RFC7626, August 2015, 479 . 481 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 482 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 483 November 2016, . 485 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 486 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 487 July 2017, . 489 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 490 Better Connectivity Using Concurrency", RFC 8305, 491 DOI 10.17487/RFC8305, December 2017, 492 . 494 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 495 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 496 January 2019, . 498 [verisign-qnamemin] 499 Thomas, M., "Maximizing Qname Minimization: A New Chapter 500 in DNS Protocol Evolution", September 2020, 501 . 504 Acknowledgments 506 TODO (refer to 7816) 508 Changes from RFC 7816 510 Changed in -06 512 * Removed lots of text from when this was experimental 514 * Lots of reorganization 516 Changed in -04 518 * Start structure for implementation section 520 * Add clarification why the used QTYPE does not matter 522 * Make algorithm DS QTYPE compatible 524 Changed in -03 525 * Drop recommendation to use the NS QTYPE to hide the incoming QTYPE 527 * Describe DoS attach vector for QNAME with large number of labels, 528 and propose a mitigation. 530 * Simplify examples and change qname to a.b.example.com to show the 531 change in number of queries. 533 Changed in -00, -01, and -02 535 * Made changes to deal with errata #4644 537 * Changed status to be on standards track 539 * Major reorganization 541 Authors' Addresses 543 Stephane Bortzmeyer 544 AFNIC 545 1, rue Stephenson 546 78180 Montigny-le-Bretonneux 547 France 549 Phone: +33 1 39 30 83 46 550 Email: bortzmeyer+ietf@nic.fr 551 URI: https://www.afnic.fr/ 553 Ralph Dolmans 554 NLnet Labs 556 Email: ralph@nlnetlabs.nl 558 Paul Hoffman 559 ICANN 561 Email: paul.hoffman@icann.org