idnits 2.17.1 draft-ietf-dnsop-nxdomain-cut-05.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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to directly say this. It does mention RFC1034 though, so this could be OK. -- The draft header indicates that this document updates RFC2308, but the abstract doesn't seem to directly say this. It does mention RFC2308 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 (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 18, 2016) is 2771 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) -- Looks like a reference, but probably isn't: '1' on line 443 -- Looks like a reference, but probably isn't: '2' on line 445 -- Looks like a reference, but probably isn't: '3' on line 447 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) == Outdated reference: A later version (-10) exists of draft-ietf-dnsop-nsec-aggressiveuse-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations (dnsop) Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Updates: 1034, 2308 (if approved) S. Huque 5 Intended status: Standards Track Verisign Labs 6 Expires: March 22, 2017 September 18, 2016 8 NXDOMAIN really means there is nothing underneath 9 draft-ietf-dnsop-nxdomain-cut-05 11 Abstract 13 This document states clearly that when a DNS resolver receives a 14 response with response code of NXDOMAIN, it means that the domain 15 name which is thus denied AND ALL THE NAMES UNDER IT do not exist. 17 REMOVE BEFORE PUBLICATION: this document should be discussed in the 18 IETF DNSOP (DNS Operations) group, through its mailing list. The 19 source of the document, as well as a list of open issues, is 20 currently kept at Github [1]. 22 This documents clarifies RFC 1034 and modifies a portion of RFC 2308, 23 so it updates both of them. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 22, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction and background . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Updates to RFC1034 . . . . . . . . . . . . . . . . . . . 5 64 3.2. Updates to RFC2308 . . . . . . . . . . . . . . . . . . . 5 65 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Implementation considerations . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 11.2. Informative References . . . . . . . . . . . . . . . . . 9 75 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Appendix A. Why can't we just use the owner name of the returned 77 SOA? . . . . . . . . . . . . . . . . . . . . . . . . 10 78 Appendix B. Related approaches . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction and background 83 The DNS protocol [RFC1035] defines response code 3 as "Name Error", 84 or "NXDOMAIN" [RFC2308], which means that the queried domain name 85 does not exist in the DNS. Since domain names are represented as a 86 tree of labels ([RFC1034], Section 3.1), non-existence of a node 87 implies non-existence of the entire sub-tree rooted at this node. 89 The DNS iterative resolution algorithm precisely interprets the 90 NXDOMAIN signal in this manner. If it encounters an NXDOMAIN 91 response code from an authoritative server, it immediately stops 92 iteration and returns the NXDOMAIN response to the querier. 94 However, in most known existing resolvers today, a cached non- 95 existence for a domain is not considered "proof" that there can be no 96 child domains underneath. This is due to an ambiguity in [RFC1034] 97 that failed to distinguish Empty Non-Terminal names (ENT) ([RFC7719]) 98 from nonexistent names (Section 3.1). The distinction became 99 especially important for the development of DNSSEC, which provides 100 proof of non-existence. [RFC4035], section 3.1.3.2, describes how 101 security-aware authoritative name servers make the distinction, but 102 no existing RFCs describe the behavior for recursive name servers. 104 This document specifies that an NXDOMAIN response for a domain name 105 means that no child domains underneath the queried name exist either. 106 And furthermore, that DNS resolvers should interpret cached non- 107 existence in this manner. Since the domain names are organized in a 108 tree, it is a simple consequence of the tree structure: non-existence 109 of a node implies non-existence of the entire sub-tree rooted at this 110 node. 112 1.1. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 "Denied name": the domain name whose existence has been denied by a 119 response of rcode NXDOMAIN. In most cases, it is the QNAME but, 120 because of [RFC6604], it is not always the case. 122 Other terms are defined in [RFC1034] or [RFC1035] or (like NXDOMAIN 123 itself) in the more recent [RFC7719]. 125 The domain name space is conceptually defined in terms of a tree 126 structure. The implementation of a DNS resolver/cache MAY use a tree 127 or other data structures. The cache being a subset of the data in 128 the domain name space, it is much easier to reason about it in terms 129 of that tree structure and to describe things in those terms (names 130 under/above, descendent names, subtrees etc). In fact, the DNS 131 algorithm description in [RFC1034] even states an assumption that the 132 cache is a tree structure, so the precedent is already well 133 established: see its section 4.3.2 which says "The following 134 algorithm assumes that the RRs are organized in several tree 135 structures, one for each zone, and another for the cache..." So, in 136 this document, each time we talk of a tree or tree operations, it 137 refers to the model, not to the actual implementation. 139 2. Rule 141 When an iterative caching DNS resolver receives a response NXDOMAIN, 142 it SHOULD store it in its cache and all names and RRsets at or below 143 that node SHOULD then be considered to be unreachable. Subsequent 144 queries for such names SHOULD elicit an NXDOMAIN response. 146 But if a resolver has cached data under the NXDOMAIN cut, it MAY 147 continue to send it as a reply (until the TTL of this cached data 148 expires), since this may avoid additional processing when a query is 149 received. Section 6 provides more information about this. 151 Another exception is that a validating resolver MAY decide to 152 implement the "NXDOMAIN cut" behaviour (described in the first 153 paragraph of this section) only when the NXDOMAIN response has been 154 validated with DNSSEC. See Section 8 for the rationale. 156 The fact that a subtree does not exist is not forever: [RFC2308], 157 section 3, already describes the amount of time that an NXDOMAIN 158 response may be cached (the "negative TTL"). 160 If the NXDOMAIN response due to a cached non-existence is from a 161 DNSSEC signed zone, then it will have accompanying NSEC or NSEC3 162 records that authenticate the non-existence of the name. For a 163 descendant name of the original NXDOMAIN name, the same set of NSEC 164 or NSEC3 records proves the non-existence of the descendant name. 165 The iterative, caching resolver MUST return these NSEC or NSEC3 166 records in the response to the triggering query if the query had the 167 DNSSEC OK (DO) bit set. 169 Warning: if there is a chain of CNAME (or DNAME), the name which does 170 not exist is the last of the chain ([RFC6604]) and not the QNAME. 171 The NXDOMAIN stored in the cache is for the denied name, not always 172 for the QNAME. 174 As an example of the consequence of these rules, consider two 175 successive queries to a resolver, with a non-existing domain 176 'foo.example': the first is for 'foo.example' (which results in an 177 NXDOMAIN) and the second for 'bar.foo.example' (which also results in 178 an NXDOMAIN). Many resolvers today will forward both queries, as 179 noticed in Section 9. However, following the rules in this document 180 ("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response, 181 as a sign of non-existence, and then immediately return an NXDOMAIN 182 response for the second query, without transmitting it to an 183 authoritative server. 185 If the first request is for 'bar.foo.example' and the second for 186 'baz.foo.example', the first NXDOMAIN response won't tell anything 187 about 'baz.foo.example' and therefore the second query will be 188 transmitted as it was before the use of "NXDOMAIN cut" optimisation 189 (see Appendix A). 191 3. Updates to RFCs 193 3.1. Updates to RFC1034 195 This document clarifies possible ambiguities in [RFC1034] that did 196 not clearly distinguish Empty Non-Terminal names (ENT) ([RFC7719]) 197 from nonexistent names, and refers to subsequent documents that do. 198 Empty Non-Terminals are nodes in the DNS that have no resource record 199 sets associated with them, but have descendant nodes that do. The 200 correct response to Empty Non-Terminals is NODATA (i.e. a response 201 code of NOERROR and an empty ANSWER section). Additional clarifying 202 language on these points is provided in section 7.16 of [RFC2136] and 203 sections 2.2.2 and 2.2.3 of [RFC4592]. 205 3.2. Updates to RFC2308 207 The second paragraph of section 5 of [RFC2308] states the following: 208 "A negative answer that resulted from a name error (NXDOMAIN) should 209 be cached such that it can be retrieved and returned in response to 210 another query for the same that resulted in the 211 cached negative response." 213 This document revises that paragraph to the following: "A negative 214 answer that resulted from a name error (NXDOMAIN) should be cached 215 such that it can be retrieved and returned in response to another 216 query for the same that resulted in the cached 217 negative response, or where QNAME is a descendant of the original 218 QNAME, and QCLASS is the same." 220 The above section Section 2 elaborates on the revised rule and 221 specifies when it may be reasonable to relax or ignore it. 223 4. Benefits 225 The main benefit is a better efficiency of the caches. In the 226 example above, the resolver sends only one query instead of two, the 227 second one being answered from the cache. This will benefit the 228 entire DNS ecosystem, since the authoritative name servers will have 229 less unnecessary traffic to process. 231 The correct behavior (in [RFC1034] and made clearer in this document) 232 is specially useful when combined with QNAME minimisation [RFC7816] 233 since it will allow a resolver to stop searching as soon as an 234 NXDOMAIN is encountered. 236 "NXDOMAIN cut" may also help mitigate certain types of random QNAME 237 attacks [joost-dnsterror] [balakrichenan-dafa888], where there is a 238 fixed suffix which does not exist. In these attacks against the 239 authoritative name server, queries are sent to resolvers for a QNAME 240 composed of a fixed suffix ("dafa888.wf" in one of the articles 241 above), which is typically nonexistent, and a random prefix, 242 different for each request. A resolver receiving these requests have 243 to forward them to the authoritative servers. With "NXDOMAIN cut", a 244 system administrator would just have to send to the resolver a query 245 for the fixed suffix, the resolver would get a NXDOMAIN and then 246 would stop forwarding the queries. (It would be better if the SOA 247 record in the NXDOMAIN response were sufficient to find the non- 248 existing domain but it is not the case, see Appendix A.) 250 5. Possible issues 252 Let's assume the TLD example exists but foobar.example is not 253 delegated (so the example's name servers will reply NXDOMAIN for a 254 query about anything.foobar.example). A system administrator decides 255 to name the internal machines of his organization under 256 office.foobar.example and uses a trick of his resolver to forward 257 requests about this zone to his local authoritative name servers. 258 "NXDOMAIN cut" would create problems here, since, depending on the 259 order of requests to the resolver, it may have cached the non- 260 existence from example and therefore "deleted" everything under. 261 This document assumes that such setup is rare and does not need to be 262 supported. 264 Another issue that may happen: today, we see broken authoritative 265 name servers which reply to ENT ([RFC7719], section 6) with NXDOMAIN 266 instead of the normal NODATA ([RFC7719], section 3). 268 RFC-EDITOR: REMOVE THE PARAGRAPH BEFORE PUBLICATION. An example 269 today is mta2._domainkey.cbs.nl (which exists) where querying 270 _domainkey.cbs.nl yields NXDOMAIN. Another example is www.upenn.edu, 271 redirected to www.upenn.edu-dscg.edgesuite.net while a query for edu- 272 dscg.edgesuite.net returns NXDOMAIN. 274 Such name servers are definitely wrong and have always been. Their 275 behaviour is incompatible with DNSSEC. Given the advantages of 276 "NXDOMAIN cut", there is little reason to support this behavior. 278 6. Implementation considerations 280 This section is non-normative, and is composed only of various things 281 which may be useful for implementors. A recursive resolver may 282 implement its cache in many ways. The most obvious one is a tree 283 data structure, because it fits the data model of domain names. But, 284 in practice, other implementations are possible, as well as various 285 optimisations (such as a tree, augmented by an index of some common 286 domain names). 288 If a resolver implements its cache as a tree (without any 289 optimisation), one way to follow the rules of Section 2 is, when 290 receiving the NXDOMAIN, to prune the subtree of positive cache 291 entries at that node, or to delete all individual cache entries for 292 names below that node. Then, when searching downward in its cache, 293 this iterative caching DNS resolver will stop searching if it 294 encounters a cached non-existence. 296 Some resolver may have a cache which is NOT organized as a tree (but, 297 for instance, as a dictionary) and therefore have a reason to ignore 298 the rules of Section 2. So these rules are a SHOULD and not a MUST. 300 7. IANA Considerations 302 This document has no actions for IANA. 304 8. Security Considerations 306 The technique described here may help against a denial-of-service 307 attack named "random qnames" and described in Section 4. 309 If a resolver does not validate the answers with DNSSEC, or if the 310 zone is not signed, the resolver can of course be poisoned with a 311 false NXDOMAIN, thus "deleting" a part of the domain name tree. This 312 denial-of-service attack is already possible without the rules of 313 this document (but "NXDOMAIN cut" may increase its effects). The 314 only solution is to use DNSSEC. 316 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 318 This section records the status of known implementations of the 319 protocol defined by this specification at the time of posting of this 320 Internet-Draft, and is based on a proposal described in [RFC6982]. 321 The description of implementations in this section is intended to 322 assist the IETF in its decision processes in progressing drafts to 323 RFCs. Please note that the listing of any individual implementation 324 here does not imply endorsement by the IETF. Furthermore, no effort 325 has been spent to verify the information presented here that was 326 supplied by IETF contributors. This is not intended as, and must not 327 be construed to be, a catalog of available implementations or their 328 features. Readers are advised to note that other implementations may 329 exist. 331 According to [RFC6982], "this will allow reviewers and working groups 332 to assign due consideration to documents that have the benefit of 333 running code, which may serve as evidence of valuable experimentation 334 and feedback that have made the implemented protocols more mature. 336 It is up to the individual working groups to use this information as 337 they see fit". 339 As of today, practically all existing DNS resolvers are conservative 340 by default: they consider a NXDOMAIN as only significant for the 341 denied name itself, not for the names under. Almost all the current 342 recursive servers will send upstream a query for out-of-cache 343 sub.example.com even if their cache contains an NXDOMAIN for 344 example.com. 346 There are a few exceptions. The Unbound resolver has a configuration 347 parameter called "harden-below-nxdomain" [2], which if set to "yes" 348 turns on "NXDOMAIN cut" behavior ("only DNSSEC-secure nxdomains are 349 used", see Section 8). The PowerDNS recursor has optional partial 350 support for "NXDOMAIN cut", for the root domain only, with its "root- 351 nx-trust" setting, described as [3] "If set, an NXDOMAIN from the 352 root-servers will serve as a blanket NXDOMAIN for the entire TLD the 353 query belonged to. The effect of this is far fewer queries to the 354 root-servers.". 356 10. Acknowledgments 358 The main idea is in this document is taken from 359 [I-D.vixie-dnsext-resimprove], section 3, "Stopping Downward Cache 360 Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney 361 Joffe, and Frederico Neves. Additionally Tony Finch, Ted Lemon, John 362 Levine, Jinmei Tatuya, Bob Harold and Duane Wessels provided valuable 363 feedback and suggestions. 365 11. References 367 11.1. Normative References 369 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 370 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 371 . 373 [RFC1035] Mockapetris, P., "Domain names - implementation and 374 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 375 November 1987, . 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 383 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 384 RFC 2136, DOI 10.17487/RFC2136, April 1997, 385 . 387 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 388 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 389 . 391 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 392 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 393 . 395 [RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits 396 Clarification", RFC 6604, DOI 10.17487/RFC6604, April 397 2012, . 399 11.2. Informative References 401 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 402 Rose, "Protocol Modifications for the DNS Security 403 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 404 . 406 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 407 Code: The Implementation Status Section", RFC 6982, 408 DOI 10.17487/RFC6982, July 2013, 409 . 411 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 412 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 413 2015, . 415 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 416 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 417 . 419 [I-D.vixie-dnsext-resimprove] 420 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 421 Resolvers for Resiliency, Robustness, and Responsiveness", 422 draft-vixie-dnsext-resimprove-00 (work in progress), June 423 2010. 425 [I-D.ietf-dnsop-nsec-aggressiveuse] 426 Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of 427 NSEC/NSEC3", draft-ietf-dnsop-nsec-aggressiveuse-02 (work 428 in progress), September 2016. 430 [joost-dnsterror] 431 Joost, M., "About DNS Attacks and ICMP Destination 432 Unreachable Reports", December 2014, 433 . 435 [balakrichenan-dafa888] 436 Balakrichenan, S., "Disturbance in the DNS - "Random 437 qnames", the dafa888 DoS attack"", October 2014, 438 . 441 11.3. URIs 443 [1] https://github.com/bortzmeyer/ietf-dnsop-nxdomain 445 [2] https://www.unbound.net/documentation/unbound.conf.html 447 [3] https://doc.powerdns.com/md/recursor/settings/#root-nx-trust 449 Appendix A. Why can't we just use the owner name of the returned SOA? 451 In this document, we deduce the non-existence of a domain only for 452 NXDOMAIN answers where the denied name was the exact domain. If a 453 resolver sends a query to the name servers of the TLD example, asking 454 for the MX record for www.foobar.example, and subsequently receives a 455 NXDOMAIN, it can only register the fact that www.foobar.example (and 456 everything underneath) does not exist. This is true regardless if 457 the accompanying SOA record is for the domain example only. One 458 cannot infer that foobar.example is nonexistent. The accompanying 459 SOA record indicates the apex of the zone, not the closest existing 460 domain name. So, using the owner name of the SOA record in the 461 Authoritative section to deduce "NXDOMAIN cuts" is currently 462 definitely not OK. 464 RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today, 465 ask the authoritative name servers of the TLD fr about 466 anything.which.does.not.exist.gouv.fr. The SOA will indicate fr (the 467 apex) even while gouv.fr does exist (there is no zone cut between 468 gouv.fr and fr). 470 Deducing the non-existence of a node from the SOA in the NXDOMAIN 471 reply may certainly help with random qnames attacks but this is out- 472 of-scope for this document. It would require to address the problems 473 mentioned in the first paragraph of this section. A possible 474 solution would be, when receiving a NXDOMAIN with a SOA which is more 475 than one label up in the tree, to send requests for the domains which 476 are between the QNAME and the owner name of the SOA. (A resolver 477 which does DNSSEC validation or QNAME minimisation will need to do 478 it, anyway.) 480 Appendix B. Related approaches 482 The document [I-D.ietf-dnsop-nsec-aggressiveuse] describes another 483 way to address some of the same concerns (decreasing the traffic for 484 non-existing domain names). Unlike "NXDOMAIN cut", it requires 485 DNSSEC but it is more powerful since it can synthesize NXDOMAINs for 486 domains that were not queried. 488 Authors' Addresses 490 Stephane Bortzmeyer 491 AFNIC 492 1, rue Stephenson 493 Montigny-le-Bretonneux 78180 494 France 496 Phone: +33 1 39 30 83 46 497 Email: bortzmeyer+ietf@nic.fr 498 URI: http://www.afnic.fr/ 500 Shumon Huque 501 Verisign Labs 502 12061 Bluemont Way 503 Reston 20190 504 USA 506 Email: shuque@verisign.com 507 URI: http://www.verisignlabs.com/