idnits 2.17.1 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.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 (February 22, 2011) is 4811 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 February 22, 2011 5 Expires: August 26, 2011 7 IPv6 AAAA DNS Whitelisting Implications 8 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 10 Abstract 12 The objective of this document is to describe what the whitelisting 13 of DNS AAAA resource records is, hereafter referred to as DNS 14 whitelisting, as well as the implications of this emerging practice 15 and what alternatives may exist. The audience for this document is 16 the Internet community generally, including the IETF and IPv6 17 implementers. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 26, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 6 55 2.1. Description of the Operation of DNS Whitelisting . . . . . 7 56 3. What Problems Are Implementers Trying To Solve? . . . . . . . 8 57 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 9 58 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 12 59 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 12 60 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 12 61 6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 13 62 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13 63 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 14 64 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15 65 7.1. Architectural Implications . . . . . . . . . . . . . . . . 15 66 7.2. Public IPv6 Address Reachability Implications . . . . . . 16 67 7.3. Operational Implications . . . . . . . . . . . . . . . . . 17 68 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 17 69 7.3.2. Authoritative DNS Server Operational Implications . . 17 70 7.3.3. DNS Recursive Resolver Server Operational 71 Implications . . . . . . . . . . . . . . . . . . . . . 18 72 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 19 73 7.3.5. Implications of Operational Momentum . . . . . . . . . 19 74 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 20 75 7.3.7. Additional Implications If Deployed On An Ad Hoc 76 Basis . . . . . . . . . . . . . . . . . . . . . . . . 20 77 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 20 78 7.5. Technology Policy Implications . . . . . . . . . . . . . . 21 79 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22 80 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 23 82 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 23 83 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 23 84 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 24 85 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 24 86 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 24 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 88 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 25 89 10.2. Authoritative DNS Response Consistency Considerations . . 26 90 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 92 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 96 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 97 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 31 98 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 32 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 1. Introduction 103 This document describes the emerging practice of whitelisting of DNS 104 AAAA resource records (RRs), which contain IPv6 addresses, hereafter 105 referred to as DNS whitelisting. The document explores the 106 implications of this emerging practice are and what alternatives may 107 exist. 109 The practice of DNS whitelisting appears to have first been used by 110 major web content sites (sometimes described herein as "highly- 111 trafficked domains" or "major domains"). These web site operators, 112 or domain operators, observed that when they added AAAA resource 113 records to their authoritative DNS servers in order to support IPv6 114 access to their content that a small fraction of end users had slow 115 or otherwise impaired access to a given web site with both AAAA and A 116 resource records. The fraction of users with such impaired access 117 has been estimated to be roughly 0.078% of total Internet users 118 [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 119 Brokenness]. Thus, in an example Internet Service Provider (ISP) 120 network of 10 million users, approximately 7,800 of those users may 121 experience such impaired access. 123 As a result of this impairment affecting end users of a given domain, 124 a few major domains have either implemented DNS whitelisting or are 125 considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations]. 126 When implemented, DNS whitelisting in practice means that a domain's 127 authoritative DNS will return a AAAA resource record to DNS recursive 128 resolvers [RFC1035] on the whitelist, while returning no AAAA 129 resource records to DNS resolvers which are not on the whitelist. It 130 is important to note that these major domains are motivated by a 131 desire to maintain a high-quality user experience for all of their 132 users. By engaging in DNS whitelisting, they are attempting to 133 shield users with impaired access from the symptoms of those 134 impairments. 136 Critics of the practice of DNS whitelisting have articulated several 137 concerns. Among these are that: 139 o DNS whitelisting is a very different behavior from the current 140 practice concerning the publishing of IPv4 address resource 141 records, 143 o that it may create a two-tiered Internet, 145 o that policies concerning whitelisting and de-whitelisting are 146 opaque, 148 o that DNS whitelisting reduces interest in the deployment of IPv6, 150 o that new operational and management burdens are created, 152 o and that the costs and negative implications of DNS whitelisting 153 outweigh the perceived benefits, compared to fixing underlying 154 impairments. 156 This document explores the reasons and motivations for DNS 157 whitelisting. It also explores the outlined concerns regarding this 158 practice. Readers will hopefully better understand what DNS 159 whitelisting is, why some parties are implementing it, and what 160 criticisms of the practice exist. 162 2. How DNS Whitelisting Works 164 DNS whitelisting is implemented in authoritative DNS servers. These 165 servers implement IP address-based restrictions on AAAA query 166 responses. So far, DNS whitelisting has been primarily implemented 167 by web server operators deploying IPv6-enabled services. For a given 168 operator of a website, such as www.example.com, the operator 169 essentially applies an access control list (ACL) on the authoritative 170 DNS servers for the domain example.com. The ACL is populated with 171 the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive 172 resolvers on the Internet, which have been authorized to receive AAAA 173 resource record responses. These DNS recursive resolvers are 174 operated by third parties, such as ISPs, universities, governments, 175 businesses, and individual end users. If a DNS recursive resolver IS 176 NOT matched in the ACL, then AAAA resource records will NOT be sent 177 in response to a query for a hostname in the example.com domain. 178 However, if a DNS recursive resolver IS matched in the ACL, then AAAA 179 resource records will be sent in response to a query for a given 180 hostname in the example.com domain. While these are not network- 181 layer access controls they are nonetheless access controls that are a 182 factor for end users and other parties like network operators, 183 especially as networks and hosts transition from one network address 184 family to another (IPv4 to IPv6). 186 In practice, DNS whitelisting generally means that a very small 187 fraction of the DNS recursive resolvers on the Internet (those in the 188 whitelist ACL) will receive AAAA responses. The large majority of 189 DNS resolvers on the Internet will therefore receive only A resource 190 records containing IPv4 addresses. Thus, quite simply, the 191 authoritative server hands out different answers depending upon who 192 is asking; with IPv4 and IPv6 resource records for some on the 193 authorized whitelist, and only IPv4 resource records for everyone 194 else. See Section 2.1 and Figure 1 for a description of how this 195 works. 197 Finally, DNS whitelisting can be deployed in two primary ways: 198 universally on a global basis, or on an ad hoc basis. Deployment on 199 a universal deployment basis means that DNS whitelisting is 200 implemented on all authoritative DNS servers, across the entire 201 Internet. In contrast, deployment on an ad hoc basis means that only 202 some authoritative DNS servers, and perhaps even only a few, 203 implement DNS whitelisting. These two potential deployment models 204 are described in Section 6. 206 2.1. Description of the Operation of DNS Whitelisting 208 The system logic of DNS whitelisting is as follows: 210 1. The authoritative DNS server for example.com receives DNS queries 211 for the A (IPv4) and AAAA (IPv6) address resource records for the 212 FQDN www.example.com, for which AAAA (IPv6) resource records 213 exist. 215 2. The authoritative DNS server examines the IP address of the DNS 216 recursive resolver sending the AAAA (IPv6) query. 218 3. The authoritative DNS server checks this IP address against the 219 access control list (ACL) that is the DNS whitelist. 221 4. If the DNS recursive resolver's IP address IS matched in the ACL, 222 then the response to that specific DNS recursive resolver can 223 contain AAAA (IPv6) address resource records. 225 5. If the DNS recursive resolver's IP address IS NOT matched in the 226 ACL, then the response to that specific DNS recursive resolver 227 cannot contain AAAA (IPv6) address resource records. In this 228 case, the server should return a response with the response code 229 (RCODE) being set to 0 (No Error) with an empty answer section 230 for the AAAA record query. 232 --------------------------------------------------------------------- 233 A query is sent from a DNS recursive resolver that IS NOT on the DNS 234 whitelist: 236 Request Request 237 www.example.com www.example.com 238 AAAA +-------------+ AAAA +-----------------+ 239 ++--++ ---------> | RESOLVER | ---------> | www.example.com | 240 || || A | **IS NOT** | A | IN A exists | 241 +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | 242 +--------+ A | example.com | A | | 243 Host <--------- | WHITELIST | <--------- | | 244 Computer A Record +-------------+ A Record +-----------------+ 245 Response DNS Recursive Response example.com 246 (only IPv4) Resolver (only IPv4) Authoritative 247 #1 Server 248 --------------------------------------------------------------------- 249 A query is sent from a DNS recursive resolver that IS on the DNS 250 whitelist: 252 Request Request 253 www.example.com www.example.com 254 AAAA +-------------+ AAAA +-----------------+ 255 ++--++ ---------> | RESOLVER | ---------> | www.example.com | 256 || || A | **IS** | A | IN A exists | 257 +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | 258 +--------+ AAAA | example.com | AAAA | | 259 Host <--------- | WHITELIST | <--------- | | 260 Computer A | | A | | 261 <--------- | | <--------- | | 262 A and AAAA +-------------+ A and AAAA +-----------------+ 263 Record DNS Recursive Record example.com 264 Responses Resolver Responses Authoritative 265 (IPv4+IPv6) #2 (IPv4+IPv6) Server 266 --------------------------------------------------------------------- 268 Figure 1: DNS Whitelisting - Functional Diagram 270 3. What Problems Are Implementers Trying To Solve? 272 As noted in Section 1, domains which implement DNS whitelisting are 273 attempting to protect a few users of their domain, who have impaired 274 IPv6 access, from having a negative experience (poor performance). 275 While it is outside the scope of this document to explore the various 276 reasons why a particular user's system (host) may have impaired IPv6 277 access, for the users who experience this impairment it is a very 278 real performance impact. It would affect access to all or most dual 279 stack services to which the user attempts to connect. This negative 280 end user experience can range from someone slower than usual (as 281 compared to native IPv4-based access), to extremely slow, to no 282 access to the domain whatsoever. 284 While one can debate whether DNS whitelisting is the optimal solution 285 to the end user experience problem, it is quite clear that DNS 286 whitelisting implementers are interested in maximizing the 287 performance of their services for end users as a primary motivation 288 for implementation. 290 At least one highly-trafficked domain has noted that they have 291 received requests to not send DNS responses with AAAA resource 292 records to particular resolvers. In this case, the operators of 293 those recursive resolvers have expressed a concern that their IPv6 294 network infrastructure is not yet ready to handle the large traffic 295 volume which may be associated with the hosts in their network 296 connecting to the websites of these domains. This concern is clearly 297 a temporary consideration relating to the deployment of IPv6 network 298 infrastructure on the part of networks with end user hosts, rather 299 than a long-term concern. These end user networks may also have 300 other tools at their disposal in order to address this concern, 301 including applying rules to network equipment such as routers and 302 firewalls (this will necessarily vary by the type of network, as well 303 as the technologies used and the design of a given network), as well 304 as configuration of their recursive resolvers (though modifying or 305 suppressing AAAA resource records in a DNSSEC-signed domain on a 306 Security-Aware Resolver will be problematic Section 10.1). 308 Some implementers with highly-trafficked domains have explained that 309 DNS whitelisting is a necessary, though temporary, risk reduction 310 tactic intended to ease their transition to IPv6 and minimize any 311 perceived risk in such a transition. As a result, they perceive this 312 as a tactic to enable them to incrementally enable IPv6 connectivity 313 to their domains during the early phases of their transition to IPv6. 315 Finally, some domains, have run IPv6 experiments whereby they added 316 AAAA resource records and observed and measured errors [Heise Online 317 Experiment], which should be important reading for any domain 318 contemplating either the use of DNS whitelisting or simply adding 319 IPv6 addressing to their site. 321 4. Concerns Regarding DNS Whitelisting 323 There are a number of potential implications relating to DNS 324 whitelisting, which have been raised as concerns by some parts of the 325 Internet community. Many of those potential implications are further 326 enumerated here and in Section 7. 328 Some parties in the Internet community, including ISPs, are concerned 329 that the practice of DNS whitelisting for IPv6 address resource 330 records represents a departure from the generally accepted practices 331 regarding IPv4 address resource records in the DNS on the Internet 332 [Whitelisting Concerns]. These parties explain their belief that for 333 A resource records, containing IPv4 addresses, once an authoritative 334 server operator adds the A record to the DNS, then any DNS recursive 335 resolver on the Internet can receive that A record in response to a 336 query. By extension, this means that any of the hosts connected to 337 any of these DNS recursive resolvers can receive the IPv4 address 338 resource records for a given FQDN. This enables new server hosts 339 which are connected to the Internet, and for which a fully qualified 340 domain name (FQDN) such as www.example.com has been added to the DNS 341 with an IPv4 address record, to be almost immediately reachable by 342 any host on the Internet. In this case, these new servers hosts 343 become more and more widely accessible as new networks and new end 344 user hosts connect to the Internet over time, capitalizing on and 345 increasing so-called "network effects" (also called network 346 externalities). It also means that the new server hosts do not need 347 to know about these new networks and new end user hosts in order to 348 make their content and applications available to them, in essence 349 that each end in this end-to-end model is responsible for connecting 350 to the Internet and once they have done so they can connect to each 351 other without additional impediments or middle networks or 352 intervening networks or servers knowing about these end points and 353 whether one is allowed to contact the other. 355 In contrast, the concern is that DNS whitelisting may fundamentally 356 change this model. In the altered DNS whitelisting end-to-end model, 357 one end (where the end user is located) cannot readily connect to the 358 other end (where the content is located), without parts of the middle 359 (recursive resolvers) used by one end (the client, or end user hosts) 360 being known to an intermediary (authoritative nameservers) and 361 approved for access to the resource at the end. As new networks 362 connect to the Internet over time, those networks need to contact any 363 and all domains which have implemented DNS whitelisting in order to 364 apply to be added to their DNS whitelist, in the hopes of making the 365 content and applications residing on named server hosts in those 366 domains accessible by the end user hosts on that new network. 367 Furthermore, this same need to contact all domains implementing DNS 368 whitelisting also applies to all pre-existing (but not whitelisted) 369 networks connected to the Internet. 371 In the current IPv4 Internet when a new server host is added to the 372 Internet it is generally widely available to all end user hosts and 373 networks, when DNS whitelisting of IPv6 resource records is used, 374 these new server hosts are not accessible to any end user hosts or 375 networks until such time as the operator of the authoritative DNS 376 servers for those new server hosts expressly authorizes access to 377 those new server hosts by adding DNS recursive resolvers around the 378 Internet to the ACL. This has the potential to be a significant 379 change in reachability of content and applications by end users and 380 networks as these end user hosts and networks transition to IPv6, 381 resulting in more (but different) breakage. A concern expressed is 382 that if much of the content that end users are most interested in is 383 not accessible as a result, then end users and/or networks may resist 384 adoption of IPv6 or actively seek alternatives to it, such as using 385 multi-layer network address translation (NAT) techniques like NAT444 386 [I-D.shirasaki-nat444] on a long-term basis. There is also concern 387 that this practice also could disrupt the continued increase in 388 Internet adoption by end users if they cannot simply access new 389 content and applications but must instead contact the operator of 390 their DNS recursive resolver, such as their ISP or another third 391 party, to have their DNS recursive resolver authorized for access to 392 the content or applications that interests them. Meanwhile, these 393 parties say, over 99.9% of the other end users that are also using 394 that same network or DNS recursive resolver are unable to access the 395 IPv6-based content, despite their experience being a positive one. 397 While in Section 1 the level of IPv6-related impairment has been 398 estimated to be as high as 0.078% of Internet users, which is a 399 primary motivation cited for the practice of DNS whitelisting, it is 400 not clear if the level of IPv4-related impairment is more or less 401 that this percentage (which in any case is likely to have declined 402 since its original citation). Indeed, as at least one document 403 reviewer has pointed out, it may simply be that websites are only 404 measuring IPv6 impairments and not IPv4 impairments, whether because 405 IPv6 is new or whether those websites are simply unable to or are 406 otherwise not in a position to be able to measure IPv4 impairment 407 (since this could result in no Internet access whatsoever). As a 408 result, it is worth considering that IPv4-related impairment could 409 exceed that of IPv6-related impairment and that such IPv4-related 410 impairment may have simply been accepted as "background noise" on the 411 Internet for a variety of reasons. Of course, this comparison of the 412 level of worldwide IPv6 impairments to IPv4 impairments is 413 speculation, as the author is not aware of any good measurement of 414 IPv4-related impairments which are comparable in nature to the IPv6- 415 related impairment measurements which have recently been conducted 416 around the world. 418 An additional concern is that the IP address of a recursive resolver 419 is not a precise indicator of the IPv6 preparedness, or lack of IPv6- 420 related impairments, of end user hosts which query (use) a particular 421 recursive resolver. While the recursive resolver may be an imperfect 422 proxy for judging IPv6 preparedness, it is at least one of the best 423 available methods at the current time. 425 5. Similarities to Other DNS Operations 427 Some aspects of DNS whitelisting may be considered similar to other 428 common DNS operational techniques which are explored below. 430 5.1. Similarities to Split DNS 432 DNS whitelisting has some similarities to so-called split DNS, 433 briefly described in Section 3.8 of [RFC2775]. When split DNS is 434 used, the authoritative DNS server returns different responses 435 depending upon what host has sent the query. While [RFC2775] notes 436 the typical use of split DNS is to provide one answer to hosts on an 437 Intranet and a different answer to hosts on the Internet, the essence 438 is that different answers are provided to hosts on different 439 networks. This is basically the way that DNS whitelisting works, 440 whereby hosts on different networks, which use different DNS 441 recursive resolvers, receive different answers if one DNS recursive 442 resolver is on the whitelist and the other is not. 444 In [RFC2956], Internet transparency and Internet fragmentation 445 concerns regarding split DNS are detailed in Section 2.1. [RFC2956] 446 further notes in Section 2.7, concerns regarding split DNS and that 447 it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint 448 identifiers more complex." Section 3.5 of [RFC2956] further 449 recommends that maintaining a stable approach to DNS operations is 450 key during transitions such as the one to IPv6 that is underway now, 451 stating that "Operational stability of DNS is paramount, especially 452 during a transition of the network layer, and both IPv6 and some 453 network address translation techniques place a heavier burden on 454 DNS." 456 5.2. Similarities to DNS Load Balancing 458 DNS whitelisting also has some similarities to DNS load balancing. 459 There are of course many ways that DNS load balancing can be 460 performed. In one example, multiple IP address resource records (A 461 and/or AAAA) can be added to the DNS for a given FQDN. This approach 462 is referred to as DNS round robin [RFC1794]. DNS round robin may 463 also be employed where SRV resource records are used [RFC2782]. 465 In another example, one or more of the IP address resource records in 466 the DNS will direct traffic to a load balancer. That load balancer, 467 in turn, may be application-aware, and pass the traffic on to one or 468 more hosts connected to the load balancer which have different IP 469 addresses. In cases where private IPv4 addresses are used [RFC1918], 470 as well as when public IP addresses are used, those end hosts may not 471 be directly reachable without passing through the load balancer first 472 . As such, while the IP address resource records have been added to 473 the DNS, the end hosts are not necessarily directly reachable, which 474 is in a small way similar to one aspect of DNS whitelisting. 476 Additionally, a geographically-aware authoritative DNS server may be 477 used, as is common with Content Delivery Networks (CDNs) or Global 478 Load Balancing (GLB, also referred to as Global Server Load 479 Balancing, or GSLB), whereby the IP address resource records returned 480 to a resolver in response to a query will vary based on the estimated 481 geographic location of the resolver [Resolvers in the Wild]. CDNs 482 perform this function in order to attempt to direct hosts to connect 483 to the nearest content cache. As a result, one can see some 484 similarities with DNS whitelisting insofar as different IP address 485 resource records are selectively returned to resolvers based on the 486 IP address of each resolver (or other imputed factors related to that 487 IP address). However, what is different is that in this case the 488 resolvers are not deliberately blocked from receiving DNS responses 489 containing an entire class of addresses; this load balancing function 490 strives to perform a content location-improvement function and not an 491 access control function. 493 6. Likely Deployment Scenarios 495 In considering how DNS whitelisting may emerge more widely, there are 496 two likely deployment scenarios, which are explored below. 498 In either of these deployment scenarios, it is possible that 499 reputable third parties could create and maintain DNS whitelists, in 500 much the same way that blacklists are used for reducing email spam. 501 In the email context, a mail operator subscribes to one or more of 502 these lists and as such the operational processes for additions and 503 deletions to the list are managed by a third party. A similar model 504 could emerge for DNS whitelisting, whether deployment occurs 505 universally or on an ad hoc basis. 507 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis 509 The seemingly most likely deployment scenario is where some 510 authoritative DNS server operators implement DNS whitelisting but 511 many or most others do not do so. What can make this scenario 512 challenging from the standpoint of a DNS recursive resolver operator 513 is determining which domains implement DNS whitelisting, particularly 514 since a domain may not do so as they initially transition to IPv6, 515 and may instead do so later. Thus, a DNS recursive resolver operator 516 may initially believe that they can receive AAAA responses as a 517 domain adopts IPv6, but then notice via end user reports that they no 518 longer receive AAAA responses due to that domain adopting DNS 519 whitelisting. Of course, a domain's IPv6 transition may be 520 effectively invisible to recursive server operators due to the effect 521 of DNS whitelisting. 523 In contrast to a universal deployment of DNS whitelisting 524 Section 6.2, deployment on an ad hoc basis is likely to be 525 significantly more challenging from an operational, monitoring, and 526 troubleshooting standpoint. In this scenario, a DNS recursive 527 resolver operator will have no way to systematically determine 528 whether DNS whitelisting is or is not implemented for a domain, since 529 the absence of AAAA resource records may simply be indicative that 530 the domain has not yet added IPv6 addressing for the domain, rather 531 than that they have done so but have restricted query access via DNS 532 whitelisting. As a result, discovering which domains implement DNS 533 whitelisting, in order to differentiate them from those that do not, 534 is likely to be challenging. 536 One benefit of DNS whitelisting being deployed on an ad hoc basis is 537 that only the domains that are interested in doing so would have to 538 upgrade their authoritative DNS servers in order to implement the 539 ACLs necessary to perform DNS whitelisting. 541 In this potential deployment scenario, it is also possible that a 542 given domain will implement DNS whitelisting temporarily. A domain, 543 particularly a highly-trafficked domain, may choose to do so in order 544 to ease their transition to IPv6 through a selective deployment and 545 minimize any perceived risk in such a transition. 547 6.2. Deploying DNS Whitelisting Universally 549 The least likely deployment scenario is one where DNS whitelisting is 550 implemented on all authoritative DNS servers, across the entire 551 Internet. While this scenario seems less likely than ad hoc 552 deployment due to some parties not sharing the concerns that have so 553 far motivated the use of DNS whitelisting, it is nonetheless 554 conceivable that it could be one of the ways in which DNS 555 whitelisting is deployed. 557 In order for this deployment scenario to occur, it is likely that DNS 558 whitelisting functionality would need to be built into all 559 authoritative DNS server software, and that all operators of 560 authoritative DNS servers would have to upgrade their software and 561 enable this functionality. It is likely that new Internet Draft 562 documents would need to be developed which describe how to properly 563 configure, deploy, and maintain DNS whitelisting. As a result, it is 564 unlikely that DNS whitelisting would, at least in the next several 565 years, become universally deployed. Furthermore, these DNS 566 whitelists are likely to vary on a domain-by-domain basis, depending 567 upon a variety of factors. Such factors may include the motivation 568 of each domain owner, the location of the DNS recursive resolvers in 569 relation to the source content, as well as various other parameters 570 that may be transitory in nature, or unique to a specific end user 571 host type. It is probably unlikely that a single clearinghouse for 572 managing whitelisting is possible; it will more likely be unique to 573 the source content owners and/or domains which implement DNS 574 whitelists. 576 While this scenario may be unlikely, it may carry some benefits. 577 First, parties performing troubleshooting would not have to determine 578 whether or not DNS whitelisting was being used, as it always would be 579 in use. In addition, if universally deployed, it is possible that 580 the criteria for being added to or removed from a DNS whitelist could 581 be standardized across the entire Internet. Nevertheless, even if 582 uniform DNS whitelisting policies were not standardized, is also 583 possible that a central registry of these policies could be developed 584 and deployed in order to make it easier to discover them, a key part 585 of achieving transparency regarding DNS whitelisting. 587 7. Implications of DNS Whitelisting 589 There are many potential implications of DNS whitelisting. The key 590 potential implications are detailed below. 592 7.1. Architectural Implications 594 DNS whitelisting could be perceived as modifying the end-to-end model 595 and/or the general notion of the architecture that prevails on the 596 Internet today. This is because this approach moves additional 597 access control information and policies into the middle of the DNS 598 resolution path of the IPv6-addressed Internet, which generally did 599 not exist before on the IPv4-addressed Internet. This poses some 600 risks noted in [RFC3724]. In explaining the history of the end-to- 601 end principle [RFC1958] states that one of the goals is to minimize 602 the state, policies, and other functions needed in the middle of the 603 network in order to enable end-to-end communications on the Internet. 604 In this case, the middle network should be understood to mean 605 anything other than the end hosts involved in communicating with one 606 another. Some state, policies, and other functions have always been 607 necessary to enable such end-to-end communication, but the goal of 608 the approach has been to minimize this to the greatest extent 609 possible. 611 It is also possible that DNS whitelisting could place at risk some of 612 the observed benefits of the end-to-end principle, as listed in 613 Section 4.1 of [RFC3724], such as protection of innovation. 614 [RFC3234] details issues and concerns regarding so-called 615 middleboxes, so there may also be parallel concerns with the DNS 616 whitelisting approach, especially concerning modified DNS servers 617 noted in Section 2.16 of [RFC3234], as well as more general concerns 618 noted in Section 1.2 of [RFC3234] about the introduction of new 619 failure modes. In particular, there may be concerns that 620 configuration is no longer limited to two ends of a session, and that 621 diagnosis of failures and misconfigurations becomes more complex. 623 Two additional sources worth considering as far as implications for 624 the end-to-end model are concerned are [Tussle in Cyberspace] and 625 [Rethinking the Internet]. In [Tussle in Cyberspace], the authors 626 note concerns regarding the introduction of new control points, as 627 well as "kludges" to the DNS, as risks to the goal of network 628 transparency in the end-to-end model. Some parties concerned with 629 the emerging use of DNS whitelisting have shared similar concerns, 630 which may make [Tussle in Cyberspace] an interesting and relevant 631 document. In addition, [Rethinking the Internet] reviews similar 632 issues that may be of interest to readers of this document. 634 Also, it is possible that DNS whitelisting could affect some of the 635 architectural assumptions which underlie parts of Section 2 of 636 [RFC4213] which outlines the dual stack approach to the IPv6 637 transition. DNS whitelisting could modify the behavior of the DNS, 638 as described in Section 2.2 of [RFC4213] and could require different 639 sets of DNS servers to be used for hosts that are (using terms from 640 that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes. 641 As such, broad use of DNS whitelisting may necessitate the review 642 and/or revision of standards documents which describe dual-stack and 643 IPv6 operating modes, dual-stack architecture generally, and IPv6 644 transition methods, including but not limited to [RFC4213]. 646 7.2. Public IPv6 Address Reachability Implications 648 The predominant experience of end user hosts and servers on the IPv4- 649 addressed Internet today is that when a new server with a public IPv4 650 address is added to the DNS, that it is then globally accessible by 651 IPv4-addressed hosts. This is a generalization and in Section 5 652 there are examples of common cases where this may not necessarily be 653 the case. For the purposes of this argument, that concept of 654 accessibility can be considered "pervasive reachability". It has so 655 far been assumed that the same expectations of pervasive reachability 656 would exist in the IPv6-addressed Internet. However, if DNS 657 whitelisting is deployed, this will not be the case since only end 658 user hosts using DNS recursive resolvers which are included in the 659 ACL of a given domain using DNS whitelisting would be able to reach 660 new servers in that given domain via IPv6 addresses. The expectation 661 of any end user host being able to connect to any server (essentially 662 both hosts, just at either end of the network), defined here as 663 "pervasive reachability", will change to "restricted reachability" 664 with IPv6. 666 Establishing DNS whitelisting as an accepted practice in the early 667 phases of mass IPv6 deployment could well establish it as an integral 668 part of how IPv6 DNS resource records are deployed globally. As a 669 result, it is then possible that DNS whitelisting could live on for 670 decades on the Internet as a key foundational element of domain name 671 management that we will all live with for a long time. 673 It is a critical to understand that the concept of reachability 674 described above depends upon a knowledge or awareness of an address 675 in the DNS. Thus, in order to establish reachability to an end 676 point, a host is dependent upon looking up an IP address in the DNS 677 when a FQDN is used. When DNS whitelisting is used, it is quite 678 likely the case that an IPv6-enabled end user host could ping or 679 connect to an example server host, even though the FQDN associated 680 with that server host is restricted via a DNS whitelist. Since most 681 Internet applications and hosts such as web servers depend upon the 682 DNS, and as end users connect to FQDNs such as www.example.com and do 683 not remember or wish to type in an IP address, the notion of 684 reachability described here should be understood to include knowledge 685 how to associate a name with a network address. 687 7.3. Operational Implications 689 This section explores some of the operational implications which may 690 occur as a result of, are related to, or become necessary when 691 engaging in the practice of DNS whitelisting. 693 7.3.1. De-Whitelisting May Occur 695 It is possible for a DNS recursive resolver added to a whitelist to 696 then be removed from the whitelist, also known as de-whitelisting. 697 Since de-whitelisting can occur, through a decision by the 698 authoritative server operator, the domain owner, or even due to a 699 technical error, an operator of a DNS recursive resolver will have 700 new operational and monitoring requirements and/or needs as noted in 701 Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. 703 7.3.2. Authoritative DNS Server Operational Implications 705 Operators of authoritative servers may need to maintain an ACL a 706 server-wide basis affecting all domains, on a domain-by-domain basis, 707 as well as on a combination of the two. As a result, operational 708 practices and software capabilities may need to be developed in order 709 to support such functionality. In addition, processes may need to be 710 put in place to protect against inadvertently adding or removing IP 711 addresses, as well as systems and/or processes to respond to such 712 incidents if and when they occur. For example, a system may be 713 needed to record DNS whitelisting requests, report on their status 714 along a workflow, add IP addresses when whitelisting has been 715 approved, remove IP addresses when they have been de-whitelisted, log 716 the personnel involved and timing of changes, schedule changes to 717 occur in the future, and to roll back any inadvertent changes. 719 Operators may also need implement new forms of monitoring in order to 720 apply change control, as noted briefly in Section 7.3.4. 722 7.3.3. DNS Recursive Resolver Server Operational Implications 724 Operators of DNS recursive resolvers, which may include ISPs, 725 enterprises, universities, governments, individual end users, and 726 many other parties, are likely to need to implement new forms of 727 monitoring, as noted briefly in Section 7.3.4. But more critically, 728 such operators may need to add people, processes, and systems in 729 order to manage large numbers of DNS whitelisting applications as 730 part of their own IPv6 transition, for all domains that the end users 731 of such servers are interested in now or in which they may be 732 interested in the future. As anticipation of interesting domains is 733 likely infeasible, it is more likely that operators may either choose 734 to only apply to be whitelisted for a domain based upon one or more 735 end user requests, or that they will attempt to do so for all domains 736 that they can ascertain to be engaging in DNS whitelisting. 738 When operators apply for DNS whitelisting for all domains, that may 739 mean doing so for all registered domains. Thus, some system would 740 have to be developed to discover whether each domain has been 741 whitelisted or not, which is touched on in Section 6 and may vary 742 depending upon whether DNS whitelisting is universally deployed or is 743 deployed on an ad hoc basis. 745 These operators (of recursive resolvers) will need to develop 746 processes and systems to track the status of all DNS whitelisting 747 applications, respond to requests for additional information related 748 to these applications, determine when and if applications have been 749 denied, manage appeals, and track any de-whitelisting actions. 751 Given the large number of domains in existence, the ease with which a 752 new domain can be added, and the continued strong growth in the 753 numbers of new domains, readers should not underestimate the 754 potential significance in personnel and expense that this could 755 represent for such operators. In addition, it is likely that systems 756 and personnel may also be needed to handle new end user requests for 757 domains for which to apply for DNS whitelisting, and/or inquiries 758 into the status of a whitelisting application, reports of de- 759 whitelisting incidents, general inquiries related to DNS 760 whitelisting, and requests for DNS whitelisting-related 761 troubleshooting by these end users. 763 7.3.4. Monitoring Implications 765 Once a DNS recursive resolver has been whitelisted for a particular 766 domain, then the operator of that DNS recursive resolver may need to 767 implement monitoring in order to detect the possible loss of 768 whitelisting status in the future. This DNS recursive resolver 769 operator could configure a monitor to check for a AAAA response in 770 the whitelisted domain, as a check to validate continued status on 771 the DNS whitelist. The monitor could then trigger an alert if at 772 some point the AAAA responses were no longer received, so that 773 operations personnel could begin troubleshooting, as outlined in 774 Section 7.3.6. 776 Also, authoritative DNS server operators are likely to need to 777 implement new forms of monitoring. In this case, they may desire to 778 monitor for significant changes in the size of the whitelist within a 779 certain period of time, which might be indicative of a technical 780 error such as the entire ACL being removed. Authoritative nameserver 781 operators may also wish to monitor their workflow process for 782 reviewing and acting upon DNS whitelisting applications and appeals, 783 potentially measuring and reporting on service level commitments 784 regarding the time an application or appeal can remain at each step 785 of the process, regardless of whether or not such information is 786 shared with parties other than that authoritative DNS server 787 operator. 789 7.3.5. Implications of Operational Momentum 791 It seems plausible that once DNS whitelisting is implemented it will 792 be very difficult to deprecate such technical and operational 793 practices. This assumption is based in an understanding of human 794 nature, not to mention physics. For example, as Sir Issac Newton 795 noted, "Every object in a state of uniform motion tends to remain in 796 that state of motion unless an external force is applied to it" [Laws 797 of Motion]. Thus, once DNS whitelisting is implemented it is quite 798 likely that it would take considerable effort to deprecate the 799 practice and remove it everywhere on the Internet - it will otherwise 800 simply remain in place in perpetuity. To better illustrate this 801 point, one could consider one example (of many) that there are many 802 email servers continuing to attempt to query or otherwise check anti- 803 spam DNS blocklists which have long ago ceased to exist. 805 7.3.6. Troubleshooting Implications 807 The implications of DNS whitelisted present many challenges, which 808 have been detailed in Section 7. These challenges may negatively 809 affect the end users' ability to troubleshoot, as well as that of DNS 810 recursive resolver operators, ISPs, content providers, domain owners 811 (where they may be different from the operator of the authoritative 812 DNS server for their domain), and other third parties. This may make 813 the process of determining why a server is not reachable 814 significantly more complex. 816 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis 818 Additional implications, should this be deployed on an ad hoc basis, 819 could include scalability problems relating to operational processes, 820 monitoring, and ACL updates. In particular, it seems likely that as 821 the number of domains that are using DNS whitelisting increases, as 822 well as the number of IPv6-capable networks requesting to be 823 whitelisted, that there is an increased likelihood of configuration 824 and other operational errors, especially with respect to the ACLs 825 themselves. 827 It is unclear when and if it would be appropriate to change from 828 whitelisting to blacklisting, and whether or how this could feasibly 829 be coordinated across the Internet, which may be proposed or 830 implemented on an ad hoc basis when a majority of networks (or 831 allocated IPv6 address blocks) have been whitelisted. Finally, some 832 parties implementing DNS whitelisting consider this to be a temporary 833 measure. As such, it is not clear how these parties will judge the 834 network conditions to have changed sufficiently to justify disabling 835 DNS whitelisting and/or what the process and timing will be in order 836 to discontinue this practice. 838 One further potential implication is that an end user with only an 839 IPv4 address, using a DNS resolver which has not been whitelisted by 840 any domains, would not be able to get any AAAA resource records. In 841 such a case, this could give that end user the incorrect impression 842 that there is no IPv6-based content on the Internet since they are 843 unable to discover any IPv6 addresses via the DNS. 845 7.4. Homogeneity May Be Encouraged 847 A broad trend which has existed on the Internet appears to be a move 848 towards increasing levels of heterogeneity. One manifestation of 849 this is in an increasing number, variety, and customization of end 850 user hosts, including home network, operating systems, client 851 software, home network devices, and personal computing devices. This 852 trend appears to have had a positive effect on the development and 853 growth of the Internet. A key facet of this that has evolved is the 854 ability of the end user to connect any technically compliant device 855 or use any technically compatible software to connect to the 856 Internet. Not only does this trend towards greater heterogeneity 857 reduce the control which is exerted in the middle of the network, 858 described in positive terms in [Tussle in Cyberspace], [Rethinking 859 the Internet], and [RFC3724], but it can also help to enable greater 860 and more rapid innovation at the edges. 862 An unfortunate implication of the adoption of DNS whitelisting may be 863 the encouragement of a reversal of this trend, which would be a move 864 back towards greater levels of homogeneity. In this case, a domain 865 owner which has implemented DNS whitelisting may prefer greater 866 levels of control be exerted over end user hosts (which broadly 867 includes all types of end user software and hardware) in order to 868 attempt to enforce technical standards relating to establishing 869 certain IPv6 capabilities or the enforcing the elimination of or 870 restriction of certain end user hosts. While the domain operator is 871 attempting to protect, maintain, and/or optimize the end user 872 experience for their domain, the collective result of many domains 873 implementing DNS whitelisting, or even a few major domains (meaning 874 domains which are a major destination of Internet traffic) 875 implementing DNS whitelisting, may be to encourage a return to more 876 homogenous and/or controlled end user hosts. This could have 877 unintended side effects on and counter-productive implications for 878 future innovation at the edges of the network. 880 7.5. Technology Policy Implications 882 A key technology policy implication concerns the policies relating to 883 the process of reviewing an application for DNS whitelisting, and the 884 decision-making process regarding whitelisting for a domain. 885 Important questions may include whether these policies have been 886 fully and transparently disclosed, are non-discriminatory, and are 887 not anti-competitive. A related implication is whether and what the 888 process for appeals is, when a domain decides not to add a DNS 889 recursive resolver to the whitelist. Key questions here may include 890 whether appeals are allowed, what the process is, what the expected 891 turn around time is, and whether the appeal will be handled by an 892 independent third party or other entity/group. 894 A further implications arises when de-whitelisting occurs. Questions 895 that may naturally be raised in such a case include whether the 896 criteria for de-whitelisting have been fully and transparently 897 disclosed, are non-discriminatory, and are not anti-competitive. 898 Additionally, the question of whether or not there was a cure period 899 available prior to de-whitelisting, during which troubleshooting 900 activities, complaint response work, and corrective actions may be 901 attempted, and whether this cure period was a reasonable amount of 902 time. 904 It is also conceivable that whitelisting and de-whitelisting 905 decisions could be quite sensitive to concerned parties beyond the 906 operator of the domain which has implemented DNS whitelisting and the 907 operator of the DNS recursive resolver, including end users, 908 application developers, content providers, advertisers, public policy 909 groups, governments, and other entities, which may also seek to 910 become involved in or express opinions concerning whitelisting and/or 911 de-whitelisting decisions. Lastly, it is conceivable that any of 912 these interested parties or other related stakeholders may seek 913 redress outside of the process a domain has establishing for DNS 914 whitelisting and de-whitelisting. 916 A final concern is that decisions relating to whitelisting and de- 917 whitelisting may occur as an expression of other commercial, 918 governmental, and/or cultural conflicts, given the new control point 919 which has be established with DNS whitelisting. For example, in one 920 imagined scenario, a domain could withhold adding a network to their 921 DNS whitelisting unless that network agreed to some sort of financial 922 payment, legal agreement, agreement to sever a relationship with a 923 competitor of the domain, etc. In another example, a music-oriented 924 domain may be engaged in some sort of dispute with an academic 925 network concerning copyright infringement concerns within that 926 network, and may choose to de-whitelist that network as a negotiating 927 technique in some sort of commercial discussion. In a final example, 928 a major email domain may choose to de-whitelist a network due to that 929 network sending some large volume of spam, which would have the 930 effect of preventing other, end users on that network from using 931 other, non-email-related applications within that domain. Thus, it 932 seems possible that DNS whitelisting and de-whitelisting could become 933 a vehicle for adjudicating other disputes, and that this may well 934 have intended and unintended consequences for end users which are 935 affected by such decisions and are unlikely to be able to express a 936 strong voice in such decisions. 938 7.6. IPv6 Adoption Implications 940 As noted in Section 4, the implications of DNS whitelisting may drive 941 end users and/or networks to delay, postpone, or cancel adoption of 942 IPv6, or to actively seek alternatives to it. Such alternatives may 943 include the use of multi-layer network address translation (NAT) 944 techniques like NAT444 [I-D.shirasaki-nat444], which these parties 945 may decide to pursue on a long-term basis to avoid the perceived 946 costs and aggravations related to DNS whitelisting. This could of 947 course come at the very time that the Internet community is trying to 948 get these very same parties interested in IPv6 and motivated to begin 949 the transition to IPv6. As a result, parties that are likely to be 950 concerned over the negative implications of DNS whitelisting could 951 logically be concerned of the negative effects that this practice 952 could have on the adoption of IPv6 if it became widespread or was 953 adopted by majors Internet domains or other major parties in the 954 Internet ecosystem. 956 At the same time, as noted in Section 3, some highly-trafficked 957 domains may find the prospect of transitioning to IPv6 daunting 958 without having some short-term ability to incrementally control the 959 amount and source of IPv6 traffic to their domains. 961 8. Solutions 963 This section outlines several possible solutions when considering DNS 964 whitelisting and associated IPv6-related issues. 966 8.1. Implement DNS Whitelisting Universally 968 One obvious solution is to implement DNS whitelisted universally, and 969 to do so using some sort of centralized registry of DNS whitelisting 970 policies, contracts, processes, or other information. This potential 971 solution seems unlikely at the current time. 973 8.2. Implement DNS Whitelisting On An Ad Hoc Basis 975 If DNS whitelisting is to be adopted, it is likely to be adopted on 976 this ad hoc, or domain-by-domain basis. Therefore, only those 977 domains interested in DNS whitelisting would need to adopt the 978 practice, though as noted herein discovering that they a given domain 979 has done so may be problematic. Also in this scenario, ad hoc use by 980 a particular domain may be a temporary measure that has been adopted 981 to ease the transition of the domain to IPv6 over some short-term 982 timeframe. 984 8.3. Do Not Implement DNS Whitelisting 986 As an alternative to adopting DNS whitelisting, the Internet 987 community generally can choose to take no action whatsoever, 988 perpetuating the current predominant authoritative DNS operational 989 model on the Internet, and leave it up to end users with IPv6-related 990 impairments to discover and fix those impairments. 992 8.3.1. Solving Current End User IPv6 Impairments 994 A further extension of not implementing DNS whitelisting, is to also 995 endeavor to actually fix the underlying technical problems that have 996 prompted the consideration of DNS whitelisting in the first place, as 997 an alternative to trying to apply temporary workarounds to avoid the 998 symptoms of underlying end user IPv6 impairments. A first step is 999 obviously to identify which users have such impairments, which would 1000 appear to be possible, and then to communicate this information to 1001 end users. Such end user communication is likely to be most helpful 1002 if the end user is not only alerted to a potential problem but is 1003 given careful and detailed advice on how to resolve this on their 1004 own, or where they can seek help in doing so. Section 11 may also be 1005 relevant in this case. 1007 One challenge with this option is the potential difficulty of 1008 motivating members of the Internet community to work collectively 1009 towards this goal, sharing the labor, time, and costs related to such 1010 an effort. Of course, since just such a community effort is now 1011 underway for IPv6, it is possible that this would call for only a 1012 moderate amount of additional work. 1014 Despite any potential challenges, many in the Internet community are 1015 already working towards this goal and/or have expressed a general 1016 preference for this approach. 1018 8.3.2. Gain Experience Using IPv6 Transition Names 1020 Another alternative is for domains to gain experience using an FQDN 1021 which has become common for domains beginning the transition to IPv6; 1022 ipv6.example.com and www.ipv6.example.com. This can be a way for a 1023 domain to gain IPv6 experience and increase IPv6 use on a relatively 1024 controlled basis, and to inform any plans for DNS whitelisting with 1025 experience. 1027 9. Is DNS Whitelisting a Recommended Practice? 1029 Opinions in the Internet community concerning whether or not DNS 1030 whitelisting is a recommended practice are understandably quite 1031 varied. However, there is clear consensus that DNS whitelisting is 1032 at best a useful temporary measure which a domain may choose to 1033 pursue as they prepare for the transition to IPv6. In particular, 1034 some major domains view DNS whitelisting as one of the few practical 1035 and low risk approaches enabling them to prepare for the transition 1036 to IPv6. Thus, DNS whitelisting is not a recommended practice over 1037 the long-term. In addition, DNS whitelisting should be avoided 1038 wherever possible in the short-term and its use is generally 1039 discouraged. Nevertheless, major domains may find DNS whitelisting a 1040 beneficial temporary tactic in their transition to IPv6. Such 1041 temporary use during the transition to IPv6 is broadly accepted 1042 within the community, so long as it does not become a long-term 1043 practice. 1045 World IPv6 Day, sponsored by the Internet Society [World IPv6 Day], 1046 is scheduled to occur on June 8, 2011. This will be an opportunity 1047 for domains to add AAAA resource records to the DNS without using DNS 1048 whitelisting. As a result, this is likely an excellent opportunity 1049 for domains to evaluate the utility or necessity of DNS whitelisting, 1050 even in the short-term. A major German news website, Heise Online, 1051 also ran a similar IPv6 experiment whereby they added AAAA resource 1052 records and observed and measured any errors [Heise Online 1053 Experiment], which is important reading for any domain contemplating 1054 either the use of DNS whitelisting or simply adding IPv6 addressing 1055 to their site. 1057 10. Security Considerations 1059 There are no particular security considerations if DNS whitelisting 1060 is not adopted, as this is how the public Internet works today with A 1061 resource records. 1063 However, if DNS whitelisting is adopted, organizations which apply 1064 DNS whitelisting policies in their authoritative servers should have 1065 procedures and systems which do not allow unauthorized parties to 1066 either remove whitelisted DNS resolvers from the whitelist or add 1067 non-whitelisted DNS resolvers to the whitelist. Should such 1068 unauthorized additions or removals from the whitelist can be quite 1069 damaging, and result in content providers and/or ISPs to incur 1070 substantial support costs resulting from end user and/or customer 1071 contacts. As such, great care must be taken to control access to the 1072 whitelist for an authoritative server. 1074 In addition, two other key security-related issues should be taken 1075 into consideration: 1077 10.1. DNSSEC Considerations 1079 DNS security extensions defined in [RFC4033], [RFC4034], and 1080 [RFC4035] use cryptographic digital signatures to provide origin 1081 authentication and integrity assurance for DNS data. This is done by 1082 creating signatures for DNS data on a Security-Aware Authoritative 1083 Name Server that can be used by Security-Aware Resolvers to verify 1084 the answers. Since DNS whitelisting is implemented on an 1085 authoritative server, which provides different answers depending upon 1086 which resolver server has sent a query, the DNSSEC chain of trust is 1087 not altered. Even though the authoritative server will not always 1088 return a AAAA resource record when one exists, respective A resource 1089 records and AAAA resource records can and should both be signed. 1090 Therefore there are no DNSSEC implications per se. However, any 1091 implementer of DNS whitelisting should be careful if they implement 1092 both DNSSEC signing of their domain and also DNS whitelisting of that 1093 same domain. Specifically, those domains should ensure that resource 1094 records are being appropriately and reliably signed, which may 1095 present incremental operational and/or technical challenges. 1097 However, as noted in Section 3, end user networks may also choose to 1098 implement tools at their disposal in order to address IPv6-related 1099 impairments. One of those possible tools could involve unspecified 1100 changes to the configuration of their recursive resolvers. If it is 1101 a Security-Aware Resolver, modifying or suppressing AAAA resource 1102 records for a DNSSEC-signed domain will be problematic and could 1103 break the chain of trust established with DNSSEC. 1105 10.2. Authoritative DNS Response Consistency Considerations 1107 In addition to the considerations raised in Section 10.1, it is 1108 conceivable that security concerns may arise when end users or other 1109 parties notice that the responses sent from an authoritative DNS 1110 server appear to vary from one network or one DNS recursive resolver 1111 to another. This may give rise to concerns that, since the 1112 authoritative responses vary that there is some sort of security 1113 issue and/or some or none of the responses can be trusted. While 1114 this may seem a somewhat obscure concern, domains nonetheless may 1115 wish to consider this when contemplating whether or not to pursue DNS 1116 whitelisting. 1118 11. Privacy Considerations 1120 As noted in Section 8.3.1, there may be methods to detect IPv6- 1121 related impairments for a particular end user. For example, this may 1122 be possible when an end user visits the website of a particular 1123 domain. In that example, there are likely no privacy considerations 1124 in communicating to that end user that the domain has detected a 1125 particular impairment. However, if that domain decided to share 1126 information concerning that particular end user with their network 1127 operator or another party, then the visited domain may wish to in 1128 some manner advise the end user of this or otherwise seek their 1129 consent to such information sharing. This may be achieved in a wide 1130 variety of ways, from presenting a message asking the user for 1131 consent (which will of course help them solve a technical problem of 1132 which they are likely unaware) to adding this to a domain's website 1133 terms of use / service. Such information sharing and communication 1134 of such sharing to end users may well vary by geographic area and/or 1135 legal jurisdiction. Thus, a domain should consider any potential 1136 privacy issues these sorts of scenarios. 1138 12. IANA Considerations 1140 There are no IANA considerations in this document. 1142 13. Contributors 1144 The following people made significant textual contributions to this 1145 document and/or played an important role in the development and 1146 evolution of this document: 1148 - John Brzozowski 1150 - Chris Griffiths 1152 - Tom Klieber 1154 - Yiu Lee 1156 - Rich Woundy 1158 14. Acknowledgements 1160 The author and contributors also wish to acknowledge the assistance 1161 of the following individuals. Some of these people provided helpful 1162 and important guidance in the development of this document and/or in 1163 the development of the concepts covered in this document. Other 1164 people assisted by performing a detailed review of this document, and 1165 then providing feedback and constructive criticism for revisions to 1166 this document. All of this was helpful and therefore the following 1167 individuals merit acknowledgement: 1169 - Bernard Aboba 1171 - Frank Bulk 1173 - Brian Carpenter 1175 - Karsten Fleischhauer 1177 - Wesley George 1178 - Jerry Huang 1180 - Joel Jaeggli 1182 - Erik Kline 1184 - Suresh Krishnan 1186 - Victor Kuarsingh 1188 - Danny McPherson 1190 - Martin Millnert 1192 - Thomas Narten 1194 - Hannes Tschofenig 1196 - Tina Tsou 1198 15. References 1200 15.1. Normative References 1202 [RFC1035] Mockapetris, P., "Domain names - implementation and 1203 specification", STD 13, RFC 1035, November 1987. 1205 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1206 E. Lear, "Address Allocation for Private Internets", 1207 BCP 5, RFC 1918, February 1996. 1209 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1210 RFC 1958, June 1996. 1212 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1213 February 2000. 1215 [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 1216 RFC 2956, October 2000. 1218 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1219 Issues", RFC 3234, February 2002. 1221 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 1222 and the Future of End-to-End: Reflections on the Evolution 1223 of the Internet Architecture", RFC 3724, March 2004. 1225 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1226 Rose, "DNS Security Introduction and Requirements", 1227 RFC 4033, March 2005. 1229 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1230 Rose, "Resource Records for the DNS Security Extensions", 1231 RFC 4034, March 2005. 1233 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1234 Rose, "Protocol Modifications for the DNS Security 1235 Extensions", RFC 4035, March 2005. 1237 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1238 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1240 15.2. Informative References 1242 [Evaluating IPv6 Adoption] 1243 Colitti, L., Gunderson, S., Kline, E., and T. Refice, 1244 "Evaluating IPv6 adoption in the Internet", Passive and 1245 Active Management (PAM) Conference 2010, April 2010, 1246 . 1248 [Heise Online Experiment] 1249 Heise.de, "World IPv6 Day - June 8, 2011", Heise.de 1250 Website http://www.h-online.com, January 2011, . 1254 [I-D.shirasaki-nat444] 1255 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 1256 and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work 1257 in progress), January 2011. 1259 [IETF-77-DNSOP] 1260 Gashinsky, I., "IPv6 & recursive resolvers: How do we make 1261 the transition less painful?", IETF 77 DNS Operations 1262 Working Group, March 2010, 1263 . 1265 [IPv6 Brokenness] 1266 Anderson, T., "Measuring and Combating IPv6 Brokenness", 1267 Reseaux IP Europeens (RIPE) 61st Meeting, November 2011, 1268 . 1270 [IPv6 Whitelist Operations] 1271 Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 1272 Implementors Conference, June 2010, . 1276 [Laws of Motion] 1277 Newton, I., "Mathematical Principles of Natural Philosophy 1278 (Philosophiae Naturalis Principia Mathematica)", 1279 Principia Mathematical Principles of Natural Philosophy 1280 (Philosophiae Naturalis Principia Mathematica), July 1687, 1281 . 1283 [NW-Article-DNS-WL] 1284 Marsan, C., "Google, Microsoft, Netflix in talks to create 1285 shared list of IPv6 users", Network World , March 2010, . 1289 [NW-Article-DNSOP] 1290 Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", 1291 Network World , March 2010, . 1294 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1295 April 1995. 1297 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1298 specifying the location of services (DNS SRV)", RFC 2782, 1299 February 2000. 1301 [Resolvers in the Wild] 1302 Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, 1303 "Comparing DNS Resolvers in the Wild", ACM Sigcomm 1304 Internet Measurement Conference 2010, November 2010, 1305 . 1307 [Rethinking the Internet] 1308 Blumenthal, M. and D. Clark, "Rethinking the design of the 1309 Internet: The end to end arguments vs. the brave new 1310 world", ACM Transactions on Internet Technology Volume 1, 1311 Number 1, Pages 70-109, August 2001, . 1315 [Tussle in Cyberspace] 1316 Braden, R., Clark, D., Sollins, K., and J. Wroclawski, 1317 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1318 Proceedings of ACM Sigcomm 2002, August 2002, . 1322 [Whitelisting Concerns] 1323 Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., 1324 Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - 1325 Could It Hinder IPv6 Adoption?", ISOC Internet Society 1326 IPv6 Deployment Workshop, April 2010, . 1330 [World IPv6 Day] 1331 The Internet Society, "World IPv6 Day - June 8, 2011", 1332 Internet Society Website http://www.isoc.org, 1333 January 2011, . 1335 Appendix A. Document Change Log 1337 [RFC Editor: This section is to be removed before publication] 1339 -03: Several changes suggested by Joel Jaeggli at the end of WGLC. 1340 This involved swapping the order of Section 6.1 and 6.2, among other 1341 changes to make the document more readable, understandable, and 1342 tonally balanced. As suggested by Karsten Fleischhauer, added a 1343 reference to RFC 4213 in Section 7.1, as well as other suggestions to 1344 that section. As suggested by Tina Tsou, made some changes to the 1345 DNSSEC section regarding signing. As suggested by Suresh Krishnan, 1346 made several changes to improve various sections of the document, 1347 such as adding an alternative concerning the use of ipv6.domain, 1348 improving the system logic section, and shortening the reference 1349 titles. As suggested by Thomas Narten, added some text regarding the 1350 imperfection of making judgements as to end user host impairments 1351 based upon the recursive resolver's IP and/or network. Finally, made 1352 sure that variations in the use of 'records' and 'resource records' 1353 was updated to 'resource records' for uniformity and to avoid 1354 confusion. 1356 -02: Called for and closed out feedback on dnsop and v6ops mailing 1357 lists. Closed out open feedback items from IETF 79. Cleared I-D 1358 nits issues, added a section on whether or not this is recommended, 1359 made language less company-specific based on feedback from Martin 1360 Millnert, Wes George, and Victor Kuarsingh. Also mentioned World 1361 IPv6 Day per Wes George's suggestion. Added references to the ISOC 1362 World IPv6 Day and the Heise.de test at the suggestion of Jerry 1363 Huang, as well as an additional implication in 7.3.7. Made any 1364 speculation on IPv4 impairment noted explicitly as such, per feedback 1365 from Martin Millnert. Added a reference to DNS SRV in the load 1366 balancing section. Added various other references. Numerous changes 1367 suggested by John Brzozowski in several sections, to clean up the 1368 document. Moved up the section on why whitelisting is performed to 1369 make the document flow more logically. Added a note in the ad hoc 1370 deployment scenario explaining that a deployment may be temporary, 1371 and including more of the perceived benefits of this tactic. Added a 1372 Privacy Considerations section to address end-user detection and 1373 communication. 1375 -01: Incorporated feedback received from Brian Carpenter (from 10/19/ 1376 2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010). 1377 Also added an informative reference at the suggestion of Wes George 1378 (from from 10/22/2010). Closed out numerous editorial notes, and 1379 made a variety of other changes. 1381 -00: First version published as a v6ops WG draft. The preceding 1382 individual draft was 1383 draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE 1384 that no changes have been made yet based on WG and list feedback. 1385 These are in queue for a -01 update. 1387 Appendix B. Open Issues 1389 [RFC Editor: This section is to be removed before publication] 1391 1. Ensure references are in the proper section (normative/ 1392 informative) 1394 Author's Address 1396 Jason Livingood 1397 Comcast Cable Communications 1398 One Comcast Center 1399 1701 John F. Kennedy Boulevard 1400 Philadelphia, PA 19103 1401 US 1403 Email: jason_livingood@cable.comcast.com 1404 URI: http://www.comcast.com