draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational February 6, 2011 Intended status: Informational February 22, 2011
Expires: August 10, 2011 Expires: August 26, 2011
IPv6 AAAA DNS Whitelisting Implications IPv6 AAAA DNS Whitelisting Implications
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Abstract Abstract
The objective of this document is to describe what whitelisting of The objective of this document is to describe what the whitelisting
DNS AAAA resource records is, or DNS whitelisting for short, as well of DNS AAAA resource records is, hereafter referred to as DNS
as what the implications of this emerging practice are and what whitelisting, as well as the implications of this emerging practice
alternatives may exist. The audience for this document is the and what alternatives may exist. The audience for this document is
Internet community generally, including the IETF and IPv6 the Internet community generally, including the IETF and IPv6
implementers. implementers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 10, 2011. This Internet-Draft will expire on August 26, 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 6
3. What Problems Are Implementers Trying To Solve? . . . . . . . 7 2.1. Description of the Operation of DNS Whitelisting . . . . . 7
4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 8 3. What Problems Are Implementers Trying To Solve? . . . . . . . 8
5. Similarities to Other DNS Operations . . . . . . . . . . . . . 10 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 9
5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 11 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 12
5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 11 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 12
6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 12 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 12
6.1. Deploying DNS Whitelisting Universally . . . . . . . . . . 12 6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 13
6.2. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13
7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 14 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 14
7.1. Architectural Implications . . . . . . . . . . . . . . . . 14 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15
7.2. Public IPv6 Address Reachability Implications . . . . . . 15 7.1. Architectural Implications . . . . . . . . . . . . . . . . 15
7.3. Operational Implications . . . . . . . . . . . . . . . . . 16 7.2. Public IPv6 Address Reachability Implications . . . . . . 16
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 16 7.3. Operational Implications . . . . . . . . . . . . . . . . . 17
7.3.2. Authoritative DNS Server Operational Implications . . 16 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 17
7.3.2. Authoritative DNS Server Operational Implications . . 17
7.3.3. DNS Recursive Resolver Server Operational 7.3.3. DNS Recursive Resolver Server Operational
Implications . . . . . . . . . . . . . . . . . . . . . 16 Implications . . . . . . . . . . . . . . . . . . . . . 18
7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 17 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 19
7.3.5. Implications of Operational Momentum . . . . . . . . . 18 7.3.5. Implications of Operational Momentum . . . . . . . . . 19
7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 18 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . . . 20
7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 19 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 20
7.5. Technology Policy Implications . . . . . . . . . . . . . . 20 7.5. Technology Policy Implications . . . . . . . . . . . . . . 21
7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 21 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22
8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 22 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 23
8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 22 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 23
8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 22 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 23
8.3.1. Solving Current End User IPv6 Impairments . . . . . . 22 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 24
9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 23 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 24
10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.2. Authoritative DNS Response Consistency Considerations . . 24 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 25
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 24 10.2. Authoritative DNS Response Consistency Considerations . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . . 27 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 29 15.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
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), which contain IPv6 addresses, or DNS AAAA resource records (RRs), which contain IPv6 addresses, hereafter
whitelisting for short. It also explores the implications of this referred to as DNS whitelisting. The document explores the
emerging practice are and what alternatives may exist. implications of this 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 (sometimes described herein as "highly- major web content sites (sometimes described herein as "highly-
trafficked domains" or "major domains"). These web site operators, trafficked domains" or "major domains"). These web site operators,
or domain operators, observed that when they added AAAA resource or domain operators, observed that when they added AAAA resource
records to their authoritative DNS servers that a small fraction of records to their authoritative DNS servers in order to support IPv6
end users had slow or otherwise impaired access to a given web site access to their content that a small fraction of end users had slow
with both AAAA and A resource records. The fraction of users with or otherwise impaired access to a given web site with both AAAA and A
such impaired access has been estimated to be roughly 0.078% of total resource records. The fraction of users with such impaired access
Internet users [IETF 77 DNSOP WG Presentation] [Network World Article has been estimated to be roughly 0.078% of total Internet users
on IETF 77 DNSOP WG Presentation] [Evaluating IPv6 Adoption] [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
[Measuring and Combating IPv6 Brokenness]. Thus, in an example Brokenness]. Thus, in an example Internet Service Provider (ISP)
Internet Service Provider (ISP) network of 10 million users, network of 10 million users, approximately 7,800 of those users may
approximately 7,800 of those users may experience such impaired experience such impaired access.
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 major domains have either implemented DNS whitelisting or are
or strongly consider the implementation of DNS whitelisting [Network considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
World Article on DNS Whitelisting] [IPv6 Whitelist Operations]. When 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
resolvers [RFC1035] on the whitelist, while returning no AAAA resolvers [RFC1035] on the whitelist, while returning no AAAA
resource records to DNS resolvers which are not on the whitelist. It resource records to DNS resolvers which are not on the whitelist. It
is important to note that these web site operators are motivated to is important to note that these major domains are motivated by a
maintain a high-quality user experience for all of their users, and desire to maintain a high-quality user experience for all of their
that they are attempting to shield users with impaired access from users. By engaging in DNS whitelisting, they are attempting to
the symptoms of these impairments that would negatively affect their shield users with impaired access from the symptoms of those
access to certain websites and related Internet resources. impairments.
However, critics of this emerging practice of DNS whitelisting have Critics of the practice of DNS whitelisting have articulated several
articulated several concerns. Among these are that this is a very concerns. Among these are that:
different behavior from the current practice concerning the
publishing of IPv4 address records, that it may create a two-tiered o DNS whitelisting is a very different behavior from the current
Internet, that policies concerning whitelisting and de-whitelisting practice concerning the publishing of IPv4 address resource
are opaque, that DNS whitelisting reduces interest in the deployment records,
of IPv6, that new operational and management burdens are created, and
that the costs and negative implications of DNS whitelisting outweigh o that it may create a two-tiered Internet,
the perceived benefits as compared to fixing underlying impairments.
o that policies concerning whitelisting and de-whitelisting are
opaque,
o that DNS whitelisting reduces interest in the deployment of IPv6,
o that new operational and management burdens are created,
o and that the costs and negative implications of DNS whitelisting
outweigh the perceived benefits, compared to fixing underlying
impairments.
This document explores the reasons and motivations for DNS This document explores the reasons and motivations for DNS
whitelisting. It also explores the concerns regarding this emerging whitelisting. It also explores the outlined concerns regarding this
practice. As a result, readers can hopefully better understand what practice. Readers will hopefully better understand what DNS
DNS whitelisting is, why some parties are implementing it, and why whitelisting is, why some parties are implementing it, and what
other parties are critical of the practice. criticisms of the practice exist.
2. How DNS Whitelisting Works 2. How DNS Whitelisting Works
DNS whitelisting is implemented in authoritative DNS servers, where DNS whitelisting is implemented in authoritative DNS servers. These
those servers implement IP address-based restrictions on AAAA query servers implement IP address-based restrictions on AAAA query
responses, which contain IPv6 addresses. In practice DNS responses. So far, DNS whitelisting has been primarily implemented
whitelisting has been primarily implemented by web server operators. by web server operators deploying IPv6-enabled services. For a given
For a given operator of the website www.example.com, that operator operator of a website, such as www.example.com, the operator
essentially applies an access control list (ACL) on their essentially applies an access control list (ACL) on the authoritative
authoritative DNS servers, which are authoritative for the domain DNS servers for the domain example.com. The ACL is populated with
example.com. The ACL is then configured with the IPv4 and/or IPv6 the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive
addresses of DNS recursive resolvers on the Internet, which have been resolvers on the Internet, which have been authorized to receive AAAA
authorized to be added to the ACL and to therefore receive AAAA
resource record responses. These DNS recursive resolvers are resource record responses. These DNS recursive resolvers are
operated by other parties, such as ISPs, universities, governments, operated by third parties, such as ISPs, universities, governments,
businesses, individual end users, etc. If a DNS recursive resolver businesses, and individual end users. If a DNS recursive resolver IS
IS NOT on the ACL, then AAAA resource records will NOT be sent in NOT matched in the ACL, then AAAA resource records will NOT be sent
response to a query for a given hostname in the example.com domain. in response to a query for a hostname in the example.com domain.
However, if a DNS recursive resolver IS on the ACL, then AAAA However, if a DNS recursive resolver IS matched in the ACL, then AAAA
resource records will be sent in response to a query for a given resource records will be sent in response to a query for a given
hostname in the example.com domain. While these are not network- hostname in the example.com domain. While these are not network-
layer access controls, they are nonetheless access controls that are layer access controls they are nonetheless access controls that are a
a factor for both end users and are directly related to the factor for end users and other parties like network operators,
transition of one network address family to another (IPv4 to IPv6). especially as networks and hosts transition from one network address
family to another (IPv4 to IPv6).
In practice this generally means that a very small fraction of the In practice, DNS whitelisting generally means that a very small
DNS recursive resolvers on the Internet can receive AAAA responses, fraction of the DNS recursive resolvers on the Internet (those in the
which means that the large majority of DNS resolvers on the Internet whitelist ACL) will receive AAAA responses. The large majority of
will receive only A resource records with IPv4 addresses. Thus, DNS resolvers on the Internet will therefore receive only A resource
quite simply, the authoritative server hands out different answers records containing IPv4 addresses. Thus, quite simply, the
depending upon who is asking; with IPv4 and IPv6 records for some on authoritative server hands out different answers depending upon who
the authorized whitelist, and only IPv4 records for everyone else. is asking; with IPv4 and IPv6 resource records for some on the
See Figure 1 and Figure 2 for two different visual descriptions of authorized whitelist, and only IPv4 resource records for everyone
how this works in practice. else. See Section 2.1 and Figure 1 for a description of how this
works.
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. Deployment on
potential deployment models are described in Section 6. a universal deployment basis means that DNS whitelisting is
implemented on all authoritative DNS servers, across the entire
Internet. In contrast, deployment on an ad hoc basis means that only
some authoritative DNS servers, and perhaps even only a few,
implement DNS whitelisting. These two potential deployment models
are described in Section 6.
1: The authoritative DNS server for example.com receives a DNS 2.1. Description of the Operation of DNS Whitelisting
query for www.example.com, for which both A (IPv4) and AAAA
(IPv6) address records exist.
2: The authoritative DNS server examines the IP address of the DNS
recursive resolver sending the query.
3: The authoritative DNS server checks this IP address against the
access control list (ACL) that is the DNS whitelist.
4: If the DNS recursive resolver's IP address IS listed in the ACL,
then the response to that specific DNS recursive resolver can
contain both A (IPv4) and AAAA (IPv6) address records.
5: If the DNS recursive resolver's IP address IS NOT listed in the
ACL, then the response to that specific DNS recursive resolver
can contain only A (IPv4) address records and therefore cannot
contain AAAA (IPv6) address records.
Figure 1: DNS Whitelisting - System Logic The system logic of DNS whitelisting is as follows:
1. The authoritative DNS server for example.com receives DNS queries
for the A (IPv4) and AAAA (IPv6) address resource records for the
FQDN www.example.com, for which AAAA (IPv6) resource records
exist.
2. The authoritative DNS server examines the IP address of the DNS
recursive resolver sending the AAAA (IPv6) query.
3. The authoritative DNS server checks this IP address against the
access control list (ACL) that is the DNS whitelist.
4. If the DNS recursive resolver's IP address IS matched in the ACL,
then the response to that specific DNS recursive resolver can
contain AAAA (IPv6) address resource records.
5. If the DNS recursive resolver's IP address IS NOT matched in the
ACL, then the response to that specific DNS recursive resolver
cannot contain AAAA (IPv6) address resource records. In this
case, the server should return a response with the response code
(RCODE) being set to 0 (No Error) with an empty answer section
for the AAAA record query.
--------------------------------------------------------------------- ---------------------------------------------------------------------
A query is sent from a DNS recursive resolver that IS NOT on the DNS A query is sent from a DNS recursive resolver that IS NOT on the DNS
whitelist: whitelist:
Request Request Request Request
www.example.com www.example.com www.example.com www.example.com
AAAA +-------------+ AAAA +-----------------+ AAAA +-------------+ AAAA +-----------------+
++--++ ---------> | RESOLVER | ---------> | www.example.com | ++--++ ---------> | RESOLVER | ---------> | www.example.com |
|| || A | **IS NOT** | A | IN A exists | || || A | **IS NOT** | A | IN A exists |
skipping to change at page 7, line 41 skipping to change at page 8, line 41
+--------+ AAAA | example.com | AAAA | | +--------+ AAAA | example.com | AAAA | |
Host <--------- | WHITELIST | <--------- | | Host <--------- | WHITELIST | <--------- | |
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 1: DNS Whitelisting - Functional Diagram
3. What Problems Are Implementers Trying To Solve? 3. What Problems Are Implementers Trying To Solve?
As noted in Section 1, domains which implement DNS whitelisting are As noted in Section 1, domains which implement DNS whitelisting are
attempting to protect a few users of their domain, which happen to attempting to protect a few users of their domain, who have impaired
have impaired IPv6 access, from having a negative end user IPv6 access, from having a negative experience (poor performance).
experience. While it is outside the scope of this document to While it is outside the scope of this document to explore the various
explore the various reasons why a particular user may experience reasons why a particular user's system (host) may have impaired IPv6
impaired IPv6 access, for the users which experience this it is a access, for the users who experience this impairment it is a very
very real effect and would of course affect access to all or most real performance impact. It would affect access to all or most dual
IPv4 and IPv6 dual stack servers. This negative end user experience stack services to which the user attempts to connect. This negative
can range from someone slower than usual (as compared to native IPv4- end user experience can range from someone slower than usual (as
based access), to extremely slow, to no access to the domain compared to native IPv4-based access), to extremely slow, to no
whatsoever. access to the domain whatsoever.
Thus, parties which implement DNS whitelisting are attempting to While one can debate whether DNS whitelisting is the optimal solution
provide a good experience to these end users. While one can debate to the end user experience problem, it is quite clear that DNS
whether DNS whitelisting is the optimal solution, it is quite clear whitelisting implementers are interested in maximizing the
that DNS whitelisting implementers are extremely interested in the performance of their services for end users as a primary motivation
performance of their services for end users as a primary motivation. for implementation.
In addition, at least one highly-trafficked domain has noted that At least one highly-trafficked domain has noted that they have
they have received requests to not send DNS responses with AAAA received requests to not send DNS responses with AAAA resource
resource records to particular resolvers. In these cases, the records to particular resolvers. In this case, the operators of
operators of those recursive resolvers have expressed a concern that those recursive resolvers have expressed a concern that their IPv6
their IPv6 network infrastructure is not yet ready to handle the network infrastructure is not yet ready to handle the large traffic
large traffic volume which may be associated with the hosts in their volume which may be associated with the hosts in their network
network connecting to the websites of these domains. In this case, connecting to the websites of these domains. This concern is clearly
this is clearly a temporary concern relating to the deployment of IP a temporary consideration relating to the deployment of IPv6 network
network infrastructure on the part of networks with end user hosts, infrastructure on the part of networks with end user hosts, rather
rather than a long-term concern. These end user networks may also than a long-term concern. These end user networks may also have
have other tools at their disposal in order to address this, other tools at their disposal in order to address this concern,
including applying rules to network equipment such as routers and including applying rules to network equipment such as routers and
firewalls (this will necessarily vary by the type of network, as well firewalls (this will necessarily vary by the type of network, as well
as the technologies used and the design of a given network). as the technologies used and the design of a given network), as well
as configuration of their recursive resolvers (though modifying or
suppressing AAAA resource records in a DNSSEC-signed domain on a
Security-Aware Resolver will be problematic Section 10.1).
Some implementers with highly-trafficked domains have also explained Some implementers with highly-trafficked domains have explained that
that DNS whitelisting is a necessary, though temporary, risk DNS whitelisting is a necessary, though temporary, risk reduction
reduction tactic intended to ease their transition to IPv6 and tactic intended to ease their transition to IPv6 and minimize any
minimize any perceived risk in such a transition. As a result, they perceived risk in such a transition. As a result, they perceive this
perceive this as a tactic to enable them to incrementally enable IPv6 as a tactic to enable them to incrementally enable IPv6 connectivity
connectivity to their domains during the early phases of the to their domains during the early phases of their transition to IPv6.
transition to IPv6.
Finally, some domains, such as major German news website, have run Finally, some domains, have run IPv6 experiments whereby they added
IPv6 experiments whereby they added AAAA resource records and AAAA resource records and observed and measured errors [Heise Online
observed and measured any errors [Heise Online Experiment], which is Experiment], which should be important reading for any domain
important reading for any domain contemplating either the use of DNS contemplating either the use of DNS whitelisting or simply adding
whitelisting or simply adding IPv6 addressing to their site. IPv6 addressing to their site.
4. Concerns Regarding DNS Whitelisting 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 been raised as concerns by some parts of the
Internet community. Many of those potential implications are Internet community. Many of those potential implications are further
described in Section 7. enumerated 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 this emerging practice of DNS whitelisting for IPv6 address that the practice of DNS whitelisting for IPv6 address resource
records could represent a departure from the generally accepted records represents a departure from the generally accepted practices
practices regarding IPv4 address records in the DNS on the Internet regarding IPv4 address resource records in the DNS on the Internet
[IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?]. These [Whitelisting Concerns]. These parties explain their belief that for
parties explain their belief that for A records, containing IPv4 A resource records, containing IPv4 addresses, once an authoritative
addresses, once an authoritative server operator adds the A record to server operator adds the A record to the DNS, then any DNS recursive
the DNS, then any DNS recursive resolver on the Internet can receive resolver on the Internet can receive that A record in response to a
that A record in response to a query. By extension, this means that query. By extension, this means that any of the hosts connected to
any of the hosts connected to any of these DNS recursive resolvers any of these DNS recursive resolvers can receive the IPv4 address
can receive the IPv4 address records for a given FQDN. This enables resource records for a given FQDN. This enables new server hosts
new server hosts which are connected to the Internet, and for which a which are connected to the Internet, and for which a fully qualified
fully qualified domain name (FQDN) such as www.example.com has been domain name (FQDN) such as www.example.com has been added to the DNS
added to the DNS with an IPv4 address record, to be almost with an IPv4 address record, to be almost immediately reachable by
immediately reachable by any host on the Internet. In this case, any host on the Internet. In this case, these new servers hosts
these new servers hosts become more and more widely accessible as new become more and more widely accessible as new networks and new end
networks and new end user hosts connect to the Internet over time, user hosts connect to the Internet over time, capitalizing on and
capitalizing on and increasing so-called "network effects" (also increasing so-called "network effects" (also called network
called network externalities). It also means that the new server externalities). It also means that the new server hosts do not need
hosts do not need to know about these new networks and new end user to know about these new networks and new end user hosts in order to
hosts in order to make their content and applications available to make their content and applications available to them, in essence
them, in essence that each end in this end-to-end model is that each end in this end-to-end model is responsible for connecting
responsible for connecting to the Internet and once they have done so to the Internet and once they have done so they can connect to each
they can connect to each other without additional impediments or other without additional impediments or middle networks or
middle networks or intervening networks or servers knowing about intervening networks or servers knowing about these end points and
these end points and whether one is allowed to contact the other. whether one is allowed to contact the other.
In contrast, these parties are concerned that DNS whitelisting may In contrast, the concern is that DNS whitelisting may fundamentally
fundamentally change this model. As a result, in this altered end- change this model. In the altered DNS whitelisting end-to-end model,
to-end model, one end (where the end user is located) cannot readily one end (where the end user is located) cannot readily connect to the
connect to the other end (where the content is located), without other end (where the content is located), without parts of the middle
parts of the middle used by one end being known by the other end and (recursive resolvers) used by one end (the client, or end user hosts)
approved for access to that end. Thus, as new networks connect to being known to an intermediary (authoritative nameservers) and
the Internet over time, those networks need to contact any and all approved for access to the resource at the end. As new networks
domains which have implemented DNS whitelisting in order to apply to connect to the Internet over time, those networks need to contact any
be added to their DNS whitelist, in the hopes of making the content and all domains which have implemented DNS whitelisting in order to
and applications residing on named server hosts in those domains apply to be added to their DNS whitelist, in the hopes of making the
accessible by the end user hosts on that new network. Furthermore, content and applications residing on named server hosts in those
this same need to contact all domains implementing DNS whitelisting domains accessible by the end user hosts on that new network.
also applies to all existing networks connected to the Internet. Furthermore, this same need to contact all domains implementing DNS
whitelisting also applies to all pre-existing (but not whitelisted)
networks connected to the Internet.
Therefore, these concerned parties explain, whereas in the current In the current IPv4 Internet when a new server host is added to the
IPv4 Internet when a new server host is added to the Internet it is Internet it is generally widely available to all end user hosts and
widely available to all end user hosts and networks, when DNS networks, when DNS whitelisting of IPv6 resource records is used,
whitelisting of IPv6 records is used then these new server hosts are these new server hosts are not accessible to any end user hosts or
not accessible to any end user hosts or networks until such time as networks until such time as the operator of the authoritative DNS
the operator of the authoritative DNS servers for those new server servers for those new server hosts expressly authorizes access to
hosts expressly authorizes access to those new server hosts by adding those new server hosts by adding DNS recursive resolvers around the
DNS recursive resolvers around the Internet to the ACL. This could Internet to the ACL. This has the potential to be a significant
represent a significant change in reachability of content and change in reachability of content and applications by end users and
applications by end users and networks as these end user hosts and networks as these end user hosts and networks transition to IPv6,
networks transition to IPv6. Therefore, a concern expressed is that resulting in more (but different) breakage. A concern expressed is
if much of the content that end users are most interested in is not that if much of the content that end users are most interested in is
accessible as a result, then end users and/or networks may resist not accessible as a result, then end users and/or networks may resist
adoption of IPv6 or actively seek alternatives to it, such as using 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 the other end users that are also using parties say, over 99.9% of the other end users that are also using
skipping to change at page 10, line 44 skipping to change at page 11, line 48
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. Of course, this comparison of the Internet for a variety of reasons. Of course, this comparison of the
level of worldwide IPv6 impairments to IPv4 impairments is level of worldwide IPv6 impairments to IPv4 impairments is
speculation, as the author is not aware of any good measurement of speculation, as the author is not aware of any good measurement of
IPv4-related impairments which are comparable in nature to the IPv6- IPv4-related impairments which are comparable in nature to the IPv6-
related impairment measurements which have recently been conducted related impairment measurements which have recently been conducted
around the world. around the world.
An additional concern is that the IP address of a recursive resolver
is not a precise indicator of the IPv6 preparedness, or lack of IPv6-
related impairments, of end user hosts which query (use) a particular
recursive resolver. While the recursive resolver may be an imperfect
proxy for judging IPv6 preparedness, it is at least one of the best
available methods at the current time.
5. 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 to other
ways to other common DNS operational techniques, which is explored common DNS operational techniques which are explored below.
briefly below.
5.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,
is briefly described in Section 3.8 of [RFC2775]. When split DNS 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,
so far as hosts of different networks, which use different DNS whereby hosts on different networks, which use different DNS
recursive resolvers, receive different answers if one DNS recursive recursive resolvers, receive different answers if one DNS recursive
resolver is on the whitelist and the other is not. Thus, in a way, resolver is on the whitelist and the other is not.
DNS whitelisting could in some ways be considered split DNS on the
public Internet, though with some differences.
In [RFC2956], Internet transparency and Internet fragmentation In [RFC2956], Internet transparency and Internet fragmentation
concerns regarding split DNS are detailed in Section 2.1. [RFC2956] concerns regarding split DNS are detailed in Section 2.1. [RFC2956]
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."
5.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 of course many ways that DNS load balancing can be
course this can mean many things to different people. In one performed. In one example, multiple IP address resource records (A
example, multiple IP address resource records (A or AAAA) can be and/or AAAA) can be added to the DNS for a given FQDN. This approach
added to the DNS to resolve a given FQDN, which is referred to as DNS is referred to as DNS round robin [RFC1794]. DNS round robin may
round robin [RFC1794], or even where SRV resource records are used also be employed where SRV resource records are used [RFC2782].
[RFC2782]. In another example, one or more of the IP address
resource records in the DNS will direct traffic to a load balancer. In another example, one or more of the IP address resource records in
That load balancer, in turn, may be application-aware, and pass the the DNS will direct traffic to a load balancer. That load balancer,
traffic on to one or more hosts connected to the load balancer which in turn, may be application-aware, and pass the traffic on to one or
have different IP addresses. In cases where private IPv4 addresses more hosts connected to the load balancer which have different IP
are used [RFC1918], as well as when public IP addresses are used, addresses. In cases where private IPv4 addresses are used [RFC1918],
those end hosts may not be directly reachable without passing through as well as when public IP addresses are used, those end hosts may not
the load balancer first . As such, while the IP address resource be directly reachable without passing through the load balancer first
records have been added to the DNS, the end hosts are not necessarily . As such, while the IP address resource records have been added to
directly reachable, which is in a small way similar to one aspect of the DNS, the end hosts are not necessarily directly reachable, which
DNS whitelisting. In addition, a geographically-aware authoritative is in a small way similar to one aspect of DNS whitelisting.
DNS server may be used, as is common with Content Delivery Networks
(CDNs), whereby the IP address resource records returned to a Additionally, a geographically-aware authoritative DNS server may be
resolver in response to a query will vary based on the estimated used, as is common with Content Delivery Networks (CDNs) or Global
geographic location of the resolver [Comparing DNS Resolvers in the Load Balancing (GLB, also referred to as Global Server Load
Wild]. CDNs perform this function in order to attempt to direct Balancing, or GSLB), whereby the IP address resource records returned
hosts to connect to the nearest content cache. As a result, one can to a resolver in response to a query will vary based on the estimated
see some similarities with DNS whitelisting insofar as different IP geographic location of the resolver [Resolvers in the Wild]. CDNs
address resource records are returned to resolvers based on the IP perform this function in order to attempt to direct hosts to connect
address of each resolver (or other imputed factors related to that IP to the nearest content cache. As a result, one can see some
address). However, what is different of course, if that in this case similarities with DNS whitelisting insofar as different IP address
the resolvers are not necessarily blocked from receiving DNS resource records are selectively returned to resolvers based on the
responses containing an entire class of addresses; this load IP address of each resolver (or other imputed factors related to that
balancing function strives to perform a content location-improvement IP address). However, what is different is that in this case the
function and not an access control function. resolvers are not deliberately blocked from receiving DNS responses
containing an entire class of addresses; this load balancing function
strives to perform a content location-improvement function and not an
access control function.
6. 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 deployment scenarios, it is possible that
that reputable third parties could create and maintain these DNS reputable third parties could create and maintain DNS whitelists, in
whitelists, in much the same way that blacklists are used for much the same way that blacklists are used for reducing email spam.
reducing email spam. In this email example, a mail operator In the email context, a mail operator subscribes to one or more of
subscribes to one or more of these lists and as such the operational these lists and as such the operational processes for additions and
processes for additions and deletions to the list are managed by a deletions to the list are managed by a third party. A similar model
third party. Thus, a similar model could emerge for DNS could emerge for DNS whitelisting, whether deployment occurs
whitelisting, whether deployment occurs universally or on an ad hoc universally or on an ad hoc basis.
basis.
6.1. Deploying DNS Whitelisting Universally 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis
The least likely deployment scenario is one where DNS whitelisting The seemingly most likely deployment scenario is where some
becomes a standardized process across all authoritative DNS servers, authoritative DNS server operators implement DNS whitelisting but
across the entire Internet. While this scenario is the least likely, many or most others do not do so. What can make this scenario
due to some parties not sharing the concerns that have so far challenging from the standpoint of a DNS recursive resolver operator
motivated the use of DNS whitelisting, it is nonetheless conceivable is determining which domains implement DNS whitelisting, particularly
that it could be one of the ways in which DNS whitelisting may be since a domain may not do so as they initially transition to IPv6,
deployed. and may instead do so later. Thus, a DNS recursive resolver operator
may initially believe that they can receive AAAA responses as a
domain adopts IPv6, but then notice via end user reports that they no
longer receive AAAA responses due to that domain adopting DNS
whitelisting. Of course, a domain's IPv6 transition may be
effectively invisible to recursive server operators due to the effect
of DNS whitelisting.
In contrast to a universal deployment of DNS whitelisting
Section 6.2, deployment on an ad hoc basis is likely to be
significantly more challenging from an operational, monitoring, and
troubleshooting standpoint. In this scenario, a DNS recursive
resolver operator will have no way to systematically determine
whether DNS whitelisting is or is not implemented for a domain, since
the absence of AAAA resource records may simply be indicative that
the domain has not yet added IPv6 addressing for the domain, rather
than that they have done so but have restricted query access via DNS
whitelisting. As a result, discovering which domains implement DNS
whitelisting, in order to differentiate them from those that do not,
is likely to be challenging.
One benefit of DNS whitelisting being deployed on an ad hoc basis is
that only the domains that are interested in doing so would have to
upgrade their authoritative DNS servers in order to implement the
ACLs necessary to perform DNS whitelisting.
In this potential deployment scenario, it is also possible that a
given domain will implement DNS whitelisting temporarily. A domain,
particularly a highly-trafficked domain, may choose to do so in order
to ease their transition to IPv6 through a selective deployment and
minimize any perceived risk in such a transition.
6.2. Deploying DNS Whitelisting Universally
The least likely deployment scenario is one where DNS whitelisting is
implemented on all authoritative DNS servers, across the entire
Internet. While this scenario seems less likely than ad hoc
deployment due to some parties not sharing the concerns that have so
far motivated the use of DNS whitelisting, it is nonetheless
conceivable that it could be one of the ways in which DNS
whitelisting is 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
whitelisting functionality would need to be built into all whitelisting functionality would need to be built into all
authoritative DNS server software, and that all operators of authoritative DNS server software, and that all operators of
authoritative DNS servers would have to upgrade their software and authoritative DNS servers would have to upgrade their software and
enable this functionality. Furthermore, it is likely that new enable this functionality. It is likely that new Internet Draft
Internet Draft documents would need to be developed which describe documents would need to be developed which describe how to properly
how to properly configure, deploy, and maintain DNS whitelisting. As configure, deploy, and maintain DNS whitelisting. As a result, it is
a result, it is unlikely that DNS whitelisting would, at least in the unlikely that DNS whitelisting would, at least in the next several
next several years, become universally deployed. Furthermore, these years, become universally deployed. Furthermore, these DNS
DNS whitelists are likely to vary on a domain-by-domain basis, whitelists are likely to vary on a domain-by-domain basis, depending
depending upon a variety of factors. Such factors may include the upon a variety of factors. Such factors may include the motivation
motivation of each domain owner, the location of the DNS recursive of each domain owner, the location of the DNS recursive resolvers in
resolvers in relation to the source content, as well as various other relation to the source content, as well as various other parameters
parameters that may be transitory in nature, or unique to a specific that may be transitory in nature, or unique to a specific end user
end user host type. Thus, it is probably unlikely that a single host type. It is probably unlikely that a single clearinghouse for
clearinghouse for managing whitelisting is possible; it will more managing whitelisting is possible; it will more likely be unique to
likely be unique to the source content owners and/or domains which the source content owners and/or domains which implement DNS
implement DNS whitelists. whitelists.
While this scenario may be unlikely, it may carry some benefits. While this scenario may be unlikely, it may carry some benefits.
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.
6.2. Deploying DNS Whitelisting On An Ad Hoc Basis
This is the most likely deployment scenario for DNS whitelisting, as
it seems today, is where some interested parties engage in DNS
whitelisting but many or most others do not do so. What can make
this scenario challenging from the standpoint of a DNS recursive
resolver operator is determining which domains implement DNS
whitelisting, particularly since a domain may not do so as they
initially transition to IPv6, and may instead do so later. Thus, a
DNS recursive resolver operator may initially believe that they can
receive AAAA responses as a domain adopts IPv6, but then notices via
end user reports that they no longer receive AAAA responses due to
that site adopting DNS whitelisting.
Thus, in contrast to universal deployment of DNS whitelisting,
deployment on an ad hoc basis is likely to be significantly more
challenging from an operational, monitoring, and troubleshooting
standpoint. In this scenario, a DNS recursive resolver operator will
have no way to systematically determine whether DNS whitelisting is
or is not implemented for a domain, since the absence of AAAA records
may simply be indicative that the domain has not yet added IPv6
addressing for the domain, not that they have done so but have
restricted query access via DNS whitelisting. As a result,
discovering which domains implement DNS whitelisting, in order to
differentiate them from those that do not, is likely to be
challenging.
On the other hand, one benefit of DNS whitelisting being deployed on
an ad hoc basis is that only the domains that are interested in doing
so would have to upgrade their authoritative DNS servers in order to
implement the ACLs necessary to perform DNS whitelisting.
In this potential deployment scenario, it is also possible that a
given domain will implement DNS whitelisting temporarily. A domain,
particularly a highly-trafficked domain, may choose to do so in order
to ease their transition to IPv6 and minimize any perceived risk in
such a transition.
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. The key
sections below, the key potential implications are listed in some potential implications are detailed below.
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 modifying the end-to-end model
end model and/or the general notion of the architecture that prevails and/or the general notion of the architecture that prevails on the
on the Internet today. This is because this approach moves Internet today. This is because this approach moves additional
additional access control information and policies into the middle of access control information and policies into the middle of the DNS
the DNS resolution path on the IPv6-addressed Internet, which did not resolution path of the IPv6-addressed Internet, which generally did
exist before on the IPv4-addressed Internet. This could raise some not exist before on the IPv4-addressed Internet. This poses some
risks noted in [RFC3724], which in explaining the history of the end- risks noted in [RFC3724]. In explaining the history of the end-to-
to-end principle [RFC1958] explains that one of the goals is to end principle [RFC1958] states that one of the goals is to minimize
minimize the state, policies, and other functions needed in the the state, policies, and other functions needed in the middle of the
middle of the network in order to enable end-to-end communications on network in order to enable end-to-end communications on the Internet.
the Internet. In this case, the middle network should be understood In this case, the middle network should be understood to mean
to mean anything other than the end hosts involved in communicating anything other than the end hosts involved in communicating with one
with one another. Obviously some state, policies, and other another. Some state, policies, and other functions have always been
functions have always been necessary to enable such end-to-end necessary to enable such end-to-end communication, but the goal of
communication, but the goal of the approach has been to minimize this the approach has been to minimize this to the greatest extent
to the greatest extent possible. possible.
It is also possible that DNS whitelisting could place at risk some of It is also possible that DNS whitelisting could place at risk some of
the benefits of the end-to-end principle, as listed in Section 4.1 of the observed benefits of the end-to-end principle, as listed in
[RFC3724], such as protection of innovation. Further, while Section 4.1 of [RFC3724], such as protection of innovation.
[RFC3234] details issues and concerns regarding so-called [RFC3234] details issues and concerns regarding so-called
middleboxes, there may be parallels to DNS whitelisting, especially middleboxes, so there may also be parallel concerns with the DNS
concerning modified DNS servers noted in Section 2.16 of [RFC3234], whitelisting approach, especially concerning modified DNS servers
and more general concerns noted in Section 1.2 of [RFC3234] about the noted in Section 2.16 of [RFC3234], as well as more general concerns
introduction of new failure modes, that configuration is no longer noted in Section 1.2 of [RFC3234] about the introduction of new
limited to two ends of a session, and that diagnosis of failures and failure modes. In particular, there may be concerns that
misconfigurations is more complex. configuration is no longer limited to two ends of a session, and that
diagnosis of failures and misconfigurations becomes more complex.
In [Tussle in Cyberspace], the authors note concerns regarding the Two additional sources worth considering as far as implications for
introduction of new control points, as well as "kludges" to the DNS, the end-to-end model are concerned are [Tussle in Cyberspace] and
as risks to the goal of network transparency in the end-to-end model. [Rethinking the Internet]. In [Tussle in Cyberspace], the authors
Some parties concerned with the emerging use of DNS whitelisting have note concerns regarding the introduction of new control points, as
shared similar concerns, which may make [Tussle in Cyberspace] an well as "kludges" to the DNS, as risks to the goal of network
interesting and relevant document. In addition, [Rethinking the transparency in the end-to-end model. Some parties concerned with
design of the Internet] reviews similar issues that may be of the emerging use of DNS whitelisting have shared similar concerns,
interest to readers of this document. which may make [Tussle in Cyberspace] an interesting and relevant
document. In addition, [Rethinking the Internet] reviews similar
issues that may be of interest to readers of this document.
In order to explore and better understand these high-level Also, it is possible that DNS whitelisting could affect some of the
architectural implications and concerns in more detail, the following architectural assumptions which underlie parts of Section 2 of
sections explore more specific potential implications. [RFC4213] which outlines the dual stack approach to the IPv6
transition. DNS whitelisting could modify the behavior of the DNS,
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
that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
As such, broad use of DNS whitelisting may necessitate the review
and/or revision of standards documents which describe dual-stack and
IPv6 operating modes, dual-stack architecture generally, and IPv6
transition methods, including but not limited to [RFC4213].
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 when a new server with a public IPv4
server with a public IPv4 address is added, that it is then globally address is added to the DNS, that it is then globally accessible by
accessible by IPv4-addressed hosts. Of course, this is a IPv4-addressed hosts. This is a generalization and in Section 5
generalization and in Section 5 there are examples of common cases there are examples of common cases where this may not necessarily be
where this may not necessarily be the case. In any case, for the the case. For the purposes of this argument, that concept of
purposes of this document, that concept of accessibility can be accessibility can be considered "pervasive reachability". It has so
considered "pervasive reachability". It has so far been assumed that far been assumed that the same expectations of pervasive reachability
the same expectations of pervasive reachability would exist in the would exist in the IPv6-addressed Internet. However, if DNS
IPv6-addressed Internet. However, if DNS whitelisting is deployed, whitelisting is deployed, this will not be the case since only end
this will not be the case since only end user hosts using DNS user hosts using DNS recursive resolvers which are included in the
recursive resolvers which have been added to the ACL of a given ACL of a given domain using DNS whitelisting would be able to reach
domain using DNS whitelisting would be able to reach new servers in new servers in that given domain via IPv6 addresses. The expectation
that given domain via IPv6 addresses. Thus, the expectation of any of any end user host being able to connect to any server (essentially
end user host being able to connect to any server (essentially both both hosts, just at either end of the network), defined here as
hosts, just at either end of the network), defined here as "pervasive "pervasive reachability", will change to "restricted reachability"
reachability", will change to "restricted reachability" with IPv6. with IPv6.
In addition, establishing DNS whitelisting as an accepted practice in Establishing DNS whitelisting as an accepted practice in the early
the early phases of mass IPv6 deployment could well establish DNS phases of mass IPv6 deployment could well establish it as an integral
whitelisting as an integral part of how IPv6 is deployed globally. part of how IPv6 DNS resource records are deployed globally. As a
As a result, it is then possible that DNS whitelisting could live on result, it is then possible that DNS whitelisting could live on for
for decades on the Internet as a key foundational element of the decades on the Internet as a key foundational element of domain name
Internet of the future that we will all live with for a long time. management that we will all live with for a long time.
However, it is a critical to understand that the concept of It is a critical to understand that the concept of reachability
reachability described above depends upon a knowledge or awareness of described above depends upon a knowledge or awareness of an address
an address in the DNS. Thus, in order to establish reachability to in the DNS. Thus, in order to establish reachability to an end
an end point, a host is dependent upon looking up an IP address in point, a host is dependent upon looking up an IP address in the DNS
the DNS when a FQDN is used. Thus, when DNS whitelisting is used, it when a FQDN is used. When DNS whitelisting is used, it is quite
is quite likely the case that a end user host could ping a example likely the case that an IPv6-enabled end user host could ping or
server host, even though the FQDN associated with that server host is connect to an example server host, even though the FQDN associated
restricted via a DNS whitelist. But since most Internet applications with that server host is restricted via a DNS whitelist. Since most
and hosts such as web servers depend upon the DNS, and as end users Internet applications and hosts such as web servers depend upon the
connect to FQDNs such as www.example.com and do not remember or wish DNS, and as end users connect to FQDNs such as www.example.com and do
to type in an IP address, the notion of reachability described here not remember or wish to type in an IP address, the notion of
should be understood to include knowledge how to associate a name reachability described here should be understood to include knowledge
with a network address. how to associate a name with a network address.
7.3. Operational Implications 7.3. Operational Implications
This section explores some of the operationally related implications This section explores some of the operational implications which may
which may occur as a result of, related to, or necessary when occur as a result of, are related to, or become necessary when
engaging in the practice of DNS whitelisting. engaging in the practice of DNS whitelisting.
7.3.1. De-Whitelisting May Occur 7.3.1. De-Whitelisting May Occur
If it is possible for a DNS recursive resolver to be added to a It is possible for a DNS recursive resolver added to a whitelist to
whitelist, then it is also possible for that resolver to be removed then be removed from the whitelist, also known as de-whitelisting.
from the whitelist, also known as de-whitelisting. Since de- Since de-whitelisting can occur, through a decision by the
whitelisting can occur, whether through a decision by the authoritative server operator, the domain owner, or even due to a
authoritative server operator or the domain owner, or even due to a
technical error, an operator of a DNS recursive resolver will have technical error, an operator of a DNS recursive resolver will have
new operational and monitoring requirements and/or needs as noted in new operational and monitoring requirements and/or needs as noted in
Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.
7.3.2. Authoritative DNS Server Operational Implications 7.3.2. Authoritative DNS Server Operational Implications
Operators of authoritative servers may need to maintain an ACL a Operators of authoritative servers may need to maintain an ACL a
server-wide basis affecting all domains, on a domain-by-domain basis, server-wide basis affecting all domains, on a domain-by-domain basis,
as well as on a combination of the two. As a result, operational as well as on a combination of the two. As a result, operational
practices and software capabilities may need to be developed in order practices and software capabilities may need to be developed in order
to support such functionality. In addition, processes may need to be to support such functionality. In addition, processes may need to be
put in place to protect against inadvertently adding or removing IP put in place to protect against inadvertently adding or removing IP
addresses, as well as systems and/or processes to respond to such addresses, as well as systems and/or processes to respond to such
incidents if and when they occur. For example, a system may be incidents if and when they occur. For example, a system may be
needed to record DNS whitelisting requests, report on their status needed to record DNS whitelisting requests, report on their status
along a workflow, add IP addresses when whitelisting has been along a workflow, add IP addresses when whitelisting has been
approved, remove IP addresses when they have been de-whitelisted, log approved, remove IP addresses when they have been de-whitelisted, log
the personnel involved and timing of changes, schedule changes to the personnel involved and timing of changes, schedule changes to
occur in the future, and to roll back any inadvertent changes. occur in the future, and to roll back any inadvertent changes.
Such operators may also need implement new forms of monitoring in Operators may also need implement new forms of monitoring in order to
order to apply change control, as noted briefly in Section 7.3.4. apply change control, as noted briefly in Section 7.3.4.
7.3.3. DNS Recursive Resolver Server Operational Implications 7.3.3. DNS Recursive Resolver Server Operational Implications
Operators of DNS recursive resolvers, which may include ISPs, Operators of DNS recursive resolvers, which may include ISPs,
enterprises, universities, governments, individual end users, and enterprises, universities, governments, individual end users, and
many other parties, are likely to need to implement new forms of many other parties, are likely to need to implement new forms of
monitoring, as noted briefly in Section 7.3.4. But more critically, monitoring, as noted briefly in Section 7.3.4. But more critically,
such operators may need to add people, processes, and systems in such operators may need to add people, processes, and systems in
order to manage countless DNS whitelisting applications, for all order to manage large numbers of DNS whitelisting applications as
domains that the end users of such servers are interested in now or part of their own IPv6 transition, for all domains that the end users
in which they may be interested in the future. As such anticipation of such servers are interested in now or in which they may be
of interesting domains is likely infeasible, it is more likely that interested in the future. As anticipation of interesting domains is
such operators may either choose to only apply to be whitelisted for likely infeasible, it is more likely that operators may either choose
a domain based upon one or more end user requests, or that they will to only apply to be whitelisted for a domain based upon one or more
attempt to do so for all domains. end user requests, or that they will attempt to do so for all domains
that they can ascertain to be engaging in DNS whitelisting.
When such operators apply for DNS whitelisting for all domains, that When operators apply for DNS whitelisting for all domains, that may
may mean doing so for all registered domains. Thus, some system mean doing so for all registered domains. Thus, some system would
would have to be developed to discover whether each domain has been have to be developed to discover whether each domain has been
whitelisted or not, which is touched on in Section 6 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 These operators (of recursive resolvers) will need to develop
systems to track the status of all DNS whitelisting applications, processes and systems to track the status of all DNS whitelisting
respond to requests for additional information related to these applications, respond to requests for additional information related
applications, determine when and if applications have been denied, to these applications, determine when and if applications have been
manage appeals, and track any de-whitelisting actions. Given the denied, manage appeals, and track any de-whitelisting actions.
incredible number of domains in existence, the ease with which a new
domain can be added, and the continued strong growth in the numbers Given the large number of domains in existence, the ease with which a
of new domains, readers should not underestimate the potential new domain can be added, and the continued strong growth in the
significance in personnel and expense that this could represent for numbers of new domains, readers should not underestimate the
such operators. In addition, it is likely that systems and personnel potential significance in personnel and expense that this could
may also be needed to handle new end user requests for domains for represent for such operators. In addition, it is likely that systems
which to apply for DNS whitelisting, and/or inquiries into the status and personnel may also be needed to handle new end user requests for
of a whitelisting application, reports of de-whitelisting incidents, domains for which to apply for DNS whitelisting, and/or inquiries
general inquiries related to DNS whitelisting, and requests for DNS into the status of a whitelisting application, reports of de-
whitelisting-related troubleshooting by these end users. whitelisting incidents, general inquiries related to DNS
whitelisting, and requests for DNS whitelisting-related
troubleshooting by these end users.
7.3.4. Monitoring Implications 7.3.4. Monitoring Implications
Once a DNS recursive resolver has been whitelisted for a particular Once a DNS recursive resolver has been whitelisted for a particular
domain, then the operator of that DNS recursive resolver may need to domain, then the operator of that DNS recursive resolver may need to
implement monitoring in order to detect the possible loss of implement monitoring in order to detect the possible loss of
whitelisting status in the future. This DNS recursive resolver whitelisting status in the future. This DNS recursive resolver
operator could configure a monitor to check for a AAAA response in operator could configure a monitor to check for a AAAA response in
the whitelisted domain, as a check to validate continued status on the whitelisted domain, as a check to validate continued status on
the DNS whitelist. The monitor could then trigger an alert if at the DNS whitelist. The monitor could then trigger an alert if at
some point the AAAA responses were no longer received, so that some point the AAAA responses were no longer received, so that
operations personnel could begin troubleshooting, as outlined in operations personnel could begin troubleshooting, as outlined in
Section 7.3.6. Section 7.3.6.
Also, authoritative DNS server operators are likely to need to Also, authoritative DNS server operators are likely to need to
implement new forms of monitoring. In this case, they may desire to implement new forms of monitoring. In this case, they may desire to
monitor for significant changes in the size of the whitelist within a monitor for significant changes in the size of the whitelist within a
certain period of time, which might be indicative of a technical certain period of time, which might be indicative of a technical
error such as the entire ACL being removed. These operators may also error such as the entire ACL being removed. Authoritative nameserver
wish to monitor their workflow process for reviewing and acting upon operators may also wish to monitor their workflow process for
DNS whitelisting applications and appeals, potentially measuring and reviewing and acting upon DNS whitelisting applications and appeals,
reporting on service level commitments regarding the time an potentially measuring and reporting on service level commitments
application or appeal can remain at each step of the process, regarding the time an application or appeal can remain at each step
regardless of whether or not such information is shared with parties of the process, regardless of whether or not such information is
other than that authoritative DNS server operator. shared with parties other than that authoritative DNS server
operator.
These are but a few examples of the types of monitoring that may be
called for as a result of DNS whitelisting, among what are likely
many other types and variations.
7.3.5. Implications of Operational Momentum 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 in an understanding of human practices. This assumption is based in an understanding of human
nature, not to mention physics. For example, as Sir Issac Newton nature, not to mention physics. For example, as Sir Issac 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" that state of motion unless an external force is applied to it" [Laws
[Newton's Laws of Motion]. Thus, once DNS whitelisting is of Motion]. Thus, once DNS whitelisting is implemented it is quite
implemented it is quite likely that it would take considerable effort likely that it would take considerable effort to deprecate the
to deprecate the practice and remove it everywhere on the Internet - practice and remove it everywhere on the Internet - it will otherwise
it will otherwise simply remain in place in perpetuity. To better simply remain in place in perpetuity. To better illustrate this
illustrate this point, one could consider in one example (of many) point, one could consider one example (of many) that there are many
that here are likely many email servers continuing to attempt to email servers continuing to attempt to query or otherwise check anti-
query or otherwise check anti-spam DNS blocklists which have long ago spam DNS blocklists which have long ago ceased to exist.
ceased to exist.
7.3.6. Troubleshooting Implications 7.3.6. Troubleshooting Implications
The implications of DNS whitelisted present many challenges, which The implications of DNS whitelisted present many challenges, which
have been detailed in Section 7. These challenges may negatively have been detailed in Section 7. These challenges may negatively
affect the end users' ability to troubleshoot, as well as that of DNS affect the end users' ability to troubleshoot, as well as that of DNS
recursive resolver operators, ISPs, content providers, domain owners recursive resolver operators, ISPs, content providers, domain owners
(where they may be different from the operator of the authoritative (where they may be different from the operator of the authoritative
DNS server for their domain), and other third parties. This may make DNS server for their domain), and other third parties. This may make
the process of determining why a server is not reachable the process of determining why a server is not reachable
significantly more complex. significantly more complex.
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 likely that as
that as the number of domains that are whitelisted increases, as well the number of domains that are using DNS whitelisting increases, as
as the number of IPv6-capable networks requesting to be whitelisted, well as the number of IPv6-capable networks requesting to be
that there is an increased likelihood of configuration and other whitelisted, that there is an increased likelihood of configuration
operational errors, especially with respect to the ACLs themselves. and other operational errors, especially with respect to the ACLs
It is also unclear when and if it would be appropriate to change from themselves.
It is unclear when and if it would be appropriate to change from
whitelisting to blacklisting, and whether or how this could feasibly whitelisting to blacklisting, and whether or how this could feasibly
be coordinated across the Internet, which may be proposed when a be coordinated across the Internet, which may be proposed or
majority of networks (or allocated IPv6 address blocks) have been implemented on an ad hoc basis when a majority of networks (or
whitelisted. Finally, some parties implementing DNS whitelisting allocated IPv6 address blocks) have been whitelisted. Finally, some
consider this to be a temporary measure. As such, it is not clear parties implementing DNS whitelisting consider this to be a temporary
how these parties will judge the network conditions to have changed measure. As such, it is not clear how these parties will judge the
sufficiently to justify disabling DNS whitelisting and/or what the network conditions to have changed sufficiently to justify disabling
process and timing will be in order to turn off and stop this DNS whitelisting and/or what the process and timing will be in order
practice. to discontinue this practice.
One further potential implication is that an end user with only an One further potential implication is that an end user with only an
IPv4 address, using a DNS resolver which has not been whitelisted by 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 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 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 that there is no IPv6-based content on the Internet since they are
unable to discover any IPv6 addresses via the DNS. unable to discover any IPv6 addresses via the DNS.
7.4. Homogeneity May Be Encouraged 7.4. Homogeneity May Be Encouraged
skipping to change at page 19, line 38 skipping to change at page 21, line 12
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
or use any technically compatible software to connect to the or use any technically compatible software to connect to the
Internet. Not only does this trend towards greater heterogeneity Internet. Not only does this trend towards greater heterogeneity
reduce the control which is exerted in the middle of the network, reduce the control which is exerted in the middle of the network,
described in positive terms in [Tussle in Cyberspace], [Rethinking described in positive terms in [Tussle in Cyberspace], [Rethinking
the design of the Internet], and [RFC3724], but it can also help to the Internet], and [RFC3724], but it can also help to enable greater
enable greater and more rapid innovation at the edges. and more rapid innovation at the edges.
An unfortunate implication of the adoption of DNS whitelisting may be An unfortunate implication of the adoption of DNS whitelisting may be
the encouragement of a reversal of this trend, which would be a move the encouragement of a reversal of this trend, which would be a move
back towards greater levels of homogeneity. In this case, a domain back towards greater levels of homogeneity. In this case, a domain
owner which has implemented DNS whitelisting may prefer greater owner which has implemented DNS whitelisting may prefer greater
levels of control be exerted over end user hosts (which broadly levels of control be exerted over end user hosts (which broadly
includes all types of end user software and hardware) in order to includes all types of end user software and hardware) in order to
attempt to enforce technical standards relating to establishing attempt to enforce technical standards relating to establishing
certain IPv6 capabilities or the enforcing the elimination of or certain IPv6 capabilities or the enforcing the elimination of or
restriction of certain end user hosts. While the domain operator is restriction of certain end user hosts. While the domain operator is
attempting to protect, maintain, and/or optimize the end user attempting to protect, maintain, and/or optimize the end user
experience for their domain, the collective result of many domains experience for their domain, the collective result of many domains
implementing DNS whitelisting, or even a few major domains (meaning implementing DNS whitelisting, or even a few major domains (meaning
domains which are a major destination of Internet traffic) domains which are a major destination of Internet traffic)
implementing DNS whitelisting, may be to encourage a return to more implementing DNS whitelisting, may be to encourage a return to more
homogenous and/or controlled end user hosts. Unfortunately, this homogenous and/or controlled end user hosts. This could have
could have unintended side effects on and counter-productive unintended side effects on and counter-productive implications for
implications for future innovation at the edges of the network. future innovation at the edges of the network.
7.5. Technology Policy Implications 7.5. Technology Policy Implications
A key technology policy implication concerns the policies relating to A key technology policy implication concerns the policies relating to
the process of reviewing an application for DNS whitelisting, and the the process of reviewing an application for DNS whitelisting, and the
decision-making process regarding whitelisting for a domain. decision-making process regarding whitelisting for a domain.
Important questions may include whether these policies have been Important questions may include whether these policies have been
fully and transparently disclosed, are non-discriminatory, and are fully and transparently disclosed, are non-discriminatory, and are
not anti-competitive. A related implication is whether and what the not anti-competitive. A related implication is whether and what the
process for appeals is, when a domain decides not to add a DNS process for appeals is, when a domain decides not to add a DNS
skipping to change at page 22, line 14 skipping to change at page 23, line 32
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 is 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 be a temporary measure that has been adopted a particular domain may be a temporary measure that has been adopted
to ease the transition of the domain to IPv6 over some short-term to ease the transition of the domain to IPv6 over some short-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 generally can 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
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. Of course, Section 11 own, or where they can seek help in doing so. Section 11 may also be
may 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. 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 general
for this approach. preference for this approach.
8.3.2. Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN
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
domain to gain IPv6 experience and increase IPv6 use on a relatively
controlled basis, and to inform any plans for DNS whitelisting with
experience.
9. Is DNS Whitelisting a Recommended Practice? 9. Is DNS Whitelisting a Recommended Practice?
Opinions in the Internet community concerning whether or not DNS Opinions in the Internet community concerning whether or not DNS
whitelisting is a recommended practice are understandably quite whitelisting is a recommended practice are understandably quite
varied. However, there is clear consensus that DNS whitelisting is varied. However, there is clear consensus that DNS whitelisting is
at best a useful temporary measure which a domain may choose to at best a useful temporary measure which a domain may choose to
pursue as they prepare for the transition to IPv6. In particular, pursue as they prepare for the transition to IPv6. In particular,
some major domains view DNS whitelisting as one of the few practical some major domains view DNS whitelisting as one of the few practical
and low risk approaches enabling them to prepare for the transition and low risk approaches enabling them to prepare for the transition
to IPv6. Thus, DNS whitelisting is not a recommended practice over to IPv6. Thus, DNS whitelisting is not a recommended practice over
the long-term. In addition, DNS whitelisting should be avoided the long-term. In addition, DNS whitelisting should be avoided
wherever possible in the short-term and its use is generally wherever possible in the short-term and its use is generally
discouraged. Nevertheless, major domains may find DNS whitelisting a discouraged. Nevertheless, major domains may find DNS whitelisting a
beneficial temporary tactic in their transition to IPv6. Such beneficial temporary tactic in their transition to IPv6. Such
temporary use during the transition to IPv6 is broadly accepted temporary use during the transition to IPv6 is broadly accepted
within the community, so long as it does not become a long-term within the community, so long as it does not become a long-term
practice. practice.
Finally, World IPv6 Day, which is sponsored by the Internet Society World IPv6 Day, sponsored by the Internet Society [World IPv6 Day],
[World IPv6 Day] and is scheduled to occur on June 8, 2011, will be is scheduled to occur on June 8, 2011. This will be an opportunity
an opportunity for domains to add AAAA resource records to the DNS for domains to add AAAA resource records to the DNS without using DNS
without using DNS whitelisting. As a result, this is likely an whitelisting. As a result, this is likely an excellent opportunity
excellent opportunity for domains to evaluate the utility or for domains to evaluate the utility or necessity of DNS whitelisting,
necessity of DNS whitelisting, even in the short-term. A major even in the short-term. A major German news website, Heise Online,
German news website, Heise Online, also ran a similar IPv6 experiment also ran a similar IPv6 experiment whereby they added AAAA resource
whereby they added AAAA resource records and observed and measured records and observed and measured any errors [Heise Online
any errors [Heise Online Experiment], which is important reading for Experiment], which is important reading for any domain contemplating
any domain contemplating either the use of DNS whitelisting or simply either the use of DNS whitelisting or simply adding IPv6 addressing
adding IPv6 addressing to their site. to their site.
10. Security Considerations 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. resource 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
skipping to change at page 24, line 22 skipping to change at page 26, line 5
10.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. Even though the authoritative server will not always
However, any implementer of DNS whitelisting should be quite careful return a AAAA resource record when one exists, respective A resource
if they implement both DNSSEC signing of their domain and also DNS records and AAAA resource records can and should both be signed.
whitelisting of that same domain. Specifically, those domains should Therefore there are no DNSSEC implications per se. However, any
ensure that records are being appropriately and reliably signed, implementer of DNS whitelisting should be careful if they implement
which may well prove operationally and/or technically challenging. both DNSSEC signing of their domain and also DNS whitelisting of that
same domain. Specifically, those domains should ensure that resource
records are being appropriately and reliably signed, which may
present incremental operational and/or technical challenges.
However, as noted in Section 3, end user networks may also choose to
implement tools at their disposal in order to address IPv6-related
impairments. One of those possible tools could involve unspecified
changes to the configuration of their recursive resolvers. If it is
a Security-Aware Resolver, modifying or suppressing AAAA resource
records for a DNSSEC-signed domain will be problematic and could
break the chain of trust established with DNSSEC.
10.2. Authoritative DNS Response Consistency Considerations 10.2. Authoritative DNS Response Consistency Considerations
In addition to the considerations raised in Section 10.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
skipping to change at page 25, line 5 skipping to change at page 26, line 46
11. Privacy Considerations 11. Privacy Considerations
As noted in Section 8.3.1, there may be methods to detect IPv6- 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 related impairments for a particular end user. For example, this may
be possible when an end user visits the website of a particular be possible when an end user visits the website of a particular
domain. In that example, there are likely no privacy considerations domain. In that example, there are likely no privacy considerations
in communicating to that end user that the domain has detected a in communicating to that end user that the domain has detected a
particular impairment. However, if that domain decided to share particular impairment. However, if that domain decided to share
information concerning that particular end user with their network information concerning that particular end user with their network
operator or another party, then the visited domain may wish to in operator or another party, then the visited domain may wish to in
some manner advise the end use of this or otherwise seek their some manner advise the end user of this or otherwise seek their
consent to such information sharing. This may be achieved in a wide consent to such information sharing. This may be achieved in a wide
variety of ways, from presenting a message asking the user for variety of ways, from presenting a message asking the user for
consent (which will of course help them solve a technical problem of 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 which they are likely unaware) to adding this to a domain's website
terms of use / service. Such information sharing and communication terms of use / service. Such information sharing and communication
of such sharing to end users may well vary by geographic area and/or of such sharing to end users may well vary by geographic area and/or
legal jurisdiction. Thus, a domain should consider any potential legal jurisdiction. Thus, a domain should consider any potential
privacy issues these sorts of scenarios. privacy issues these sorts of scenarios.
12. IANA Considerations 12. IANA Considerations
skipping to change at page 26, line 4 skipping to change at page 27, line 43
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 - Karsten Fleischhauer
- Wesley George
- Jerry Huang - Jerry Huang
- Joel Jaeggli
- Erik Kline - Erik Kline
- Suresh Krishnan
- Victor Kuarsingh - Victor Kuarsingh
- Danny McPherson - Danny McPherson
- Martin Millnert - Martin Millnert
- Thomas Narten
- Hannes Tschofenig - Hannes Tschofenig
- Tina Tsou
15. References 15. References
15.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.
skipping to change at page 27, line 13 skipping to change at page 29, line 17
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.
15.2. Informative References [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[Comparing DNS Resolvers in the Wild] 15.2. Informative References
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] [Evaluating IPv6 Adoption]
Colitti, L., Gunderson, S., Kline, E., and T. Refice, Colitti, L., Gunderson, S., Kline, E., and T. Refice,
"Evaluating IPv6 adoption in the Internet", Passive and "Evaluating IPv6 adoption in the Internet", Passive and
Active Management (PAM) Conference 2010, April 2010, Active Management (PAM) Conference 2010, April 2010,
<http://www.google.com/research/pubs/archive/36240.pdf>. <http://www.google.com/research/pubs/archive/36240.pdf>.
[Heise Online Experiment] [Heise Online Experiment]
Heise.de, "World IPv6 Day - June 8, 2011", Heise.de 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.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]
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 DNS Whitelisting - Could It Hinder IPv6 Adoption?] [IPv6 Brokenness]
Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., Anderson, T., "Measuring and Combating IPv6 Brokenness",
Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
Could It Hinder IPv6 Adoption?", ISOC Internet Society <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
IPv6 Deployment Workshop, April 2010, <http://
www.comcast6.net/
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] [Laws of Motion]
Anderson, T., "Measuring and Combating IPv6 Brokenness", Newton, I., "Mathematical Principles of Natural Philosophy
Reseaux IP Europeens (RIPE) 61st Meeting, November 2011, (Philosophiae Naturalis Principia Mathematica)",
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>. Principia Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica), July 1687,
<http://en.wikipedia.org/wiki/Newton's_laws_of_motion>.
[Network World Article on DNS Whitelisting] [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>.
[Network World Article on IETF 77 DNSOP WG Presentation] [NW-Article-DNSOP]
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, I., "Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica)",
Principia Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica), July 1687,
<http://en.wikipedia.org/wiki/Newton's_laws_of_motion>.
[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.
[Rethinking the design of the Internet] [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>.
[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 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>.
[Whitelisting Concerns]
Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y.,
Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting -
Could It Hinder IPv6 Adoption?", ISOC Internet Society
IPv6 Deployment Workshop, April 2010, <http://
www.comcast6.net/
IPv6_DNS_Whitelisting_Concerns_20100416.pdf>.
[World IPv6 Day] [World IPv6 Day]
The Internet Society, "World IPv6 Day - June 8, 2011", The Internet Society, "World IPv6 Day - June 8, 2011",
Internet Society Website http://www.isoc.org, Internet Society Website http://www.isoc.org,
January 2011, <http://isoc.org/wp/worldipv6day/>. 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]
-03: Several changes suggested by Joel Jaeggli at the end of WGLC.
This involved swapping the order of Section 6.1 and 6.2, among other
changes to make the document more readable, understandable, and
tonally balanced. As suggested by Karsten Fleischhauer, added a
reference to RFC 4213 in Section 7.1, as well as other suggestions to
that section. As suggested by Tina Tsou, made some changes to the
DNSSEC section regarding signing. As suggested by Suresh Krishnan,
made several changes to improve various sections of the document,
such as adding an alternative concerning the use of ipv6.domain,
improving the system logic section, and shortening the reference
titles. As suggested by Thomas Narten, added some text regarding the
imperfection of making judgements as to end user host impairments
based upon the recursive resolver's IP and/or network. Finally, made
sure that variations in the use of 'records' and 'resource records'
was updated to 'resource records' for uniformity and to avoid
confusion.
-02: Called for and closed out feedback on dnsop and v6ops mailing -02: Called for and closed out feedback on dnsop and v6ops mailing
lists. Closed out open feedback items from IETF 79. Cleared I-D lists. Closed out open feedback items from IETF 79. Cleared I-D
nits issues, added a section on whether or not this is recommended, nits issues, added a section on whether or not this is recommended,
made language less company-specific based on feedback from Martin made language less company-specific based on feedback from Martin
Millnert, Wes George, and Victor Kuarsingh. Also mentioned World Millnert, Wes George, and Victor Kuarsingh. Also mentioned World
IPv6 Day per Wes George's suggestion. Added references to the ISOC 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 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 Huang, as well as an additional implication in 7.3.7. Made any
speculation on IPv4 impairment noted explicitly as such, per feedback speculation on IPv4 impairment noted explicitly as such, per feedback
from Martin Millnert. Added a reference to DNS SRV in the load from Martin Millnert. Added a reference to DNS SRV in the load
skipping to change at page 30, line 4 skipping to change at page 32, line 25
-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
(normative/informative) 1. Ensure references are in the proper section (normative/
informative)
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. 90 change blocks. 
536 lines changed or deleted 635 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/