idnits 2.17.1 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2011) is 4705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational June 8, 2011 5 Expires: December 10, 2011 7 IPv6 AAAA DNS Whitelisting Implications 8 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06 10 Abstract 12 This document describes the practice and implications of whitelisting 13 DNS recursive resolvers in order to limit AAAA resource record 14 responses (which contain IPv6 addresses) sent by authoritative DNS 15 servers. This is an IPv6 transition mechanism used by domains as a 16 method for incrementally transitioning inbound traffic to a domain 17 from IPv4 to IPv6 transport. The audience for this document is the 18 Internet community generally, particularly IPv6 implementers. 20 Status of this Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on December 10, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 56 2.1. Description of the Operation of DNS Whitelisting . . . . . 6 57 2.2. Comparison with Blacklisting . . . . . . . . . . . . . . . 9 58 3. Similarities to Other DNS Operations . . . . . . . . . . . . . 9 59 3.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 9 60 3.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 10 61 4. What Problems Are Implementers Trying To Solve? . . . . . . . 10 62 4.1. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 11 63 4.2. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 11 64 4.3. Free Versus Subscription Services . . . . . . . . . . . . 13 65 5. General Implementation Variations . . . . . . . . . . . . . . 13 66 5.1. Implement DNS Whitelisting Universally . . . . . . . . . . 13 67 5.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 14 68 5.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 14 69 5.3.1. Solve Current End User IPv6 Impairments . . . . . . . 14 70 5.3.2. Gain Experience Using IPv6 Transition Names . . . . . 15 71 5.3.3. Implement DNS Blacklisting . . . . . . . . . . . . . . 15 72 6. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 16 73 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 17 74 7.1. Architectural Implications . . . . . . . . . . . . . . . . 17 75 7.2. Public IPv6 Address Reachability Implications . . . . . . 18 76 7.3. Operational Implications . . . . . . . . . . . . . . . . . 19 77 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 19 78 7.3.2. Authoritative DNS Server Operational Implications . . 19 79 7.3.3. DNS Recursive Resolver Server Operational 80 Implications . . . . . . . . . . . . . . . . . . . . . 20 81 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 21 82 7.3.5. Implications of Operational Momentum . . . . . . . . . 22 83 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 22 84 7.3.7. Additional Implications If Deployed On An Ad Hoc 85 Basis . . . . . . . . . . . . . . . . . . . . . . . . 22 86 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 23 87 7.5. Technology Policy Implications . . . . . . . . . . . . . . 23 88 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 24 89 7.7. Implications with Poor IPv4 and Good IPv6 Transport . . . 25 90 7.8. Implications for Users of Third-Party DNS Recursive 91 Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 25 92 8. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 26 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 94 9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 27 95 9.2. Authoritative DNS Response Consistency Considerations . . 27 97 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 14.1. Normative References . . . . . . . . . . . . . . . . . . . 30 103 14.2. Informative References . . . . . . . . . . . . . . . . . . 31 104 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 33 105 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 36 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 108 1. Introduction 110 This document describes the practice and implications of whitelisting 111 DNS recursive resolvers in order to limit AAAA resource record (RR) 112 responses (which contain IPv6 addresses) sent by authoritative DNS 113 servers. This is referred to hereafter as DNS Whitelisting. This is 114 an IPv6 transition mechanism used by domains as a method for 115 incrementally transitioning inbound traffic to a domain from IPv4 to 116 IPv6 transport. When implemented, a domain's authoritative DNS will 117 return a AAAA resource record to DNS recursive resolvers [RFC1035] on 118 the whitelist, while returning no AAAA resource records to DNS 119 recursive resolvers which are not on the whitelist. The practice 120 appears to have first been used by major web content sites (sometimes 121 described hereafter as "high-traffic domains"), which have specific 122 concerns relating to maintaining a high-quality user experience for 123 all of their users during their transition to IPv6. 125 Critics of the practice of DNS Whitelisting have articulated several 126 concerns. Among these are that: 128 o DNS Whitelisting is a very different behavior from the current 129 practice concerning the publishing of IPv4 address resource 130 records, 132 o that it may create a two-tiered Internet, 134 o that policies and decision-making for whitelisting and de- 135 whitelisting are opaque or likely to cause conflict, 137 o that DNS Whitelisting reduces interest in the deployment of IPv6, 139 o that new operational and management burdens are created, 141 o that the practice does not scale, 143 o that it violates a basic premise of cross-Internet 144 interoperability by requiring prior arrangements, 146 o and that the costs and negative implications of DNS Whitelisting 147 outweigh the perceived benefits. 149 This document explores the reasons and motivations for DNS 150 Whitelisting Section 4. It also explores the concerns regarding this 151 practice, and whether and when the practice is recommended Section 8. 152 Readers will hopefully better understand what DNS Whitelisting is, 153 why some domains are implementing it, and what the implications are. 155 2. How DNS Whitelisting Works 157 Generally, using a whitelist means no traffic (or traffic of a 158 certain type) is permitted to the destination host unless the 159 originating host's IP address is contained in the whitelist. In 160 contrast, using a blacklist means that all traffic is permitted to 161 the destination host unless the originating host's IP address is 162 contained in the blacklist. 164 DNS Whitelisting is implemented in authoritative DNS servers, not in 165 DNS recursive resolvers. These authoritative DNS servers implement 166 IP address-based restrictions on AAAA query responses. So far, DNS 167 Whitelisting has been primarily implemented by web site operators 168 deploying IPv6-enabled services, though this practice could affect 169 all protocols and services within a domain. For a given operator of 170 a website, such as www.example.com, the domain operator essentially 171 applies an access control list (ACL) on the authoritative DNS servers 172 for the domain example.com. The ACL is populated with the IPv4 173 and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on 174 the Internet, which have been authorized to receive (or access) AAAA 175 resource record responses. These DNS recursive resolvers are 176 operated by third parties, such as Internet Service Providers (ISPs), 177 universities, governments, businesses, and individual end users. If 178 a DNS recursive resolver IS NOT matched in the ACL, then AAAA 179 resource records WILL NOT be sent in response to a query for a 180 hostname in the example.com domain. However, if a DNS recursive 181 resolver IS matched in the ACL, then AAAA resource records WILL be 182 sent in response to a query for a given hostname in the example.com 183 domain. While these are not network-layer access controls (as many 184 ACLs are) they are nonetheless access controls that are a factor for 185 end users and other organizations such as network operators, 186 especially as networks and hosts transition from one network address 187 family to another (IPv4 to IPv6). Thus, if a DNS recursive resolver 188 is on the ACL (whitelist) then they have access to AAAA resource 189 records for the domain. 191 In practice, DNS Whitelisting generally means that a very small 192 fraction of the DNS recursive resolvers on the Internet (those in the 193 whitelist or ACL) will receive AAAA responses. The large majority of 194 DNS recursive resolvers on the Internet will therefore receive only A 195 resource records containing IPv4 addresses. Thus, quite simply, the 196 authoritative server hands out different answers depending upon who 197 is asking; with IPv4 and IPv6 resource records for all those the 198 authorized whitelist, and only IPv4 resource records for everyone 199 else. See Section 2.1 and Figure 1 for more details. 201 DNS Whitelisting also works independently of whether an authoritative 202 DNS server, DNS recursive resolver, or end user host uses IPv4 203 transport, IPv6, or both. So, for example, whitelisting may prevent 204 sending AAAA responses even in those cases where the DNS recursive 205 resolver has queried the authoritative server over IPv6 transport, or 206 where the end user host's original query to the DNS recursive 207 resolver was over IPv6 transport. One important reason for this is 208 that even though the DNS recursive resolver may have no IPv6-related 209 impairments, this is not a reliable predictor of whether the same is 210 true of the end user host. This also means that a DNS whitelist can 211 contain both IPv4 and IPv6 addresses. 213 Finally, DNS Whitelisting could possibly be deployed in two ways: 214 universally on a global basis (though that would be considered 215 harmful and is just covered to explain why this is the case), or, 216 more realistically, on an ad hoc basis. Deployment on a universal 217 deployment basis means that DNS Whitelisting is implemented on all 218 authoritative DNS servers, across the entire Internet. In contrast, 219 deployment on an ad hoc basis means that only some authoritative DNS 220 servers, and perhaps even only a few, implement DNS Whitelisting. 221 These two potential deployment models are described in Section 5. 223 Specific implementations will vary from domain to domain, based on a 224 range of factors such as the technical capabilities of a given 225 domain. As such, any examples listed herein should be considered 226 general examples and are not intended to be exhaustive. 228 2.1. Description of the Operation of DNS Whitelisting 230 The system logic of DNS Whitelisting is as follows: 232 1. The authoritative DNS server for example.com receives DNS queries 233 for the A (IPv4) and/or AAAA (IPv6) address resource records for 234 the Fully Qualified Domain Name (FQDN) www.example.com, for which 235 AAAA (IPv6) resource records exist. 237 2. The authoritative DNS server checks the IP address (IPv4, IPv6, 238 or both) of the DNS recursive resolver sending the AAAA (IPv6) 239 query against the access control list (ACL) that is the DNS 240 Whitelist. 242 3. If the DNS recursive resolver's IP address IS matched in the ACL, 243 then the response to that specific DNS recursive resolver can 244 contain AAAA (IPv6) address resource records. 246 4. If the DNS recursive resolver's IP address IS NOT matched in the 247 ACL, then the response to that specific DNS recursive resolver 248 cannot contain AAAA (IPv6) address resource records. In this 249 case, the server will likely return a response with the response 250 code (RCODE) being set to 0 (No Error) with an empty answer 251 section for the AAAA record query. 253 +--------------------------------------------------------------------+ 254 | Caching Server 1 - IS NOT ON the DNS Whitelist | 255 | Caching Server 2 - IS ON the DNS Whitelist | 256 | Note: Transport between each host can be IPv4 or IPv6. | 257 +--------------------------------------------------------------------+ 258 +----------+ +---------------+ +---------------+ 259 | Stub | | DNS Caching | | DNS | 260 | Resolver | | Server 1 | | Server | 261 +----------+ +---------------+ +---------------+ 262 | DNS Query: | | 263 | example.com A, AAAA | | 264 |---------------------->| | 265 | | | 266 | | DNS Query: | 267 | | example.com A, AAAA | 268 | |------------------------>| 269 | | | 270 | | | NOT on Whitelist 271 | | DNS Response: | 272 | | example.com A | 273 | |<------------------------| 274 | | | 275 | DNS Response: | | 276 | example.com A | | 277 |<----------------------| | 279 +----------+ +---------------+ +---------------+ 280 | Stub | | DNS Caching | | DNS | 281 | Resolver | | Server 2 | | Server | 282 +----------+ +---------------+ +---------------+ 283 | DNS Query: | | 284 | example.com A, AAAA | | 285 |---------------------->| | 286 | | | 287 | | DNS Query: | 288 | | example.com A, AAAA | 289 | |------------------------>| 290 | | | 291 | | | IS on Whitelist 292 | | DNS Response: | 293 | | example.com A, AAAA | 294 | |<------------------------| 295 | | | 296 | DNS Response: | | 297 | example.com A, AAAA | | 298 |<----------------------| | 300 Figure 1: DNS Whitelisting Diagram 302 2.2. Comparison with Blacklisting 304 With DNS Whitelisting, DNS recursive resolvers can receive AAAA 305 resource records only if they are on the whitelist. In contrast, 306 blacklisting would be the opposite whereby all DNS recursive 307 resolvers can receive AAAA resource records unless they are on the 308 blacklist. So a whitelist contains a list of hosts allowed 309 something, whereby a blacklist contains a list of hosts disallowed 310 something. While the distinction between the concepts of 311 whitelisting and blacklisting is important, this is noted 312 specifically since some implementers of DNS Whitelisting may choose 313 to transition to DNS Blacklisting before returning to a state without 314 address-family-related ACLs in their authoritative DNS servers. It 315 is unclear when and if it would be appropriate to change from 316 whitelisting to blacklisting. Nor is it clear how implementers will 317 judge the network conditions to have changed sufficiently to justify 318 disabling such controls. 320 3. Similarities to Other DNS Operations 322 Some aspects of DNS Whitelisting may be considered similar to other 323 common DNS operational techniques which are explored below. 325 3.1. Similarities to Split DNS 327 DNS Whitelisting has some similarities to so-called split DNS, 328 briefly described in Section 3.8 of [RFC2775]. When split DNS is 329 used, the authoritative DNS server returns different responses 330 depending upon what host has sent the query. While [RFC2775] notes 331 the typical use of split DNS is to provide one answer to hosts on an 332 Intranet and a different answer to hosts on the Internet, the essence 333 is that different answers are provided to hosts on different 334 networks. This is basically the way that DNS Whitelisting works, 335 whereby hosts on different networks which use different DNS recursive 336 resolvers, receive different answers if one DNS recursive resolver is 337 on the whitelist and the other is not. 339 In [RFC2956], Internet transparency and Internet fragmentation 340 concerns regarding split DNS are detailed in Section 2.1. [RFC2956] 341 further notes in Section 2.7, concerns regarding split DNS and that 342 it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint 343 identifiers more complex." Section 3.5 of [RFC2956] further 344 recommends that maintaining a stable approach to DNS operations is 345 key during transitions such as the one to IPv6 that is underway now, 346 stating that "Operational stability of DNS is paramount, especially 347 during a transition of the network layer, and both IPv6 and some 348 network address translation techniques place a heavier burden on 349 DNS." 351 3.2. Similarities to DNS Load Balancing 353 DNS Whitelisting also has some similarities to DNS load balancing. 354 There are of course many ways that DNS load balancing can be 355 performed. In one example, multiple IP address resource records (A 356 and/or AAAA) can be added to the DNS for a given FQDN. This approach 357 is referred to as DNS round robin [RFC1794]. DNS round robin may 358 also be employed where SRV resource records are used [RFC2782]. 360 In another example, one or more of the IP address resource records in 361 the DNS will direct traffic to a load balancer. That load balancer, 362 in turn, may be application-aware, and pass the traffic on to one or 363 more hosts connected to the load balancer which have different IP 364 addresses. In cases where private IPv4 addresses are used [RFC1918], 365 as well as when public IP addresses are used, those end hosts may not 366 necessarily be directly reachable without passing through the load 367 balancer first. 369 Additionally, a geographically-aware authoritative DNS server may be 370 used, as is common with Content Delivery Networks (CDNs) or Global 371 Load Balancing (GLB, also referred to as Global Server Load 372 Balancing, or GSLB), whereby the IP address resource records returned 373 to a resolver in response to a query will vary based on the estimated 374 geographic location of the resolver [Wild-Resolvers]. CDNs perform 375 this function in order to attempt to direct hosts to connect to the 376 nearest content cache. As a result, one can see some similarities 377 with DNS Whitelisting insofar as different IP address resource 378 records are selectively returned to resolvers based on the IP address 379 of each resolver (or other imputed factors related to that IP 380 address). However, what is different is that in this case the 381 resolvers are not deliberately blocked from receiving DNS responses 382 containing an entire class of addresses; this load balancing function 383 strives to perform a content location-improvement function and not an 384 access control function. 386 4. What Problems Are Implementers Trying To Solve? 388 Implementers are attempting to protect users of their domain from 389 having a negative experience (poor performance) when they receive DNS 390 response containing AAAA resource records or when attempting to use 391 IPv6 transport. There are two concerns which relate to this 392 practice; one of which relates to IPv6-related impairment and the 393 other which relates to the maturity or stability of IPv6 transport 394 for high-traffic domains. Both can negatively affect the experience 395 of end users. 397 Not all domains may face these challenges, though some clearly do, 398 since the user base of each domain, traffic sources, traffic volumes, 399 and other factors obviously varies between domains. For example, 400 while some domains have implemented DNS Whitelisting, others have run 401 IPv6 experiments whereby they added AAAA resource records and 402 observed and measured errors, and then decided not to implement DNS 403 Whitelisting [Heise]. A more widespread such experiment was World 404 IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011. 405 This was a unique opportunity for hundreds of domains to add AAAA 406 resource records to the DNS without using DNS Whitelisting, all at 407 the same time. Domains can run their own independent experiments in 408 the future, adding AAAA resource records for a period of time, and 409 then analyzing any impacts or effects on traffic and the experience 410 of end users. 412 4.1. Volume-Based Concerns 414 Some implementers are trying to gradually add IPv6 traffic to their 415 domain since they may find that network operations, tools, processes 416 and procedures are less mature for IPv6 as compared to IPv4. 417 Compared to domains with small to moderate traffic volumes, whether 418 by the count of end users or count of bytes transferred, high-traffic 419 domains receive such a level of usage that it is prudent to undertake 420 any network changes gradually or in a manner which minimizes any risk 421 of disruption. 423 For example, one can imagine for one of the top ten sites globally 424 that the idea of suddenly turning on a significant amount of IPv6 425 traffic is quite daunting. DNS Whitelisting may therefore offer such 426 high-traffic domains one potential method for incrementally enabling 427 IPv6. Thus, some implementers with high-traffic domains plan to use 428 DNS Whitelisting as a necessary, though temporary, risk reduction 429 tactic intended to ease their transition to IPv6 and minimize any 430 perceived risk in such a transition. 432 4.2. IPv6-Related Impairment 434 Some implementers have observed that when they added AAAA resource 435 records to their authoritative DNS servers in order to support IPv6 436 access to their content that a small fraction of end users had slow 437 or otherwise impaired access to a given web site with both AAAA and A 438 resource records. The fraction of users with such impaired access 439 has been estimated to be as high as 0.078% of total Internet users 440 [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness], 441 though more recent measurements indicate this is declining 442 [Impairment-Tracker]. In these situations, DNS recursive resolvers 443 are added to the DNS Whitelist only when the measured level of 444 impairment of the hosts using that resolver declines to some level 445 acceptable by the domain. 447 It is not clear if the level of IPv4-related impairment is more or 448 less that IPv6-related impairment. As one document reviewer has 449 pointed out, it may simply be that websites are only measuring IPv6 450 impairments and not IPv4 impairments, whether because IPv6 is new or 451 whether those websites are simply unable to or are otherwise not in a 452 position to be able to measure IPv4 impairment (since this could 453 result in no Internet access whatsoever). 455 As a result of this impairment affecting end users of a given domain, 456 a few high-traffic domains have either implemented DNS Whitelisting 457 or are considering doing so [NW-Article-DNS-WL] [WL-Ops]. While it 458 is outside the scope of this document to explore the various reasons 459 why a particular user's system (host) may have impaired IPv6 access, 460 for the users who experience this impairment it has a very real 461 performance impact. It would affect access to all or most dual stack 462 services to which the user attempts to connect. This negative end 463 user experience can range from somewhat slower than usual access (as 464 compared to native IPv4-based access), to extremely slow access, to 465 no access to the domain whatsoever. In essence, whether the end user 466 even has an IPv6 address or not, merely by receiving a AAAA record 467 response the user either cannot access a FQDN or it is so slow that 468 the user gives up and assumes the destination is unreachable. 470 In addition, at least one high-traffic domain has noted that they 471 have received requests to not send DNS responses with AAAA resource 472 records to particular DNS recursive resolvers. In this case, a DNS 473 recursive resolver operator expressed a short-term concern that their 474 IPv6 network infrastructure was not yet ready to handle the large 475 traffic volume that may be associated with the hosts in their network 476 connecting to the websites of these domains. These end user networks 477 may also have other tools at their disposal in order to address this 478 concern, including applying rules to network equipment such as 479 routers and firewalls (this will necessarily vary by the type of 480 network, as well as the technologies used and the design of a given 481 network), as well as configuration of their DNS recursive resolvers 482 (though modifying or suppressing AAAA resource records in a DNSSEC- 483 signed domain on a Security-Aware Resolver will be problematic 484 Section 9.1). 486 It is worth noting that the IP address of a DNS recursive resolver is 487 not a precise indicator of the IPv6 preparedness, or lack of IPv6- 488 related impairment, of end user hosts which query (use) a particular 489 DNS recursive resolver. While the DNS recursive resolver may be an 490 imperfect proxy for judging IPv6 preparedness, it is at least one of 491 the best available methods at the current time. 493 4.3. Free Versus Subscription Services 495 It is also worth noting the differences between domains containing 496 primarily subscription-based services compared to those containing 497 primarily free services. In the case of free services, such as 498 search engines, end users have no direct billing relationship with 499 the domain and can switch sites simply by changing the address they 500 enter into their browser (ignoring other value added services which 501 may tie a user's preference to a given domain or otherwise create 502 switching costs). As a result, such domains may be more sensitive to 503 IPv6 transition issues since their users can quickly switch to 504 another domain that is not using IPv6. 506 5. General Implementation Variations 508 In considering how DNS Whitelisting may emerge more widely, there are 509 two deployment scenarios explored below, one of which, the ad-hoc 510 case Section 5.2, is realistic and is happening now. The other, 511 universal deployment Section 5.1, is only described for the sake of 512 completeness, to highlight its difficulties, and to explain why it 513 would be considered harmful. Other possible alternative or 514 supplementary approaches are also outlined. 516 In evaluating implementing DNS Whitelisting universally and on an ad 517 hoc basis, it is possible that reputable third parties could create 518 and maintain DNS whitelists, in much the same way that blacklists are 519 distributed and used for reducing email spam. In the email context, 520 a mail operator subscribes to one or more of these lists and as such 521 the operational processes for additions and deletions to the list are 522 managed by a third party. A similar model could emerge for DNS 523 Whitelisting. 525 In either of those scenarios a DNS recursive resolver operator will 526 have to determine whether or not DNS Whitelisting has been 527 implemented for a domain, since the absence of AAAA resource records 528 may simply be indicative that the domain has not yet added IPv6 529 addressing for the domain, rather than that they have done so but are 530 using DNS Whitelisting. This will be challenging at scale. 532 5.1. Implement DNS Whitelisting Universally 534 One approach is to implement DNS Whitelisting universally, which 535 could also involve using some sort of centralized registry of DNS 536 Whitelisting policies, contracts, processes, or other information. 537 For this deployment scenario to occur, DNS Whitelisting functionality 538 would need to be built into all authoritative DNS server software, 539 and all operators of authoritative DNS servers would have to upgrade 540 their software in order to enable this functionality. New IETF 541 Request for Comment (RFC) documents may need to be completed to 542 describe how to properly configure, deploy, and maintain DNS 543 Whitelisting across the entire Internet. As a result, it is highly 544 unlikely that DNS Whitelisting will become universally deployed. 546 Such an approach is considered harmful and problematic, and almost 547 certain not to happen. 549 5.2. Implement DNS Whitelisting On An Ad Hoc Basis 551 DNS Whitelisting is now being adopted on an ad hoc, or domain-by- 552 domain basis. Therefore, only those domains interested in DNS 553 Whitelisting would need to adopt the practice. Also in this 554 scenario, ad hoc use by a particular domain is likely to be a 555 temporary measure that has been adopted to ease the transition of the 556 domain to IPv6. A domain, particularly a high-traffic domain, may 557 choose to do so in order to ease their transition to IPv6 through a 558 selective deployment so as to minimize any risks or disruptions in 559 such a transition. 561 One benefit of DNS Whitelisting being deployed on an ad hoc basis is 562 that only the domains that are interested in doing so would have to 563 upgrade their authoritative DNS servers (or take other steps) in 564 order to implement DNS Whitelisting. Some domains that plan to or 565 already have implemented this and are manually updating their 566 whitelist, while others such as CDNs have discussed the possibility 567 of an automated method for doing so. 569 5.3. Do Not Implement DNS Whitelisting 571 As an alternative to adopting DNS Whitelisting, domains can choose 572 not to implement DNS Whitelisting, continuing the current predominant 573 authoritative DNS operational model on the Internet. It is then up 574 to end users with IPv6-related impairments to discover and fix those 575 impairments, though clearly other parties including end user host 576 operating system developers can play a critical role. However, the 577 concerns and risks related to traffic volume Section 4.1 should still 578 be considered since those are not directly related to such 579 impairments. 581 5.3.1. Solve Current End User IPv6 Impairments 583 A further extension of not implementing DNS Whitelisting, is to also 584 endeavor fix the underlying technical problems experienced by end 585 users during the transition to IPv6. A first step is to identify 586 which users have such impairments and then to communicate this 587 information to affected users. Such end user communication is likely 588 to be most helpful if the end user is not only alerted to a potential 589 problem but is given careful and detailed advice on how to resolve 590 this on their own, or where they can seek help in doing so. 591 Section 10 may also be relevant in this case. 593 One challenge with this option is the potential difficulty of 594 motivating members of the Internet community to work collectively 595 towards this goal, sharing the labor, time, and costs related to such 596 an effort. However, World IPv6 Day [W6D] shows that such community 597 efforts are possible and despite any potential challenges, the 598 Internet community continues to work to solve end user IPv6 599 impairments. 601 However, as noted above, the concerns and risks related to traffic 602 volume Section 4.1 should still be considered since those are not 603 directly related to such impairments. 605 5.3.2. Gain Experience Using IPv6 Transition Names 607 Another alternative is for domains to gain experience using an FQDN 608 which has become common for domains beginning the transition to IPv6; 609 ipv6.example.com and www.ipv6.example.com. This can be a way for a 610 domain to gain IPv6 experience and increase IPv6 use on a relatively 611 controlled basis, and to inform any plans for DNS Whitelisting with 612 experience. 614 While this is a good first step to functionally test and prepare a 615 domain for IPv6, the utility of the tactic is limited since users 616 must know the transition name, the traffic volume will be low, and 617 the traffic is unlikely to be representative of the general 618 population of end users, among other reasons. Thus, as noted above, 619 the concerns and risks related to traffic volume Section 4.1 should 620 still be considered. 622 5.3.3. Implement DNS Blacklisting 624 Some domains may wish to be more permissive than if they adopted DNS 625 Whitelisting, but still have some level of control over returning 626 AAAA record responses. In this case an alternative may be to employ 627 DNS Blacklisting, which would enable all DNS recursive resolvers to 628 receive AAAA record responses except for the relatively small number 629 that are listed in the blacklist. This could, for example, enable an 630 implementer to only prevent such responses where there has been a 631 relatively high level of IPv6-related impairments, until such time as 632 these impairments can be fixed or otherwise meaningfully reduced to 633 an acceptable level. 635 This approach is likely to be significantly less labor intensive for 636 an authoritative DNS server operator, as they would presumably focus 637 on a smaller number of DNS recursive resolvers than if they 638 implemented whitelisting. Thus, these authoritative DNS server 639 operators would only need to communicate with a few DNS recursive 640 resolver operators rather than potentially all such operators. This 641 should result in lower labor, systems, and process requirements. 642 This is not to say that there will be no time required to work with 643 those parties affected by a blacklist, simply that there are likely 644 to be fewer such interactions and that each such interaction could be 645 shorter in duration. 647 The email industry has a long experience with blacklists and, very 648 generally speaking, blacklists tend to be effective and well received 649 when it is easy to discover if a server is on a blacklist, if there 650 is a transparent and easily understood process for requesting removal 651 from a blacklist, and if the decision-making criteria for placing a 652 server on a blacklist is transparently disclosed and perceived as 653 fair. 655 As noted in Section 7.3.7, it is also possible that a domain may 656 choose to first implement DNS Whitelisting and then migrate to DNS 657 Blacklisting. 659 6. Concerns Regarding DNS Whitelisting 661 There is concern that the practice of DNS Whitelisting for IPv6 662 address resource records represents a departure from the generally 663 accepted practices regarding IPv4 address resource records in the DNS 664 on the Internet [WL-Concerns]. Generally, once an authoritative 665 server operator adds an A record (IPv4) to the DNS, then any DNS 666 recursive resolver on the Internet can receive that A record in 667 response to a query. This enables new server hosts that are 668 connected to the Internet, and for which a FQDN such as 669 www.example.com has been added to the DNS with an IPv4 address 670 record, to be almost immediately reachable by any host on the 671 Internet. Each end in this end-to-end model is responsible for 672 connecting to the Internet and once they have done so they can 673 connect to each other without additional impediments, middle 674 networks, intervening networks, or servers either knowing about all 675 end points or whether one is allowed to discover and contact the 676 other. The end result is that new server hosts become more and more 677 widely accessible as new networks and new hosts connect to the 678 Internet over time, capitalizing on and increasing so-called "network 679 effects" (also called network externalities). 681 In contrast, DNS Whitelisting may fundamentally change this model. 682 In the altered DNS Whitelisting end-to-end model, one end (where the 683 end user is located) cannot readily discover the other end (where the 684 content is located), without parts of the middle (authoritative DNS 685 servers) making a new type of access control decision in the DNS. So 686 in the current IPv4-based Internet when a new server host is added to 687 the Internet it is generally widely available to all end user hosts 688 via a FQDN. When DNS Whitelisting of IPv6 resource records is used, 689 these new server hosts are not accessible via a FQDN by any end user 690 hosts until such time as the operator of the authoritative DNS 691 servers adds DNS recursive resolvers around the Internet to the DNS 692 Whitelist. 694 7. Implications of DNS Whitelisting 696 The key DNS Whitelisting implications are detailed below. 698 7.1. Architectural Implications 700 DNS Whitelisting modifies the end-to-end model and the general notion 701 of spontaneous interoperability of the architecture that prevails on 702 the Internet today. This is because this approach moves additional 703 access control information and policies into the middle of the DNS 704 resolution path of the IPv6-addressed Internet, which generally did 705 not exist before on the IPv4-addressed Internet, and it requires some 706 type of prior registration with authoritative servers. This poses 707 some risks noted in [RFC3724]. In explaining the history of the end- 708 to-end principle, [RFC1958] states that one of the goals is to 709 minimize the state, policies, and other functions needed in the 710 middle of the network in order to enable end-to-end communications on 711 the Internet. In this case, the middle network should be understood 712 to mean anything other than the end hosts involved in communicating 713 with one another. Some state, policies, and other functions have 714 always been necessary to enable such end-to-end communication, but 715 the goal of the approach has been to minimize this to the greatest 716 extent possible. 718 It is also possible that DNS Whitelisting could place at risk some of 719 the observed benefits of the end-to-end principle, as listed in 720 Section 4.1 of [RFC3724], such as protection of innovation. 721 [RFC3234] details issues and concerns regarding so-called 722 middleboxes, so there may also be parallel concerns with the DNS 723 Whitelisting approach, especially concerning modified DNS servers 724 noted in Section 2.16 of [RFC3234], as well as more general concerns 725 noted in Section 1.2 of [RFC3234] about the introduction of new 726 failure modes. In particular, there may be concerns that 727 configuration is no longer limited to two ends of a session, and that 728 diagnosis of failures and misconfigurations becomes more complex. 730 Two additional sources worth considering as far as implications for 731 the end-to-end model are concerned are [Tussle] and [Rethinking]. In 732 [Tussle], the authors note concerns regarding the introduction of new 733 control points, as well as "kludges" to the DNS, as risks to the goal 734 of network transparency in the end-to-end model. Given the emerging 735 use of DNS Whitelisting [Tussle] is an interesting and relevant 736 document. In addition, [Rethinking] reviews similar issues that are 737 of interest to readers of this document. 739 Also, it is somewhat possible that DNS Whitelisting could affect some 740 of the architectural assumptions which underlie parts of Section 2 of 741 [RFC4213] which outlines the dual stack approach to the IPv6 742 transition. DNS Whitelisting could modify the behavior of the DNS, 743 as described in Section 2.2 of [RFC4213] and could require different 744 sets of DNS servers to be used for hosts that are (using terms from 745 that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes. 746 As such, broad use of DNS Whitelisting may necessitate the review 747 and/or revision (though revision is unlikely to be necessary) of 748 standards documents which describe dual-stack and IPv6 operating 749 modes, dual-stack architecture generally, and IPv6 transition 750 methods, including but not limited to [RFC4213]. 752 7.2. Public IPv6 Address Reachability Implications 754 It is a critical to understand that the concept of reachability 755 described here depends upon a knowledge of an address in the DNS. 756 Thus, in order to establish reachability to an end point, a host is 757 dependent upon looking up an IP address in the DNS when a FQDN is 758 used. When DNS Whitelisting is used, it is quite likely that an 759 IPv6-enabled end user host could connect to an example server host 760 using the IPv6 address, even though the FQDN associated with that 761 server host is restricted via a DNS whitelist. Since most Internet 762 applications and hosts such as web servers depend upon the DNS, and 763 as end users connect to FQDNs such as www.example.com and do not 764 remember or wish to type in an IP address, the notion of reachability 765 described here should be understood to include knowledge of how to 766 associate a name with a network address. 768 The predominant experience of end user hosts and servers on the IPv4- 769 addressed Internet today is that when a new server with a public IPv4 770 address is added to the DNS, that a FQDN is immediately useful for 771 reaching it. This is a generalization and in Section 3 there are 772 examples of common cases where this may not necessarily be the case. 773 For the purposes of this argument, that concept of accessibility is 774 described as "pervasive reachability". It has so far been assumed 775 that the same expectations of pervasive reachability would exist in 776 the IPv6-addressed Internet. However, if DNS Whitelisting is 777 deployed, this will not be the case since only end user hosts using 778 DNS recursive resolvers that are included in the ACL of a given 779 domain using DNS Whitelisting would be able to reach new servers in 780 that given domain via IPv6 addresses. The expectation of any end 781 user host being able to connect to any server (essentially both 782 hosts, just at either end of the network), defined here as "pervasive 783 reachability", will change to "restricted reachability" with IPv6. 785 Establishing DNS Whitelisting as an accepted practice in the early 786 phases of mass IPv6 deployment could establish it as an integral part 787 of how IPv6 DNS resource records are deployed globally. This risks 788 DNS Whitelisting living on for many years as a key foundational 789 element of domain name management on the Internet. 791 7.3. Operational Implications 793 This section explores some of the operational implications which may 794 occur as a result of, are related to, or become necessary when 795 engaging in the practice of DNS Whitelisting. 797 7.3.1. De-Whitelisting May Occur 799 It is possible for a DNS recursive resolver added to a whitelist to 800 then be removed from the whitelist, also known as de-whitelisting. 801 Since de-whitelisting can occur, through a decision by the 802 authoritative server operator, the domain owner, or even due to a 803 technical error, an operator of a DNS recursive resolver will have 804 new operational and monitoring requirements and/or needs as noted in 805 Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. One 806 particular risk is that, especially when a high-traffic domain de- 807 whitelists a large network, this may cause a sudden and dramatic 808 change to networks since a large volume of traffic will then switch 809 from IPv6 to IPv4. This can have dramatic effects on those being de- 810 whitelisted as well as on other interconnected networks. In some 811 cases, IPv4 network links may rapidly become congested and users of 812 affected networks will experience network access impairments well 813 beyond the domain which performed the de-whitelisting. Thus, once 814 "operational stability" has been achieved between a whitelisting and 815 whitelisted party, then de-whitelisting should generally not occur 816 except in cases of operational emergencies, and there should be 817 opportunities for joint troubleshooting or at least for advance 818 warning to affected parties. 820 7.3.2. Authoritative DNS Server Operational Implications 822 DNS Whitelisting serves as a critical infrastructure service; to be 823 useful it needs careful and extensive administration, monitoring and 824 operation. Each new and essential mechanism creates substantial 825 follow-on support costs. 827 Operators of authoritative servers (which are frequently 828 authoritative for multiple domain names) will need to maintain an ACL 829 on a server-wide basis affecting all domains, or on a domain-by- 830 domain basis. As a result, operational practices and software 831 capabilities may need to be developed in order to support such 832 functionality. In addition, processes may need to be put in place to 833 protect against inadvertently adding or removing IP addresses, as 834 well as systems and/or processes to respond to such incidents if and 835 when they occur. For example, a system may be needed to record DNS 836 Whitelisting requests, report on their status along a workflow, add 837 IP addresses when whitelisting has been approved, remove IP addresses 838 when they have been de-whitelisted, log the personnel involved and 839 timing of changes, schedule changes to occur in the future, and to 840 roll back any inadvertent changes. 842 Operators may also need implement new forms of monitoring in order to 843 apply change control, as noted briefly in Section 7.3.4. 845 It is important for operators of authoritative servers to recognize 846 that the operational burden is likely to increase dramatically over 847 time, as more and more networks transition to IPv6. As a result, the 848 volume of new DNS Whitelisting requests will increase over time, 849 potentially at an extraordinary growth rate, which will place an 850 increasing burden on personnel, systems, and/or processes. Operators 851 should also consider that any supporting systems, including the 852 authoritative servers themselves, may experience reduced performance 853 when a DNS whitelist becomes quite large. 855 7.3.3. DNS Recursive Resolver Server Operational Implications 857 For operators of DNS recursive resolvers, coping with DNS 858 Whitelisting becomes expensive in time and personnel as the practice 859 scales up. These operators include ISPs, enterprises, universities, 860 governments; a wide range of organization types with a range of DNS- 861 related expertise. They will need to implement new forms of 862 monitoring, as noted briefly in Section 7.3.4. But more critically, 863 such operators will need to add people, processes, and systems in 864 order to manage large numbers of DNS Whitelisting applications. 865 Since there is no common method for determining whether or not a 866 domain is engaged in DNS Whitelisting, operators will have to apply 867 to be whitelisted for a domain based upon one or more end user 868 requests, which means systems, processes, and personnel for handling 869 and responding to those requests will also be necessary. 871 When operators apply for DNS Whitelisting for all domains, that may 872 mean doing so for all registered domains. Thus, some system would 873 have to be developed to discover whether each domain has been 874 whitelisted or not, which is touched on in Section 5 and may vary 875 depending upon whether DNS Whitelisting is universally deployed or is 876 deployed on an ad hoc basis. 878 These operators (of DNS recursive resolvers) will need to develop 879 processes and systems to track the status of all DNS Whitelisting 880 applications, respond to requests for additional information related 881 to these applications, determine when and if applications have been 882 denied, manage appeals, and track any de-whitelisting actions. 884 Given the large number of domains in existence, the ease with which a 885 new domain can be added, and the continued strong growth in the 886 numbers of new domains, readers should not underestimate the 887 potential significance in personnel and expense that this could 888 represent for such operators. In addition, it is likely that systems 889 and personnel may also be needed to handle new end user requests for 890 domains for which to apply for DNS Whitelisting, and/or inquiries 891 into the status of a whitelisting application, reports of de- 892 whitelisting incidents, general inquiries related to DNS 893 Whitelisting, and requests for DNS Whitelisting-related 894 troubleshooting by these end users. 896 7.3.4. Monitoring Implications 898 Once a DNS recursive resolver has been whitelisted for a particular 899 domain, then the operator of that DNS recursive resolver may need to 900 implement monitoring in order to detect the possible loss of DNS 901 Whitelisting in the future. This DNS recursive resolver operator 902 could configure a monitor to check for a AAAA response in the 903 whitelisted domain, as a check to validate continued status on the 904 DNS whitelist. The monitor could then trigger an alert if at some 905 point the AAAA responses were no longer received, so that operations 906 personnel could begin troubleshooting, as outlined in Section 7.3.6. 908 Also, authoritative DNS server operators are likely to need to 909 implement new forms of monitoring. In this case, they may desire to 910 monitor for significant changes in the size of the whitelist within a 911 certain period of time, which might be indicative of a technical 912 error such as the entire ACL being removed. Authoritative DNS server 913 operators may also wish to monitor their workflow process for 914 reviewing and acting upon DNS Whitelisting applications and appeals, 915 potentially measuring and reporting on service level commitments 916 regarding the time an application or appeal can remain at each step 917 of the process, regardless of whether or not such information is 918 shared with parties other than that authoritative DNS server 919 operator. 921 7.3.5. Implications of Operational Momentum 923 It seems plausible that once DNS Whitelisting is implemented it will 924 be very difficult to deprecate such technical and operational 925 practices. This assumption is based on an understanding of human 926 nature, not to mention physics. For example, as Sir Isaac Newton 927 noted, "Every object in a state of uniform motion tends to remain in 928 that state of motion unless an external force is applied to it" 929 [Motion]. Thus, once DNS Whitelisting is implemented it is quite 930 likely that it would take considerable effort to deprecate the 931 practice and remove it everywhere on the Internet; it may otherwise 932 simply remain in place in perpetuity. To illustrate this point, one 933 could consider for example that there are many email servers 934 continuing to attempt to query anti-spam DNS blocklists which have 935 long ago ceased to exist. 937 7.3.6. Troubleshooting Implications 939 The implications of DNS whitelisted present many challenges, as 940 detailed throughout Section 7. These challenges may negatively 941 affect the end users' ability to troubleshoot, as well as that of DNS 942 recursive resolver operators, ISPs, content providers, domain owners 943 (where they may be different from the operator of the authoritative 944 DNS server for their domain), and other third parties. This may make 945 the process of determining why a server is not reachable via a FQDN 946 significantly more complex and time-consuming. 948 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis 950 As more domains choose to implement DNS Whitelisting, and more 951 networks become IPv6-capable and request to be whitelisted, scaling 952 up operational processes, monitoring, and ACL updates will become 953 more difficult. The increased rate of change and increased size of 954 whitelists will increase the likelihood of configuration and other 955 operational errors. 957 It is unclear when and if it would be appropriate to change from 958 whitelisting to blacklisting. It also seems unlikely for such a 959 change from whitelisting to blacklisting to be coordinated across the 960 Internet, so such a change to blacklisting will likely occur on an 961 ad-hoc basis as well (if at all). 963 Finally, some implementers consider DNS Whitelisting to be a 964 temporary measure. As such, it is not clear how these implementers 965 will judge the network conditions to have changed sufficiently to 966 justify disabling DNS Whitelisting (or blacklisting, or other AAAA 967 resource record access controls) and/or what the process and timing 968 will be in order to discontinue this practice. 970 7.4. Homogeneity May Be Encouraged 972 A broad trend on the Internet is a move toward more heterogeneity. 973 One manifestation of this is in an increasing number, variety, and 974 customization of end user hosts, including home networks, operating 975 systems, client software, home network devices, and personal 976 computing devices. This trend appears to have had a positive effect 977 on the development and growth of the Internet and has enabled end 978 users to connect any technically compliant device or use any 979 technically compatible software to connect to the Internet. Not only 980 does this trend towards greater heterogeneity reduce the control 981 which is exerted in the middle of the network, described positively 982 in [Tussle], [Rethinking], and [RFC3724], but it also appears to help 983 to enable greater and more rapid innovation at the edge of the 984 network. 986 Some forms of so-called "network neutrality" principles around the 987 world include the notion that any IP-capable device should be able to 988 connect to a network, encouraging heterogeneity. These principles 989 are often explicitly encouraged by application providers, though some 990 of these same providers may be using DNS Whitelisting. This is 991 ironic, as one implication of the adoption of DNS Whitelisting is 992 that it could encourage a move back towards homogeneity resulting 993 from greater control over devices in order to attempt to enforce 994 technical requirements intended to reduce IPv6-related impairments. 995 This return to an environment of more homogenous and/or controlled 996 end user hosts could have unintended side effects on and counter- 997 productive implications for future innovation at the edge of the 998 network. 1000 7.5. Technology Policy Implications 1002 A key technology policy implication concerns the policies and 1003 processes related to reviewing and making decisions on DNS 1004 Whitelisting applications for a domain, as well as making any 1005 possible de-whitelisting decisons. Important questions may include 1006 whether these policies have been fully and transparently disclosed, 1007 are non-discriminatory, and are not anti-competitive. Key questions 1008 here may include whether appeals are allowed, what the process is, 1009 what the expected turn around time is, and whether the appeal will be 1010 handled by an independent third party. 1012 It is also conceivable that whitelisting and de-whitelisting 1013 decisions could be quite sensitive to concerned parties beyond the 1014 operator of the domain operator and the operator of the DNS recursive 1015 resolver, including end users, application developers, content 1016 providers, advertisers, public policy groups, governments, and other 1017 entities. These concerned parties may seek to become involved in or 1018 express opinions concerning whitelisting and/or de-whitelisting 1019 decisions. 1021 A final concern is that decisions relating to whitelisting and de- 1022 whitelisting may occur as an expression of other commercial, 1023 governmental, and/or cultural conflicts, given the new control point 1024 which has been established with DNS Whitelisting. For example, in 1025 one imagined scenario, a domain could withhold adding a network to 1026 their DNS Whitelisting unless that network agreed to some sort of 1027 financial payment, legal agreement, agreement to sever a relationship 1028 with a competitor of the domain, etc. In another example, a music- 1029 oriented domain may be engaged in some sort of dispute with an 1030 academic network concerning copyright infringement concerns within 1031 that network, and may choose to de-whitelist that network as a 1032 negotiating technique in some sort of commercial discussion. In a 1033 final example, a major email domain may choose to de-whitelist a 1034 network due to that network sending some large volume of spam. Thus, 1035 it seems possible that whitelisting and de-whitelisting could become 1036 a vehicle for adjudicating other disputes, and that this may well 1037 have consequences for end users which are affected by such decisions 1038 and are unable to express a strong voice in such decisions. 1040 7.6. IPv6 Adoption Implications 1042 As noted in Section 6, the implications of DNS Whitelisting may drive 1043 end users and/or networks to delay, postpone, or cancel adoption of 1044 IPv6, or to actively seek alternatives to it. Such alternatives may 1045 include the use of multi-layer or large scale network address 1046 translation (NAT) techniques, which these parties may decide to 1047 pursue on a long-term basis to avoid the perceived costs and 1048 aggravations related to DNS Whitelisting. This could of course come 1049 at the very time that the Internet community is trying to get these 1050 very same parties interested in IPv6 and motivated to begin the 1051 transition to IPv6. As a result, parties that are likely to be 1052 concerned over the negative implications of DNS Whitelisting could 1053 logically be concerned of the negative effects that this practice 1054 could have on the adoption of IPv6 if it became widespread. 1056 At the same time, as noted in Section 4, some high-traffic domains 1057 may find the prospect of transitioning to IPv6 daunting without 1058 having some short-term ability to incrementally control the amount 1059 and source of IPv6 traffic to their domains. Lacking such controls, 1060 some domains may choose to substantially delay their transition to 1061 IPv6. 1063 7.7. Implications with Poor IPv4 and Good IPv6 Transport 1065 It is possible that there could be situations where the differing 1066 quality of the IPv4 and IPv6 connectivity of an end user could cause 1067 complications in accessing content which is in a whitelisted domain, 1068 when the end user's DNS recursive resolver is not on that whitelist. 1069 While today most end users' IPv4 connectivity is typically superior 1070 to IPv6 connectivity (if such connectivity exists at all), there 1071 could be implications when the reverse is true and and end user has 1072 markedly superior IPv6 connectivity as compared to IPv4. This is 1073 admittedly theoretical but could become a factor as the transition to 1074 IPv6 continues and IPv4 address availability within networks becomes 1075 strained. 1077 For example, in one possible scenario, a user is issued IPv6 1078 addresses by their ISP and has a home network and devices or 1079 operating systems which fully support IPv6. As a result this 1080 theoretical user has very good IPv6 connectivity. However, this end 1081 user's ISP may have exhausted their available pool of unique IPv4 1082 address, and so that ISP uses NAT in order to reuse IPv4 addresses. 1083 So for IPv4 content, the end user must send their IPv4 traffic 1084 through some additional network element (e.g. NAT, proxy, tunnel 1085 server). Use of this additional network element may cause the end 1086 user to experience sub-optimal IPv4 connectivity when certain 1087 protocols or applications are used. This user then has good IPv6 1088 connectivity but impaired IPv4 connectivity. Furthermore, this end 1089 user's DNS recursive resolver is not whitelisted by the authoritative 1090 server for a domain that the user is trying to access, meaning the 1091 end user only gets A record responses for their impaired IPv4 1092 transport rather than also AAAA record responses for their stable and 1093 well-performing IPv6 transport. Thus, the user's poor IPv4 1094 connectivity situation is potentially exacerbated by not having 1095 access to a given domain's IPv6 content since they must use the 1096 address family with relatively poor performance. 1098 7.8. Implications for Users of Third-Party DNS Recursive Resolvers 1100 In most cases it is assumed that end users will make use of DNS 1101 recursive resolvers which are operated by their access network 1102 provider, whether that is an ISP, campus network, enterprise network, 1103 or some other type of network. However there are also cases where an 1104 end user has changed their DNS server IP addresses in their device's 1105 operating system to those of a third party which operates DNS 1106 recursive resolvers independently of end user access networks. 1108 In these cases, an authoritative DNS server may receive a query from 1109 a DNS recursive resolver in one network, though the end user sending 1110 the original query is in an entirely different network. It may 1111 therefore be more challenging for a DNS Whitelist implementer to 1112 determine the level of IPv6-related impairment when such third-party 1113 DNS recursive resolvers are used, given the wide variety of end user 1114 access networks which may be used and that this mix may change in 1115 unpredictable ways over time. 1117 There may also be cases where end users' assigned DNS recursive 1118 resolvers have not been whitelisted for a particular domain, but 1119 where the end user tries to switch to a third-party DNS recursive 1120 resolver that has been whitelisted. While in most cases the end user 1121 will be able to switch to use that third-party's DNS servers, some 1122 specialized access networks, such as in hotels and conference 1123 centers, may prevent using third-party DNS servers. In these cases, 1124 end users may be frustrated at their inability to access certain 1125 content over IPv6, resulting in complaints to both a particular 1126 domain as well as the access network operator. 1128 8. Is DNS Whitelisting a Recommended Practice? 1130 Opinions in the Internet community concerning whether or not DNS 1131 Whitelisting is a recommended practice are understandably quite 1132 varied. However, there is clear consensus that DNS Whitelisting can 1133 be a useful tactic a domain may choose to use as they transition to 1134 IPv6. In particular, some high-traffic domains view DNS Whitelisting 1135 as one of the few practical and low-risk approaches enabling them to 1136 transition to IPv6, without which their transition may not take place 1137 for some time. However, there is also consensus is that this 1138 practice is workable only in the short-term and that it will not 1139 scale over the long-term. Thus, some domains may find DNS 1140 Whitelisting a beneficial temporary tactic in their transition to 1141 IPv6. Such temporary use during the transition to IPv6 is broadly 1142 accepted within the community, so long as it does not become a long- 1143 term practice. 1145 9. Security Considerations 1147 If DNS Whitelisting is adopted, then organizations which apply DNS 1148 Whitelisting policies in their authoritative servers should have 1149 procedures and systems which do not allow unauthorized parties to 1150 either remove whitelisted DNS recursive resolvers from the whitelist 1151 or add non-whitelisted DNS recursive resolvers to the whitelist, just 1152 as all configuration settings for name servers should be protected by 1153 appropriate procedures and systems. Should such unauthorized 1154 additions or removals from the whitelist can be quite damaging, and 1155 result in content providers and/or ISPs to incur substantial support 1156 costs resulting from end user and/or customer contacts. As such, 1157 great care must be taken to control access to the whitelist for an 1158 authoritative server. 1160 In addition, two other key security-related issues should be taken 1161 into consideration: 1163 9.1. DNSSEC Considerations 1165 DNS security extensions defined in [RFC4033], [RFC4034], and 1166 [RFC4035] use cryptographic digital signatures to provide origin 1167 authentication and integrity assurance for DNS data. This is done by 1168 creating signatures for DNS data on a Security-Aware Authoritative 1169 Name Server that can be used by Security-Aware Resolvers to verify 1170 the answers. Since DNS Whitelisting is implemented on an 1171 authoritative DNS server, which provides different answers depending 1172 upon which DNS resolver has sent a query, the DNSSEC chain of trust 1173 is not altered. Even though the authoritative DNS server will not 1174 always return a AAAA resource record when one exists, respective A 1175 resource records and AAAA resource records can and should both be 1176 signed. Therefore there are no DNSSEC implications per se. However, 1177 any implementer of DNS Whitelisting should be careful if they 1178 implement both DNSSEC signing of their domain and also DNS 1179 Whitelisting of that same domain. Specifically, those domains should 1180 ensure that resource records are being appropriately and reliably 1181 signed, which may present modest incremental operational and/or 1182 technical challenges. 1184 However, as noted in fourth paragraph of Section 4.2, end user 1185 networks may also choose to implement tools at their disposal in 1186 order to address IPv6-related impairments. One of those tools could 1187 involve unspecified changes to the configuration of their DNS 1188 recursive resolvers. If those are Security-Aware Resolvers, 1189 modifying or suppressing AAAA resource records for a DNSSEC-signed 1190 domain will be problematic and could break the chain of trust 1191 established with DNSSEC. 1193 9.2. Authoritative DNS Response Consistency Considerations 1195 In addition to the considerations raised in Section 9.1, it is 1196 conceivable that security concerns may arise when end users or other 1197 parties notice that the responses sent from an authoritative DNS 1198 server appear to vary from one network or one DNS recursive resolver 1199 to another. This may give rise to concerns that, since the 1200 authoritative responses vary that there is some sort of security 1201 issue and/or some or none of the responses can be trusted. While 1202 this may seem a somewhat obscure concern, domains nonetheless may 1203 wish to consider this when contemplating whether or not to pursue DNS 1204 Whitelisting. 1206 10. Privacy Considerations 1208 As noted in Section 5.3.1, there may be methods to detect IPv6- 1209 related impairments for a particular end user. For example, this may 1210 be possible when an end user visits the website of a particular 1211 domain. In that example, there are likely no privacy considerations 1212 in automatically communicating to that end user that the domain has 1213 detected a particular impairment. However, if that domain decided to 1214 share information concerning that particular end user with their 1215 network operator or another party, then the visited domain may wish 1216 to in some manner advise the end user of this or otherwise seek to 1217 obtain the user's consent to such information sharing. This may be 1218 achieved in a wide variety of ways, from presenting a message asking 1219 the user for consent (which will of course help them solve a 1220 technical problem of which they are likely unaware) to adding this to 1221 a domain's website terms of use / service. Such information sharing 1222 and communication of such sharing to end users may well vary by 1223 geographic area and/or legal jurisdiction. Thus, a domain should 1224 consider any potential privacy issues these sorts of scenarios. 1226 To the extent that domains or network operators decide to publish 1227 impairment statistics, they should not identify individual hosts, 1228 host identifiers, or users. 1230 11. IANA Considerations 1232 There are no IANA considerations in this document. 1234 12. Contributors 1236 The following people made significant textual contributions to this 1237 document and/or played an important role in the development and 1238 evolution of this document: 1240 - John Brzozowski 1242 - Chris Griffiths 1244 - Tom Klieber 1246 - Yiu Lee 1248 - Rich Woundy 1250 13. Acknowledgements 1252 The author and contributors also wish to acknowledge the assistance 1253 of the following individuals or groups. Some of these people 1254 provided helpful and important guidance in the development of this 1255 document and/or in the development of the concepts covered in this 1256 document. Other people assisted by performing a detailed review of 1257 this document, and then providing feedback and constructive criticism 1258 for revisions to this document, or engaged in a healthy debate over 1259 the subject of the document. All of this was helpful and therefore 1260 the following individuals merit acknowledgement: 1262 - Bernard Aboba 1264 - Jari Arkko 1266 - Frank Bulk 1268 - Brian Carpenter 1270 - Lorenzo Colitti 1272 - Alissa Cooper 1274 - Dave Crocker 1276 - Ralph Droms 1278 - Wesley Eddy 1280 - J.D. Falk 1282 - Adrian Farrel 1284 - Stephen Farrell 1286 - Tony Finch 1288 - Karsten Fleischhauer 1290 - Wesley George 1292 - Philip Homburg 1294 - Jerry Huang 1296 - Ray Hunter 1297 - Joel Jaeggli 1299 - Erik Kline 1301 - Suresh Krishnan 1303 - Victor Kuarsingh 1305 - John Leslie 1307 - John Mann 1309 - Danny McPherson 1311 - Milo Medin 1313 - Martin Millnert 1315 - Russ Mundy 1317 - Thomas Narten 1319 - Pekka Savola 1321 - Robert Sparks 1323 - Barbara Stark 1325 - Joe Touch 1327 - Hannes Tschofenig 1329 - Tina Tsou 1331 - Members of the Broadband Internet Technical Advisory Group (BITAG) 1333 14. References 1335 14.1. Normative References 1337 [RFC1035] Mockapetris, P., "Domain names - implementation and 1338 specification", STD 13, RFC 1035, November 1987. 1340 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1341 April 1995. 1343 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1344 E. Lear, "Address Allocation for Private Internets", 1345 BCP 5, RFC 1918, February 1996. 1347 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1348 RFC 1958, June 1996. 1350 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1351 February 2000. 1353 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1354 specifying the location of services (DNS SRV)", RFC 2782, 1355 February 2000. 1357 [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 1358 RFC 2956, October 2000. 1360 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1361 Issues", RFC 3234, February 2002. 1363 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 1364 and the Future of End-to-End: Reflections on the Evolution 1365 of the Internet Architecture", RFC 3724, March 2004. 1367 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1368 Rose, "DNS Security Introduction and Requirements", 1369 RFC 4033, March 2005. 1371 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1372 Rose, "Resource Records for the DNS Security Extensions", 1373 RFC 4034, March 2005. 1375 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1376 Rose, "Protocol Modifications for the DNS Security 1377 Extensions", RFC 4035, March 2005. 1379 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1380 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1382 14.2. Informative References 1384 [Heise] Heise.de, "The Big IPv6 Experiment", Heise.de 1385 Website http://www.h-online.com, January 2011, . 1389 [IETF-77-DNSOP] 1390 Gashinsky, I., "IPv6 & recursive resolvers: How do we make 1391 the transition less painful?", IETF 77 DNS Operations 1392 Working Group, March 2010, 1393 . 1395 [IPv6-Brokenness] 1396 Anderson, T., "Measuring and Combating IPv6 Brokenness", 1397 Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, 1398 . 1400 [IPv6-Growth] 1401 Colitti, L., Gunderson, S., Kline, E., and T. Refice, 1402 "Evaluating IPv6 adoption in the Internet", Passive and 1403 Active Management (PAM) Conference 2010, April 2010, 1404 . 1406 [Impairment-Tracker] 1407 Anderson, T., "IPv6 dual-stack client loss in Norway", 1408 Website , May 2011, . 1410 [Motion] Newton, I., "Mathematical Principles of Natural Philosophy 1411 (Philosophiae Naturalis Principia Mathematica)", 1412 Principia Mathematical Principles of Natural Philosophy 1413 (Philosophiae Naturalis Principia Mathematica), July 1687, 1414 . 1416 [NW-Article-DNS-WL] 1417 Marsan, C., "Google, Microsoft, Netflix in talks to create 1418 shared list of IPv6 users", Network World , March 2010, . 1422 [NW-Article-DNSOP] 1423 Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", 1424 Network World , March 2010, . 1427 [Rethinking] 1428 Blumenthal, M. and D. Clark, "Rethinking the design of the 1429 Internet: The end to end arguments vs. the brave new 1430 world", ACM Transactions on Internet Technology Volume 1, 1431 Number 1, Pages 70-109, August 2001, . 1435 [Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski, 1436 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1437 Proceedings of ACM Sigcomm 2002, August 2002, . 1441 [W6D] The Internet Society, "World IPv6 Day - June 8, 2011", 1442 Internet Society Website http://www.isoc.org, 1443 January 2011, . 1445 [WL-Concerns] 1446 Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., 1447 Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - 1448 Could It Hinder IPv6 Adoption?", ISOC Internet Society 1449 IPv6 Deployment Workshop, April 2010, . 1453 [WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 1454 Implementors Conference, June 2010, . 1458 [Wild-Resolvers] 1459 Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, 1460 "Comparing DNS Resolvers in the Wild", ACM Sigcomm 1461 Internet Measurement Conference 2010, November 2010, 1462 . 1464 Appendix A. Document Change Log 1466 [RFC Editor: This section is to be removed before publication] 1468 -06: Removed the Open Issue #8 concerning the document name, at the 1469 direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and 1470 removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG 1471 mailing list. Revised the Abstract and Intro as recommended by Tony 1472 Finch. Per Dave Crocker, updated the diagram following remedial 1473 ASCII art assistance, added a reference regarding IPv4-brokenness 1474 statistics. Removed Open Issue #1, after validating proper reference 1475 placement and removing NAT444 reference. Updates per Ralph Droms' 1476 review for the IESG. Closed Open Issue #4, Per Joe Touch, moved 1477 section 8 to just after section 3 - and also moved up section 6 and 1478 merged it. Closed Open Issue #5, per Dave Crocker and John Leslie, 1479 simplifying the document more, consolidating sections, etc. Closed 1480 Open Issue #6. Closed Open Issue #7, per Jari Arkko, ensuring all 1481 motivations are accounted for, etc. Closed Open Issue #9, per 1482 Stephen Farrell, re. World IPv6 Day (retained reference but re- 1483 worded those sections). Removed the happy-eyeballs reference since 1484 this was an informative reference and the draft could be delayed due 1485 to that dependency. ALL OPEN ITEMS ARE NOW CLOSED. 1487 -05: Additional changes requested by Stephen Farrell intended to 1488 close his Discuss on the I-D. These changes were in Sections 6.2 and 1489 8.3. Also shortened non-RFC references at Stephen's request. 1491 -04: Made changed based on feedback received during IESG review. 1492 This does NOT include updated from the more general IETF last call - 1493 that will be in a -05 version of the document. Per Ralph Droms, 1494 change the title of 6.2 from "Likely Deployment Scenarios" to 1495 "General Implementation Variations", as well as changes to improve 1496 the understanding of sentences in Sections 2, 3, 4, and 8.2. Per 1497 Adrian Farrel, made a minor change to Section 3. Per Robert Sparks, 1498 to make clear in Section 2 that whitelisting is done on authoritative 1499 servers and not DNS recursive resolvers, and to improve Section 8.3 1500 and add a reference to I-D.ietf-v6ops-happy-eyeballs. Per Wesley 1501 Eddy, updated Section 7.3.2 to address operational concerns and re- 1502 titled Section 8 from "Solutions" to "General Implementation 1503 Variations". Per Stephen Farrell, added text to Section 8.1 and 1504 Section 6.2, with a reference to 8.1 in the Introduction, to say that 1505 universal deployment is considered harmful. Added text to Section 2 1506 per the v6ops list discussion to indicate that whitelisting is 1507 independent of the IP address family of the end user host or 1508 resolver. There was also discussion with the IESG to change the name 1509 of the draft to IPv6 DNS Resolver Whitelisting or IPv6 AAAA DNS 1510 Resolver Whitelisting (as suggested originally by John Mann) but 1511 there was not a strong consensus to do so. Added a new section 7.7, 1512 at the suggestion of Philip Homburg. Per Joe Touch, added a new 1513 Section 8.4 on blacklisting as an alternative, mentioned blacklisting 1514 in Section 2, added a new Section 7.8 on the use of 3rd party 1515 resolvers, and updated section 6.2 to change Internet Draft documents 1516 to RFCs. Minor changes from Barbara Stark. Changes to the Privacy 1517 Considerations section based on feedback from Alissa Cooper. Changed 1518 "highly-trafficked" domains to "high-traffic" domains. Per Bernard 1519 Aboba, added text noting that a whitelist may be manually or 1520 automatically updated, contrasting whitelisting with blacklisting, 1521 reorganized Section 3, added a note on multiple clearinghouses being 1522 possible. Per Pekka Savola, added a note regarding multiple 1523 clearinghouses to the Ad Hoc section, corrected grammar in Section 1524 7.5, reworded Section 7.3.7, corrected the year in a RIPE reference 1525 citation. Also incorporated general feedback from the Broadband 1526 Internet Technical Advisory Group. Per Jari Arkko, simplified the 1527 introduction to the Implications section, played down possible 1528 impacts on RFC 4213, added caveats to Section 8.3.2 on the utility of 1529 transition names, re-wrote Section 9. Updated the Abstract and 1530 Introduction, per errors noted by Tony Finch. Updated the Security 1531 Considerations based on feedback from Russ Mundy. Per Ray Hunter, 1532 added some text to the De-Whitelisting implications section regarding 1533 effects on networks of switching from IPv6 to IPv4. Updated 7.3.1 1534 per additional feedback from Karsten Fleischhauer. Per Dave Crocker, 1535 added a complete description of the practice to the Abstract, added a 1536 note to the Introduction that the operational impacts are 1537 particularly acute at scale, added text to Intro to make clear this 1538 practice affects all protocols and not just HTTP, added a new query/ 1539 response diagram, added text to the Abstract and Introduction noting 1540 that this is an IPv6 transition mechanism, and too many other changes 1541 to list. 1543 -03: Several changes suggested by Joel Jaeggli at the end of WGLC. 1544 This involved swapping the order of Section 6.1 and 6.2, among other 1545 changes to make the document more readable, understandable, and 1546 tonally balanced. As suggested by Karsten Fleischhauer, added a 1547 reference to RFC 4213 in Section 7.1, as well as other suggestions to 1548 that section. As suggested by Tina Tsou, made some changes to the 1549 DNSSEC section regarding signing. As suggested by Suresh Krishnan, 1550 made several changes to improve various sections of the document, 1551 such as adding an alternative concerning the use of ipv6.domain, 1552 improving the system logic section, and shortening the reference 1553 titles. As suggested by Thomas Narten, added some text regarding the 1554 imperfection of making judgements as to end user host impairments 1555 based upon the DNS recursive resolver's IP and/or network. Finally, 1556 made sure that variations in the use of 'records' and 'resource 1557 records' was updated to 'resource records' for uniformity and to 1558 avoid confusion. 1560 -02: Called for and closed out feedback on dnsop and v6ops mailing 1561 lists. Closed out open feedback items from IETF 79. Cleared I-D 1562 nits issues, added a section on whether or not this is recommended, 1563 made language less company-specific based on feedback from Martin 1564 Millnert, Wes George, and Victor Kuarsingh. Also mentioned World 1565 IPv6 Day per Wes George's suggestion. Added references to the ISOC 1566 World IPv6 Day and the Heise.de test at the suggestion of Jerry 1567 Huang, as well as an additional implication in 7.3.7. Made any 1568 speculation on IPv4 impairment noted explicitly as such, per feedback 1569 from Martin Millnert. Added a reference to DNS SRV in the load 1570 balancing section. Added various other references. Numerous changes 1571 suggested by John Brzozowski in several sections, to clean up the 1572 document. Moved up the section on why whitelisting is performed to 1573 make the document flow more logically. Added a note in the ad hoc 1574 deployment scenario explaining that a deployment may be temporary, 1575 and including more of the perceived benefits of this tactic. Added a 1576 Privacy Considerations section to address end-user detection and 1577 communication. 1579 -01: Incorporated feedback received from Brian Carpenter (from 10/19/ 1580 2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010). 1581 Also added an informative reference at the suggestion of Wes George 1582 (from from 10/22/2010). Closed out numerous editorial notes, and 1583 made a variety of other changes. 1585 -00: First version published as a v6ops WG draft. The preceding 1586 individual draft was 1587 draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE 1588 that no changes have been made yet based on WG and list feedback. 1589 These are in queue for a -01 update. 1591 Appendix B. Open Issues 1593 [RFC Editor: This section is to be removed before publication] 1595 Author's Address 1597 Jason Livingood 1598 Comcast Cable Communications 1599 One Comcast Center 1600 1701 John F. Kennedy Boulevard 1601 Philadelphia, PA 19103 1602 US 1604 Email: jason_livingood@cable.comcast.com 1605 URI: http://www.comcast.com