IPv6 Operations                                             J. Livingood
Internet-Draft                                                   Comcast
Intended status: Informational                          December 3, 2010                          January 25, 2011
Expires: June 6, July 29, 2011

                IPv6 AAAA DNS Whitelisting Implications


   The objective of this document is to describe what whitelisting of
   DNS AAAA resource records is, or DNS whitelisting for short, as well
   as what the implications of this emerging practice are and what
   alternatives may exist.  The audience for this document is the
   Internet community generally, including the IETF and IPv6

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 6, July 29, 2011.

Copyright Notice

   Copyright (c) 2010 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  How DNS Whitelisting Works . . . . . . . . . . . . . . . . . .  5
   3.  Concerns Regarding DNS Whitelisting  . . . . . . . . . . . . .  7
   4.  Similarities to Split Other DNS Operations . . . . . . . . . . . . .  9
     4.1.  Similarities to Split DNS  . . . . . . . . . . . . . . . .  9
     4.2.  Similarities to DNS Load Balancing . . . . . . . . . . . . 10
   5.  Likely Deployment Scenarios  . . . . . . . . . . . . . . . . . 10 11
     5.1.  Deploying DNS Whitelisting Universally . . . . . . . . . . 10 11
     5.2.  Deploying DNS Whitelisting On An Ad Hoc Basis  . . . . . . 11 12
   6.  What Problems Are DNS Whitelisting Implementers Trying To
       Solve? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13
   7.  Implications of DNS Whitelisting . . . . . . . . . . . . . . . 12 13
     7.1.  Architectural Implications . . . . . . . . . . . . . . . . 12 13
     7.2.  Public IPv6 Address Reachability Implications  . . . . . . 13 14
     7.3.  Operational Implications . . . . . . . . . . . . . . . . . 13 15
       7.3.1.  De-Whitelisting May Occur  . . . . . . . . . . . . . . 13 15
       7.3.2.  Authoritative DNS Server Operational Implications  . . 13 16
       7.3.3.  DNS Recursive Resolver Server Operational
               Implications . . . . . . . . . . . . . . . . . . . . . 14 16
       7.3.4.  Monitoring Implications  . . . . . . . . . . . . . . . 15 17
       7.3.5.  Implications of Operational Momentum . . . . . . . . . 17
       7.3.6.  Troubleshooting Implications . . . . . . . . . . . . . 15
       7.3.6. 18
       7.3.7.  Additional Implications If Deployed On An Ad Hoc
               Basis  . . . . . . . . . . . . . . . . . . . . . . . . 16 18
     7.4.  Homogeneity May Be Encouraged  . . . . . . . . . . . . . . 16 18
     7.5.  Technology Policy Implications . . . . . . . . . . . . . . 17 19
     7.6.  IPv6 Adoption Implications . . . . . . . . . . . . . . . . 18 20
   8.  Solutions  . . . . . . . . . . . . . . . . . . . . . . . . . . 18 21
     8.1.  Implement DNS Whitelisting Universally . . . . . . . . . . 18 21
     8.2.  Implement DNS Whitelisting On An Ad Hoc Basis  . . . . . . 18 21
     8.3.  Do Not Implement DNS Whitelisting  . . . . . . . . . . . . 19 21
       8.3.1.  Solving Current End User IPv6 Impairments  . . . . . . 19 21
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19 22
     9.1.  DNSSEC Considerations  . . . . . . . . . . . . . . . . . . 20 22
     9.2.  Authoritative DNS Response Consistency Considerations  . . 20 23
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20 23
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 23
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 23
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 24
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 24
     13.2. Informative References . . . . . . . . . . . . . . . . . . 22 25
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 22 26
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 23 26
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 27

1.  Introduction

   [EDITORIAL: This is a rough first -00 draft.  Some sections have not
   yet been completed but will be soon.  Suggestions on all parts of
   this document are eagerly solicited.]

   This document describes the emerging practice of whitelisting of DNS
   AAAA resource records (RRs), or DNS whitelisting for short.  It also
   explores the implications of this emerging practice are and what
   alternatives may exist.

   The practice of DNS whitelisting appears to have first been used by
   major web content sites. sites, such as Google's various websites.  These
   web site operators operators, or domain operators, observed that when they
   added AAAA RRs to their authoritative DNS servers that a small
   fraction of end users had slow or otherwise impaired access to a
   given web site with both AAAA and A RRs.  The fraction of users with
   such impaired access has been estimated to be roughly 0.078% of total
   Internet users [IETF 77 DNSOP WG Presentation] [Network World Article
   on IETF 77 DNSOP WG Presentation].  Thus, in an example Internet
   Service Provider (ISP) network of 10 million users, approximately
   7,800 of those users may experience such impaired access.

   As a result of this impairment affecting end users of a given domain,
   a few large web site operators domains have begun to either implement DNS whitelisting
   or strongly consider the implementation of DNS whitelisting [Network
   World Article on DNS Whitelisting]. Whitelisting] [IPv6 Whitelist Operations].  When
   implemented, DNS whitelisting in practice means that a domain's
   authoritative DNS will return a AAAA RR to DNS recursive resolvers
   [RFC1035] on the whitelist, while returning no AAAA RRs to DNS
   resolvers which are not on the whitelist.  It is important to note
   that these web site operators are motivated to maintain a high-
   quality user experience for all of their users, and that they are
   attempting to shield users with impaired access from the symptoms of
   these impairments that would negatively affect their access to
   certain websites and related Internet resources.

   [EDITORIAL: change web site operators --> domain operators?]

   However, critics of this emerging practice of DNS whitelisting have
   articulated several concerns.  Among these are that this is a very
   different behavior from the current practice concerning the
   publishing of IPv4 address records, that it may create a two-tiered
   Internet, that policies concerning whitelisting and de-whitelisting
   are opaque, that DNS whitelisting reduces interest in the deployment
   of IPv6, that new operational and management burdens are created, and
   that the costs and negative implications of DNS whitelisting outweigh
   the perceived benefits as compared to fixing underlying impairments.

   This document explores the reasons and motivations for DNS
   whitelisting.  It also explores the concerns regarding this emerging
   practice.  As a result, readers can hopefully better understand what
   DNS whitelisting is, why some parties are implementing it, and why
   other parties are critical of the practice.

2.  How DNS Whitelisting Works

   DNS whitelisting is implemented in authoritative DNS servers, where
   those servers implement IP address-based restrictions on AAAA query
   responses, which contain IPv6 addresses.  In practice DNS
   whitelisting has been primarily implemented by web server operators.
   For a given operator of the website www.example.com, that operator
   essentially applies an access control list (ACL) on their
   authoritative DNS servers, which are authoritative for the domain
   example.com.  The ACL is then configured with the IPv4 and/or IPv6
   addresses of DNS recursive resolvers on the Internet, which have been
   authorized to be added to the ACL and to therefore receive AAAA RR
   responses.  These DNS recursive resolvers are operated by other
   parties, such as ISPs, universities, governments, businesses,
   individual end users, etc.  If a DNS recursive resolver IS NOT on the
   ACL, then NO AAAA RRs with IPv6 addresses will be sent in response to
   a query for a given hostname in the example.com domain.  However, if
   a DNS recursive resolver IS on the ACL, then AAAA RRs with IPv6
   addresses will be sent in response to a query for a given hostname in
   the example.com domain.  While these are not network-layer access
   controls, they are nonetheless access controls that are a factor for
   both end users and are directly related to the transition of one
   network address family to another (IPv4 to IPv6).

   In practice this generally means that a very small fraction of the
   DNS recursive resolvers on the Internet can receive AAAA responses
   with IPv6 addresses, which means that the large majority of DNS
   resolvers on the Internet will receive only A RRs with IPv4
   addresses.  Thus, quite simply, the authoritative server hands out
   different answers depending upon who is asking; with IPv4 and IPv6
   records for some on the authorized whitelist, and only IPv4 records
   for everyone else.  See Figure 1 and Figure 2 for two different
   visual descriptions of how this works in practice.

   Finally, DNS whitelisting can be deployed in two primary ways:
   universally on a global basis, or on an ad hoc basis.  These two
   potential deployment models are described in Section 5.

   1: The authoritative DNS server for example.com receives a DNS
      query for www.example.com, for which both A (IPv4) and AAAA
      (IPv6) address records exist.
   2: The authoritative DNS server examines the IP address of the DNS
      recursive resolver sending the query.
   3: The authoritative DNS server checks this IP address against the
      access control list (ACL) that is the DNS whitelist.
   4: If the DNS recursive resolver's IP address IS listed in the ACL,
      then the response to that specific DNS recursive resolver can
      contain both A (IPv4) and AAAA (IPv6) address records.
   5: If the DNS recursive resolver's IP address IS NOT listed in the
      ACL, then the response to that specific DNS recursive resolver
      can contain only A (IPv4) address records and therefore cannot
      contain AAAA (IPv6) address records.

                 Figure 1: DNS Whitelisting - System Logic

   A query is sent from a DNS recursive resolver that IS NOT on the DNS

               Request                      Request
           www.example.com                  www.example.com
                 AAAA    +-------------+     AAAA    +-----------------+
     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
     ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
   +--------+     A      | example.com |      A      |                 |
      Host    <--------- |  WHITELIST  |  <--------- |                 |
    Computer   A Record  +-------------+  A Record   +-----------------+
               Response   DNS Recursive   Response       example.com
              (only IPv4)   Resolver       (IPv4)     (only IPv4)    Authoritative
                              #1                           Server
   A query is sent from a DNS recursive resolver that IS on the DNS

               Request                      Request
           www.example.com                  www.example.com
                AAAA     +-------------+     AAAA    +-----------------+
     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
     ||  ||       A      |   **IS**    |      A      | IN A exists     |
   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
   +--------+   AAAA     | example.com |     AAAA    |                 |
      Host    <--------- |  WHITELIST  |  <--------- |                 |
    Computer      A      |             |      A      |                 |
              <--------- |             |  <--------- |                 |
              A and AAAA +-------------+ A and AAAA  +-----------------+
               Record     DNS Recursive   Record        example.com
              Responses     Resolver     Responses      Authoritative
              (IPv4+IPv6)      #2        (IPv4+IPv6)       Server

              Figure 2: DNS Whitelisting - Functional Diagram

3.  Concerns Regarding DNS Whitelisting

   There are a number of potential implications relating to DNS
   whitelisting, which have raised various concerns in some parts of the
   Internet community.  Many of those potential implications are
   described in Section 7.

   Some parties in the Internet community community, including ISPs like Comcast,
   are concerned that this emerging practice of DNS whitelisting for
   IPv6 address records could represent a departure from the generally
   accepted practices regarding IPv4 address records in the DNS on the Internet.
   Internet [IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?].
   These parties explain their belief that for A records, containing
   IPv4 addresses, once an authoritative server operator adds the A
   record to the DNS, then any DNS recursive resolver on the Internet
   can receive that A record in response to a query.  By extension, this
   means that any of the hosts connected to any of these DNS recursive
   resolvers can receive the IPv4 address records for a given FQDN.
   This enables new server hosts which are connected to the Internet,
   and for which a fully qualified domain name (FQDN) such as
   www.example.com has been added to the DNS with an IPv4 address
   record, to be almost immediately reachable by any host on the
   Internet.  In this case, these new servers hosts become more and more
   widely accessible as new networks and new end user hosts connect to
   the Internet over time [EDITORIAL: consider reference to network
   effects].  It also means that the new server hosts do not need to
   know about these new networks and new end user hosts in order to make
   their content and applications available to them, in essence that
   each end in this end-
   to-end end-to-end model is responsible for connecting to
   the Internet and once they have done so they can connect to each
   other without additional impediments or middle networks or
   intervening networks or servers knowing about these end points and
   whether one is allowed to contact the other.

   In contrast, these parties are concerned that DNS whitelisting may
   fundamentally change this model.  As a result, in this altered end-
   to-end model, one end (where the end user is located) cannot readily
   connect to the other end (where the content is located), without
   parts of the middle used by one end being known by the other end and
   approved for access to that end.  Thus, as new networks connect to
   the Internet over time, those networks need to contact any and all
   domains which have implemented DNS whitelisting in order to apply to
   be added to their DNS whitelist, in the hopes of making the content
   and applications residing on named server hosts in those domains
   accessible by the end user hosts on that new network.  Furthermore,
   this same need to contact all domains implementing DNS whitelisting
   also applies to all existing networks connected to the Internet.

   Therefore, these concerned parties explain, whereas in the current
   IPv4 Internet when a new server host is added to the Internet it is
   widely available to all end user hosts and networks, when DNS
   whitelisting of IPv6 records is used then these new server hosts are
   not accessible to any end user hosts or networks until such time as
   the operator of the authoritative DNS servers for those new server
   hosts expressly authorizes access to those new server hosts by adding
   DNS recursive resolvers around the Internet to the ACL.  This could
   represent a significant change in reachability of content and
   applications by end users and networks as these end user hosts and
   networks transition to IPv6.  Therefore, a concern expressed is that
   if much of the content that end users are most interested in is not
   accessible as a result, then end users and/or networks may resist
   adoption of IPv6 or actively seek alternatives to it, such as using
   multi-layer network address translation (NAT) techniques like NAT444
   [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
   that this practice also could disrupt the continued increase in
   Internet adoption by end users if they cannot simply access new
   content and applications but must instead contact the operator of
   their DNS recursive resolver, such as their ISP or another third
   party, to have their DNS recursive resolver authorized for access to
   the content or applications that interests them.  Meanwhile, these
   parties say, over 99.9% of all other end users that are also using
   that same network or DNS recursive resolver are unable to access the
   IPv6-based content, despite their experience being a positive one.

   [EDITORIAL: Are there additional concerns to add here?]

4.  Similarities to Split DNS

   DNS whitelisting as described herein is

   While in some ways similar to so-
   called Section 1 the level of IPv6-related impairment has been
   estimated to be as high as 0.078% of Internet users, which is a
   primary motivation cited for the practice of DNS whitelisting, it is
   not clear if the level of IPv4-related impairment is more or less
   that this percentage (which in any case is likely to have declined
   since its original citation).  Indeed, as at least one document
   reviewer has pointed out, it may simply be that websites are only
   measuring IPv6 impairments and not IPv4 impairments, whether because
   IPv6 is new or whether those websites are simply unable to or are
   otherwise not in a position to be able to measure IPv4 impairment
   (since this could result in no Internet access whatsoever).  As a
   result, it is worth considering that IPv4-related impairment could
   exceed that of IPv6-related impairment and that such IPv4-related
   impairment may have simply been accepted as "background noise" on the
   Internet for a variety of reasons.

4.  Similarities to Other DNS Operations

   Some aspects of DNS whitelisting may be considered similar in some
   ways to other common DNS operational techniques, which is explored
   briefly below.

4.1.  Similarities to Split DNS

   DNS whitelisting has some similarities to so-called split DNS, which
   is briefly described in Section 3.8 of [RFC2775].  When split DNS is
   used, the authoritative DNS server returns different responses
   depending upon what host has sent the query.  While [RFC2775] notes
   the typical use of split DNS is to provide one answer to hosts on an
   Intranet and a different answer to hosts on the Internet, the essence
   is that different answers are provided to hosts on different
   networks.  This is basically the way that DNS whitelisting works, in
   so far as hosts of different networks, which use different DNS
   recursive resolvers, receive different answers if one DNS recursive
   resolver is on the whitelist and the other is not.  Thus, in a way,
   DNS whitelisting could in some ways be considered split DNS on the
   public Internet, though with some differences.

   In [RFC2956], Internet transparency and Internet fragmentation
   concerns regarding split DNS are detailed in Section 2.1.  [RFC2956]
   further notes in Section 2.7, concerns regarding split DNS and that
   it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint
   identifiers more complex."  Section 3.5 of [RFC2956] further
   recommends that maintaining a stable approach to DNS operations is
   key during transitions such as the one to IPv6 that is underway now,
   stating that "Operational stability of DNS is paramount, especially
   during a transition paramount, especially
   during a transition of the network layer, and both IPv6 and some
   network address translation techniques place a heavier burden on

4.2.  Similarities to DNS Load Balancing

   DNS whitelisting also has some similarities to DNS load balancing.
   There are many ways that DNS load balancing can be performed, and of
   course this can mean many things to different people.  In one
   example, multiple IP address resource records (A or AAAA) can be
   added to the DNS to resolve a given FQDN, which is referred to as DNS
   round robin [REFERENCE AVAILABLE?].  In another example, one or more
   of the IP address resource records in the DNS will direct traffic to
   a load balancer [REFERENCE AVAILABLE?].  That load balancer, in turn,
   may be application-aware, and pass the traffic on to one or more
   hosts connected to the load balancer which have different IP
   addresses.  In cases where private IPv4 addresses are used [RFC1918],
   as well as when public IP addresses are used, those end hosts may not
   be directly reachable without passing through the load balancer first
   .  As such, while the IP address resource records have been added to
   the DNS, the end hosts are not necessarily directly reachable, which
   is in a small way similar to one aspect of DNS whitelisting.  In
   addition, a geographically-aware authoritative DNS server may be
   used, as is common with Content Delivery Networks (CDNs), whereby the
   IP address resource records returned to a resolver in response to a
   query will vary based on the estimated geographic location of the
   resolver [REFERENCE AVAILABLE?].  CDNs perform this function in order
   to attempt to direct hosts to connect to the nearest content cache.
   As a result, one can see some similarities with DNS whitelisting
   insofar as different IP address resource records are returned to
   resolvers based on the IP address of each resolver (or other imputed
   factors related to that IP address).  However, what is different of
   course, if that in this case the network layer, and both IPv6 and some
   network address translation techniques place resolvers are not necessarily
   blocked from receiving DNS responses containing an entire class of
   addresses; this load balancing function strives to perform a heavier burden on
   DNS." content
   location-improvement function and not an access control function.

5.  Likely Deployment Scenarios

   In considering how DNS whitelisting may emerge more widely, there are
   two likely deployment scenarios, which are explored below.

   In either of these likely deployment scenarios below, it is possible
   that reputable third parties could create and maintain these DNS
   whitelists, in much the same way that blacklists are used for
   reducing email spam.  In this email example, a mail operator
   subscribes to one or more of these lists and as such the operational
   processes for additions and deletions to the list are managed by a
   third party.  Thus, a similar model could emerge for DNS
   whitelisting, whether deployment occurs universally or on an ad hoc

5.1.  Deploying DNS Whitelisting Universally

   The least likely deployment scenario is one where DNS whitelisting
   becomes a standardized process across all authoritative DNS servers,
   across the entire Internet.  While this scenario is the least likely,
   due to some parties not sharing the concerns that have so far
   motivated the use of DNS whitelisting, it is nonetheless conceivable
   that it could be one of the ways in which DNS whitelisting may be

   In order for this deployment scenario to occur, it is likely that DNS
   whitelisting functionality would need to be built into all
   authoritative DNS server software, and that all operators of
   authoritative DNS servers would have to upgrade their software and
   enable this functionality.  Furthermore, it is likely that new
   Internet Draft documents would need to be developed which describe
   how to properly configure, deploy, and maintain DNS whitelisting.  As
   a result, it is unlikely that DNS whitelisting would, at least in the
   next several years, become universally deployed.  Furthermore, these
   DNS whitelists are likely to vary on a domain-by-domain basis,
   depending upon a variety of factors.  Such factors may include the
   motivation of each domain owner, the location of the DNS recursive
   resolvers in relation to the source content, as well as various other
   parameters that may be transitory in nature, or unique to a specific
   end user host type.  Thus, it is probably unlikely that a single
   clearinghouse for managing whitelisting is possible; it will more
   likely be unique to the source content owners and/or domains which
   implement DNS whitelists.

   While this scenario may be unlikely, it may carry some benefits.
   First, parties performing troubleshooting would not have to determine
   whether or not DNS whitelisting was being used, as it always would be
   in use.  In addition, if universally deployed, it is possible that
   the criteria for being added to or removed from a DNS whitelist could
   be standardized across the entire Internet.  Nevertheless, even if
   uniform DNS whitelisting policies were not standardized, is also
   possible that a central registry of these policies could be developed
   and deployed in order to make it easier to discover them, a key part
   of achieving transparency regarding DNS whitelisting.

   [EDITORIAL: Are there additional benefits or challenges to add here?]

5.2.  Deploying DNS Whitelisting On An Ad Hoc Basis

   This is the most likely deployment scenario for DNS whitelisting, as
   it seems today, is where some interested parties engage in DNS
   whitelisting but many or most others do not do so.  What can make
   this scenario challenging from the standpoint of a DNS recursive
   resolver operator is determining which domains implement DNS
   whitelisting, particularly since a domain may not do so as they
   initially transition to IPv6, and may instead do so later.  Thus, a
   DNS recursive resolver operator may initially believe that they can
   receive AAAA responses with IPv6 addresses as a domain adopts IPv6,
   but then notices via end user reports that they no longer receive
   AAAA responses due to that site adopting DNS whitelisting.

   Thus, in contrast to universal deployment of DNS whitelisting,
   deployment on an ad hoc basis is likely to be significantly more
   challenging from an operational, monitoring, and troubleshooting
   standpoint.  In this scenario, a DNS recursive resolver operator will
   have no way to systematically determine whether DNS whitelisting is
   or is not implemented for a domain, since the absence of AAAA records
   with IPv6 addresses may simply be indicative that the domain has not
   yet added IPv6 addressing for the domain, not that they have done so
   but have restricted query access via DNS whitelisting.  As a result,
   discovering which domains implement DNS whitelisting, in order to
   differentiate them from those that do not, is likely to be

   On the other hand, one benefit of DNS whitelisting being deployed on
   an ad hoc basis is that only the domains that are interested in doing
   so would have to upgrade their authoritative DNS servers in order to
   implement the ACLs necessary to perform DNS whitelisting.

   [EDITORIAL: Additional benefits or challenges to add?]

6.  What Problems Are DNS Whitelisting Implementers Trying To Solve?

   As noted in Section 1, domains which implement DNS whitelisting are
   attempting to protect a few users of their domain, which happen to
   have impaired IPv6 access, from having a negative end user
   experience.  While it is outside the scope of this document to
   explore the various reasons why a particular user may experience
   impaired IPv6 access, for the users which experience this it is a
   very real effect and would of course affect access to all or most
   IPv4 and IPv6 dual stack servers.  This negative end user experience
   can range from someone slower than usual (as compared to native IPv4-
   based access), to extremely slow, to no access to the domain

   Thus, parties which implement DNS whitelisting are attempting to
   provide a good experience to these end users.  While one can debate
   whether DNS whitelisting is the optimal solution, it is quite clear
   that DNS whitelisting implementers are extremely interested in the
   performance of their services for end users as a primary motivation.

   [EDITORIAL 1: More motivations

   In addition, Google has noted that they have received requests to add?]

   [EDITORIAL 2:Any good external references not
   send DNS responses with AAAA resource records to consider adding?] particular
   resolvers.  In these cases, the operators of those recursive
   resolvers have expressed a concern that their IPv6 network
   infrastructure is not yet ready to handle the traffic volume which
   may be associated with the hosts in their network connecting to
   Google websites, such as YouTube.  In this case, this is clearly a
   temporary concern relating to the deployment of IP network
   infrastructure on the part of networks with end user hosts, rather
   than a long-term concern.  These end user networks may also have
   other tools at their disposal in order to address this, including
   applying rules to network equipment such as routers and firewalls
   (this will necessarily vary by the type of network, as well as the
   technologies used and the design of a given network).

7.  Implications of DNS Whitelisting

   There are many potential implications of DNS whitelisting.  In the
   sections below, the key potential implications are listed in some

7.1.  Architectural Implications

   DNS whitelisting could be perceived as somewhat modifying the end-to-
   end model and/or the general notion of the architecture that prevails
   on the IPv4 Internet today.  This is because this approach moves
   additional access control information and policies into the middle of
   the network DNS resolution path on the IPv6-addressed Internet, which did not
   exist before on the IPv4-addressed Internet.  This could raise some
   risks noted in [RFC3724], which in explaining the history of the end-
   to-end principle [RFC1958] explains that one of the goals is to
   minimize the state, policies, and other functions needed in the
   middle of the network in order to enable end-to-end communications on
   the Internet.  In this case, the middle network should be understood
   to mean anything other than the end hosts involved in communicating
   with one another.  Obviously some state, policies, and other
   functions have always been necessary to enable such end-to-end
   communication, but the goal of the approach has been to minimize this
   to the greatest extent possible.

   It is also possible that DNS whitelisting could place at risk some of
   the benefits of the end-to-end principle, as listed in Section 4.1 of
   [RFC3724], such as protection of innovation.  Further, while
   [RFC3234] details issues and concerns regarding so-called
   middleboxes, there may be parallels to DNS whitelisting, especially
   concerning modified DNS servers noted in Section 2.16 of [RFC3234],
   and more general concerns noted in Section 1.2 of [RFC3234] about the
   introduction of new failure modes, that configuration is no longer
   limited to two ends of a session, and that diagnosis of failures and
   misconfigurations is more complex.

   In [Tussle in Cyberspace], the authors note concerns regarding the
   introduction of new control points, as well as "kludges" to the DNS,
   as risks to the goal of network transparency in the end-to-end model.
   Some parties concerned with the emerging use of DNS whitelisting have
   shared similar concerns, which may make [Tussle in Cyberspace] an
   interesting and relevant document.  In addition, [Rethinking the
   design of the Internet] reviews similar issues that may be of
   interest to readers of this document.

   In order to explore and better understand these high-level
   architectural implications and concerns in more detail, the following
   sections explore more specific potential implications.

7.2.  Public IPv6 Address Reachability Implications

   The predominant experience of end user hosts and servers on the IPv4-
   addressed Internet today is that, very generally speaking, when a new
   server with a public IPv4 address is added, that it is then globally
   accessible by IPv4-addressed hosts.  For  Of course, this is a
   generalization and in Section 4 there are examples of common cases
   where this may not necessarily be the case.  In any case, for the
   purposes of this document, that concept of accessibility can be
   considered "pervasive reachability".  It has so far been assumed that
   the same expectations of pervasive reachability would exist in the
   IPv6-addressed Internet.  However, if DNS whitelisting is deployed,
   this will not be the case since only end user hosts using DNS
   recursive resolvers which have been added to the ACL of a given
   domain using DNS whitelisting would be able to reach new servers in
   that given domain via IPv6 addresses.  Thus, the expectation of any
   end user host being able to connect to any server (essentially both
   hosts, just at either end of the network), defined here as "pervasive
   reachability", will change to "restricted reachability" with IPv6.

   In addition, establishing DNS whitelisting as an accepted practice in
   the early phases of mass IPv6 deployment could well establish DNS
   whitelisting as an integral part of how IPv6 is deployed globally.
   As a result, it is then possible that DNS whitelisting could live on
   for decades on the Internet as a key foundational element of the
   Internet of the future that we will all live with for a long time.

   However, it is a critical to understand that the concept of
   reachability described above depends upon a knowledge or awareness of
   an address in the DNS.  Thus, in order to establish reachability
   would exist to
   an end point, a host is dependent upon looking up an IP address in
   the IPv6-addressed Internet.  However, if DNS when a FQDN is used.  Thus, when DNS whitelisting is deployed, this will not be used, it
   is quite likely the case since only that a end user hosts using DNS recursive resolvers which have been added to host could ping a example
   server host, even though the
   ACL of FQDN associated with that server host is
   restricted via a given domain using DNS whitelisting would be able to reach
   new whitelist.  But since most Internet applications
   and hosts such as web servers in that given domain via IPv6 addresses.

   Thus, depend upon the expectation of any DNS, and as end user host being able to users
   connect to
   any server (essentially both hosts, just at either end of FQDNs such as www.example.com and do not remember or wish
   to type in an IP address, the
   network), defined notion of reachability described here as "pervasive reachability", will change
   should be understood to
   "restricted reachability" include knowledge how to associate a name
   with IPv6.

   [EDITORIAL: Additional implications?] a network address.

7.3.  Operational Implications

   This section explores some of the operationally related implications
   which may occur as a result of, related to, or necessary when
   engaging in the practice of DNS whitelisting.

7.3.1.  De-Whitelisting May Occur

   If it is possible for a DNS recursive resolver to be added to a
   whitelist, then it is also possible for that resolver to be removed
   from the whitelist, also known as de-whitelisting.  Since de-
   whitelisting can occur, whether through a decision by the
   authoritative server operator or the domain owner, or even due to a
   technical error, an operator of a DNS recursive resolver will have
   new operational and monitoring requirements and/or needs as noted in
   Section 7.3.3, Section 7.3.4, Section 7.3.5, 7.3.6, and Section 7.5.

7.3.2.  Authoritative DNS Server Operational Implications

   Operators of authoritative servers may need to maintain an ACL a
   server-wide basis affecting all domains, on a domain-by-domain basis,
   as well as on a combination of the two.  As a result, operational
   practices and software capabilities may need to be developed in order
   to support such functionality.  In addition, processes may need to be
   put in place to protect against inadvertently adding or removing IP
   addresses, as well as systems and/or processes to respond to such
   incidents if and when they occur.  For example, a system may be
   needed to record DNS whitelisting requests, report on their status
   along a workflow, add IP addresses when whitelisting has been
   approved, remove IP addresses when they have been de-whitelisted, log
   the personnel involved and timing of changes, schedule changes to
   occur in the future, and to roll back any inadvertent changes.

   Such operators may also need implement new forms of monitoring in
   order to apply change control, as noted briefly in Section 7.3.4.

   [EDITORIAL: Additional implications?]

7.3.3.  DNS Recursive Resolver Server Operational Implications

   Operators of DNS recursive resolvers, which may include ISPs,
   enterprises, universities, governments, individual end users, and
   many other parties, are likely to need to implement new forms of
   monitoring, as noted briefly in Section 7.3.4.  But more critically,
   such operators may need to add people, processes, and systems in
   order to manage countless DNS whitelisting applications, for all
   domains that the end users of such servers are interested in now or
   in which they may be interested in the future.  As such anticipation
   of interesting domains is likely infeasible, it is more likely that
   such operators may either choose to only apply to be whitelisted for
   a domain based upon one or more end user requests, or that they will
   attempt to do so for all domains.

   When such operators apply for DNS whitelisting for all domains, that
   may mean doing so for all registered domains.  Thus, some system
   would have to be developed to discover whether each domain has been
   whitelisted or not, which is touched on in Section 5 and may vary
   depending upon whether DNS whitelisting is universally deployed or is
   deployed on an ad hoc basis.

   Furthermore, these operators will need to develop processes and
   systems to track the status of all DNS whitelisting applications,
   respond to requests for additional information related to these
   applications, determine when and if applications have been denied,
   manage appeals, and track any de-whitelisting actions.  Given the
   incredible number of domains in existence, the ease with which a new
   domain can be added, and the continued strong growth in the numbers
   of new domains, readers should not underestimate the potential
   significance in personnel and expense that this could represent for
   such operators.  In addition, it is likely that systems and personnel
   may also be needed to handle new end user requests for domains for
   which to apply for DNS whitelisting, and/or inquiries into the status
   of a whitelisting application, reports of de-whitelisting incidents,
   general inquiries related to DNS whitelisting, and requests for DNS
   whitelisting-related troubleshooting by these end users.

   [EDITORIAL: Additional implications?]

7.3.4.  Monitoring Implications

   Once a DNS recursive resolver has been whitelisted for a particular
   domain, then the operator of that DNS recursive resolver may need to
   implement monitoring in order to detect the possible loss of
   whitelisting status in the future.  This DNS recursive resolver
   operator could configure a monitor to check for a AAAA response in
   the whitelisted domain, as a check to validate continued status on
   the DNS whitelist.  The monitor could then trigger an alert if at
   some point the AAAA responses were no longer received, so that
   operations personnel could begin troubleshooting, as outlined in
   Section 7.3.5. 7.3.6.

   Also, authoritative DNS server operators are likely to need to
   implement new forms of monitoring.  In this case, they may desire to
   monitor for significant changes in the size of the whitelist within a
   certain period of time, which might be indicative of a technical
   error such as the entire ACL being removed.  These operators may also
   wish to monitor their workflow process for reviewing and acting upon
   DNS whitelisting applications and appeals, potentially measuring and
   reporting on service level commitments regarding the time an
   application or appeal can remain at each step of the process,
   regardless of whether or not such information is shared with parties
   other than that authoritative DNS server operator.

   These are but a few examples of the types of monitoring types of monitoring that may be
   called for as a result of DNS whitelisting, among what are likely
   many other types and variations.

7.3.5.  Implications of Operational Momentum

   It seems plausible that once DNS whitelisting is implemented it will
   be very difficult to deprecate such technical and operational
   practices.  This assumption is based in an understanding of human
   nature, not to mention physics.  For example, as Sir Issac Newton
   noted, "Every object in a state of uniform motion tends to remain in
   that state of motion unless an external force is applied to it"
   [Newton's Laws of Motion].  Thus, once DNS whitelisting is
   implemented it is quite likely that it would take considerable effort
   to deprecate the practice and remove it everywhere on the Internet -
   it will otherwise simply remain in place in perpetuity.  To better
   illustrate this point, one could consider in one example (of many)
   that may be
   called for as a result of DNS whitelisting, among what here are likely many other types and variations.

   [EDITORIAL: Additional implications?]

7.3.5. email servers continuing to attempt to
   query or otherwise check anti-spam DNS blocklists which have long ago
   ceased to exist.

7.3.6.  Troubleshooting Implications

   The implications of DNS whitelisted present many challenges, which
   have been detailed in Section 7.  These challenges may negatively
   affect the end users' ability to troubleshoot, as well as that of DNS
   recursive resolver operators, ISPs, content providers, domain owners
   (where they may be different from the operator of the authoritative
   DNS server for their domain), and other third parties.  This may make
   the process of determining why a server is not reachable
   significantly more complex.


   [EDITORIAL: Additional implications?]


7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis



   Additional implications?] implications, should this be deployed on an ad hoc basis,
   could include scalability problems relating to operational processes,
   monitoring, and ACL updates.  In particular, it seems quite likely
   that as the number of domains that are whitelisted increases, as well
   as the number of IPv6-capable networks requesting to be whitelisted,
   that there is an increased likelihood of configuration and other
   operational errors, especially with respect to the ACLs themselves.
   It is also unclear when and if it would be appropriate to change from
   whitelisting to blacklisting, and whether/how this could feasibly be
   coordinated across the Internet, which may be proposed when a
   majority of networks (or allocated IPv6 address blocks) have been
   whitelisted.  Finally, some parties implementing DNS whitelisting
   consider this to be a temporary measure.  As such, it is not clear
   how these parties will judge the network conditions to have changed
   sufficiently to justify disabling DNS whitelisting and/or what the
   process and timing will be in order to turn off and stop this

7.4.  Homogeneity May Be Encouraged

   A broad trend which has existed on the Internet appears to be a move
   towards increasing levels of heterogeneity.  One manifestation of
   this is in an increasing number, variety, and customization of end
   user hosts, including home network, operating systems, client
   software, home network devices, and personal computing devices.  This
   trend appears to have had a positive effect on the development and
   growth of the Internet.  A key facet of this that has evolved is the
   ability of the end user to connect any technically compliant device
   or use any technically compatible software to connect to the
   Internet.  Not only does this trend towards greater heterogeneity
   reduce the control which is exerted in the middle of the network,
   described in positive terms in [Tussle in Cyberspace], [Rethinking
   the design of the Internet], and [RFC3724], but it can also help to
   enable greater and more rapid innovation at the edges.

   An unfortunate implication of the adoption of DNS whitelisting may be
   the encouragement of a reversal of this trend, which would be a move
   back towards greater levels of homogeneity.  In this case, a domain
   owner which has implemented DNS whitelisting may prefer greater
   levels of control be exerted over end user hosts (which broadly
   includes all types of end user software and hardware) in order to
   attempt to enforce technical standards relating to establishing
   certain IPv6 capabilities or the enforcing the elimination of or
   restriction of certain end user hosts.  While the domain operator is
   attempting to protect, maintain, and/or optimize the end user
   experience for their domain, the collective result of many domains
   implementing DNS whitelisting, or even a few important major domains (meaning
   domains which are a major destination of Internet traffic)
   implementing DNS whitelisting, may be to encourage a return to more
   homogenous and/or controlled end user hosts.  Unfortunately, this
   could have unintended side effects on and counter-productive
   implications for future innovation at the edges of the network.

7.5.  Technology Policy Implications

   A key technology policy implication concerns the policies relating to
   the process of reviewing an application for DNS whitelisting, and the
   decision-making process regarding whitelisting for a domain.
   Important questions may include whether these policies have been
   fully and transparently disclosed, are non-discriminatory, and are
   not anti-competitive.  A related implication is whether and what the
   process for appeals is, when a domain decides not to add a DNS
   recursive resolver to the whitelist.  Key questions here may include
   whether appeals are allowed, what the process is, what the expected
   turn around time is, and whether the appeal will be handled by an
   independent third party or other entity/group.

   A further implications arises when de-whitelisting occurs.  Questions
   that may naturally be raised in such a case include whether the
   criteria for de-whitelisting have been fully and transparently
   disclosed, are non-discriminatory, and are not anti-competitive.
   Additionally, the question of whether or not there was a cure period
   available prior to de-whitelisting, during which troubleshooting
   activities, complaint response work, and corrective actions may be
   attempted, and whether this cure period was a reasonable amount of

   It is also conceivable that whitelisting and de-whitelisting
   decisions could be quite sensitive to concerned parties beyond the
   operator of the domain which has implemented DNS whitelisting and the
   operator of the DNS recursive resolver, including end users,
   application developers, content providers, advertisers, public policy
   groups, governments, and other entities, which may also seek to
   become involved in or express opinions concerning whitelisting and/or
   de-whitelisting decisions.  Lastly, it is conceivable that any of
   these interested parties or other related stakeholders may seek
   redress outside of the process a domain has establishing for DNS
   whitelisting and de-whitelisting.

   A final concern is that decisions relating to whitelisting and de-
   whitelisting may occur as an expression of other commercial,
   governmental, and/or cultural conflicts, given the new control point
   which has be established with DNS whitelisting.  For example, in one
   imagined scenario, it may be conceivable that one government is
   unhappy with a news story or book published in domain could withhold adding a particular country,
   and that this government may retaliate against or protest this news
   story or book by requiring domains operating within network to their
   DNS whitelisting unless that government's
   territory network agreed to de-whitelist commercial, governmental, or other entities
   involved in or related some sort of financial
   payment, legal agreement, agreement to (however tangentially) publishing the news
   story or book.  By sever a relationship with a
   competitor of the same token, domain, etc.  In another example, a news site operating in multiple
   territories music-oriented
   domain may be unhappy with governmental policies engaged in one
   particular territory some sort of dispute with an academic
   network concerning copyright infringement concerns within that
   network, and may choose to express dissatisfaction in de-whitelist that territory by de-whitelisting commercial, governmental, or other
   entities network as a negotiating
   technique in some sort of commercial discussion.  In a final example,
   a major email domain may choose to de-whitelist a network due to that
   network sending some large volume of spam, which would have the
   effect of preventing other, end users on that network from using
   other, non-email-related applications within that territory. domain.  Thus, it
   seems possible that DNS whitelisting and de-whitelisting could become
   a vehicle for adjudicating other disputes, and that this may well
   have intended and unintended consequences for end users which are
   affected by such decisions and are unlikely to be able to express a
   strong voice in such decisions.

7.6.  IPv6 Adoption Implications

   As noted in Section 3, the implications of DNS whitelisting may drive
   end users and/or networks to delay, postpone, or cancel adoption of
   IPv6, or to actively seek alternatives to it.  Such alternatives may
   include the use of multi-layer network address translation (NAT)
   techniques like NAT444 [I-D.shirasaki-nat444], which these parties
   may decide to pursue on a long-term basis to avoid the perceived
   costs and aggravations related to DNS whitelisting.  This could of
   course come at the very time that the Internet community is trying to
   get these very same parties interested in IPv6 and motivated to begin
   the transition to IPv6.  As a result, parties that are likely to be
   concerned over the negative implications of DNS whitelisting have said they are very could
   logically be concerned of the negative effects that this practice
   could have on the adoption of IPv6 if it became widespread or was
   adopted by key majors Internet domains or other major parties in the
   Internet ecosystem.

   [EDITORIAL: Additional implications?]

8.  Solutions

   This section outline several possible solutions when considering DNS
   whitelisting and associated IPv6-related issues.

8.1.  Implement DNS Whitelisting Universally

   One obvious solution is to implement DNS whitelisted universally, and
   to do so using some sort of centralized registry of DNS whitelisting
   policies, contracts, processes, or other information.  This potential
   solution seems unlikely at the current time.

   [EDITORIAL: More to add?]

8.2.  Implement DNS Whitelisting On An Ad Hoc Basis

   If DNS whitelisting was to be adopted more widely, adopted, it is likely to be adopted on
   this ad hoc, or domain-by-domain basis.  Therefore, only those
   domains interested in DNS whitelisting would need to adopt the
   practice, though as noted herein discovering that they a given domain
   has done so may be problematic.

   [EDITORIAL: More  Also in this scenario, ad hoc use by
   a particular domain may also be a temporary measure that has been
   adopted to ease the transition of the domain to add?] IPv6 over some short-
   term timeframe.

8.3.  Do Not Implement DNS Whitelisting

   As an alternative to adopting DNS whitelisting, the Internet
   community can instead choose to take no action whatsoever,
   perpetuating the current predominant authoritative DNS operational
   model on the Internet, and leave it up to end users with IPv6-related
   impairments to discover and fix those impairments.

8.3.1.  Solving Current End User IPv6 Impairments

   A further extension of not implementing DNS whitelisting, is to also
   endeavor to actually fix the underlying technical problems that have
   prompted the consideration of DNS whitelisting in the first place, as
   an alternative to trying to apply temporary workarounds to avoid the
   symptoms of underlying end user IPv6 impairments.  A first step is
   obviously to identify which users have such impairments, which would
   appear to be possible, and then to communicate this information to
   end users.  Such end user communication is likely to be most helpful
   if the end user is not only alerted to a potential problem but is
   given careful and detailed advice on how to resolve this on their
   own, or where they can seek help in doing so.

   One challenge with this option is the potential difficulty of
   motivating members of the Internet community to work collectively
   towards this goal, sharing the labor, time, and costs related to such
   an effort.  Of course, since just such a community effort is now
   underway for IPv6, it is possible that this would call for only a
   moderate amount of additional work.

   [EDITORIAL: More to add?]

   Despite any potential challenges, many in the Internet community are
   already working towards this goal and/or have expressed a preference
   for this approach.

9.  Security Considerations

   There are no particular security considerations if DNS whitelisting
   is not adopted, as this is how the public Internet works today with A

   However, if DNS whitelisting is adopted, organizations which apply
   DNS whitelisting policies in their authoritative servers should have
   procedures and systems which do not allow unauthorized parties to
   either remove whitelisted DNS resolvers from the whitelist or add
   non-whitelisted DNS resolvers to the whitelist.  Should such
   unauthorized additions or removals from the whitelist can be quite
   damaging, and result in content providers and/or ISPs to incur
   substantial support costs resulting from end user and/or customer
   contacts.  As such, great care must be taken to control access to the
   whitelist for an authoritative server.

   In addition, two other key security-related issues should be taken
   into consideration:

9.1.  DNSSEC Considerations

   DNS security extensions defined in [RFC4033], [RFC4034], and
   [RFC4035] use cryptographic digital signatures to provide origin
   authentication and integrity assurance for DNS data.  This is done by
   creating signatures for DNS data on a Security-Aware Authoritative
   Name Server that can be used by Security-Aware Resolvers to verify
   the answers.  Since DNS whitelisting is implemented on an
   authoritative server, which provides different answers depending upon
   which resolver server has sent a query, the DNSSEC chain of trust is
   not altered.  Therefore there are no DNSSEC implications per se, and
   thus no specific DNSSEC considerations to se.
   However, any implementer of DNS whitelisting should be listed. quite careful
   if they implement both DNSSEC signing of their domain and also DNS
   whitelisting of that same domain.  Specifically, those domains should
   ensure that records are being appropriately and reliably signed,
   which may well prove operationally and/or technically challenging.

9.2.  Authoritative DNS Response Consistency Considerations



   In addition to the considerations raised in Section 9.1 does not contain any specific DNSSEC
   considerations.  However, 9.1, it is certainly
   conceivable that security concerns may arise when end users or other
   parties notice that the responses sent from an authoritative DNS
   server appear to vary from one network or one DNS recursive resolver
   to another.  This may give rise to concerns that, since the
   authoritative responses vary that there is some sort of security
   issue and/or some or none of the
   responses can be trusted. none of the responses can be trusted.  While
   this may seem a somewhat obscure concern, domains nonetheless may
   wish to consider this when contemplating whether or not to pursue DNS

10.  IANA Considerations

   There are no IANA considerations in this document.

11.  Contributors

   The following people made significant textual contributions to this
   document and/or played an important role in the development and
   evolution of this document:

   - John Brzozowski

   - Chris Griffiths

   - Tom Klieber

   - Yiu Lee

   - Rich Woundy

12.  Acknowledgements

   The authors author and contributors also wish to acknowledge the assistance
   of the following individuals individuals.  Some of these people provided helpful
   and important guidance in helping us to develop the development of this document and/or in
   the development of the concepts covered in this document.  Other
   people assisted by performing a detailed review of this document: document, and
   then providing feedback and constructive criticism for revisions to
   this document.  All of this was helpful and therefore the following
   individuals merit acknowledgement:

   - Bernard Aboba

   - Frank Bulk

   - Brian Carpenter

   - Wesley George

   - Erik Kline

   - Danny McPherson

   - Hannes Tschofenig

13.  References

13.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              February 2000.

   [RFC2956]  Kaat, M., "Overview of 1999 IAB Network Layer Workshop",
              RFC 2956, October 2000.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC3724]  Kempf, J., Austein, R., and IAB, "The Rise of the Middle
              and the Future of End-to-End: Reflections on the Evolution
              of the Internet Architecture", RFC 3724, March 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

13.2.  Informative References

              Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "NAT444", draft-shirasaki-nat444-02 draft-shirasaki-nat444-03 (work
              in progress), July 2010. January 2011.

   [IETF 77 DNSOP WG Presentation]
              Gashinsky, I., "IPv6 & recursive resolvers: How do we make
              the transition less painful?", IETF 77 DNS Operations
              Working Group, March 2010,

   [IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?]
              Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y.,
              Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting -
              Could It Hinder IPv6 Adoption?", ISOC Internet Society
              IPv6 Deployment Workshop, April 2010, <http://

   [IPv6 Whitelist Operations]
              Kline, E., "IPv6 Whitelist Operations", Google Google IPv6
              Implementors Conference, June 2010, <http://

   [Network World Article on DNS Whitelisting]
              Marsan, C., "Google, Microsoft, Netflix in talks to create
              shared list of IPv6 users", Network World , March 2010, <h

   [Network World Article on IETF 77 DNSOP WG Presentation]
              Marsan, C., "Yahoo proposes 'really ugly hack' to DNS",
              Network World , March 2010, <http://www.networkworld.com/

   [Newton's Laws of Motion]
              Newton, I., "Mathematical Principles of Natural Philosophy
              (Philosophiae Naturalis Principia Mathematica)",
              Principia Mathematical Principles of Natural Philosophy
              (Philosophiae Naturalis Principia Mathematica), July 1687,

   [Rethinking the design of the Internet]
              Blumenthal, M. and D. Clark, "Rethinking the design of the
              Internet: The end to end arguments vs. the brave new
              world", ACM Transactions on Internet Technology Volume 1,
              Number 1, Pages 70-109, August 2001, <http://

   [Tussle in Cyberspace]
              Braden, R., Clark, D., Sollins, K., and J. Wroclawski,
              "Tussle in Cyberspace: Defining Tomorrow's Internet",
              Proceedings of ACM Sigcomm 2002, August 2002, <http://

Appendix A.  Document Change Log

   [RFC Editor: This section is to be removed before publication]

   -01: Incorporated feedback received from Brian Carpenter (from 10/19/
   2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010).
   Also added an informative reference at the suggestion of Wes George
   (from from 10/22/2010).  Closed out numerous editorial notes, and
   made a variety of other changes.

   -00: First version published as a v6ops WG draft.  The preceding
   individual draft was
   draft-livingood-dns-whitelisting-implications-01.  IMPORTANT TO NOTE
   that no changes have been made yet based on WG and list feedback.
   These are in queue for a -01 update.

Appendix B.  Open Issues

   [RFC Editor: This section is to be removed before publication]

   1.   Incorporate  Close the issues below and any feedback received at IETF 79

   2.   Incorporate feedback from Erik Kline, received 10/1/2010

   3.   Incorporate feedback the v6ops and dnsop
       mailing lists in a -02 update, then request WGLC

   2.  Perform an second review of notes from Brian Carpenter, received 10/19/2010

   4.   Incorporate IETF 79 to ensure that all
       feedback from Wesley George, received 10/XX/2010

   5.   Bring on new contributors: Hannes Tschofenig and Danny McPherson then has so far offered to contribute.

   6.   Close out any EDITORIAL notes

   7. been fully taken into account!

   3.  Add any good references throughout the document

   8.   Add reviewers - posed in
       question to the acknowledgements section

   9. v6ops

   4.  Ensure references are in the proper section (normative/


   5.  Include a number of references from RFC3724?

   11.  Call DNS WL something else or add note

   6.  Add brokenness reference to

   7.  Should I include a full list or other details of the effect that this
        is unrelated to DNS WL used for email root causes
       of IPv6 brokenness? - such as www.dnswl.org posed in question to v6ops

Author's Address

   Jason Livingood
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103

   Email: jason_livingood@cable.comcast.com
   URI:   http://www.comcast.com