draft-ietf-v6ops-v6-aaaa-whitelisting-implications-04.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational May 29, 2011 Intended status: Informational May 30, 2011
Expires: November 30, 2011 Expires: December 1, 2011
IPv6 AAAA DNS Whitelisting Implications IPv6 AAAA DNS Whitelisting Implications
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-04 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05
Abstract Abstract
The objective of this document is to describe the practice of The objective of this document is to describe the practice of
whitelisting of DNS recursive resolvers in order to limit AAAA whitelisting of DNS recursive resolvers in order to limit AAAA
resource records responses, which contain IPv6 addresses, hereafter resource records responses, which contain IPv6 addresses, hereafter
referred to as DNS Whitelisting, as well as the implications of this referred to as DNS Whitelisting, as well as the implications of this
emerging practice and what alternatives or variations may exist. emerging practice and what alternatives or variations may exist.
This practice is a type of IPv6 transition mechanism used by domains, This practice is a type of IPv6 transition mechanism used by domains,
as a method for incrementally transitioning inbound traffic to a as a method for incrementally transitioning inbound traffic to a
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2011. This Internet-Draft will expire on December 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2.2. Comparison with Blacklisting . . . . . . . . . . . . . . . 8 2.2. Comparison with Blacklisting . . . . . . . . . . . . . . . 8
3. What Problems Are Implementers Trying To Solve? . . . . . . . 8 3. What Problems Are Implementers Trying To Solve? . . . . . . . 8
3.1. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 9 3.1. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 9
3.2. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 10 3.2. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 10
3.3. Free Versus Subscription Services . . . . . . . . . . . . 10 3.3. Free Versus Subscription Services . . . . . . . . . . . . 10
4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 10 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 10
5. Similarities to Other DNS Operations . . . . . . . . . . . . . 13 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 13
5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 13 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 13
5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 13 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 13
6. Possible Deployment Scenarios . . . . . . . . . . . . . . . . 14 6. Possible Deployment Scenarios . . . . . . . . . . . . . . . . 14
6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 14 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 15
6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 15 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 15
7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 16 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 16
7.1. Architectural Implications . . . . . . . . . . . . . . . . 16 7.1. Architectural Implications . . . . . . . . . . . . . . . . 16
7.2. Public IPv6 Address Reachability Implications . . . . . . 17 7.2. Public IPv6 Address Reachability Implications . . . . . . 17
7.3. Operational Implications . . . . . . . . . . . . . . . . . 18 7.3. Operational Implications . . . . . . . . . . . . . . . . . 18
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 18 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 18
7.3.2. Authoritative DNS Server Operational Implications . . 18 7.3.2. Authoritative DNS Server Operational Implications . . 18
7.3.3. DNS Recursive Resolver Server Operational 7.3.3. DNS Recursive Resolver Server Operational
Implications . . . . . . . . . . . . . . . . . . . . . 19 Implications . . . . . . . . . . . . . . . . . . . . . 19
7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 20 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 20
7.3.5. Implications of Operational Momentum . . . . . . . . . 21 7.3.5. Implications of Operational Momentum . . . . . . . . . 20
7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 21 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 21
7.3.7. Additional Implications If Deployed On An Ad Hoc 7.3.7. Additional Implications If Deployed On An Ad Hoc
Basis . . . . . . . . . . . . . . . . . . . . . . . . 21 Basis . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 22 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 22
7.5. Technology Policy Implications . . . . . . . . . . . . . . 22 7.5. Technology Policy Implications . . . . . . . . . . . . . . 22
7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 24 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 23
7.7. Implications with Poor IPv4 and Good IPv6 Transport . . . 24 7.7. Implications with Poor IPv4 and Good IPv6 Transport . . . 24
7.8. Implications for Users of Third-Party DNS Recursive 7.8. Implications for Users of Third-Party DNS Recursive
Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 25 Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 25
8. General Implementation Variations . . . . . . . . . . . . . . 26 8. General Implementation Variations . . . . . . . . . . . . . . 25
8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 26 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 26
8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 26 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 26
8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 26 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 26
8.3.1. Solve Current End User IPv6 Impairments . . . . . . . 26 8.3.1. Solve Current End User IPv6 Impairments . . . . . . . 26
8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 27 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 27
8.3.3. Implement DNS Blacklisting . . . . . . . . . . . . . . 27 8.3.3. Implement DNS Blacklisting . . . . . . . . . . . . . . 27
9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 28 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 29 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 29
10.2. Authoritative DNS Response Consistency Considerations . . 29 10.2. Authoritative DNS Response Consistency Considerations . . 29
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document describes the emerging practice of whitelisting of DNS This document describes the emerging practice of whitelisting of DNS
recursive resolvers in order to limit AAAA resource record (RR) recursive resolvers in order to limit AAAA resource record (RR)
responses, which contain IPv6 addresses, hereafter referred to as DNS responses, which contain IPv6 addresses, hereafter referred to as DNS
Whitelisting. The document explores the implications of this Whitelisting. The document explores the implications of this
emerging practice are and what alternatives may exist. When emerging practice are and what alternatives may exist. When
implemented, DNS Whitelisting in practice means that a domain's implemented, DNS Whitelisting in practice means that a domain's
authoritative DNS will return a AAAA resource record to DNS recursive authoritative DNS will return a AAAA resource record to DNS recursive
skipping to change at page 6, line 14 skipping to change at page 6, line 14
transport, IPv6, or both. So, for example, whitelisting may prevent transport, IPv6, or both. So, for example, whitelisting may prevent
sending AAAA responses even in those cases where the DNS recursive sending AAAA responses even in those cases where the DNS recursive
resolver has queried the authoritative server over IPv6 transport, or resolver has queried the authoritative server over IPv6 transport, or
where the end user host's original query to the DNS recursive where the end user host's original query to the DNS recursive
resolver was over IPv6 transport. One important reason for this is resolver was over IPv6 transport. One important reason for this is
that even though the DNS recursive resolver may have no IPv6-related that even though the DNS recursive resolver may have no IPv6-related
impairments, this is not a reliable predictor of whether the same is impairments, this is not a reliable predictor of whether the same is
true of the end user host. This also means that a DNS whitelist can true of the end user host. This also means that a DNS whitelist can
contain both IPv4 and IPv6 addresses. contain both IPv4 and IPv6 addresses.
Finally, DNS Whitelisting can be deployed in two primary ways: Finally, DNS Whitelisting could possibly be deployed in two ways:
universally on a global basis, or on an ad hoc basis. Deployment on universally on a global basis, (though that would be considered
a universal deployment basis means that DNS Whitelisting is harmful and is just covered to explain why this is the case), or,
implemented on all authoritative DNS servers, across the entire more realistically, on an ad hoc basis. Deployment on a universal
Internet. In contrast, deployment on an ad hoc basis means that only deployment basis means that DNS Whitelisting is implemented on all
some authoritative DNS servers, and perhaps even only a few, authoritative DNS servers, across the entire Internet. In contrast,
implement DNS Whitelisting. These two potential deployment models deployment on an ad hoc basis means that only some authoritative DNS
are described in Section 6. servers, and perhaps even only a few, implement DNS Whitelisting.
These two potential deployment models are described in Section 6.
2.1. Description of the Operation of DNS Whitelisting 2.1. Description of the Operation of DNS Whitelisting
The system logic of DNS Whitelisting is as follows: The system logic of DNS Whitelisting is as follows:
1. The authoritative DNS server for example.com receives DNS queries 1. The authoritative DNS server for example.com receives DNS queries
for the A (IPv4) and/or AAAA (IPv6) address resource records for for the A (IPv4) and/or AAAA (IPv6) address resource records for
the FQDN www.example.com, for which AAAA (IPv6) resource records the FQDN www.example.com, for which AAAA (IPv6) resource records
exist. exist.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
Implementers are attempting to protect users of their domain from Implementers are attempting to protect users of their domain from
having a negative experience (poor performance) when they receive DNS having a negative experience (poor performance) when they receive DNS
response containing AAAA resource records or when attempting to use response containing AAAA resource records or when attempting to use
IPv6 transport. Therefore there are two concerns which relate to IPv6 transport. Therefore there are two concerns which relate to
this practice; one of which relates to IPv6-related impairment and this practice; one of which relates to IPv6-related impairment and
the other which relates to the maturity or stability of IPv6 the other which relates to the maturity or stability of IPv6
transport for high-traffic domains. transport for high-traffic domains.
Finally, some domains, have run IPv6 experiments whereby they added Finally, some domains, have run IPv6 experiments whereby they added
AAAA resource records and observed and measured errors [Heise Online AAAA resource records and observed and measured errors [Heise], which
Experiment], which should be important reading for any domain should be important reading for any domain contemplating either the
contemplating either the use of DNS Whitelisting or simply adding use of DNS Whitelisting or simply adding IPv6 addressing to their
IPv6 addressing to their site. site.
3.1. IPv6-Related Impairment 3.1. IPv6-Related Impairment
Some implementers have observed that when they added AAAA resource Some implementers have observed that when they added AAAA resource
records to their authoritative DNS servers in order to support IPv6 records to their authoritative DNS servers in order to support IPv6
access to their content that a small fraction of end users had slow access to their content that a small fraction of end users had slow
or otherwise impaired access to a given web site with both AAAA and A or otherwise impaired access to a given web site with both AAAA and A
resource records. The fraction of users with such impaired access resource records. The fraction of users with such impaired access
has been estimated to be as high as 0.078% of total Internet users has been estimated to be as high as 0.078% of total Internet users
[IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness].
Brokenness]. In these situations, DNS recursive resolvers are added In these situations, DNS recursive resolvers are added to the DNS
to the DNS Whitelist only when the measured level of impairment of Whitelist only when the measured level of impairment of the hosts
the hosts using that resolver declines to some level acceptable by using that resolver declines to some level acceptable by the
the implementer. implementer.
As a result of this impairment affecting end users of a given domain, As a result of this impairment affecting end users of a given domain,
a few high-traffic domains have either implemented DNS Whitelisting a few high-traffic domains have either implemented DNS Whitelisting
or are considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist or are considering doing so [NW-Article-DNS-WL] [WL-Ops]. While it
Operations]. While it is outside the scope of this document to is outside the scope of this document to explore the various reasons
explore the various reasons why a particular user's system (host) may why a particular user's system (host) may have impaired IPv6 access,
have impaired IPv6 access, for the users who experience this for the users who experience this impairment it has a very real
impairment it has a very real performance impact. It would affect performance impact. It would affect access to all or most dual stack
access to all or most dual stack services to which the user attempts services to which the user attempts to connect. This negative end
to connect. This negative end user experience can range from user experience can range from somewhat slower than usual (as
somewhat slower than usual (as compared to native IPv4-based access), compared to native IPv4-based access), to extremely slow, to no
to extremely slow, to no access to the domain whatsoever. In access to the domain whatsoever. In essence, whether the end user
essence, whether the end user even has an IPv6 address or not (they even has an IPv6 address or not (they probably only have an IPv4
probably only have an IPv4 address), merely by receiving a AAAA address), merely by receiving a AAAA record response the user either
record response the user either cannot access a FQDN or it is so slow cannot access a FQDN or it is so slow that the user gives up and
that the user gives up and assumes the destination is unreachable. assumes the destination is unreachable.
In addition, at least one high-traffic domain has noted that they In addition, at least one high-traffic domain has noted that they
have received requests to not send DNS responses with AAAA resource have received requests to not send DNS responses with AAAA resource
records to particular resolvers. In this case, DNS recursive records to particular resolvers. In this case, DNS recursive
resolvers operators have expressed a short-term concern that their resolvers operators have expressed a short-term concern that their
IPv6 network infrastructure is not yet ready to handle the large IPv6 network infrastructure is not yet ready to handle the large
traffic volume that may be associated with the hosts in their network traffic volume that may be associated with the hosts in their network
connecting to the websites of these domains. These end user networks connecting to the websites of these domains. These end user networks
may also have other tools at their disposal in order to address this may also have other tools at their disposal in order to address this
concern, including applying rules to network equipment such as concern, including applying rules to network equipment such as
skipping to change at page 10, line 25 skipping to change at page 10, line 25
and procedures are less mature for IPv6 as compared to IPv4. While and procedures are less mature for IPv6 as compared to IPv4. While
for domains with small to moderate traffic volumes, whether by the for domains with small to moderate traffic volumes, whether by the
count of end users or count of bytes transferred, high-traffic count of end users or count of bytes transferred, high-traffic
domains receive such a level of usage that it is prudent to undertake domains receive such a level of usage that it is prudent to undertake
any network changes gradually or in a manner which minimizes any risk any network changes gradually or in a manner which minimizes any risk
of disruption. For example, one can imagine for one of the top ten of disruption. For example, one can imagine for one of the top ten
sites globally that the idea of suddenly turning on a significant sites globally that the idea of suddenly turning on a significant
amount of IPv6 traffic might be quite daunting. DNS Whitelisting may amount of IPv6 traffic might be quite daunting. DNS Whitelisting may
therefore offer such high-traffic domains one potential method for therefore offer such high-traffic domains one potential method for
incrementally enabling IPv6. Thus, some implementers with high- incrementally enabling IPv6. Thus, some implementers with high-
traffic domains plan to use DNS Whitelisting is a necessary, though traffic domains plan to use DNS Whitelisting as a necessary, though
temporary, risk reduction tactic intended to ease their transition to temporary, risk reduction tactic intended to ease their transition to
IPv6 and minimize any perceived risk in such a transition. IPv6 and minimize any perceived risk in such a transition.
3.3. Free Versus Subscription Services 3.3. Free Versus Subscription Services
It is also worth noting the differences between domains containing It is also worth noting the differences between domains containing
primarily subscription-based services compared to those containing primarily subscription-based services compared to those containing
primarily free services. In the case of free services, such as primarily free services. In the case of free services, such as
search engines, end users have no direct billing relationship with search engines, end users have no direct billing relationship with
the domain and can switch sites simply by changing the address they the domain and can switch sites simply by changing the address they
enter into their browser (ignoring other value added services which enter into their browser (ignoring other value added services which
may tie a user?s preference to a given domain or otherwise create may tie a user's preference to a given domain or otherwise create
switching costs). As a result, such domains explain that they switching costs). As a result, such domains explain that they
believe they are more sensitive to the quality of the services within believe they are more sensitive to the quality of the services within
their domain since if the user has issues when they turn on IPv6, their domain since if the user has issues when they turn on IPv6,
then that user could switch to another domain that is not using IPv6. then that user could switch to another domain that is not using IPv6.
4. Concerns Regarding DNS Whitelisting 4. Concerns Regarding DNS Whitelisting
The implications relating to DNS Whitelisting are further enumerated The implications relating to DNS Whitelisting are further enumerated
here and in Section 7. here and in Section 7.
Some parties in the Internet community, including ISPs, are concerned Some parties in the Internet community, including ISPs, are concerned
that the practice of DNS Whitelisting for IPv6 address resource that the practice of DNS Whitelisting for IPv6 address resource
records represents a departure from the generally accepted practices records represents a departure from the generally accepted practices
regarding IPv4 address resource records in the DNS on the Internet regarding IPv4 address resource records in the DNS on the Internet
[Whitelisting Concerns]. These parties explain their belief that [WL-Concerns]. These parties explain their belief that once an
once an authoritative server operator adds an A record (IPv4) to the authoritative server operator adds an A record (IPv4) to the DNS,
DNS, then any DNS recursive resolver on the Internet can receive that then any DNS recursive resolver on the Internet can receive that A
A record in response to a query. By extension, this means that any record in response to a query. By extension, this means that any of
of the hosts connected to any of these DNS recursive resolvers can the hosts connected to any of these DNS recursive resolvers can
receive the IPv4 address resource records for a given FQDN. This receive the IPv4 address resource records for a given FQDN. This
enables new server hosts which are connected to the Internet, and for enables new server hosts which are connected to the Internet, and for
which a fully qualified domain name (FQDN) such as www.example.com 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 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, immediately reachable by any host on the Internet. In this case,
these new servers hosts become more and more widely accessible as new these new servers hosts become more and more widely accessible as new
networks and new end user hosts connect to the Internet over time, networks and new end user hosts connect to the Internet over time,
capitalizing on and increasing so-called "network effects" (also capitalizing on and increasing so-called "network effects" (also
called network externalities). It also means that the new server called network externalities). It also means that the new server
hosts do not need to know about these new networks and new end user hosts do not need to know about these new networks and new end user
skipping to change at page 14, line 12 skipping to change at page 14, line 12
be directly reachable without passing through the load balancer first be directly reachable without passing through the load balancer first
. As such, while the IP address resource records have been added to . As such, while the IP address resource records have been added to
the DNS, the end hosts are not necessarily directly reachable, which the DNS, the end hosts are not necessarily directly reachable, which
is in a small way similar to one aspect of DNS Whitelisting. is in a small way similar to one aspect of DNS Whitelisting.
Additionally, a geographically-aware authoritative DNS server may be Additionally, a geographically-aware authoritative DNS server may be
used, as is common with Content Delivery Networks (CDNs) or Global used, as is common with Content Delivery Networks (CDNs) or Global
Load Balancing (GLB, also referred to as Global Server Load Load Balancing (GLB, also referred to as Global Server Load
Balancing, or GSLB), whereby the IP address resource records returned Balancing, or GSLB), whereby the IP address resource records returned
to a resolver in response to a query will vary based on the estimated to a resolver in response to a query will vary based on the estimated
geographic location of the resolver [Resolvers in the Wild]. CDNs geographic location of the resolver [Wild-Resolvers]. CDNs perform
perform this function in order to attempt to direct hosts to connect this function in order to attempt to direct hosts to connect to the
to the nearest content cache. As a result, one can see some nearest content cache. As a result, one can see some similarities
similarities with DNS Whitelisting insofar as different IP address with DNS Whitelisting insofar as different IP address resource
resource records are selectively returned to resolvers based on the records are selectively returned to resolvers based on the IP address
IP address of each resolver (or other imputed factors related to that of each resolver (or other imputed factors related to that IP
IP address). However, what is different is that in this case the address). However, what is different is that in this case the
resolvers are not deliberately blocked from receiving DNS responses resolvers are not deliberately blocked from receiving DNS responses
containing an entire class of addresses; this load balancing function containing an entire class of addresses; this load balancing function
strives to perform a content location-improvement function and not an strives to perform a content location-improvement function and not an
access control function. access control function.
6. Possible Deployment Scenarios 6. Possible Deployment Scenarios
In considering how DNS Whitelisting may emerge more widely, there are In considering how DNS Whitelisting may emerge more widely, there are
two main deployment scenarios, which are explored below. two deployment scenarios explored below, one of which, the ad-hoc
case, is realistic and may happen. The other, universal deployment,
is only described for the sake of completeness, to highlight its
difficulties, and to explain why it would be considered harmful.
In either of these deployment scenarios, it is possible that In either of these deployment scenarios, it is possible that
reputable third parties could create and maintain DNS whitelists, in reputable third parties could create and maintain DNS whitelists, in
much the same way that blacklists are distributed and used for much the same way that blacklists are distributed and used for
reducing email spam. In the email context, a mail operator reducing email spam. In the email context, a mail operator
subscribes to one or more of these lists and as such the operational 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 processes for additions and deletions to the list are managed by a
third party. A similar model could emerge for DNS Whitelisting, third party. A similar model could emerge for DNS Whitelisting,
whether deployment occurs universally or on an ad hoc basis. whether deployment occurs universally or on an ad hoc basis.
skipping to change at page 15, line 33 skipping to change at page 15, line 39
given domain will implement DNS Whitelisting temporarily. A domain, given domain will implement DNS Whitelisting temporarily. A domain,
particularly a high-traffic domain, may choose to do so in order to particularly a high-traffic domain, may choose to do so in order to
ease their transition to IPv6 through a selective deployment and ease their transition to IPv6 through a selective deployment and
minimize any perceived risk in such a transition. In addition, it is minimize any perceived risk in such a transition. In addition, it is
possible that one or more DNS Whitelist clearinghouses may emerge, possible that one or more DNS Whitelist clearinghouses may emerge,
providing implementers with a way to subscribe to a whitelist in a providing implementers with a way to subscribe to a whitelist in a
manner similar to that used on email servers for blacklists. manner similar to that used on email servers for blacklists.
6.2. Deploying DNS Whitelisting Universally 6.2. Deploying DNS Whitelisting Universally
The less likely deployment scenario is one where DNS Whitelisting is This deployment scenario is one where DNS Whitelisting is implemented
implemented on all authoritative DNS servers, across the entire on all authoritative DNS servers, across the entire Internet, which
Internet. While this scenario seems less likely than ad hoc is highly unlikely and unrealistic. While this scenario seems far
deployment due to some parties not sharing the concerns that have so less likely than ad hoc deployment due to many parties not sharing
far motivated the use of DNS Whitelisting, it is nonetheless the concerns that have so far motivated the use of DNS Whitelisting,
conceivable that it could be one of the ways in which DNS it is nonetheless conceivable that it could be one of the ways in
Whitelisting is deployed, though such a universal deployment could be which DNS Whitelisting is deployed, though such a universal
considered harmful and problematic. deployment could be considered harmful and problematic.
In order for this deployment scenario to occur, it is likely that DNS For this deployment scenario to occur, DNS Whitelisting functionality
Whitelisting functionality would need to be built into all would need to be built into all authoritative DNS server software,
authoritative DNS server software, and that all operators of and that all operators of authoritative DNS servers would have to
authoritative DNS servers would have to upgrade their software and upgrade their software in order to enable this functionality. New
enable this functionality. It is likely that new IETF Request for IETF Request for Comment (RFC) documents would need to be completed
Comment (RFC) documents would need to be developed which describe how to describe how to properly configure, deploy, and maintain DNS
to properly configure, deploy, and maintain DNS Whitelisting. As a Whitelisting across the entire Internet. As a result, it is highly
result, it is unlikely that DNS Whitelisting would, at least in the unlikely that DNS Whitelisting will become universally deployed.
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. 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 (so multiple clearinghouses are certainly
possible).
7. Implications of DNS Whitelisting 7. Implications of DNS Whitelisting
There are many implications of DNS Whitelisting. The key There are many implications of DNS Whitelisting. The key
implications are detailed below. implications are detailed below.
7.1. Architectural Implications 7.1. Architectural Implications
DNS Whitelisting modifies the end-to-end model and the general notion DNS Whitelisting modifies the end-to-end model and the general notion
of spontaneous interoperability of the architecture that prevails on of spontaneous interoperability of the architecture that prevails on
skipping to change at page 17, line 6 skipping to change at page 16, line 46
[RFC3234] details issues and concerns regarding so-called [RFC3234] details issues and concerns regarding so-called
middleboxes, so there may also be parallel concerns with the DNS middleboxes, so there may also be parallel concerns with the DNS
Whitelisting approach, especially concerning modified DNS servers Whitelisting approach, especially concerning modified DNS servers
noted in Section 2.16 of [RFC3234], as well as more general concerns noted in Section 2.16 of [RFC3234], as well as more general concerns
noted in Section 1.2 of [RFC3234] about the introduction of new noted in Section 1.2 of [RFC3234] about the introduction of new
failure modes. In particular, there may be concerns that failure modes. In particular, there may be concerns that
configuration is no longer limited to two ends of a session, and that configuration is no longer limited to two ends of a session, and that
diagnosis of failures and misconfigurations becomes more complex. diagnosis of failures and misconfigurations becomes more complex.
Two additional sources worth considering as far as implications for Two additional sources worth considering as far as implications for
the end-to-end model are concerned are [Tussle in Cyberspace] and the end-to-end model are concerned are [Tussle] and [Rethinking]. In
[Rethinking the Internet]. In [Tussle in Cyberspace], the authors [Tussle], the authors note concerns regarding the introduction of new
note concerns regarding the introduction of new control points, as control points, as well as "kludges" to the DNS, as risks to the goal
well as "kludges" to the DNS, as risks to the goal of network of network transparency in the end-to-end model. Some parties
transparency in the end-to-end model. Some parties concerned with concerned with the emerging use of DNS Whitelisting have shared
the emerging use of DNS Whitelisting have shared similar concerns, similar concerns, which may make [Tussle] an interesting and relevant
which may make [Tussle in Cyberspace] an interesting and relevant document. In addition, [Rethinking] reviews similar issues that may
document. In addition, [Rethinking the Internet] reviews similar be of interest to readers of this document.
issues that may be of interest to readers of this document.
Also, it is somewhat possible that DNS Whitelisting could affect some Also, it is somewhat possible that DNS Whitelisting could affect some
of the architectural assumptions which underlie parts of Section 2 of of the architectural assumptions which underlie parts of Section 2 of
[RFC4213] which outlines the dual stack approach to the IPv6 [RFC4213] which outlines the dual stack approach to the IPv6
transition. DNS Whitelisting could modify the behavior of the DNS, transition. DNS Whitelisting could modify the behavior of the DNS,
as described in Section 2.2 of [RFC4213] and could require different as described in Section 2.2 of [RFC4213] and could require different
sets of DNS servers to be used for hosts that are (using terms from sets of DNS servers to be used for hosts that are (using terms from
that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes. that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
As such, broad use of DNS Whitelisting may necessitate the review As such, broad use of DNS Whitelisting may necessitate the review
and/or revision (though revision is unlikely to be neccessary) of and/or revision (though revision is unlikely to be neccessary) of
skipping to change at page 21, line 12 skipping to change at page 21, line 5
shared with parties other than that authoritative DNS server shared with parties other than that authoritative DNS server
operator. operator.
7.3.5. Implications of Operational Momentum 7.3.5. Implications of Operational Momentum
It seems plausible that once DNS Whitelisting is implemented it will It seems plausible that once DNS Whitelisting is implemented it will
be very difficult to deprecate such technical and operational be very difficult to deprecate such technical and operational
practices. This assumption is based on an understanding of human practices. This assumption is based on an understanding of human
nature, not to mention physics. For example, as Sir Isaac Newton nature, not to mention physics. For example, as Sir Isaac Newton
noted, "Every object in a state of uniform motion tends to remain in 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" [Laws that state of motion unless an external force is applied to it"
of Motion]. Thus, once DNS Whitelisting is implemented it is quite [Motion]. Thus, once DNS Whitelisting is implemented it is quite
likely that it would take considerable effort to deprecate the likely that it would take considerable effort to deprecate the
practice and remove it everywhere on the Internet; it may otherwise practice and remove it everywhere on the Internet; it may otherwise
simply remain in place in perpetuity. To illustrate this point, one simply remain in place in perpetuity. To illustrate this point, one
could consider for example that there are many email servers could consider for example that there are many email servers
continuing to attempt to query anti-spam DNS blocklists which have continuing to attempt to query anti-spam DNS blocklists which have
long ago ceased to exist. long ago ceased to exist.
7.3.6. Troubleshooting Implications 7.3.6. Troubleshooting Implications
The implications of DNS whitelisted present many challenges, as The implications of DNS whitelisted present many challenges, as
skipping to change at page 22, line 24 skipping to change at page 22, line 17
A broad trend on the Internet is a move toward more heterogeneity. A broad trend on the Internet is a move toward more heterogeneity.
One manifestation of this is in an increasing number, variety, and One manifestation of this is in an increasing number, variety, and
customization of end user hosts, including home networks, operating customization of end user hosts, including home networks, operating
systems, client software, home network devices, and personal systems, client software, home network devices, and personal
computing devices. This trend appears to have had a positive effect computing devices. This trend appears to have had a positive effect
on the development and growth of the Internet. This trend has on the development and growth of the Internet. This trend has
enabled end user to connect any technically compliant device or use enabled end user to connect any technically compliant device or use
any technically compatible software to connect to the Internet. Not any technically compatible software to connect to the Internet. Not
only does this trend towards greater heterogeneity reduce the control only does this trend towards greater heterogeneity reduce the control
which is exerted in the middle of the network, described positively which is exerted in the middle of the network, described positively
in [Tussle in Cyberspace], [Rethinking the Internet], and [RFC3724], in [Tussle], [Rethinking], and [RFC3724], but it also appears to help
but it also appears to help to enable greater and more rapid to enable greater and more rapid innovation at the edges.
innovation at the edges.
Some forms of so-called "network neutrality" principles around the Some forms of so-called "network neutrality" principles around the
world include the notion that any IP-capable device should be able to world include the notion that any IP-capable device should be able to
connect to a network, which seems to encourage heterogeneity. These connect to a network, which seems to encourage heterogeneity. These
principles are often explicitly encouraged by application providers principles are often explicitly encouraged by application providers
given the reasons noted above, though some of these same providers given the reasons noted above, though some of these same providers
may also be implementing DNS Whitelisting. This is ironic, as one may also be implementing DNS Whitelisting. This is ironic, as one
implication of the adoption of DNS Whitelisting is that in encourages implication of the adoption of DNS Whitelisting is that in encourages
a move back towards homogeneity. This is because some implementers a move back towards homogeneity. This is because some implementers
have expressed a preference for greater levels of control by networks have expressed a preference for greater levels of control by networks
skipping to change at page 26, line 13 skipping to change at page 26, line 7
whitelisting as well as to the access network operator. whitelisting as well as to the access network operator.
8. General Implementation Variations 8. General Implementation Variations
This section outlines several possible approaches which may be This section outlines several possible approaches which may be
followed when considering DNS Whitelisting and associated IPv6- followed when considering DNS Whitelisting and associated IPv6-
related issues. related issues.
8.1. Implement DNS Whitelisting Universally 8.1. Implement DNS Whitelisting Universally
One obvious approach is to implement DNS whitelisted universally, and One seemingly obvious approach is to implement DNS whitelisted
to do so using some sort of centralized registry of DNS Whitelisting universally, and to do so using some sort of centralized registry of
policies, contracts, processes, or other information. Such an DNS Whitelisting policies, contracts, processes, or other
approach is also considered harmful and problematic, and almost information. Such an approach is considered harmful and problematic,
certain not to happen. and almost certain not to happen.
8.2. Implement DNS Whitelisting On An Ad Hoc Basis 8.2. Implement DNS Whitelisting On An Ad Hoc Basis
DNS Whitelisting is now being adopted on an ad hoc, or domain-by- DNS Whitelisting is now being adopted on an ad hoc, or domain-by-
domain basis. Therefore, only those domains interested in DNS domain basis. Therefore, only those domains interested in DNS
Whitelisting would need to adopt the practice, though as noted herein Whitelisting would need to adopt the practice, though as noted herein
discovering that a given domain has done so may be problematic. Also discovering that a given domain has done so may be problematic. Also
in this scenario, ad hoc use by a particular domain may be a in this scenario, ad hoc use by a particular domain may be a
temporary measure that has been adopted to ease the transition of the temporary measure that has been adopted to ease the transition of the
domain to IPv6 over some short-term timeframe. domain to IPv6 over some short-term timeframe.
skipping to change at page 27, line 10 skipping to change at page 27, line 4
if the end user is not only alerted to a potential problem but is 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 given careful and detailed advice on how to resolve this on their
own, or where they can seek help in doing so. Section 11 may also be own, or where they can seek help in doing so. Section 11 may also be
relevant in this case. relevant in this case.
One challenge with this option is the potential difficulty of One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such towards this goal, sharing the labor, time, and costs related to such
an effort. Of course, since just such a community effort is now 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 underway for IPv6, it is possible that this would call for only a
moderate amount of additional work [World IPv6 Day]. moderate amount of additional work [W6D].
Despite any potential challenges, many in the Internet community are Despite any potential challenges, many in the Internet community are
already working towards this goal and/or have expressed a general already working towards this goal and/or have expressed a general
preference for this approach. preference for this approach.
8.3.2. Gain Experience Using IPv6 Transition Names 8.3.2. Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN Another alternative is for domains to gain experience using an FQDN
which has become common for domains beginning the transition to IPv6; which has become common for domains beginning the transition to IPv6;
ipv6.example.com and www.ipv6.example.com. This can be a way for a ipv6.example.com and www.ipv6.example.com. This can be a way for a
skipping to change at page 28, line 33 skipping to change at page 28, line 28
Whitelisting as one of the few practical and low-risk approaches Whitelisting as one of the few practical and low-risk approaches
enabling them to transition to IPv6, without which their transition enabling them to transition to IPv6, without which their transition
may not take place for some time. However, there is also consensus may not take place for some time. However, there is also consensus
is that this practice is acceptable only in the short-term and that is that this practice is acceptable only in the short-term and that
it will not scale over the long-term. Thus, some domains may find it will not scale over the long-term. Thus, some domains may find
DNS Whitelisting a beneficial temporary tactic in their transition to DNS Whitelisting a beneficial temporary tactic in their transition to
IPv6. Such temporary use during the transition to IPv6 is broadly IPv6. Such temporary use during the transition to IPv6 is broadly
accepted within the community, so long as it does not become a long- accepted within the community, so long as it does not become a long-
term practice. term practice.
World IPv6 Day, sponsored by the Internet Society [World IPv6 Day], World IPv6 Day, sponsored by the Internet Society [W6D], is scheduled
is scheduled to occur on June 8, 2011. This will be an opportunity to occur on June 8, 2011. This will be an opportunity for domains to
for domains to add AAAA resource records to the DNS without using DNS add AAAA resource records to the DNS without using DNS Whitelisting.
Whitelisting. As a result, this is likely an excellent opportunity As a result, this is likely an excellent opportunity for domains to
for domains to evaluate the utility or necessity of DNS Whitelisting, evaluate the utility or necessity of DNS Whitelisting, even in the
even in the short-term. A major German news website, Heise Online, short-term. A major German news website, Heise Online, also ran a
also ran a similar IPv6 experiment whereby they added AAAA resource similar IPv6 experiment whereby they added AAAA resource records and
records and observed and measured any errors [Heise Online observed and measured any errors [Heise], which is important reading
Experiment], which is important reading for any domain contemplating for any domain contemplating either the use of DNS Whitelisting or
either the use of DNS Whitelisting or simply adding IPv6 addressing simply adding IPv6 addressing to their site.
to their site.
10. Security Considerations 10. Security Considerations
If DNS Whitelisting is adopted, then organizations which apply DNS If DNS Whitelisting is adopted, then organizations which apply DNS
Whitelisting policies in their authoritative servers should have Whitelisting policies in their authoritative servers should have
procedures and systems which do not allow unauthorized parties to procedures and systems which do not allow unauthorized parties to
either remove whitelisted DNS resolvers from the whitelist or add either remove whitelisted DNS resolvers from the whitelist or add
non-whitelisted DNS resolvers to the whitelist, just as all non-whitelisted DNS resolvers to the whitelist, just as all
configuration settings for name servers should be protected by configuration settings for name servers should be protected by
appropriate procedures and systems. Should such unauthorized appropriate procedures and systems. Should such unauthorized
skipping to change at page 33, line 33 skipping to change at page 33, line 27
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
15.2. Informative References 15.2. Informative References
[Evaluating IPv6 Adoption] [Heise] Heise.de, "The Big IPv6 Experiment", Heise.de
Colitti, L., Gunderson, S., Kline, E., and T. Refice,
"Evaluating IPv6 adoption in the Internet", Passive and
Active Management (PAM) Conference 2010, April 2010,
<http://www.google.com/research/pubs/archive/36240.pdf>.
[Heise Online Experiment]
Heise.de, "World IPv6 Day - June 8, 2011", Heise.de
Website http://www.h-online.com, January 2011, <http:// Website http://www.h-online.com, January 2011, <http://
www.h-online.com/features/ www.h-online.com/features/
The-big-IPv6-experiment-1165042.html>. The-big-IPv6-experiment-1165042.html>.
[I-D.ietf-v6ops-happy-eyeballs] [I-D.ietf-v6ops-happy-eyeballs]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
Towards Success with Dual-Stack Hosts", Towards Success with Dual-Stack Hosts",
draft-ietf-v6ops-happy-eyeballs-02 (work in progress), draft-ietf-v6ops-happy-eyeballs-02 (work in progress),
May 2011. May 2011.
skipping to change at page 34, line 14 skipping to change at page 33, line 49
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), January 2011. in progress), January 2011.
[IETF-77-DNSOP] [IETF-77-DNSOP]
Gashinsky, I., "IPv6 & recursive resolvers: How do we make Gashinsky, I., "IPv6 & recursive resolvers: How do we make
the transition less painful?", IETF 77 DNS Operations the transition less painful?", IETF 77 DNS Operations
Working Group, March 2010, Working Group, March 2010,
<http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>. <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IPv6 Brokenness] [IPv6-Brokenness]
Anderson, T., "Measuring and Combating IPv6 Brokenness", Anderson, T., "Measuring and Combating IPv6 Brokenness",
Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, Reseaux IP Europeens (RIPE) 61st Meeting, November 2010,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>. <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[IPv6 Whitelist Operations] [IPv6-Growth]
Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 Colitti, L., Gunderson, S., Kline, E., and T. Refice,
Implementors Conference, June 2010, <http:// "Evaluating IPv6 adoption in the Internet", Passive and
sites.google.com/site/ipv6implementors/2010/agenda/ Active Management (PAM) Conference 2010, April 2010,
IPv6_Whitelist_Operations.pdf>. <http://www.google.com/research/pubs/archive/36240.pdf>.
[Laws of Motion] [Motion] Newton, I., "Mathematical Principles of Natural Philosophy
Newton, I., "Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica)", (Philosophiae Naturalis Principia Mathematica)",
Principia Mathematical Principles of Natural Philosophy Principia Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica), July 1687, (Philosophiae Naturalis Principia Mathematica), July 1687,
<http://en.wikipedia.org/wiki/Newton's_laws_of_motion>. <http://en.wikipedia.org/wiki/Newton's_laws_of_motion>.
[NW-Article-DNS-WL] [NW-Article-DNS-WL]
Marsan, C., "Google, Microsoft, Netflix in talks to create Marsan, C., "Google, Microsoft, Netflix in talks to create
shared list of IPv6 users", Network World , March 2010, <h shared list of IPv6 users", Network World , March 2010, <h
ttp://www.networkworld.com/news/2010/ ttp://www.networkworld.com/news/2010/
032610-dns-ipv6-whitelist.html>. 032610-dns-ipv6-whitelist.html>.
skipping to change at page 34, line 50 skipping to change at page 34, line 36
Network World , March 2010, <http://www.networkworld.com/ Network World , March 2010, <http://www.networkworld.com/
news/2010/032610-yahoo-dns.html>. news/2010/032610-yahoo-dns.html>.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995. April 1995.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[Resolvers in the Wild] [Rethinking]
Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig,
"Comparing DNS Resolvers in the Wild", ACM Sigcomm
Internet Measurement Conference 2010, November 2010,
<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
[Rethinking the Internet]
Blumenthal, M. and D. Clark, "Rethinking the design of the Blumenthal, M. and D. Clark, "Rethinking the design of the
Internet: The end to end arguments vs. the brave new Internet: The end to end arguments vs. the brave new
world", ACM Transactions on Internet Technology Volume 1, world", ACM Transactions on Internet Technology Volume 1,
Number 1, Pages 70-109, August 2001, <http:// Number 1, Pages 70-109, August 2001, <http://
dspace.mit.edu/bitstream/handle/1721.1/1519/ dspace.mit.edu/bitstream/handle/1721.1/1519/
TPRC_Clark_Blumenthal.pdf>. TPRC_Clark_Blumenthal.pdf>.
[Tussle in Cyberspace] [Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski,
Braden, R., Clark, D., Sollins, K., and J. Wroclawski,
"Tussle in Cyberspace: Defining Tomorrow's Internet", "Tussle in Cyberspace: Defining Tomorrow's Internet",
Proceedings of ACM Sigcomm 2002, August 2002, <http:// Proceedings of ACM Sigcomm 2002, August 2002, <http://
groups.csail.mit.edu/ana/Publications/PubPDFs/ groups.csail.mit.edu/ana/Publications/PubPDFs/
Tussle2002.pdf>. Tussle2002.pdf>.
[Whitelisting Concerns] [W6D] The Internet Society, "World IPv6 Day - June 8, 2011",
Internet Society Website http://www.isoc.org,
January 2011, <http://isoc.org/wp/worldipv6day/>.
[WL-Concerns]
Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y.,
Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting -
Could It Hinder IPv6 Adoption?", ISOC Internet Society Could It Hinder IPv6 Adoption?", ISOC Internet Society
IPv6 Deployment Workshop, April 2010, <http:// IPv6 Deployment Workshop, April 2010, <http://
www.comcast6.net/ www.comcast6.net/
IPv6_DNS_Whitelisting_Concerns_20100416.pdf>. IPv6_DNS_Whitelisting_Concerns_20100416.pdf>.
[World IPv6 Day] [WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google Google IPv6
The Internet Society, "World IPv6 Day - June 8, 2011", Implementors Conference, June 2010, <http://
Internet Society Website http://www.isoc.org, sites.google.com/site/ipv6implementors/2010/agenda/
January 2011, <http://isoc.org/wp/worldipv6day/>. IPv6_Whitelist_Operations.pdf>.
[Wild-Resolvers]
Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig,
"Comparing DNS Resolvers in the Wild", ACM Sigcomm
Internet Measurement Conference 2010, November 2010,
<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
Appendix A. Document Change Log Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-05: Additional changes requested by Stephen Farrell intended to
close his Discuss on the I-D. These changes were in Sections 6.2 and
8.3. Also shortened non-RFC references at Stephen's request.
-04: Made changed based on feedback received during IESG review. -04: Made changed based on feedback received during IESG review.
This does NOT include updated from the more general IETF last call - This does NOT include updated from the more general IETF last call -
that will be in a -05 version of the document. Per Ralph Droms, that will be in a -05 version of the document. Per Ralph Droms,
change the title of 6.2 from "Likely Deployment Scenarios" to change the title of 6.2 from "Likely Deployment Scenarios" to
"Possible Deployment Scenarios", as well as changes to improve the "Possible Deployment Scenarios", as well as changes to improve the
understanding of sentences in Sections 2, 3, 4, and 8.2. Per Adrian understanding of sentences in Sections 2, 3, 4, and 8.2. Per Adrian
Farrel, made a minor change to Section 3. Per Robert Sparks, to make Farrel, made a minor change to Section 3. Per Robert Sparks, to make
clear in Section 2 that whitelisting is done on authoritative servers clear in Section 2 that whitelisting is done on authoritative servers
and not DNS recursive resolvers, and to improve Section 8.3 and add a and not DNS recursive resolvers, and to improve Section 8.3 and add a
reference to I-D.ietf?v6ops?happy?eyeballs. Per Wesley Eddy, updated reference to I-D.ietf?v6ops?happy?eyeballs. Per Wesley Eddy, updated
skipping to change at page 38, line 4 skipping to change at page 37, line 41
-00: First version published as a v6ops WG draft. The preceding -00: First version published as a v6ops WG draft. The preceding
individual draft was individual draft was
draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE
that no changes have been made yet based on WG and list feedback. that no changes have been made yet based on WG and list feedback.
These are in queue for a -01 update. These are in queue for a -01 update.
Appendix B. Open Issues Appendix B. Open Issues
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
1. RFC Editor: Please consider shortening the names of the non-RFC
references.
2. Ensure references are in the proper section (normative/ 1. Ensure references are in the proper section (normative/
informative) informative)
3. JD Falk question - should I add a sub-section to 9 to explain how 2. JD Falk question - should I add a sub-section to 9 to explain how
best to implement if you did it? (transparent/published policies, best to implement if you did it? (transparent/published policies,
SLA on decision making,etc.) SLA on decision making,etc.)
4. Per Ray Hunter - "Which is why my original posting suggested that 3. Per Ray Hunter - "Which is why my original posting suggested that
the WG might wish to express a concern about anyone making the WG might wish to express a concern about anyone making
assumptions about any undocumented architectural links between assumptions about any undocumented architectural links between
DNS and transport, and also suggest that operators of aaaa DNS and transport, and also suggest that operators of aaaa
whitelists (party X) should disclose their aaaa methodology and whitelists (party X) should disclose their aaaa methodology and
data, and that they should not share whitelist data with other data, and that they should not share whitelist data with other
aaaa operators in an uncontrolled manner, so that at least Party aaaa operators in an uncontrolled manner, so that at least Party
Y could see what was happening and why, and also have a chance of Y could see what was happening and why, and also have a chance of
correcting it." correcting it."
5. Per Joe Touch, consider moving section 8 to just after section 3. 4. Per Joe Touch, consider moving section 8 to just after section 3.
(only do so after -04) (only do so after -04)
6. Per Dave Crocker, this is a bit long-winded and should be edited 5. Per Dave Crocker, this is a bit long-winded and should be edited
down - in particular removing mentions of 'parties' in various down - in particular removing mentions of 'parties' in various
parts ("I suggest merely noting that there are concerns and then parts ("I suggest merely noting that there are concerns and then
listing and discussing the concerns, rather than adding text to listing and discussing the concerns, rather than adding text to
attribute the concerns to others, even if the conclusion of your attribute the concerns to others, even if the conclusion of your
text is that a particular concern is not valid.") (and ""These text is that a particular concern is not valid.") (and ""These
parties explain their belief" is an example of personalization parties explain their belief" is an example of personalization
that is not needed. This isn't about the believers. It is about that is not needed. This isn't about the believers. It is about
possible problems."). John Leslie concurs - feels it should be possible problems."). John Leslie concurs - feels it should be
simplified. simplified.
7. Per Pekka Savola and Stephen Farrell, should universal deployment 6. Per Pekka Savola and Stephen Farrell, should universal deployment
be removed completely (consider after -04). be removed completely (consider after -04).
8. Per Jari Arkko, review the document again after -04 to ensure the 7. Per Jari Arkko, review the document again after -04 to ensure the
right tone and that all motivations are properly accounted for. right tone and that all motivations are properly accounted for.
9. Per Dave Crocker - do we need to change the name from 8. Per Dave Crocker - do we need to change the name from
whitelisting to an alternate term? Dave suggests "IPv6 Resolver whitelisting to an alternate term? Dave suggests "IPv6 Resolver
Whitelisting" or "IPv6 DNS Response Preference List" or "DNS Whitelisting" or "IPv6 DNS Response Preference List" or "DNS
Response Content Preference List". Tony Finch suggests: So I Response Content Preference List". Tony Finch suggests: So I
suggest retitling the document "IPv6 DNS resolver whitelisting" suggest retitling the document "IPv6 DNS resolver whitelisting"
and revising the terminology throughout to match. Mark Andrews and revising the terminology throughout to match. Mark Andrews
also suggests "DNS resolver whitelisting for AAAA resolution". also suggests "DNS resolver whitelisting for AAAA resolution".
John Leslie suggests "AAAA-blocking". John Leslie suggests "AAAA-blocking".
9. Per Stephen Farrell, consider removing W6D references.
Author's Address Author's Address
Jason Livingood Jason Livingood
Comcast Cable Communications Comcast Cable Communications
One Comcast Center One Comcast Center
1701 John F. Kennedy Boulevard 1701 John F. Kennedy Boulevard
Philadelphia, PA 19103 Philadelphia, PA 19103
US US
Email: jason_livingood@cable.comcast.com Email: jason_livingood@cable.comcast.com
 End of changes. 44 change blocks. 
152 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/