idnits 2.17.1 draft-vandergaast-edns-client-ip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2010) is 5204 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsext C. Contavalli 3 Internet-Draft W. van der Gaast 4 Intended status: Standards Track Google 5 Expires: July 30, 2010 S. Leach 6 D. Rodden 7 Neustar 8 January 26, 2010 10 Client IP information in DNS requests 11 draft-vandergaast-edns-client-ip-00 13 Abstract 15 This draft defines an EDNS0 extension to allow Authoritative 16 Nameservers to return varying replies based upon the network address 17 of the client that initiated the query rather than of the client's 18 Recursive Resolver. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on July 30, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Option format . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Protocol description . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Querying Authoritative Nameservers . . . . . . . . . . . . 6 66 4.2. Generating a response . . . . . . . . . . . . . . . . . . 7 67 4.3. Handling edns-client-ip replies and caching . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 11 70 7. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 12 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8.2. Attack scenarios . . . . . . . . . . . . . . . . . . . . . 13 74 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 81 1. Introduction 83 Authoritative Nameservers of most major web sites today return 84 different replies based on the perceived vicinity of the user to a 85 particular location and knowledge of available resources. This 86 significantly reduces the overall latency of connections established 87 by the end user and optimizes network resource usage. 89 To find the best reply for a given query, most nameservers use the IP 90 address of the incoming query to attempt to establish the location of 91 the end user. 93 Most users today, however, do not query the Authoritative Nameserver 94 directly. Instead, queries are relayed by Recursive Resolvers 95 operated by their ISP or third parties. 97 When the Recursive Resolver does not use an IP address that appears 98 to be topologically close to the end user, the results returned by 99 those Authoritative Nameservers will be at best sub-optimal. 101 This draft proposes a DNS protocol extension to enable Authoritative 102 Nameservers to return answers based on the network address of the 103 actual client, by allowing Recursive Resolvers to include it in 104 queries. 106 This draft also includes guidelines on how to best cache those 107 results and provides recommendations on when this protocol extension 108 should be used. 110 1.1. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Terminology 118 Authoritative Nameserver: A nameserver that has authority over one 119 or more DNS zones. These are normally not contacted by clients 120 directly but by Recursive Resolvers. Described in [RFC1035] 121 chapter 6. 123 Recursive Resolver: A nameserver that is responsible for resolving 124 domain names for clients by following the domain's delegation 125 chain, starting at the root. Recursive Resolvers frequently use 126 caches to be able to respond to client queries quickly. Described 127 in [RFC1035] chapter 7. 129 Third-party nameserver: Recursive Resolvers provided by parties that 130 are not Internet Service Providers (ISPs). These services are 131 often offered as substitutes for ISP-run nameservers. 133 Optimized reply: A reply from a nameserver that is optimized for the 134 node that sent the request, normally based on performance (i.e. 135 lowest latency, least number of hops, topological distance, ...). 137 Topologically close: Refers to two hosts being close in terms of 138 number of hops or time it takes for a packet to travel from one 139 host to the other. The concept of topological distance is only 140 loosely related to the concept of geographical distance: two 141 geographically close hosts can still be very distant from a 142 topological perspective. 144 3. Option format 146 This draft uses an EDNS0 ([RFC2671]) option to include client IP 147 information in DNS messages. The option is structured as follows: 149 +0 (MSB) +1 (LSB) 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 151 0: | OPTION-CODE | 152 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 153 2: | OPTION-LENGTH | 154 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 155 4: | FAMILY | 156 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 157 6: | NETMASK | ADDRESS... / 158 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 160 o (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-client-ip 161 is TBD. 163 o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the 164 length of the payload (everything after OPTION-LENGTH) in bytes. 166 o FAMILY, 2 octets, indicates the family of the address contained in 167 the option, using address family codes as assigned by IANA in 168 IANA-AFI [1]. 170 The format of the address part depends on the value of FAMILY. This 171 document only defines the format for FAMILY 1 (IP version 4) and 2 172 (IP version 6), which are as follows: 174 o NETMASK, 1 octet, indicating how many most-significant bits of the 175 original ADDRESS are included (i.e. a netmask in CIDR notation). 177 o ADDRESS, variable number of octets, contains either an IPv4 or 178 IPv6 address (depending on FAMILY), truncated to the number of 179 bits indicated by the NETMASK field, with bits set to 0 to pad up 180 to the end of the last octet used. 182 All fields are in network byte order. 184 4. Protocol description 186 The edns-client-ip extension allows DNS servers to propagate the 187 network address of the client that initiated the resolution through 188 to Authoritative Nameservers during recursion. 190 Servers that receive queries containing an edns-client-ip option can 191 generate answers based on the original network address of the client. 192 Those answers will generally be optimized for that client and other 193 clients in the same network. 195 The option also allows Authoritative Nameservers to specify the 196 network range for which the reply can be cached and re-used. 198 4.1. Querying Authoritative Nameservers 200 When a Recursive Resolver performs recursion for an incoming query, 201 it MAY include an edns-client-ip option in queries to Authoritative 202 Namesevers. 204 If an edns-client-ip option is included, the FAMILY and ADDRESS 205 fields MUST be populated with the IP address of the client that 206 originally initiated the resolution. The address SHOULD be truncated 207 to an arbitrary NETMASK chosen by the owners of the Recursive 208 Resolver as described in Section 3, following the recommendations 209 provided in Section 8, and the NETMASK field populated accordingly. 211 If the incoming query originally contained an edns-client-ip option, 212 its FAMILY, ADDRESS and NETMASK information MUST be used instead, 213 with the only exceptions being listed in Section 8. 215 A Recursive Resolver set up to serve clients in private address space 216 (as defined in [RFC1918] and [RFC4193]) MUST NOT add edns-client-ip 217 options containing a non-public address to its queries. An edns- 218 client-ip option MUST never contain a non-public address. 220 For privacy reasons, and because the whole IP address is rarely 221 required to determine an optimized reply, the address MUST be 222 truncated to a certain number of bits, indicated by the NETMASK 223 field, as described in Section 8. 225 A Recursive Resolver MAY be configured to omit the edns-client-ip 226 option completely when querying servers from which a delegation 227 response is expected, for example TLD servers or root servers. 229 4.2. Generating a response 231 When a query containing an edns-client-ip option is received, an 232 Authoritative Nameserver supporting edns-client-ip MAY use the 233 ADDRESS and NETMASK specified in the option in order to generate an 234 optimized reply. 236 Requests with an edns-client-ip option considered invalid (i.e. wrong 237 formatting, unsupported address family, private address space) MUST 238 be treated as if no edns-client-ip option was specified. 240 In the reply, the server MUST include an edns-client-ip option. The 241 ADDRESS and FAMILY specified MUST match the ADDRESS and FAMILY in the 242 request, while the NETMASK in the reply indicates how many bits of 243 that ADDRESS were actually used or would have been required to 244 calculate an optimal reply, as described below. 246 Note that the NETMASK value in the reply can actually be higher than 247 the NETMASK value in the request, indicating that the address range 248 provided in the query was not specific enough to select a single, 249 best response, and that an optimal reply would require at least 250 NETMASK bits of address information. The additional bits of the 251 ADDRESS in the reply MUST be set to 0, and if octet boundaries are 252 crossed, extra octets must be added. 254 Conversely, a lower NETMASK indicates that more bits than necessary 255 were provided. In this case, the ADDRESS in the reply MUST be 256 truncated according to the new NETMASK value, as described in 257 Section 3. 259 In both cases, the value of the NETMASK in the reply has strong 260 implications with regard to how the reply should be cached by 261 Recursive Resolvers, as described in Section 4.3. 263 Servers MUST NOT include an edns-client-ip option in replies if an 264 edns-client-ip option was not present in the request. 266 If the edns-client-ip option in the request is not used at all (for 267 example if an optimized reply was temporarily unavailable or not 268 supported for the requested domain name), a server supporting edns- 269 client-ip MUST indicate that no bits of the ADDRESS in the request 270 have been used by specifying a NETMASK of 0 and no ADDRESS 271 (equivalent to the networks 0.0.0.0/0 or ::/0). 273 If no optimized answer could be found at all for the ADDRESS and 274 NETMASK indicated in the query, the Authoritative Nameserver SHOULD 275 still return the best result it knows of (i.e. by using the query 276 source IP address instead, or a sensible default), and indicate that 277 this result should only be cached for the FAMILY, ADDRESS and NETMASK 278 indicated in the request. 280 4.3. Handling edns-client-ip replies and caching 282 When a Recursive Resolver receives a reply containing an 283 edns-client-ip option, it will return a reply to the client and cache 284 the result as usual. 286 In the cache, any resource record in the answer section will be tied 287 to the network specified by the FAMILY, ADDRESS and NETMASK fields, 288 as detailed below. 290 If another query is received matching the entry in the cache, the 291 resolver will verify that the FAMILY and ADDRESS that represent the 292 client match any of the networks in the cache for that entry. 294 If the address of the client is within any of the networks in the 295 cache, then the cached response MUST be returned as usual. In case 296 the address of the client matches multiple networks in the cache, the 297 entry with the highest NETMASK value MUST be returned, as with most 298 route-matching algorithms. 300 If the address of the client does not match any network in the cache, 301 then the Recursive Resolver MUST behave as if no match was found and 302 perform resolution as usual. This is necessary to avoid sub-optimal 303 replies in the cache from being returned to the wrong clients, and to 304 avoid a single request coming from a client on a different network 305 from polluting the cache with a sub-optimal reply for all the users 306 of that resolver. 308 Note that every time a Recursive Resolver queries an Authoritative 309 Nameserver by forwarding the edns-client-ip option that it received 310 from another client, a low NETMASK in the original request could 311 cause a sub-optimal reply to be returned by the Authoritative 312 Nameserver. 314 To avoid this sub-optimal reply from being served from cache for 315 clients for which a better reply would be available, the Recursive 316 Resolver MUST check the NETMASK that was returned by the 317 Authoritative Nameserver: 319 o If the NETMASK in the reply is higher than the NETMASK in the 320 request, it means that the reply might be sub-optimal. A 321 Recursive Resolver MUST return this entry from cache only to 322 queries that do not allow a higher NETMASK to be forwarded. 324 o If the NETMASK in the reply is lower or equal to the NETMASK in 325 the request, the reply is optimal, and SHOULD be returned from 326 cache to any client in a subnet matching the ADDRESS and NETMASK 327 indicated by the Authoritative Nameserver. 329 When another request is performed, the existing entries SHOULD be 330 kept in the cache until their TTL expires, as per standard behavior. 332 As another reply is received, the reply will be tied to a different 333 network. The server MAY keep in cache both replies, and return the 334 most appropriate one depending on the address of the client. 336 Any reply containing an edns-client-ip option considered invalid 337 should be treated as if no edns-client-ip option was specified at 338 all. 340 Replies coming from servers not supporting edns-client-ip or 341 otherwise not containing an edns-client-ip option SHOULD be 342 considered as containing a NETMASK of 0 (e.g., 0.0.0.0/0 or ::/0) for 343 all the supported families. 345 In any case, the response from the resolver to the client MUST NOT 346 contain the edns-client-ip option if none was present in the client's 347 original request. If the original client request contained a valid 348 edns-client-ip option that was used during recursion, the Recursive 349 Resolver MUST include the edns-client-ip option from the 350 Authoritative Nameserver response in the response to the client. 352 Enabling support for edns-client-ip in a recursive resolver will 353 significantly increase the size of the cache, reduce the number of 354 results that can be served from cache, and increase the load on the 355 server. Implementing the mitigation techniques described in 356 Section 8 is strongly recommended. 358 5. IANA Considerations 360 We request IANA to assign an option code for edns-client-ip, as 361 specified in [RFC2671]. Within this document, the text 'TBD' should 362 be replaced with the option code assigned by IANA. 364 6. DNSSEC Considerations 366 The presence or absence of an OPT resource record containing an edns- 367 client-ip option in a DNS query does not change the usage of those 368 resource records and mechanisms used to provide data origin 369 authentication and data integrity to the DNS, as described in 370 [RFC4033], [RFC4034] and [RFC4035]. 372 7. NAT Considerations 374 Special awareness of edns-client-ip in devices that perform NAT as 375 described in [RFC2663] is not required, queries can be passed through 376 as-is. The client's network address MUST NOT be added, and existing 377 edns-client-ip options, if present, MUST NOT be modified by NAT 378 devices. 380 Recursive Resolvers sited behind NAT devices MUST NOT add their 381 external network address in an edns-client-ip options, and MUST 382 behave exactly as described in the previous sections. 384 Note that Authoritative Nameservers or Recursive Resolvers can still 385 provide an optimized reply by looking at the source IP of the query. 387 8. Security Considerations 389 8.1. Privacy 391 With the edns-client-ip option, the network address of the client 392 that initiated the resolution becomes visible to all servers involved 393 in the resolution process. Additionally, it will be visible from any 394 network traversed by the DNS packets. 396 To protect users' privacy, Recursive Resolvers are strongly 397 encouraged to conceal part of the IP address of the user by 398 truncating IPv4 addresses to 24 bits. No recommendation is provided 399 for IPv6 at this time, but IPv6 addresses should be similarly 400 truncated in order to not allow to uniquely identify the client. 402 Users who wish their full IP address to be hidden can include an 403 edns-client-ip option specifying the wildcard address 0.0.0.0/0 (i.e. 404 FAMILY set to 1 (IPv4), NETMASK to 0 and no ADDRESS). As described 405 in previous sections, this option will be forwarded across all the 406 Recursive Resolvers supporting edns-client-ip, which MUST NOT modify 407 it to include the network address of the client. 409 Note that even without edns-client-ip options, any server queried 410 directly by the user will be able to see the full client IP address. 411 Recursive Resolvers or Authoritative Nameservers MAY use the source 412 IP address of requests to return a cached entry or to generate an 413 optimized reply that best matches the request. 415 8.2. Attack scenarios 417 It is simple for an arbitrary resolver or client to provide false 418 information in the edns-client-ip option, or to send UDP packets with 419 forged source IP addresses. 421 This could be used to pollute the cache of intermediate resolvers, by 422 filling it with results that will rarely (if ever) be used, or to 423 reverse engineer the algorithms (or data) used by the Authoritative 424 Nameserver to calculate the optimized answers. 426 Even without malicious intent, third-party Recursive Resolvers 427 providing answers to clients in multiple networks will need to cache 428 different replies for different networks, putting significantly more 429 pressure on the cache. 431 To mitigate those problems: 433 o Recursive Resolvers implementing edns-client-ip should only enable 434 it in deployments where it is expected to bring clear advantages 435 to the end users. For example, when expecting clients from a 436 variety of networks or from a wide geographical area. Due to the 437 high cache pressure introduced by edns-client-ip, the feature must 438 be disabled in all default configurations. 440 o Recursive Resolvers should limit the number of networks and 441 answers they keep in the cache for a given query. 443 o Recursive Resolvers should limit the number of total different 444 networks that they keep in cache. 446 o Recursive Resolvers should never send edns-client-ip options with 447 NETMASKs providing more bits in the ADDRESS than they are willing 448 to cache responses for. 450 o Recursive Resolvers should implement algorithms to improve the 451 cache hit rate, given the size constraints indicated above. 452 Recursive Resolvers may, for example, decide to discard more 453 specific cache entries first. 455 o Authoritative Nameservers and Recursive Resolvers should discard 456 known to be wrong or known to be forged edns-client-ip options. 457 They must at least ignore unroutable addresses, including the ones 458 defined in [RFC1918] and [RFC4193], and should ignore and never 459 forward edns-client-ip options specifying networks or addresses 460 that are known not to be served by those servers when feasible. 462 o Authoritative Nameservers consider the edns-client-ip option just 463 as a hint to provide better results. They can decide to ignore 464 the content of the edns-client-ip option based on black or white 465 lists, rate limiting mechanisms, or any other logic implemented in 466 the software. 468 9. Example 470 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve 471 www.example.com, by forwarding the query to the Recursive 472 Resolver R from IP address IP, asking for recursion. 474 2. R, supporting edns-client-ip, looks up www.example.com in its 475 cache. An entry is found neither for www.example.com, nor for 476 example.com. 478 3. R builds a query to send to the root and .com servers. The 479 implementation of R does not include an edns-client-ip option 480 when querying TLD or root nameservers, because there is no 481 expectation to receive a client-network-specific response. 482 Thus, no edns-client-ip option is added, and resolution is 483 performed as usual. 485 4. R now knows the Authoritative Nameserver ANS responsible for 486 example.com. 488 5. R prepares a new query for www.example.com, including an edns- 489 client-ip option with: 491 * OPTION-CODE, set to TBD. 493 * OPTION-LENGTH, set to 0x00 0x06. 495 * FAMILY, set to 0x00 0x01 as IP is an IPv4 address. 497 * NETMASK, set to 0x18, as it is configured to conceal the last 498 8 bits of every IPv4 address. 500 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 501 bits of the IPv4 address. 503 6. The query is sent. Authoritative Nameserver ANS understands and 504 uses edns-client-ip. It parses the edns-client-ip option, and 505 generates an optimized reply. 507 7. Due to the internal implementation of the Authoritative 508 Nameserver ANS, ANS finds a reply that is optimal for the whole 509 /16 of the client that performed the request. 511 8. The Authoritative Nameserver ANS adds an edns-client-ip option 512 in the reply, containing: 514 * OPTION-CODE, set to TBD. 516 * OPTION-LENGTH, set to 0x00 0x05. 518 * FAMILY, set to 0x00 0x01. 520 * NETMASK, set to 0x10. 522 * ADDRESS, set to 0xC0 0x00: the first 2 octets of the ADDRESS 523 included in the request. 525 9. The Recursive Resolver R receives the reply containing an edns- 526 client-ip option. The resolver: 528 * Verifies that FAMILY is set to 1, as it was in the request. 530 * Sees that NETMASK was lowered to 16, and truncates the IP 531 address of stub resolver SR to that size. 533 * Verifies that this address matches ADDRESS in the response. 534 If not, the option is discarded. 536 10. The reply is interpreted as usual. Since the reply still 537 contains an edns-client-ip option, the ADDRESS, NETMASK, and 538 FAMILY in the response are used to cache the entry. 540 11. R sends a response to stub resolver SR, without including an 541 edns-client-ip option. 543 12. R receives another request to resolve www.example.com. This 544 time, a reply is cached. The reply, however, is tied to a 545 particular network. If the address of the client matches any 546 network in the cache, then the reply is returned from the cache. 547 Otherwise, another query is performed. If multiple results 548 match, the one with the longest NETMASK is chosen, as per common 549 best-network match algorithms. 551 10. Acknowledgements 553 The authors wish to thank the following people for reviewing early 554 drafts of this document and for providing useful feedback: Paul S. R. 555 Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, 556 Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren 557 Kumari, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, 558 Edward Lewis, Eric Burger from Neustar, David Ulevitch from OpenDNS, 559 Patrick W. Gilmore from Akamai, Colm MacCartaigh, Richard Sheehan and 560 all the other people that replied to our emails on various mailing 561 lists. 563 11. References 565 11.1. Normative References 567 [RFC1035] Mockapetris, P., "Domain names - implementation and 568 specification", STD 13, RFC 1035, November 1987. 570 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 571 E. Lear, "Address Allocation for Private Internets", 572 BCP 5, RFC 1918, February 1996. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 578 RFC 2671, August 1999. 580 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 581 Rose, "DNS Security Introduction and Requirements", 582 RFC 4033, March 2005. 584 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 585 Rose, "Resource Records for the DNS Security Extensions", 586 RFC 4034, March 2005. 588 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 589 Rose, "Protocol Modifications for the DNS Security 590 Extensions", RFC 4035, March 2005. 592 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 593 Addresses", RFC 4193, October 2005. 595 11.2. Informative References 597 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 598 Translator (NAT) Terminology and Considerations", 599 RFC 2663. 601 URIs 603 [1] 605 Authors' Addresses 607 Carlo Contavalli 608 Google 609 Gordon House, Barrow Street 610 Dublin 4 611 IE 613 Email: ccontavalli@google.com 615 Wilmer van der Gaast 616 Google 617 Gordon House, Barrow Street 618 Dublin 4 619 IE 621 Email: wilmer@google.com 623 Sean Leach 624 Neustar 625 46000 Center Oak Plaza 626 Sterling, VA 20166 627 VA 629 Email: sean.leach@neustar.com 631 Darryl Rodden 632 Neustar 633 46000 Center Oak Plaza 634 Sterling, VA 20166 635 VA 637 Email: darryl.rodden@neustar.com