idnits 2.17.1 draft-livingood-dns-whitelisting-implications-01.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2010) is 4927 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-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational October 22, 2010 5 Expires: April 25, 2011 7 IPv6 AAAA DNS Whitelisting Implications 8 draft-livingood-dns-whitelisting-implications-01 10 Abstract 12 The objective of this document is to describe what whitelisting of 13 DNS AAAA resource records is, or DNS whitelisting for short, as well 14 as what the implications of this emerging practice are and what 15 alternatives may exist. The audience for this document is the 16 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 April 25, 2011. 36 Copyright Notice 38 Copyright (c) 2010 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 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 67 3. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 7 68 4. Similarities to Split DNS . . . . . . . . . . . . . . . . . . 9 69 5. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 10 70 5.1. Deploying DNS Whitelisting Universally . . . . . . . . . . 10 71 5.2. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 11 72 6. What Problems Are DNS Whitelisting Implementers Trying To 73 Solve? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 12 75 7.1. Architectural Implications . . . . . . . . . . . . . . . . 12 76 7.2. Public IPv6 Address Reachability Implications . . . . . . 13 77 7.3. Operational Implications . . . . . . . . . . . . . . . . . 13 78 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 13 79 7.3.2. Authoritative DNS Server Operational Implications . . 13 80 7.3.3. DNS Recursive Resolver Server Operational 81 Implications . . . . . . . . . . . . . . . . . . . . . 14 82 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 15 83 7.3.5. Troubleshooting Implications . . . . . . . . . . . . . 15 84 7.3.6. Additional Implications If Deployed On An Ad Hoc 85 Basis . . . . . . . . . . . . . . . . . . . . . . . . 16 86 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 16 87 7.5. Technology Policy Implications . . . . . . . . . . . . . . 17 88 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 18 89 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 18 91 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 18 92 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 19 93 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 19 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 20 96 9.2. Authoritative DNS Response Consistency Considerations . . 20 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 98 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 102 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 103 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 22 104 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 23 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 1. Introduction 109 [EDITORIAL: This is a rough first -00 draft. Some sections have not 110 yet been completed but will be soon. Suggestions on all parts of 111 this document are eagerly solicited.] 113 This document describes the emerging practice of whitelisting of DNS 114 AAAA resource records (RRs), or DNS whitelisting for short. It also 115 explores the implications of this emerging practice are and what 116 alternatives may exist. 118 The practice of DNS whitelisting appears to have first been used by 119 major web content sites. These web site operators observed that when 120 they added AAAA RRs to their authoritative DNS servers that a small 121 fraction of end users had slow or otherwise impaired access to a 122 given web site with both AAAA and A RRs. The fraction of users with 123 such impaired access has been estimated to be roughly 0.078% of total 124 Internet users [IETF 77 DNSOP WG Presentation] [Network World Article 125 on IETF 77 DNSOP WG Presentation]. Thus, in an example Internet 126 Service Provider (ISP) network of 10 million users, approximately 127 7,800 of those users may experience such impaired access. 129 As a result of this impairment affecting end users of a given domain, 130 a few large web site operators have begun to either implement DNS 131 whitelisting or strongly consider the implementation of DNS 132 whitelisting [Network World Article on DNS Whitelisting]. When 133 implemented, DNS whitelisting in practice means that a domain's 134 authoritative DNS will return a AAAA RR to DNS recursive resolvers 135 [RFC1035] on the whitelist, while returning no AAAA RRs to DNS 136 resolvers which are not on the whitelist. It is important to note 137 that these web site operators are motivated to maintain a high- 138 quality user experience for all of their users, and that they are 139 attempting to shield users with impaired access from the symptoms of 140 these impairments that would negatively affect their access to 141 certain websites and related Internet resources. 143 [EDITORIAL: change web site operators --> domain operators?] 145 However, critics of this emerging practice of DNS whitelisting have 146 articulated several concerns. Among these are that this is a very 147 different behavior from the current practice concerning the 148 publishing of IPv4 address records, that it may create a two-tiered 149 Internet, that policies concerning whitelisting and de-whitelisting 150 are opaque, that DNS whitelisting reduces interest in the deployment 151 of IPv6, that new operational and management burdens are created, and 152 that the costs and negative implications of DNS whitelisting outweigh 153 the perceived benefits as compared to fixing underlying impairments. 155 This document explores the reasons and motivations for DNS 156 whitelisting. It also explores the concerns regarding this emerging 157 practice. As a result, readers can hopefully better understand what 158 DNS whitelisting is, why some parties are implementing it, and why 159 other parties are critical of the practice. 161 2. How DNS Whitelisting Works 163 DNS whitelisting is implemented in authoritative DNS servers, where 164 those servers implement IP address-based restrictions on AAAA query 165 responses, which contain IPv6 addresses. In practice DNS 166 whitelisting has been primarily implemented by web server operators. 167 For a given operator of the website www.example.com, that operator 168 essentially applies an access control list (ACL) on their 169 authoritative DNS servers, which are authoritative for the domain 170 example.com. The ACL is then configured with the IPv4 and/or IPv6 171 addresses of DNS recursive resolvers on the Internet, which have been 172 authorized to be added to the ACL and to therefore receive AAAA RR 173 responses. These DNS recursive resolvers are operated by other 174 parties, such as ISPs, universities, governments, businesses, 175 individual end users, etc. If a DNS recursive resolver IS NOT on the 176 ACL, then NO AAAA RRs with IPv6 addresses will be sent in response to 177 a query for a given hostname in the example.com domain. However, if 178 a DNS recursive resolver IS on the ACL, then AAAA RRs with IPv6 179 addresses will be sent in response to a query for a given hostname in 180 the example.com domain. 182 In practice this generally means that a very small fraction of the 183 DNS recursive resolvers on the Internet can receive AAAA responses 184 with IPv6 addresses, which means that the large majority of DNS 185 resolvers on the Internet will receive only A RRs with IPv4 186 addresses. Thus, quite simply, the authoritative server hands out 187 different answers depending upon who is asking; with IPv4 and IPv6 188 records for some on the authorized whitelist, and only IPv4 records 189 for everyone else. See Figure 1 and Figure 2 for two different 190 visual descriptions of how this works in practice. 192 Finally, DNS whitelisting can be deployed in two primary ways: 193 universally on a global basis, or on an ad hoc basis. These two 194 potential deployment models are described in Section 5. 196 1: The authoritative DNS server for example.com receives a DNS 197 query for www.example.com, for which both A (IPv4) and AAAA 198 (IPv6) address records exist. 199 2: The authoritative DNS server examines the IP address of the DNS 200 recursive resolver sending the query. 201 3: The authoritative DNS server checks this IP address against the 202 access control list (ACL) that is the DNS whitelist. 203 4: If the DNS recursive resolver's IP address IS listed in the ACL, 204 then the response to that specific DNS recursive resolver can 205 contain both A (IPv4) and AAAA (IPv6) address records. 206 5: If the DNS recursive resolver's IP address IS NOT listed in the 207 ACL, then the response to that specific DNS recursive resolver 208 can contain only A (IPv4) address records and therefore cannot 209 contain AAAA (IPv6) address records. 211 Figure 1: DNS Whitelisting - System Logic 213 --------------------------------------------------------------------- 214 A query is sent from a DNS recursive resolver that IS NOT on the DNS 215 whitelist: 217 Request Request 218 www.example.com www.example.com 219 +-------------+ +-----------------+ 220 ++--++ ---------> | RESOLVER | ---------> | www.example.com | 221 || || | **IS NOT** | | IN A exists | 222 +-++--++-+ | ON | | IN AAAA exists | 223 +--------+ | example.com | | | 224 Host <--------- | WHITELIST | <--------- | | 225 Computer A Record +-------------+ A Record +-----------------+ 226 Response DNS Recursive Response example.com 227 (IPv4) Resolver (IPv4) Authoritative 228 #1 Server 229 --------------------------------------------------------------------- 230 A query is sent from a DNS recursive resolver that IS on the DNS 231 whitelist: 233 Request Request 234 www.example.com www.example.com 235 +-------------+ +-----------------+ 236 ++--++ ---------> | RESOLVER | ---------> | www.example.com | 237 || || | **IS** | | IN A exists | 238 +-++--++-+ | ON | | IN AAAA exists | 239 +--------+ | example.com | | | 240 Host <--------- | WHITELIST | <--------- | | 241 Computer A and AAAA +-------------+ A and AAAA +-----------------+ 242 Record DNS Recursive Record example.com 243 Responses Resolver Responses Authoritative 244 (IPv4+IPv6) #2 (IPv4+IPv6) Server 245 --------------------------------------------------------------------- 247 Figure 2: DNS Whitelisting - Functional Diagram 249 3. Concerns Regarding DNS Whitelisting 251 There are a number of potential implications relating to DNS 252 whitelisting, which have raised various concerns in some parts of the 253 Internet community. Many of those potential implications are 254 described in Section 7. 256 Some parties in the Internet community are concerned that this 257 emerging practice of DNS whitelisting for IPv6 address records could 258 represent a departure from the generally accepted practices regarding 259 IPv4 address records in the DNS on the Internet. These parties 260 explain their belief that for A records, containing IPv4 addresses, 261 once an authoritative server operator adds the A record to the DNS, 262 then any DNS recursive resolver on the Internet can receive that A 263 record in response to a query. By extension, this means that any of 264 the hosts connected to any of these DNS recursive resolvers can 265 receive the IPv4 address records for a given FQDN. This enables new 266 server hosts which are connected to the Internet, and for which a 267 fully qualified domain name (FQDN) such as www.example.com has been 268 added to the DNS with an IPv4 address record, to be almost 269 immediately reachable by any host on the Internet. In this case, 270 these new servers hosts become more and more widely accessible as new 271 networks and new end user hosts connect to the Internet over time 272 [EDITORIAL: consider reference to network effects]. It also means 273 that the new server hosts do not need to know about these new 274 networks and new end user hosts in order to make their content and 275 applications available to them, in essence that each end in this end- 276 to-end model is responsible for connecting to the Internet and once 277 they have done so they can connect to each other without additional 278 impediments or middle networks or intervening networks or servers 279 knowing about these end points and whether one is allowed to contact 280 the other. 282 In contrast, these parties are concerned that DNS whitelisting may 283 fundamentally change this model. As a result, in this altered end- 284 to-end model, one end (where the end user is located) cannot readily 285 connect to the other end (where the content is located), without 286 parts of the middle used by one end being known by the other end and 287 approved for access to that end. Thus, as new networks connect to 288 the Internet over time, those networks need to contact any and all 289 domains which have implemented DNS whitelisting in order to apply to 290 be added to their DNS whitelist, in the hopes of making the content 291 and applications residing on named server hosts in those domains 292 accessible by the end user hosts on that new network. Furthermore, 293 this same need to contact all domains implementing DNS whitelisting 294 also applies to all existing networks connected to the Internet. 296 Therefore, these concerned parties explain, whereas in the current 297 IPv4 Internet when a new server host is added to the Internet it is 298 widely available to all end user hosts and networks, when DNS 299 whitelisting of IPv6 records is used then these new server hosts are 300 not accessible to any end user hosts or networks until such time as 301 the operator of the authoritative DNS servers for those new server 302 hosts expressly authorizes access to those new server hosts by adding 303 DNS recursive resolvers around the Internet to the ACL. This could 304 represent a significant change in reachability of content and 305 applications by end users and networks as these end user hosts and 306 networks transition to IPv6. Therefore, a concern expressed is that 307 if much of the content that end users are most interested in is not 308 accessible as a result, then end users and/or networks may resist 309 adoption of IPv6 or actively seek alternatives to it, such as using 310 multi-layer network address translation (NAT) techniques like NAT444 311 [I-D.shirasaki-nat444] on a long-term basis. There is also concern 312 that this practice also could disrupt the continued increase in 313 Internet adoption by end users if they cannot simply access new 314 content and applications but must instead contact the operator of 315 their DNS recursive resolver, such as their ISP or another third 316 party, to have their DNS recursive resolver authorized for access to 317 the content or applications that interests them. Meanwhile, these 318 parties say, over 99.9% of all other end users that are also using 319 that same network or DNS recursive resolver are unable to access the 320 IPv6-based content, despite their experience being a positive one. 322 [EDITORIAL: Are there additional concerns to add here?] 324 4. Similarities to Split DNS 326 DNS whitelisting as described herein is in some ways similar to so- 327 called split DNS, which is briefly described in Section 3.8 of 328 [RFC2775]. When split DNS is used, the authoritative DNS server 329 returns different responses depending upon what host has sent the 330 query. While [RFC2775] notes the typical use of split DNS is to 331 provide one answer to hosts on an Intranet and a different answer to 332 hosts on the Internet, the essence is that different answers are 333 provided to hosts on different networks. This is basically the way 334 that DNS whitelisting works, in so far as hosts of different 335 networks, which use different DNS recursive resolvers, receive 336 different answers if one DNS recursive resolver is on the whitelist 337 and the other is not. Thus, in a way, DNS whitelisting could in some 338 ways be considered split DNS on the public Internet, though with some 339 differences. 341 In [RFC2956], Internet transparency and Internet fragmentation 342 concerns regarding split DNS are detailed in Section 2.1. [RFC2956] 343 further notes in Section 2.7, concerns regarding split DNS and that 344 it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint 345 identifiers more complex." Section 3.5 of [RFC2956] further 346 recommends that maintaining a stable approach to DNS operations is 347 key during transitions such as the one to IPv6 that is underway now, 348 stating that "Operational stability of DNS is paramount, especially 349 during a transition of the network layer, and both IPv6 and some 350 network address translation techniques place a heavier burden on 351 DNS." 353 5. Likely Deployment Scenarios 355 In considering how DNS whitelisting may emerge more widely, there are 356 two likely deployment scenarios, which are explored below. 358 5.1. Deploying DNS Whitelisting Universally 360 The least likely deployment scenario is one where DNS whitelisting 361 becomes a standardized process across all authoritative DNS servers, 362 across the entire Internet. While this scenario is the least likely, 363 due to some parties not sharing the concerns that have so far 364 motivated the use of DNS whitelisting, it is nonetheless conceivable 365 that it could be one of the ways in which DNS whitelisting may be 366 deployed. 368 In order for this deployment scenario to occur, it is likely that DNS 369 whitelisting functionality would need to be built into all 370 authoritative DNS server software, and that all operators of 371 authoritative DNS servers would have to upgrade their software and 372 enable this functionality. Furthermore, it is likely that new 373 Internet Draft documents would need to be developed which describe 374 how to properly configure, deploy, and maintain DNS whitelisting. As 375 a result, it is unlikely that DNS whitelisting would, at least in the 376 next several years, become universally deployed. Furthermore, these 377 DNS whitelists are likely to vary on a domain-by-domain basis, 378 depending upon a variety of factors. Such factors may include the 379 motivation of each domain owner, the location of the DNS recursive 380 resolvers in relation to the source content, as well as various other 381 parameters that may be transitory in nature, or unique to a specific 382 end user host type. Thus, it is probably unlikely that a single 383 clearinghouse for managing whitelisting is possible; it will more 384 likely be unique to the source content owners and/or domains which 385 implement DNS whitelists. 387 While this scenario may be unlikely, it may carry some benefits. 388 First, parties performing troubleshooting would not have to determine 389 whether or not DNS whitelisting was being used, as it always would be 390 in use. In addition, if universally deployed, it is possible that 391 the criteria for being added to or removed from a DNS whitelist could 392 be standardized across the entire Internet. Nevertheless, even if 393 uniform DNS whitelisting policies were not standardized, is also 394 possible that a central registry of these policies could be developed 395 and deployed in order to make it easier to discover them, a key part 396 of achieving transparency regarding DNS whitelisting. 398 [EDITORIAL: Are there additional benefits or challenges to add here?] 400 5.2. Deploying DNS Whitelisting On An Ad Hoc Basis 402 This is the most likely deployment scenario for DNS whitelisting, as 403 it seems today, is where some interested parties engage in DNS 404 whitelisting but many or most others do not do so. What can make 405 this scenario challenging from the standpoint of a DNS recursive 406 resolver operator is determining which domains implement DNS 407 whitelisting, particularly since a domain may not do so as they 408 initially transition to IPv6, and may instead do so later. Thus, a 409 DNS recursive resolver operator may initially believe that they can 410 receive AAAA responses with IPv6 addresses as a domain adopts IPv6, 411 but then notices via end user reports that they no longer receive 412 AAAA responses due to that site adopting DNS whitelisting. 414 Thus, in contrast to universal deployment of DNS whitelisting, 415 deployment on an ad hoc basis is likely to be significantly more 416 challenging from an operational, monitoring, and troubleshooting 417 standpoint. In this scenario, a DNS recursive resolver operator will 418 have no way to systematically determine whether DNS whitelisting is 419 or is not implemented for a domain, since the absence of AAAA records 420 with IPv6 addresses may simply be indicative that the domain has not 421 yet added IPv6 addressing for the domain, not that they have done so 422 but have restricted query access via DNS whitelisting. As a result, 423 discovering which domains implement DNS whitelisting, in order to 424 differentiate them from those that do not, is likely to be 425 challenging. 427 On the other hand, one benefit of DNS whitelisting being deployed on 428 an ad hoc basis is that only the domains that are interested in doing 429 so would have to upgrade their authoritative DNS servers in order to 430 implement the ACLs necessary to perform DNS whitelisting. 432 [EDITORIAL: Additional benefits or challenges to add?] 434 6. What Problems Are DNS Whitelisting Implementers Trying To Solve? 436 As noted in Section 1, domains which implement DNS whitelisting are 437 attempting to protect a few users of their domain, which happen to 438 have impaired IPv6 access, from having a negative end user 439 experience. While it is outside the scope of this document to 440 explore the various reasons why a particular user may experience 441 impaired IPv6 access, for the users which experience this it is a 442 very real effect and would of course affect access to all or most 443 IPv4 and IPv6 dual stack servers. This negative end user experience 444 can range from someone slower than usual (as compared to native IPv4- 445 based access), to extremely slow, to no access to the domain 446 whatsoever. 448 Thus, parties which implement DNS whitelisting are attempting to 449 provide a good experience to these end users. While one can debate 450 whether DNS whitelisting is the optimal solution, it is quite clear 451 that DNS whitelisting implementers are extremely interested in the 452 performance of their services for end users as a primary motivation. 454 [EDITORIAL 1: More motivations to add?] 456 [EDITORIAL 2:Any good external references to consider adding?] 458 7. Implications of DNS Whitelisting 460 There are many potential implications of DNS whitelisting. In the 461 sections below, the key potential implications are listed in some 462 detail. 464 7.1. Architectural Implications 466 DNS whitelisting could be perceived as somewhat modifying the end-to- 467 end model that prevails on the IPv4 Internet today. This approach 468 moves additional access control information and policies into the 469 middle of the network on the IPv6-addressed Internet, which did not 470 exist before on the IPv4-addressed Internet. This could raise some 471 risks noted in [RFC3724], which in explaining the history of the end- 472 to-end principle [RFC1958] explains that one of the goals is to 473 minimize the state, policies, and other functions needed in the 474 middle of the network in order to enable end-to-end communications on 475 the Internet. 477 It is also possible that DNS whitelisting could place at risk some of 478 the benefits of the end-to-end principle, as listed in Section 4.1 of 479 [RFC3724], such as protection of innovation. Further, while 480 [RFC3234] details issues and concerns regarding so-called 481 middleboxes, there may be parallels to DNS whitelisting, especially 482 concerning modified DNS servers noted in Section 2.16 of [RFC3234], 483 and more general concerns noted in Section 1.2 of [RFC3234] about the 484 introduction of new failure modes, that configuration is no longer 485 limited to two ends of a session, and that diagnosis of failures and 486 misconfigurations is more complex. 488 In [Tussle in Cyberspace], the authors note concerns regarding the 489 introduction of new control points, as well as "kludges" to the DNS, 490 as risks to the goal of network transparency in the end-to-end model. 491 Some parties concerned with the emerging use of DNS whitelisting have 492 shared similar concerns, which may make [Tussle in Cyberspace] an 493 interesting and relevant document. In addition, [Rethinking the 494 design of the Internet] reviews similar issues that may be of 495 interest to readers of this document. 497 In order to explore and better understand these high-level 498 architectural implications and concerns in more detail, the following 499 sections explore more specific potential implications. 501 7.2. Public IPv6 Address Reachability Implications 503 The predominant experience of end user hosts and servers on the IPv4- 504 addressed Internet today is that, very generally speaking, when a new 505 server with a public IPv4 address is added, that it is then globally 506 accessible by IPv4-addressed hosts. For the purposes of this 507 document, that concept can be considered "pervasive reachability". 508 It has so far been assumed that the same expectations of reachability 509 would exist in the IPv6-addressed Internet. However, if DNS 510 whitelisting is deployed, this will not be the case since only end 511 user hosts using DNS recursive resolvers which have been added to the 512 ACL of a given domain using DNS whitelisting would be able to reach 513 new servers in that given domain via IPv6 addresses. 515 Thus, the expectation of any end user host being able to connect to 516 any server (essentially both hosts, just at either end of the 517 network), defined here as "pervasive reachability", will change to 518 "restricted reachability" with IPv6. 520 [EDITORIAL: Additional implications?] 522 7.3. Operational Implications 524 This section explores some of the operationally related implications 525 which may occur as a result of, related to, or necessary when 526 engaging in the practice of DNS whitelisting. 528 7.3.1. De-Whitelisting May Occur 530 If it is possible for a DNS recursive resolver to be added to a 531 whitelist, then it is also possible for that resolver to be removed 532 from the whitelist, also known as de-whitelisting. Since de- 533 whitelisting can occur, whether through a decision by the 534 authoritative server operator or the domain owner, or even due to a 535 technical error, an operator of a DNS recursive resolver will have 536 new operational and monitoring requirements and/or needs as noted in 537 Section 7.3.3, Section 7.3.4, Section 7.3.5, and Section 7.5. 539 7.3.2. Authoritative DNS Server Operational Implications 541 Operators of authoritative servers may need to maintain an ACL a 542 server-wide basis affecting all domains, on a domain-by-domain basis, 543 as well as on a combination of the two. As a result, operational 544 practices and software capabilities may need to be developed in order 545 to support such functionality. In addition, processes may need to be 546 put in place to protect against inadvertently adding or removing IP 547 addresses, as well as systems and/or processes to respond to such 548 incidents if and when they occur. For example, a system may be 549 needed to record DNS whitelisting requests, report on their status 550 along a workflow, add IP addresses when whitelisting has been 551 approved, remove IP addresses when they have been de-whitelisted, log 552 the personnel involved and timing of changes, schedule changes to 553 occur in the future, and to roll back any inadvertent changes. 555 Such operators may also need implement new forms of monitoring in 556 order to apply change control, as noted briefly in Section 7.3.4. 558 [EDITORIAL: Additional implications?] 560 7.3.3. DNS Recursive Resolver Server Operational Implications 562 Operators of DNS recursive resolvers, which may include ISPs, 563 enterprises, universities, governments, individual end users, and 564 many other parties, are likely to need to implement new forms of 565 monitoring, as noted briefly in Section 7.3.4. But more critically, 566 such operators may need to add people, processes, and systems in 567 order to manage countless DNS whitelisting applications, for all 568 domains that the end users of such servers are interested in now or 569 in which they may be interested in the future. As such anticipation 570 of interesting domains is likely infeasible, it is more likely that 571 such operators may either choose to only apply to be whitelisted for 572 a domain based upon one or more end user requests, or that they will 573 attempt to do so for all domains. 575 When such operators apply for DNS whitelisting for all domains, that 576 may mean doing so for all registered domains. Thus, some system 577 would have to be developed to discover whether each domain has been 578 whitelisted or not, which is touched on in Section 5 and may vary 579 depending upon whether DNS whitelisting is universally deployed or is 580 deployed on an ad hoc basis. 582 Furthermore, these operators will need to develop processes and 583 systems to track the status of all DNS whitelisting applications, 584 respond to requests for additional information related to these 585 applications, determine when and if applications have been denied, 586 manage appeals, and track any de-whitelisting actions. Given the 587 incredible number of domains in existence, the ease with which a new 588 domain can be added, and the continued strong growth in the numbers 589 of new domains, readers should not underestimate the potential 590 significance in personnel and expense that this could represent for 591 such operators. In addition, it is likely that systems and personnel 592 may also be needed to handle new end user requests for domains for 593 which to apply for DNS whitelisting, and/or inquiries into the status 594 of a whitelisting application, reports of de-whitelisting incidents, 595 general inquiries related to DNS whitelisting, and requests for DNS 596 whitelisting-related troubleshooting by these end users. 598 [EDITORIAL: Additional implications?] 600 7.3.4. Monitoring Implications 602 Once a DNS recursive resolver has been whitelisted for a particular 603 domain, then the operator of that DNS recursive resolver may need to 604 implement monitoring in order to detect the possible loss of 605 whitelisting status in the future. This DNS recursive resolver 606 operator could configure a monitor to check for a AAAA response in 607 the whitelisted domain, as a check to validate continued status on 608 the DNS whitelist. The monitor could then trigger an alert if at 609 some point the AAAA responses were no longer received, so that 610 operations personnel could begin troubleshooting, as outlined in 611 Section 7.3.5. 613 Also, authoritative DNS server operators are likely to need to 614 implement new forms of monitoring. In this case, they may desire to 615 monitor for significant changes in the size of the whitelist within a 616 certain period of time, which might be indicative of a technical 617 error such as the entire ACL being removed. These operators may also 618 wish to monitor their workflow process for reviewing and acting upon 619 DNS whitelisting applications and appeals, potentially measuring and 620 reporting on service level commitments regarding the time an 621 application or appeal can remain at each step of the process, 622 regardless of whether or not such information is shared with parties 623 other than that authoritative DNS server operator. 625 These are but a few examples of the types of monitoring that may be 626 called for as a result of DNS whitelisting, among what are likely 627 many other types and variations. 629 [EDITORIAL: Additional implications?] 631 7.3.5. Troubleshooting Implications 633 The implications of DNS whitelisted present many challenges, which 634 have been detailed in Section 7. These challenges may negatively 635 affect the end users' ability to troubleshoot, as well as that of DNS 636 recursive resolver operators, ISPs, content providers, domain owners 637 (where they may be different from the operator of the authoritative 638 DNS server for their domain), and other third parties. This may make 639 the process of determining why a server is not reachable 640 significantly more complex. 642 [SECTION INCOMPLETE - MIGHT LIKE TO ADD SOME EXAMPLES HERE] 644 [EDITORIAL: Additional implications?] 646 7.3.6. Additional Implications If Deployed On An Ad Hoc Basis 648 [SECTION INCOMPLETE - IS THIS NEEDED? - PLACEHOLDER FOR NOW] 650 [EDITORIAL: Additional implications?] 652 7.4. Homogeneity May Be Encouraged 654 A broad trend which has existed on the Internet appears to be a move 655 towards increasing levels of heterogeneity. One manifestation of 656 this is in an increasing number, variety, and customization of end 657 user hosts, including home network, operating systems, client 658 software, home network devices, and personal computing devices. This 659 trend appears to have had a positive effect on the development and 660 growth of the Internet. A key facet of this that has evolved is the 661 ability of the end user to connect any technically compliant device 662 or use any technically compatible software to connect to the 663 Internet. Not only does this trend towards greater heterogeneity 664 reduce the control which is exerted in the middle of the network, 665 described in positive terms in [Tussle in Cyberspace], [Rethinking 666 the design of the Internet], and [RFC3724], but it can also help to 667 enable greater and more rapid innovation at the edges. 669 An unfortunate implication of the adoption of DNS whitelisting may be 670 the encouragement of a reversal of this trend, which would be a move 671 back towards greater levels of homogeneity. In this case, a domain 672 owner which has implemented DNS whitelisting may prefer greater 673 levels of control be exerted over end user hosts (which broadly 674 includes all types of end user software and hardware) in order to 675 attempt to enforce technical standards relating to establishing 676 certain IPv6 capabilities or the enforcing the elimination of or 677 restriction of certain end user hosts. While the domain operator is 678 attempting to protect, maintain, and/or optimize the end user 679 experience for their domain, the collective result of many domains 680 implementing DNS whitelisting, or even a few important domains 681 implementing DNS whitelisting, may be to encourage a return to more 682 homogenous and/or controlled end user hosts. Unfortunately, this 683 could have unintended side effects on and counter-productive 684 implications for future innovation at the edges of the network. 686 7.5. Technology Policy Implications 688 A key technology policy implication concerns the policies relating to 689 the process of reviewing an application for DNS whitelisting, and the 690 decision-making process regarding whitelisting for a domain. 691 Important questions may include whether these policies have been 692 fully and transparently disclosed, are non-discriminatory, and are 693 not anti-competitive. A related implication is whether and what the 694 process for appeals is, when a domain decides not to add a DNS 695 recursive resolver to the whitelist. Key questions here may include 696 whether appeals are allowed, what the process is, what the expected 697 turn around time is, and whether the appeal will be handled by an 698 independent third party or other entity/group. 700 A further implications arises when de-whitelisting occurs. Questions 701 that may naturally be raised in such a case include whether the 702 criteria for de-whitelisting have been fully and transparently 703 disclosed, are non-discriminatory, and are not anti-competitive. 704 Additionally, the question of whether or not there was a cure period 705 available prior to de-whitelisting, during which troubleshooting 706 activities, complaint response work, and corrective actions may be 707 attempted, and whether this cure period was a reasonable amount of 708 time. 710 It is also conceivable that whitelisting and de-whitelisting 711 decisions could be quite sensitive to concerned parties beyond the 712 operator of the domain which has implemented DNS whitelisting and the 713 operator of the DNS recursive resolver, including end users, 714 application developers, content providers, advertisers, public policy 715 groups, governments, and other entities, which may also seek to 716 become involved in or express opinions concerning whitelisting and/or 717 de-whitelisting decisions. Lastly, it is conceivable that any of 718 these interested parties or other related stakeholders may seek 719 redress outside of the process a domain has establishing for DNS 720 whitelisting and de-whitelisting. 722 A final concern is that decisions relating to whitelisting and de- 723 whitelisting may occur as an expression of other commercial, 724 governmental, and/or cultural conflicts, given the new control point 725 which has be established with DNS whitelisting. For example, in one 726 imagined scenario, it may be conceivable that one government is 727 unhappy with a news story or book published in a particular country, 728 and that this government may retaliate against or protest this news 729 story or book by requiring domains operating within that government's 730 territory to de-whitelist commercial, governmental, or other entities 731 involved in or related to (however tangentially) publishing the news 732 story or book. By the same token, a news site operating in multiple 733 territories may be unhappy with governmental policies in one 734 particular territory and may choose to express dissatisfaction in 735 that territory by de-whitelisting commercial, governmental, or other 736 entities in that territory. Thus, it seems possible that DNS 737 whitelisting and de-whitelisting could become a vehicle for 738 adjudicating other disputes, and that this may well have intended and 739 unintended consequences for end users which are affected by such 740 decisions and are unlikely to be able to express a strong voice in 741 such decisions. 743 7.6. IPv6 Adoption Implications 745 As noted in Section 3, the implications of DNS whitelisting may drive 746 end users and/or networks to delay, postpone, or cancel adoption of 747 IPv6, or to actively seek alternatives to it. Such alternatives may 748 include the use of multi-layer network address translation (NAT) 749 techniques like NAT444 [I-D.shirasaki-nat444], which these parties 750 may decide to pursue on a long-term basis to avoid the perceived 751 costs and aggravations related to DNS whitelisting. This could of 752 course come at the very time that the Internet community is trying to 753 get these very same parties interested in IPv6 and motivated to begin 754 the transition to IPv6. As a result, parties concerned over the 755 negative implications of DNS whitelisting have said they are very 756 concerned of the negative effects that this practice could have on 757 the adoption of IPv6 if it became widespread or was adopted by key 758 parties in the Internet ecosystem. 760 [EDITORIAL: Additional implications?] 762 8. Solutions 764 8.1. Implement DNS Whitelisting Universally 766 One obvious solution is to implement DNS whitelisted universally, and 767 to do so using some sort of centralized registry of DNS whitelisting 768 policies, contracts, processes, or other information. This potential 769 solution seems unlikely at the current time. 771 [EDITORIAL: More to add?] 773 8.2. Implement DNS Whitelisting On An Ad Hoc Basis 775 If DNS whitelisting was to be adopted more widely, it is likely to be 776 adopted on this ad hoc, or domain-by-domain basis. Therefore, only 777 those domains interested in DNS whitelisting would need to adopt the 778 practice, though as noted herein discovering that they a given domain 779 has done so may be problematic. 781 [EDITORIAL: More to add?] 783 8.3. Do Not Implement DNS Whitelisting 785 As an alternative to adopting DNS whitelisting, the Internet 786 community can instead choose to take no action whatsoever, 787 perpetuating the current predominant authoritative DNS operational 788 model on the Internet, and leave it up to end users with IPv6-related 789 impairments to discover and fix those impairments. 791 8.3.1. Solving Current End User IPv6 Impairments 793 A further extension of not implementing DNS whitelisting, is to also 794 endeavor to actually fix the underlying technical problems that have 795 prompted the consideration of DNS whitelisting in the first place, as 796 an alternative to trying to apply temporary workarounds to avoid the 797 symptoms of underlying end user IPv6 impairments. A first step is 798 obviously to identify which users have such impairments, which would 799 appear to be possible, and then to communicate this information to 800 end users. Such end user communication is likely to be most helpful 801 if the end user is not only alerted to a potential problem but is 802 given careful and detailed advice on how to resolve this on their 803 own, or where they can seek help in doing so. 805 One challenge with this option is the potential difficulty of 806 motivating members of the Internet community to work collectively 807 towards this goal, sharing the labor, time, and costs related to such 808 an effort. Of course, since just such a community effort is now 809 underway for IPv6, it is possible that this would call for only a 810 moderate amount of additional work. 812 [EDITORIAL: More to add?] 814 9. Security Considerations 816 There are no particular security considerations if DNS whitelisting 817 is not adopted, as this is how the public Internet works today with A 818 records. 820 However, if DNS whitelisting is adopted, organizations which apply 821 DNS whitelisting policies in their authoritative servers should have 822 procedures and systems which do not allow unauthorized parties to 823 either remove whitelisted DNS resolvers from the whitelist or add 824 non-whitelisted DNS resolvers to the whitelist. Should such 825 unauthorized additions or removals from the whitelist can be quite 826 damaging, and result in content providers and/or ISPs to incur 827 substantial support costs resulting from end user and/or customer 828 contacts. As such, great care must be taken to control access to the 829 whitelist for an authoritative server. 831 In addition, two other key security-related issues should be taken 832 into consideration: 834 9.1. DNSSEC Considerations 836 DNS security extensions defined in [RFC4033], [RFC4034], and 837 [RFC4035] use cryptographic digital signatures to provide origin 838 authentication and integrity assurance for DNS data. This is done by 839 creating signatures for DNS data on a Security-Aware Authoritative 840 Name Server that can be used by Security-Aware Resolvers to verify 841 the answers. Since DNS whitelisting is implemented on an 842 authoritative server, which provides different answers depending upon 843 which resolver server has sent a query, the DNSSEC chain of trust is 844 not altered. Therefore there are no DNSSEC implications per se, and 845 thus no specific DNSSEC considerations to be listed. 847 9.2. Authoritative DNS Response Consistency Considerations 849 [INCOMPLETE!!] 851 While Section 9.1 does not contain any specific DNSSEC 852 considerations. However, it is certainly conceivable that security 853 concerns may arise when end users or other parties notice that the 854 responses sent from an authoritative DNS server appear to vary from 855 one network or one DNS recursive resolver to another. This may give 856 rise to concerns that, since the authoritative responses vary that 857 there is some sort of security issue and/or some or none of the 858 responses can be trusted. 860 10. IANA Considerations 862 There are no IANA considerations in this document. 864 11. Contributors 866 The following people made significant textual contributions to this 867 document and/or played an important role in the development and 868 evolution of this document: 870 John Brzozowski 872 Chris Griffiths 873 Tom Klieber 875 Yiu Lee 877 Rich Woundy 879 12. Acknowledgements 881 The authors and contributors also wish to acknowledge the assistance 882 of the following individuals in helping us to develop and/or review 883 this document: 885 13. References 887 13.1. Normative References 889 [RFC1035] Mockapetris, P., "Domain names - implementation and 890 specification", STD 13, RFC 1035, November 1987. 892 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 893 RFC 1958, June 1996. 895 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 896 February 2000. 898 [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 899 RFC 2956, October 2000. 901 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 902 Issues", RFC 3234, February 2002. 904 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 905 and the Future of End-to-End: Reflections on the Evolution 906 of the Internet Architecture", RFC 3724, March 2004. 908 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 909 Rose, "DNS Security Introduction and Requirements", 910 RFC 4033, March 2005. 912 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 913 Rose, "Resource Records for the DNS Security Extensions", 914 RFC 4034, March 2005. 916 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 917 Rose, "Protocol Modifications for the DNS Security 918 Extensions", RFC 4035, March 2005. 920 13.2. Informative References 922 [I-D.shirasaki-nat444] 923 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 924 and H. Ashida, "NAT444", draft-shirasaki-nat444-02 (work 925 in progress), July 2010. 927 [IETF 77 DNSOP WG Presentation] 928 Gashinsky, I., "IPv6 & recursive resolvers: How do we make 929 the transition less painful?", IETF 77 DNS Operations 930 Working Group, March 2010, 931 . 933 [Network World Article on DNS Whitelisting] 934 Marsan, C., "Google, Microsoft, Netflix in talks to create 935 shared list of IPv6 users", Network World , March 2010, . 939 [Network World Article on IETF 77 DNSOP WG Presentation] 940 Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", 941 Network World , March 2010, . 944 [Rethinking the design of the Internet] 945 Blumenthal, M. and D. Clark, "Rethinking the design of the 946 Internet: The end to end arguments vs. the brave new 947 world", ACM Transactions on Internet Technology Volume 1, 948 Number 1, Pages 70-109, August 2001, . 952 [Tussle in Cyberspace] 953 Braden, R., Clark, D., Sollins, K., and J. Wroclawski, 954 "Tussle in Cyberspace: Defining Tomorrow's Internet", 955 Proceedings of ACM Sigcomm 2002, August 2002, . 959 Appendix A. Document Change Log 961 [RFC Editor: This section is to be removed before publication] 963 -00: First version published 965 -01: Updated the title of the document, to avoid confusion (based on 966 feedback) 968 Appendix B. Open Issues 970 [RFC Editor: This section is to be removed before publication] 972 1. Incorporate any feedback received at IETF 79 974 2. Incorporate feedback from Erik Kline, received 10/1/2010 976 3. Incorporate feedback from Brian Carpenter, received 10/19/2010 978 4. Bring on new contributors: Hannes Tschofenig and Danny McPherson 979 has so far offered to contribute. 981 5. Close out any EDITORIAL notes 983 6. Add any good references throughout the document 985 7. Add reviewers to the acknowledgements section 987 8. Ensure references are in the proper section (normative/ 988 informative) 990 9. Include a number of references from RFC3724? 992 10. Call DNS WL something else or add note to the effect that this 993 is unrelated to DNS WL used for email - such as www.dnswl.org 995 Author's Address 997 Jason Livingood 998 Comcast Cable Communications 999 One Comcast Center 1000 1701 John F. Kennedy Boulevard 1001 Philadelphia, PA 19103 1002 US 1004 Email: jason_livingood@cable.comcast.com 1005 URI: http://www.comcast.com