draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational January 25, 2011 Intended status: Informational February 6, 2011
Expires: July 29, 2011 Expires: August 10, 2011
IPv6 AAAA DNS Whitelisting Implications IPv6 AAAA DNS Whitelisting Implications
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02
Abstract Abstract
The objective of this document is to describe what whitelisting of The objective of this document is to describe what whitelisting of
DNS AAAA resource records is, or DNS whitelisting for short, as well DNS AAAA resource records is, or DNS whitelisting for short, as well
as what the implications of this emerging practice are and what as what the implications of this emerging practice are and what
alternatives may exist. The audience for this document is the alternatives may exist. The audience for this document is the
Internet community generally, including the IETF and IPv6 Internet community generally, including the IETF and IPv6
implementers. implementers.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 29, 2011. This Internet-Draft will expire on August 10, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5
3. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 7 3. What Problems Are Implementers Trying To Solve? . . . . . . . 7
4. Similarities to Other DNS Operations . . . . . . . . . . . . . 9 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 8
4.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 9 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 10
4.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 10 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 11
5. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 11 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 11
5.1. Deploying DNS Whitelisting Universally . . . . . . . . . . 11 6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 12
5.2. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 12 6.1. Deploying DNS Whitelisting Universally . . . . . . . . . . 12
6. What Problems Are DNS Whitelisting Implementers Trying To 6.2. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13
Solve? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 14
7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 13 7.1. Architectural Implications . . . . . . . . . . . . . . . . 14
7.1. Architectural Implications . . . . . . . . . . . . . . . . 13 7.2. Public IPv6 Address Reachability Implications . . . . . . 15
7.2. Public IPv6 Address Reachability Implications . . . . . . 14 7.3. Operational Implications . . . . . . . . . . . . . . . . . 16
7.3. Operational Implications . . . . . . . . . . . . . . . . . 15 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 16
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 15
7.3.2. Authoritative DNS Server Operational Implications . . 16 7.3.2. Authoritative DNS Server Operational Implications . . 16
7.3.3. DNS Recursive Resolver Server Operational 7.3.3. DNS Recursive Resolver Server Operational
Implications . . . . . . . . . . . . . . . . . . . . . 16 Implications . . . . . . . . . . . . . . . . . . . . . 16
7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 17 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 17
7.3.5. Implications of Operational Momentum . . . . . . . . . 17 7.3.5. Implications of Operational Momentum . . . . . . . . . 18
7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 18 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 18
7.3.7. Additional Implications If Deployed On An Ad Hoc 7.3.7. Additional Implications If Deployed On An Ad Hoc
Basis . . . . . . . . . . . . . . . . . . . . . . . . 18 Basis . . . . . . . . . . . . . . . . . . . . . . . . 18
7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 18 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 19
7.5. Technology Policy Implications . . . . . . . . . . . . . . 19 7.5. Technology Policy Implications . . . . . . . . . . . . . . 20
7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 20 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 21
8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 21 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 22
8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 21 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 22
8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 21 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 22
8.3.1. Solving Current End User IPv6 Impairments . . . . . . 21 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 23
9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.2. Authoritative DNS Response Consistency Considerations . . 23 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10.2. Authoritative DNS Response Consistency Considerations . . 24
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 26 15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 29
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document describes the emerging practice of whitelisting of DNS This document describes the emerging practice of whitelisting of DNS
AAAA resource records (RRs), or DNS whitelisting for short. It also AAAA resource records (RRs), which contain IPv6 addresses, or DNS
explores the implications of this emerging practice are and what whitelisting for short. It also explores the implications of this
alternatives may exist. emerging practice are and what alternatives may exist.
The practice of DNS whitelisting appears to have first been used by The practice of DNS whitelisting appears to have first been used by
major web content sites, such as Google's various websites. These major web content sites (sometimes described herein as "highly-
web site operators, or domain operators, observed that when they trafficked domains" or "major domains"). These web site operators,
added AAAA RRs to their authoritative DNS servers that a small or domain operators, observed that when they added AAAA resource
fraction of end users had slow or otherwise impaired access to a records to their authoritative DNS servers that a small fraction of
given web site with both AAAA and A RRs. The fraction of users with end users had slow or otherwise impaired access to a given web site
with both AAAA and A resource records. The fraction of users with
such impaired access has been estimated to be roughly 0.078% of total such impaired access has been estimated to be roughly 0.078% of total
Internet users [IETF 77 DNSOP WG Presentation] [Network World Article Internet users [IETF 77 DNSOP WG Presentation] [Network World Article
on IETF 77 DNSOP WG Presentation]. Thus, in an example Internet on IETF 77 DNSOP WG Presentation] [Evaluating IPv6 Adoption]
Service Provider (ISP) network of 10 million users, approximately [Measuring and Combating IPv6 Brokenness]. Thus, in an example
7,800 of those users may experience such impaired access. 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, As a result of this impairment affecting end users of a given domain,
a few large domains have begun to either implement DNS whitelisting a few large domains have begun to either implement DNS whitelisting
or strongly consider the implementation of DNS whitelisting [Network or strongly consider the implementation of DNS whitelisting [Network
World Article on DNS Whitelisting] [IPv6 Whitelist Operations]. When World Article on DNS Whitelisting] [IPv6 Whitelist Operations]. 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 RR to DNS recursive resolvers authoritative DNS will return a AAAA resource record to DNS recursive
[RFC1035] on the whitelist, while returning no AAAA RRs to DNS resolvers [RFC1035] on the whitelist, while returning no AAAA
resolvers which are not on the whitelist. It is important to note resource records to DNS resolvers which are not on the whitelist. It
that these web site operators are motivated to maintain a high- is important to note that these web site operators are motivated to
quality user experience for all of their users, and that they are maintain a high-quality user experience for all of their users, and
attempting to shield users with impaired access from the symptoms of that they are attempting to shield users with impaired access from
these impairments that would negatively affect their access to the symptoms of these impairments that would negatively affect their
certain websites and related Internet resources. access to certain websites and related Internet resources.
However, critics of this emerging practice of DNS whitelisting have However, critics of this emerging practice of DNS whitelisting have
articulated several concerns. Among these are that this is a very articulated several concerns. Among these are that this is a very
different behavior from the current practice concerning the different behavior from the current practice concerning the
publishing of IPv4 address records, that it may create a two-tiered publishing of IPv4 address records, that it may create a two-tiered
Internet, that policies concerning whitelisting and de-whitelisting Internet, that policies concerning whitelisting and de-whitelisting
are opaque, that DNS whitelisting reduces interest in the deployment are opaque, that DNS whitelisting reduces interest in the deployment
of IPv6, that new operational and management burdens are created, and of IPv6, that new operational and management burdens are created, and
that the costs and negative implications of DNS whitelisting outweigh that the costs and negative implications of DNS whitelisting outweigh
the perceived benefits as compared to fixing underlying impairments. the perceived benefits as compared to fixing underlying impairments.
skipping to change at page 5, line 16 skipping to change at page 5, line 19
DNS whitelisting is implemented in authoritative DNS servers, where DNS whitelisting is implemented in authoritative DNS servers, where
those servers implement IP address-based restrictions on AAAA query those servers implement IP address-based restrictions on AAAA query
responses, which contain IPv6 addresses. In practice DNS responses, which contain IPv6 addresses. In practice DNS
whitelisting has been primarily implemented by web server operators. whitelisting has been primarily implemented by web server operators.
For a given operator of the website www.example.com, that operator For a given operator of the website www.example.com, that operator
essentially applies an access control list (ACL) on their essentially applies an access control list (ACL) on their
authoritative DNS servers, which are authoritative for the domain authoritative DNS servers, which are authoritative for the domain
example.com. The ACL is then configured with the IPv4 and/or IPv6 example.com. The ACL is then configured with the IPv4 and/or IPv6
addresses of DNS recursive resolvers on the Internet, which have been addresses of DNS recursive resolvers on the Internet, which have been
authorized to be added to the ACL and to therefore receive AAAA RR authorized to be added to the ACL and to therefore receive AAAA
responses. These DNS recursive resolvers are operated by other resource record responses. These DNS recursive resolvers are
parties, such as ISPs, universities, governments, businesses, operated by other parties, such as ISPs, universities, governments,
individual end users, etc. If a DNS recursive resolver IS NOT on the businesses, individual end users, etc. If a DNS recursive resolver
ACL, then NO AAAA RRs with IPv6 addresses will be sent in response to IS NOT on the ACL, then AAAA resource records will NOT be sent in
a query for a given hostname in the example.com domain. However, if response to a query for a given hostname in the example.com domain.
a DNS recursive resolver IS on the ACL, then AAAA RRs with IPv6 However, if a DNS recursive resolver IS on the ACL, then AAAA
addresses will be sent in response to a query for a given hostname in resource records will be sent in response to a query for a given
the example.com domain. While these are not network-layer access hostname in the example.com domain. While these are not network-
controls, they are nonetheless access controls that are a factor for layer access controls, they are nonetheless access controls that are
both end users and are directly related to the transition of one a factor for both end users and are directly related to the
network address family to another (IPv4 to IPv6). transition of one network address family to another (IPv4 to IPv6).
In practice this generally means that a very small fraction of the In practice this generally means that a very small fraction of the
DNS recursive resolvers on the Internet can receive AAAA responses DNS recursive resolvers on the Internet can receive AAAA responses,
with IPv6 addresses, which means that the large majority of DNS which means that the large majority of DNS resolvers on the Internet
resolvers on the Internet will receive only A RRs with IPv4 will receive only A resource records with IPv4 addresses. Thus,
addresses. Thus, quite simply, the authoritative server hands out quite simply, the authoritative server hands out different answers
different answers depending upon who is asking; with IPv4 and IPv6 depending upon who is asking; with IPv4 and IPv6 records for some on
records for some on the authorized whitelist, and only IPv4 records the authorized whitelist, and only IPv4 records for everyone else.
for everyone else. See Figure 1 and Figure 2 for two different See Figure 1 and Figure 2 for two different visual descriptions of
visual descriptions of how this works in practice. how this works in practice.
Finally, DNS whitelisting can be deployed in two primary ways: Finally, DNS whitelisting can be deployed in two primary ways:
universally on a global basis, or on an ad hoc basis. These two universally on a global basis, or on an ad hoc basis. These two
potential deployment models are described in Section 5. potential deployment models are described in Section 6.
1: The authoritative DNS server for example.com receives a DNS 1: The authoritative DNS server for example.com receives a DNS
query for www.example.com, for which both A (IPv4) and AAAA query for www.example.com, for which both A (IPv4) and AAAA
(IPv6) address records exist. (IPv6) address records exist.
2: The authoritative DNS server examines the IP address of the DNS 2: The authoritative DNS server examines the IP address of the DNS
recursive resolver sending the query. recursive resolver sending the query.
3: The authoritative DNS server checks this IP address against the 3: The authoritative DNS server checks this IP address against the
access control list (ACL) that is the DNS whitelist. access control list (ACL) that is the DNS whitelist.
4: If the DNS recursive resolver's IP address IS listed in the ACL, 4: If the DNS recursive resolver's IP address IS listed in the ACL,
then the response to that specific DNS recursive resolver can then the response to that specific DNS recursive resolver can
skipping to change at page 7, line 43 skipping to change at page 7, line 43
Computer A | | A | | Computer A | | A | |
<--------- | | <--------- | | <--------- | | <--------- | |
A and AAAA +-------------+ A and AAAA +-----------------+ A and AAAA +-------------+ A and AAAA +-----------------+
Record DNS Recursive Record example.com Record DNS Recursive Record example.com
Responses Resolver Responses Authoritative Responses Resolver Responses Authoritative
(IPv4+IPv6) #2 (IPv4+IPv6) Server (IPv4+IPv6) #2 (IPv4+IPv6) Server
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 2: DNS Whitelisting - Functional Diagram Figure 2: DNS Whitelisting - Functional Diagram
3. Concerns Regarding DNS Whitelisting 3. What Problems Are 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
whatsoever.
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.
In addition, at least one highly-trafficked domain has noted that
they have received requests to not send DNS responses with AAAA
resource records to 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
large traffic volume which may be associated with the hosts in their
network connecting to the websites of these domains. 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).
Some implementers with highly-trafficked domains have also explained
that DNS whitelisting is a necessary, though temporary, risk
reduction tactic intended to ease their transition to IPv6 and
minimize any perceived risk in such a transition. As a result, they
perceive this as a tactic to enable them to incrementally enable IPv6
connectivity to their domains during the early phases of the
transition to IPv6.
Finally, some domains, such as major German news website, have run
IPv6 experiments whereby they added AAAA resource records and
observed and measured any errors [Heise Online Experiment], which is
important reading for any domain contemplating either the use of DNS
whitelisting or simply adding IPv6 addressing to their site.
4. Concerns Regarding DNS Whitelisting
There are a number of potential implications relating to DNS There are a number of potential implications relating to DNS
whitelisting, which have raised various concerns in some parts of the whitelisting, which have raised various concerns in some parts of the
Internet community. Many of those potential implications are Internet community. Many of those potential implications are
described in Section 7. described in Section 7.
Some parties in the Internet community, including ISPs like Comcast, Some parties in the Internet community, including ISPs, are concerned
are concerned that this emerging practice of DNS whitelisting for that this emerging practice of DNS whitelisting for IPv6 address
IPv6 address records could represent a departure from the generally records could represent a departure from the generally accepted
accepted practices regarding IPv4 address records in the DNS on the practices regarding IPv4 address records in the DNS on the Internet
Internet [IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?]. [IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?]. These
These parties explain their belief that for A records, containing parties explain their belief that for A records, containing IPv4
IPv4 addresses, once an authoritative server operator adds the A addresses, once an authoritative server operator adds the A record to
record to the DNS, then any DNS recursive resolver on the Internet the DNS, then any DNS recursive resolver on the Internet can receive
can receive that A record in response to a query. By extension, this that A record in response to a query. By extension, this means that
means that any of the hosts connected to any of these DNS recursive any of the hosts connected to any of these DNS recursive resolvers
resolvers can receive the IPv4 address records for a given FQDN. can receive the IPv4 address records for a given FQDN. This enables
This enables new server hosts which are connected to the Internet, new server hosts which are connected to the Internet, and for which a
and for which a fully qualified domain name (FQDN) such as fully qualified domain name (FQDN) such as www.example.com has been
www.example.com has been added to the DNS with an IPv4 address added to the DNS with an IPv4 address record, to be almost
record, to be almost immediately reachable by any host on the immediately reachable by any host on the Internet. In this case,
Internet. In this case, these new servers hosts become more and more these new servers hosts become more and more widely accessible as new
widely accessible as new networks and new end user hosts connect to networks and new end user hosts connect to the Internet over time,
the Internet over time [EDITORIAL: consider reference to network capitalizing on and increasing so-called "network effects" (also
effects]. It also means that the new server hosts do not need to called network externalities). It also means that the new server
know about these new networks and new end user hosts in order to make hosts do not need to know about these new networks and new end user
their content and applications available to them, in essence that hosts in order to make their content and applications available to
each end in this end-to-end model is responsible for connecting to them, in essence that each end in this end-to-end model is
the Internet and once they have done so they can connect to each responsible for connecting to the Internet and once they have done so
other without additional impediments or middle networks or they can connect to each other without additional impediments or
intervening networks or servers knowing about these end points and middle networks or intervening networks or servers knowing about
whether one is allowed to contact the other. these end points and whether one is allowed to contact the other.
In contrast, these parties are concerned that DNS whitelisting may In contrast, these parties are concerned that DNS whitelisting may
fundamentally change this model. As a result, in this altered end- fundamentally change this model. As a result, in this altered end-
to-end model, one end (where the end user is located) cannot readily to-end model, one end (where the end user is located) cannot readily
connect to the other end (where the content is located), without 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 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 approved for access to that end. Thus, as new networks connect to
the Internet over time, those networks need to contact any and all the Internet over time, those networks need to contact any and all
domains which have implemented DNS whitelisting in order to apply to domains which have implemented DNS whitelisting in order to apply to
be added to their DNS whitelist, in the hopes of making the content be added to their DNS whitelist, in the hopes of making the content
skipping to change at page 9, line 17 skipping to change at page 10, line 19
accessible as a result, then end users and/or networks may resist accessible as a result, then end users and/or networks may resist
adoption of IPv6 or actively seek alternatives to it, such as using adoption of IPv6 or actively seek alternatives to it, such as using
multi-layer network address translation (NAT) techniques like NAT444 multi-layer network address translation (NAT) techniques like NAT444
[I-D.shirasaki-nat444] on a long-term basis. There is also concern [I-D.shirasaki-nat444] on a long-term basis. There is also concern
that this practice also could disrupt the continued increase in that this practice also could disrupt the continued increase in
Internet adoption by end users if they cannot simply access new Internet adoption by end users if they cannot simply access new
content and applications but must instead contact the operator of content and applications but must instead contact the operator of
their DNS recursive resolver, such as their ISP or another third their DNS recursive resolver, such as their ISP or another third
party, to have their DNS recursive resolver authorized for access to party, to have their DNS recursive resolver authorized for access to
the content or applications that interests them. Meanwhile, these the content or applications that interests them. Meanwhile, these
parties say, over 99.9% of all other end users that are also using parties say, over 99.9% of the other end users that are also using
that same network or DNS recursive resolver are unable to access the that same network or DNS recursive resolver are unable to access the
IPv6-based content, despite their experience being a positive one. IPv6-based content, despite their experience being a positive one.
While in Section 1 the level of IPv6-related impairment has been While in Section 1 the level of IPv6-related impairment has been
estimated to be as high as 0.078% of Internet users, which is a 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 primary motivation cited for the practice of DNS whitelisting, it is
not clear if the level of IPv4-related impairment is more or less 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 that this percentage (which in any case is likely to have declined
since its original citation). Indeed, as at least one document since its original citation). Indeed, as at least one document
reviewer has pointed out, it may simply be that websites are only reviewer has pointed out, it may simply be that websites are only
measuring IPv6 impairments and not IPv4 impairments, whether because measuring IPv6 impairments and not IPv4 impairments, whether because
IPv6 is new or whether those websites are simply unable to or are 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 otherwise not in a position to be able to measure IPv4 impairment
(since this could result in no Internet access whatsoever). As a (since this could result in no Internet access whatsoever). As a
result, it is worth considering that IPv4-related impairment could result, it is worth considering that IPv4-related impairment could
exceed that of IPv6-related impairment and that such IPv4-related exceed that of IPv6-related impairment and that such IPv4-related
impairment may have simply been accepted as "background noise" on the impairment may have simply been accepted as "background noise" on the
Internet for a variety of reasons. Internet for a variety of reasons. Of course, this comparison of the
level of worldwide IPv6 impairments to IPv4 impairments is
speculation, as the author is not aware of any good measurement of
IPv4-related impairments which are comparable in nature to the IPv6-
related impairment measurements which have recently been conducted
around the world.
4. Similarities to Other DNS Operations 5. Similarities to Other DNS Operations
Some aspects of DNS whitelisting may be considered similar in some Some aspects of DNS whitelisting may be considered similar in some
ways to other common DNS operational techniques, which is explored ways to other common DNS operational techniques, which is explored
briefly below. briefly below.
4.1. Similarities to Split DNS 5.1. Similarities to Split DNS
DNS whitelisting has some similarities to so-called split DNS, which DNS whitelisting has some similarities to so-called split DNS, which
is briefly described in Section 3.8 of [RFC2775]. When split DNS is is briefly described in Section 3.8 of [RFC2775]. When split DNS is
used, the authoritative DNS server returns different responses used, the authoritative DNS server returns different responses
depending upon what host has sent the query. While [RFC2775] notes 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 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 Intranet and a different answer to hosts on the Internet, the essence
is that different answers are provided to hosts on different is that different answers are provided to hosts on different
networks. This is basically the way that DNS whitelisting works, in networks. This is basically the way that DNS whitelisting works, in
so far as hosts of different networks, which use different DNS so far as hosts of different networks, which use different DNS
skipping to change at page 10, line 24 skipping to change at page 11, line 33
further notes in Section 2.7, concerns regarding split DNS and that further notes in Section 2.7, concerns regarding split DNS and that
it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint
identifiers more complex." Section 3.5 of [RFC2956] further identifiers more complex." Section 3.5 of [RFC2956] further
recommends that maintaining a stable approach to DNS operations is recommends that maintaining a stable approach to DNS operations is
key during transitions such as the one to IPv6 that is underway now, key during transitions such as the one to IPv6 that is underway now,
stating that "Operational stability of DNS is paramount, especially stating that "Operational stability of DNS is paramount, especially
during a transition of the network layer, and both IPv6 and some during a transition of the network layer, and both IPv6 and some
network address translation techniques place a heavier burden on network address translation techniques place a heavier burden on
DNS." DNS."
4.2. Similarities to DNS Load Balancing 5.2. Similarities to DNS Load Balancing
DNS whitelisting also has some 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 There are many ways that DNS load balancing can be performed, and of
course this can mean many things to different people. In one course this can mean many things to different people. In one
example, multiple IP address resource records (A or AAAA) can be 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 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 round robin [RFC1794], or even where SRV resource records are used
of the IP address resource records in the DNS will direct traffic to [RFC2782]. In another example, one or more of the IP address
a load balancer [REFERENCE AVAILABLE?]. That load balancer, in turn, resource records in the DNS will direct traffic to a load balancer.
may be application-aware, and pass the traffic on to one or more That load balancer, in turn, may be application-aware, and pass the
hosts connected to the load balancer which have different IP traffic on to one or more hosts connected to the load balancer which
addresses. In cases where private IPv4 addresses are used [RFC1918], have different IP addresses. In cases where private IPv4 addresses
as well as when public IP addresses are used, those end hosts may not are used [RFC1918], as well as when public IP addresses are used,
be directly reachable without passing through the load balancer first those end hosts may not be directly reachable without passing through
. As such, while the IP address resource records have been added to the load balancer first . As such, while the IP address resource
the DNS, the end hosts are not necessarily directly reachable, which records have been added to the DNS, the end hosts are not necessarily
is in a small way similar to one aspect of DNS whitelisting. In directly reachable, which is in a small way similar to one aspect of
addition, a geographically-aware authoritative DNS server may be DNS whitelisting. In addition, a geographically-aware authoritative
used, as is common with Content Delivery Networks (CDNs), whereby the DNS server may be used, as is common with Content Delivery Networks
IP address resource records returned to a resolver in response to a (CDNs), whereby the IP address resource records returned to a
query will vary based on the estimated geographic location of the resolver in response to a query will vary based on the estimated
resolver [REFERENCE AVAILABLE?]. CDNs perform this function in order geographic location of the resolver [Comparing DNS Resolvers in the
to attempt to direct hosts to connect to the nearest content cache. Wild]. CDNs perform this function in order to attempt to direct
As a result, one can see some similarities with DNS whitelisting hosts to connect to the nearest content cache. As a result, one can
insofar as different IP address resource records are returned to see some similarities with DNS whitelisting insofar as different IP
resolvers based on the IP address of each resolver (or other imputed address resource records are returned to resolvers based on the IP
factors related to that IP address). However, what is different of address of each resolver (or other imputed factors related to that IP
course, if that in this case the resolvers are not necessarily address). However, what is different of course, if that in this case
blocked from receiving DNS responses containing an entire class of the resolvers are not necessarily blocked from receiving DNS
addresses; this load balancing function strives to perform a content responses containing an entire class of addresses; this load
location-improvement function and not an access control function. balancing function strives to perform a content location-improvement
function and not an access control function.
5. Likely Deployment Scenarios 6. Likely 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 likely deployment scenarios, which are explored below. two likely deployment scenarios, which are explored below.
In either of these likely deployment scenarios below, it is possible In either of these likely deployment scenarios below, it is possible
that reputable third parties could create and maintain these DNS that reputable third parties could create and maintain these DNS
whitelists, in much the same way that blacklists are used for whitelists, in much the same way that blacklists are used for
reducing email spam. In this email example, a mail operator reducing email spam. In this email example, 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. Thus, a similar model could emerge for DNS third party. Thus, a similar model could emerge for DNS
whitelisting, whether deployment occurs universally or on an ad hoc whitelisting, whether deployment occurs universally or on an ad hoc
basis. basis.
5.1. Deploying DNS Whitelisting Universally 6.1. Deploying DNS Whitelisting Universally
The least likely deployment scenario is one where DNS whitelisting The least likely deployment scenario is one where DNS whitelisting
becomes a standardized process across all authoritative DNS servers, becomes a standardized process across all authoritative DNS servers,
across the entire Internet. While this scenario is the least likely, across the entire Internet. While this scenario is the least likely,
due to some parties not sharing the concerns that have so far due to some parties not sharing the concerns that have so far
motivated the use of DNS whitelisting, it is nonetheless conceivable motivated the use of DNS whitelisting, it is nonetheless conceivable
that it could be one of the ways in which DNS whitelisting may be that it could be one of the ways in which DNS whitelisting may be
deployed. deployed.
In order for this deployment scenario to occur, it is likely that DNS In order for this deployment scenario to occur, it is likely that DNS
skipping to change at page 12, line 17 skipping to change at page 13, line 26
First, parties performing troubleshooting would not have to determine First, parties performing troubleshooting would not have to determine
whether or not DNS whitelisting was being used, as it always would be whether or not DNS whitelisting was being used, as it always would be
in use. In addition, if universally deployed, it is possible that in use. In addition, if universally deployed, it is possible that
the criteria for being added to or removed from a DNS whitelist could the criteria for being added to or removed from a DNS whitelist could
be standardized across the entire Internet. Nevertheless, even if be standardized across the entire Internet. Nevertheless, even if
uniform DNS whitelisting policies were not standardized, is also uniform DNS whitelisting policies were not standardized, is also
possible that a central registry of these policies could be developed 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 and deployed in order to make it easier to discover them, a key part
of achieving transparency regarding DNS whitelisting. of achieving transparency regarding DNS whitelisting.
5.2. Deploying DNS Whitelisting On An Ad Hoc Basis 6.2. Deploying DNS Whitelisting On An Ad Hoc Basis
This is the most likely deployment scenario for DNS whitelisting, as This is the most likely deployment scenario for DNS whitelisting, as
it seems today, is where some interested parties engage in DNS it seems today, is where some interested parties engage in DNS
whitelisting but many or most others do not do so. What can make whitelisting but many or most others do not do so. What can make
this scenario challenging from the standpoint of a DNS recursive this scenario challenging from the standpoint of a DNS recursive
resolver operator is determining which domains implement DNS resolver operator is determining which domains implement DNS
whitelisting, particularly since a domain may not do so as they whitelisting, particularly since a domain may not do so as they
initially transition to IPv6, and may instead do so later. Thus, a initially transition to IPv6, and may instead do so later. Thus, a
DNS recursive resolver operator may initially believe that they can DNS recursive resolver operator may initially believe that they can
receive AAAA responses with IPv6 addresses as a domain adopts IPv6, receive AAAA responses as a domain adopts IPv6, but then notices via
but then notices via end user reports that they no longer receive end user reports that they no longer receive AAAA responses due to
AAAA responses due to that site adopting DNS whitelisting. that site adopting DNS whitelisting.
Thus, in contrast to universal deployment of DNS whitelisting, Thus, in contrast to universal deployment of DNS whitelisting,
deployment on an ad hoc basis is likely to be significantly more deployment on an ad hoc basis is likely to be significantly more
challenging from an operational, monitoring, and troubleshooting challenging from an operational, monitoring, and troubleshooting
standpoint. In this scenario, a DNS recursive resolver operator will standpoint. In this scenario, a DNS recursive resolver operator will
have no way to systematically determine whether DNS whitelisting is have no way to systematically determine whether DNS whitelisting is
or is not implemented for a domain, since the absence of AAAA records 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 may simply be indicative that the domain has not yet added IPv6
yet added IPv6 addressing for the domain, not that they have done so addressing for the domain, not that they have done so but have
but have restricted query access via DNS whitelisting. As a result, restricted query access via DNS whitelisting. As a result,
discovering which domains implement DNS whitelisting, in order to discovering which domains implement DNS whitelisting, in order to
differentiate them from those that do not, is likely to be differentiate them from those that do not, is likely to be
challenging. challenging.
On the other hand, one benefit of DNS whitelisting being deployed on 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 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 so would have to upgrade their authoritative DNS servers in order to
implement the ACLs necessary to perform DNS whitelisting. implement the ACLs necessary to perform DNS whitelisting.
6. What Problems Are DNS Whitelisting Implementers Trying To Solve? In this potential deployment scenario, it is also possible that a
given domain will implement DNS whitelisting temporarily. A domain,
As noted in Section 1, domains which implement DNS whitelisting are particularly a highly-trafficked domain, may choose to do so in order
attempting to protect a few users of their domain, which happen to to ease their transition to IPv6 and minimize any perceived risk in
have impaired IPv6 access, from having a negative end user such a transition.
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
whatsoever.
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.
In addition, Google has noted that they have received requests to not
send DNS responses with AAAA resource records to 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 7. Implications of DNS Whitelisting
There are many potential implications of DNS whitelisting. In the There are many potential implications of DNS whitelisting. In the
sections below, the key potential implications are listed in some sections below, the key potential implications are listed in some
detail. detail.
7.1. Architectural Implications 7.1. Architectural Implications
DNS whitelisting could be perceived as somewhat modifying the end-to- DNS whitelisting could be perceived as somewhat modifying the end-to-
skipping to change at page 14, line 47 skipping to change at page 15, line 24
In order to explore and better understand these high-level In order to explore and better understand these high-level
architectural implications and concerns in more detail, the following architectural implications and concerns in more detail, the following
sections explore more specific potential implications. sections explore more specific potential implications.
7.2. Public IPv6 Address Reachability Implications 7.2. Public IPv6 Address Reachability Implications
The predominant experience of end user hosts and servers on the IPv4- The predominant experience of end user hosts and servers on the IPv4-
addressed Internet today is that, very generally speaking, when a new addressed Internet today is that, very generally speaking, when a new
server with a public IPv4 address is added, that it is then globally server with a public IPv4 address is added, that it is then globally
accessible by IPv4-addressed hosts. Of course, this is a accessible by IPv4-addressed hosts. Of course, this is a
generalization and in Section 4 there are examples of common cases generalization and in Section 5 there are examples of common cases
where this may not necessarily be the case. In any case, for the where this may not necessarily be the case. In any case, for the
purposes of this document, that concept of accessibility can be purposes of this document, that concept of accessibility can be
considered "pervasive reachability". It has so far been assumed that considered "pervasive reachability". It has so far been assumed that
the same expectations of pervasive reachability would exist in the the same expectations of pervasive reachability would exist in the
IPv6-addressed Internet. However, if DNS whitelisting is deployed, IPv6-addressed Internet. However, if DNS whitelisting is deployed,
this will not be the case since only end user hosts using DNS 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 recursive resolvers which have been added to the ACL of a given
domain using DNS whitelisting would be able to reach new servers in domain using DNS whitelisting would be able to reach new servers in
that given domain via IPv6 addresses. Thus, the expectation of any that given domain via IPv6 addresses. Thus, the expectation of any
end user host being able to connect to any server (essentially both end user host being able to connect to any server (essentially both
skipping to change at page 16, line 42 skipping to change at page 17, line 16
domains that the end users of such servers are interested in now or 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 in which they may be interested in the future. As such anticipation
of interesting domains is likely infeasible, it is more likely that of interesting domains is likely infeasible, it is more likely that
such operators may either choose to only apply to be whitelisted for 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 a domain based upon one or more end user requests, or that they will
attempt to do so for all domains. attempt to do so for all domains.
When such operators apply for DNS whitelisting for all domains, that When such operators apply for DNS whitelisting for all domains, that
may mean doing so for all registered domains. Thus, some system may mean doing so for all registered domains. Thus, some system
would have to be developed to discover whether each domain has been 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 whitelisted or not, which is touched on in Section 6 and may vary
depending upon whether DNS whitelisting is universally deployed or is depending upon whether DNS whitelisting is universally deployed or is
deployed on an ad hoc basis. deployed on an ad hoc basis.
Furthermore, these operators will need to develop processes and Furthermore, these operators will need to develop processes and
systems to track the status of all DNS whitelisting applications, systems to track the status of all DNS whitelisting applications,
respond to requests for additional information related to these respond to requests for additional information related to these
applications, determine when and if applications have been denied, applications, determine when and if applications have been denied,
manage appeals, and track any de-whitelisting actions. Given the manage appeals, and track any de-whitelisting actions. Given the
incredible number of domains in existence, the ease with which a new incredible number of domains in existence, the ease with which a new
domain can be added, and the continued strong growth in the numbers domain can be added, and the continued strong growth in the numbers
skipping to change at page 18, line 32 skipping to change at page 19, line 7
7.3.7. Additional Implications If Deployed On An Ad Hoc Basis 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis
Additional implications, should this be deployed on an ad hoc basis, Additional implications, should this be deployed on an ad hoc basis,
could include scalability problems relating to operational processes, could include scalability problems relating to operational processes,
monitoring, and ACL updates. In particular, it seems quite likely monitoring, and ACL updates. In particular, it seems quite likely
that as the number of domains that are whitelisted increases, as well that as the number of domains that are whitelisted increases, as well
as the number of IPv6-capable networks requesting to be whitelisted, as the number of IPv6-capable networks requesting to be whitelisted,
that there is an increased likelihood of configuration and other that there is an increased likelihood of configuration and other
operational errors, especially with respect to the ACLs themselves. operational errors, especially with respect to the ACLs themselves.
It is also unclear when and if it would be appropriate to change from It is also unclear when and if it would be appropriate to change from
whitelisting to blacklisting, and whether/how this could feasibly be whitelisting to blacklisting, and whether or how this could feasibly
coordinated across the Internet, which may be proposed when a be coordinated across the Internet, which may be proposed when a
majority of networks (or allocated IPv6 address blocks) have been majority of networks (or allocated IPv6 address blocks) have been
whitelisted. Finally, some parties implementing DNS whitelisting whitelisted. Finally, some parties implementing DNS whitelisting
consider this to be a temporary measure. As such, it is not clear consider this to be a temporary measure. As such, it is not clear
how these parties will judge the network conditions to have changed how these parties will judge the network conditions to have changed
sufficiently to justify disabling DNS whitelisting and/or what the sufficiently to justify disabling DNS whitelisting and/or what the
process and timing will be in order to turn off and stop this process and timing will be in order to turn off and stop this
practice. practice.
One further potential implication is that an end user with only an
IPv4 address, using a DNS resolver which has not been whitelisted by
any domains, would not be able to get any AAAA resource records. In
such a case, this could give that end user the incorrect impression
that there is no IPv6-based content on the Internet since they are
unable to discover any IPv6 addresses via the DNS.
7.4. Homogeneity May Be Encouraged 7.4. Homogeneity May Be Encouraged
A broad trend which has existed on the Internet appears to be a move A broad trend which has existed on the Internet appears to be a move
towards increasing levels of heterogeneity. One manifestation of towards increasing levels of heterogeneity. One manifestation of
this is in an increasing number, variety, and customization of end this is in an increasing number, variety, and customization of end
user hosts, including home network, operating systems, client user hosts, including home network, operating systems, client
software, home network devices, and personal computing devices. This software, home network devices, and personal computing devices. This
trend appears to have had a positive effect on the development and 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 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 ability of the end user to connect any technically compliant device
skipping to change at page 20, line 41 skipping to change at page 21, line 23
effect of preventing other, end users on that network from using effect of preventing other, end users on that network from using
other, non-email-related applications within that domain. Thus, it other, non-email-related applications within that domain. Thus, it
seems possible that DNS whitelisting and de-whitelisting could become seems possible that DNS whitelisting and de-whitelisting could become
a vehicle for adjudicating other disputes, and that this may well a vehicle for adjudicating other disputes, and that this may well
have intended and unintended consequences for end users which are have intended and unintended consequences for end users which are
affected by such decisions and are unlikely to be able to express a affected by such decisions and are unlikely to be able to express a
strong voice in such decisions. strong voice in such decisions.
7.6. IPv6 Adoption Implications 7.6. IPv6 Adoption Implications
As noted in Section 3, the implications of DNS whitelisting may drive As noted in Section 4, the implications of DNS whitelisting may drive
end users and/or networks to delay, postpone, or cancel adoption of end users and/or networks to delay, postpone, or cancel adoption of
IPv6, or to actively seek alternatives to it. Such alternatives may IPv6, or to actively seek alternatives to it. Such alternatives may
include the use of multi-layer network address translation (NAT) include the use of multi-layer network address translation (NAT)
techniques like NAT444 [I-D.shirasaki-nat444], which these parties techniques like NAT444 [I-D.shirasaki-nat444], which these parties
may decide to pursue on a long-term basis to avoid the perceived may decide to pursue on a long-term basis to avoid the perceived
costs and aggravations related to DNS whitelisting. This could of costs and aggravations related to DNS whitelisting. This could of
course come at the very time that the Internet community is trying to 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 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 the transition to IPv6. As a result, parties that are likely to be
concerned over the negative implications of DNS whitelisting could concerned over the negative implications of DNS whitelisting could
logically be concerned of the negative effects that this practice logically be concerned of the negative effects that this practice
could have on the adoption of IPv6 if it became widespread or was could have on the adoption of IPv6 if it became widespread or was
adopted by majors Internet domains or other major parties in the adopted by majors Internet domains or other major parties in the
Internet ecosystem. Internet ecosystem.
At the same time, as noted in Section 3, some highly-trafficked
domains may find the prospect of transitioning to IPv6 daunting
without having some short-term ability to incrementally control the
amount and source of IPv6 traffic to their domains.
8. Solutions 8. Solutions
This section outline several possible solutions when considering DNS This section outlines several possible solutions when considering DNS
whitelisting and associated IPv6-related issues. whitelisting and associated IPv6-related issues.
8.1. Implement DNS Whitelisting Universally 8.1. Implement DNS Whitelisting Universally
One obvious solution is to implement DNS whitelisted universally, and One obvious solution is to implement DNS whitelisted universally, and
to do so using some sort of centralized registry of DNS whitelisting to do so using some sort of centralized registry of DNS whitelisting
policies, contracts, processes, or other information. This potential policies, contracts, processes, or other information. This potential
solution seems unlikely at the current time. solution seems unlikely at the current time.
8.2. Implement DNS Whitelisting On An Ad Hoc Basis 8.2. Implement DNS Whitelisting On An Ad Hoc Basis
If DNS whitelisting was to be adopted, it is likely to be adopted on If DNS whitelisting was to be adopted, it is likely to be adopted on
this ad hoc, or domain-by-domain basis. Therefore, only those this ad hoc, or domain-by-domain basis. Therefore, only those
domains interested in DNS whitelisting would need to adopt the domains interested in DNS whitelisting would need to adopt the
practice, though as noted herein discovering that they a given domain practice, though as noted herein discovering that they a given domain
has done so may be problematic. Also in this scenario, ad hoc use by has done so may be problematic. Also in this scenario, ad hoc use by
a particular domain may also be a temporary measure that has been a particular domain may be a temporary measure that has been adopted
adopted to ease the transition of the domain to IPv6 over some short- to ease the transition of the domain to IPv6 over some short-term
term timeframe. timeframe.
8.3. Do Not Implement DNS Whitelisting 8.3. Do Not Implement DNS Whitelisting
As an alternative to adopting DNS whitelisting, the Internet As an alternative to adopting DNS whitelisting, the Internet
community can instead choose to take no action whatsoever, community can instead choose to take no action whatsoever,
perpetuating the current predominant authoritative DNS operational perpetuating the current predominant authoritative DNS operational
model on the Internet, and leave it up to end users with IPv6-related model on the Internet, and leave it up to end users with IPv6-related
impairments to discover and fix those impairments. impairments to discover and fix those impairments.
8.3.1. Solving Current End User IPv6 Impairments 8.3.1. Solving Current End User IPv6 Impairments
skipping to change at page 22, line 4 skipping to change at page 22, line 43
A further extension of not implementing DNS whitelisting, is to also A further extension of not implementing DNS whitelisting, is to also
endeavor to actually fix the underlying technical problems that have endeavor to actually fix the underlying technical problems that have
prompted the consideration of DNS whitelisting in the first place, as prompted the consideration of DNS whitelisting in the first place, as
an alternative to trying to apply temporary workarounds to avoid the an alternative to trying to apply temporary workarounds to avoid the
symptoms of underlying end user IPv6 impairments. A first step is symptoms of underlying end user IPv6 impairments. A first step is
obviously to identify which users have such impairments, which would obviously to identify which users have such impairments, which would
appear to be possible, and then to communicate this information to appear to be possible, and then to communicate this information to
end users. Such end user communication is likely to be most helpful 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 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. own, or where they can seek help in doing so. Of course, Section 11
may be 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. moderate amount of additional work.
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 preference already working towards this goal and/or have expressed a preference
for this approach. for this approach.
9. Security Considerations 9. Is DNS Whitelisting a Recommended Practice?
Opinions in the Internet community concerning whether or not DNS
whitelisting is a recommended practice are understandably quite
varied. However, there is clear consensus that DNS whitelisting is
at best a useful temporary measure which a domain may choose to
pursue as they prepare for the transition to IPv6. In particular,
some major domains view DNS whitelisting as one of the few practical
and low risk approaches enabling them to prepare for the transition
to IPv6. Thus, DNS whitelisting is not a recommended practice over
the long-term. In addition, DNS whitelisting should be avoided
wherever possible in the short-term and its use is generally
discouraged. Nevertheless, major domains may find DNS whitelisting a
beneficial temporary tactic in their transition to IPv6. Such
temporary use during the transition to IPv6 is broadly accepted
within the community, so long as it does not become a long-term
practice.
Finally, World IPv6 Day, which is sponsored by the Internet Society
[World IPv6 Day] and is scheduled to occur on June 8, 2011, will be
an opportunity for domains to add AAAA resource records to the DNS
without using DNS whitelisting. As a result, this is likely an
excellent opportunity for domains to evaluate the utility or
necessity of DNS whitelisting, even in the short-term. A major
German news website, Heise Online, also ran a similar IPv6 experiment
whereby they added AAAA resource records and observed and measured
any errors [Heise Online Experiment], which is important reading for
any domain contemplating either the use of DNS whitelisting or simply
adding IPv6 addressing to their site.
10. Security Considerations
There are no particular security considerations if DNS whitelisting There are no particular security considerations if DNS whitelisting
is not adopted, as this is how the public Internet works today with A is not adopted, as this is how the public Internet works today with A
records. records.
However, if DNS whitelisting is adopted, organizations which apply However, if DNS whitelisting is adopted, organizations which apply
DNS whitelisting policies in their authoritative servers should have DNS 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. Should such non-whitelisted DNS resolvers to the whitelist. Should such
unauthorized additions or removals from the whitelist can be quite unauthorized additions or removals from the whitelist can be quite
damaging, and result in content providers and/or ISPs to incur damaging, and result in content providers and/or ISPs to incur
substantial support costs resulting from end user and/or customer substantial support costs resulting from end user and/or customer
contacts. As such, great care must be taken to control access to the contacts. As such, great care must be taken to control access to the
whitelist for an authoritative server. whitelist for an authoritative server.
In addition, two other key security-related issues should be taken In addition, two other key security-related issues should be taken
into consideration: into consideration:
9.1. DNSSEC Considerations 10.1. DNSSEC Considerations
DNS security extensions defined in [RFC4033], [RFC4034], and DNS security extensions defined in [RFC4033], [RFC4034], and
[RFC4035] use cryptographic digital signatures to provide origin [RFC4035] use cryptographic digital signatures to provide origin
authentication and integrity assurance for DNS data. This is done by authentication and integrity assurance for DNS data. This is done by
creating signatures for DNS data on a Security-Aware Authoritative creating signatures for DNS data on a Security-Aware Authoritative
Name Server that can be used by Security-Aware Resolvers to verify Name Server that can be used by Security-Aware Resolvers to verify
the answers. Since DNS whitelisting is implemented on an the answers. Since DNS whitelisting is implemented on an
authoritative server, which provides different answers depending upon authoritative server, which provides different answers depending upon
which resolver server has sent a query, the DNSSEC chain of trust is which resolver server has sent a query, the DNSSEC chain of trust is
not altered. Therefore there are no DNSSEC implications per se. not altered. Therefore there are no DNSSEC implications per se.
However, any implementer of DNS whitelisting should be quite careful However, any implementer of DNS whitelisting should be quite careful
if they implement both DNSSEC signing of their domain and also DNS if they implement both DNSSEC signing of their domain and also DNS
whitelisting of that same domain. Specifically, those domains should whitelisting of that same domain. Specifically, those domains should
ensure that records are being appropriately and reliably signed, ensure that records are being appropriately and reliably signed,
which may well prove operationally and/or technically challenging. which may well prove operationally and/or technically challenging.
9.2. Authoritative DNS Response Consistency Considerations 10.2. Authoritative DNS Response Consistency Considerations
In addition to the considerations raised in Section 9.1, it is In addition to the considerations raised in Section 10.1, it is
conceivable that security concerns may arise when end users or other conceivable that security concerns may arise when end users or other
parties notice that the responses sent from an authoritative DNS parties notice that the responses sent from an authoritative DNS
server appear to vary from one network or one DNS recursive resolver server appear to vary from one network or one DNS recursive resolver
to another. This may give rise to concerns that, since the to another. This may give rise to concerns that, since the
authoritative responses vary that there is some sort of security authoritative responses vary that there is some sort of security
issue and/or some or none of the responses can be trusted. While issue and/or some or none of the responses can be trusted. While
this may seem a somewhat obscure concern, domains nonetheless may this may seem a somewhat obscure concern, domains nonetheless may
wish to consider this when contemplating whether or not to pursue DNS wish to consider this when contemplating whether or not to pursue DNS
whitelisting. whitelisting.
10. IANA Considerations 11. Privacy Considerations
As noted in Section 8.3.1, there may be methods to detect IPv6-
related impairments for a particular end user. For example, this may
be possible when an end user visits the website of a particular
domain. In that example, there are likely no privacy considerations
in communicating to that end user that the domain has detected a
particular impairment. However, if that domain decided to share
information concerning that particular end user with their network
operator or another party, then the visited domain may wish to in
some manner advise the end use of this or otherwise seek their
consent to such information sharing. This may be achieved in a wide
variety of ways, from presenting a message asking the user for
consent (which will of course help them solve a technical problem of
which they are likely unaware) to adding this to a domain's website
terms of use / service. Such information sharing and communication
of such sharing to end users may well vary by geographic area and/or
legal jurisdiction. Thus, a domain should consider any potential
privacy issues these sorts of scenarios.
12. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
11. Contributors 13. Contributors
The following people made significant textual contributions to this The following people made significant textual contributions to this
document and/or played an important role in the development and document and/or played an important role in the development and
evolution of this document: evolution of this document:
- John Brzozowski - John Brzozowski
- Chris Griffiths - Chris Griffiths
- Tom Klieber - Tom Klieber
- Yiu Lee - Yiu Lee
- Rich Woundy - Rich Woundy
12. Acknowledgements 14. Acknowledgements
The author and contributors also wish to acknowledge the assistance The author and contributors also wish to acknowledge the assistance
of the following individuals. Some of these people provided helpful of the following individuals. Some of these people provided helpful
and important guidance in the development of this document and/or in and important guidance in the development of this document and/or in
the development of the concepts covered in this document. Other the development of the concepts covered in this document. Other
people assisted by performing a detailed review of this document, and people assisted by performing a detailed review of this document, and
then providing feedback and constructive criticism for revisions to then providing feedback and constructive criticism for revisions to
this document. All of this was helpful and therefore the following this document. All of this was helpful and therefore the following
individuals merit acknowledgement: individuals merit acknowledgement:
skipping to change at page 24, line 9 skipping to change at page 26, line 4
and important guidance in the development of this document and/or in and important guidance in the development of this document and/or in
the development of the concepts covered in this document. Other the development of the concepts covered in this document. Other
people assisted by performing a detailed review of this document, and people assisted by performing a detailed review of this document, and
then providing feedback and constructive criticism for revisions to then providing feedback and constructive criticism for revisions to
this document. All of this was helpful and therefore the following this document. All of this was helpful and therefore the following
individuals merit acknowledgement: individuals merit acknowledgement:
- Bernard Aboba - Bernard Aboba
- Frank Bulk - Frank Bulk
- Brian Carpenter - Brian Carpenter
- Wesley George - Wesley George
- Jerry Huang
- Erik Kline - Erik Kline
- Victor Kuarsingh
- Danny McPherson - Danny McPherson
- Martin Millnert
- Hannes Tschofenig - Hannes Tschofenig
13. References 15. References
13.1. Normative References 15.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996. RFC 1958, June 1996.
skipping to change at page 25, line 13 skipping to change at page 27, line 13
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[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.
13.2. Informative References 15.2. Informative References
[Comparing DNS Resolvers in the Wild]
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>.
[Evaluating IPv6 Adoption]
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://
www.h-online.com/features/
The-big-IPv6-experiment-1165042.html>.
[I-D.shirasaki-nat444] [I-D.shirasaki-nat444]
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 WG Presentation] [IETF 77 DNSOP WG Presentation]
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,
skipping to change at page 25, line 40 skipping to change at page 28, line 9
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>.
[IPv6 Whitelist Operations] [IPv6 Whitelist Operations]
Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 Kline, E., "IPv6 Whitelist Operations", Google Google IPv6
Implementors Conference, June 2010, <http:// Implementors Conference, June 2010, <http://
sites.google.com/site/ipv6implementors/2010/agenda/ sites.google.com/site/ipv6implementors/2010/agenda/
IPv6_Whitelist_Operations.pdf>. IPv6_Whitelist_Operations.pdf>.
[Measuring and Combating IPv6 Brokenness]
Anderson, T., "Measuring and Combating IPv6 Brokenness",
Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[Network World Article on DNS Whitelisting] [Network World Article on DNS Whitelisting]
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>.
[Network World Article on IETF 77 DNSOP WG Presentation] [Network World Article on IETF 77 DNSOP WG Presentation]
Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Marsan, C., "Yahoo proposes 'really ugly hack' to DNS",
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>.
[Newton's Laws of Motion] [Newton's Laws of 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>.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[Rethinking the design of the Internet] [Rethinking the design of 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 in Cyberspace]
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>.
[World IPv6 Day]
The Internet Society, "World IPv6 Day - June 8, 2011",
Internet Society Website http://www.isoc.org,
January 2011, <http://isoc.org/wp/worldipv6day/>.
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]
-02: Called for and closed out feedback on dnsop and v6ops mailing
lists. Closed out open feedback items from IETF 79. Cleared I-D
nits issues, added a section on whether or not this is recommended,
made language less company-specific based on feedback from Martin
Millnert, Wes George, and Victor Kuarsingh. Also mentioned World
IPv6 Day per Wes George's suggestion. Added references to the ISOC
World IPv6 Day and the Heise.de test at the suggestion of Jerry
Huang, as well as an additional implication in 7.3.7. Made any
speculation on IPv4 impairment noted explicitly as such, per feedback
from Martin Millnert. Added a reference to DNS SRV in the load
balancing section. Added various other references. Numerous changes
suggested by John Brzozowski in several sections, to clean up the
document. Moved up the section on why whitelisting is performed to
make the document flow more logically. Added a note in the ad hoc
deployment scenario explaining that a deployment may be temporary,
and including more of the perceived benefits of this tactic. Added a
Privacy Considerations section to address end-user detection and
communication.
-01: Incorporated feedback received from Brian Carpenter (from 10/19/ -01: Incorporated feedback received from Brian Carpenter (from 10/19/
2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010). 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 Also added an informative reference at the suggestion of Wes George
(from from 10/22/2010). Closed out numerous editorial notes, and (from from 10/22/2010). Closed out numerous editorial notes, and
made a variety of other changes. made a variety of other changes.
-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. During WGLC: Ensure references are in the proper section
1. Close the issues below and any feedback from the v6ops and dnsop (normative/informative)
mailing lists in a -02 update, then request WGLC
2. Perform an second review of notes from IETF 79 to ensure that all
feedback received then has been fully taken into account!
3. Add any good references throughout the document - posed in
question to v6ops
4. Ensure references are in the proper section (normative/
informative)
5. Include a number of references from RFC3724?
6. Add brokenness reference to
http://ripe61.ripe.net/presentations/162-ripe61.pdf
7. Should I include a full list or other details of the root causes
of IPv6 brokenness? - posed in question to v6ops
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
 End of changes. 57 change blocks. 
231 lines changed or deleted 353 lines changed or added

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