draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-04.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational February 22, 2011 Intended status: Informational May 29, 2011
Expires: August 26, 2011 Expires: November 30, 2011
IPv6 AAAA DNS Whitelisting Implications IPv6 AAAA DNS Whitelisting Implications
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-04
Abstract Abstract
The objective of this document is to describe what the whitelisting The objective of this document is to describe the practice of
of DNS AAAA resource records is, hereafter referred to as DNS whitelisting of DNS recursive resolvers in order to limit AAAA
whitelisting, as well as the implications of this emerging practice resource records responses, which contain IPv6 addresses, hereafter
and what alternatives may exist. The audience for this document is referred to as DNS Whitelisting, as well as the implications of this
the Internet community generally, including the IETF and IPv6 emerging practice and what alternatives or variations may exist.
implementers. This practice is a type of IPv6 transition mechanism used by domains,
as a method for incrementally transitioning inbound traffic to a
domain from IPv4 to IPv6 transport. The audience for this document
is the Internet community generally, particularly IPv6 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 26, 2011. This Internet-Draft will expire on November 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 6 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5
2.1. Description of the Operation of DNS Whitelisting . . . . . 7 2.1. Description of the Operation of DNS Whitelisting . . . . . 6
2.2. Comparison with Blacklisting . . . . . . . . . . . . . . . 8
3. What Problems Are Implementers Trying To Solve? . . . . . . . 8 3. What Problems Are Implementers Trying To Solve? . . . . . . . 8
4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 9 3.1. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 9
5. Similarities to Other DNS Operations . . . . . . . . . . . . . 12 3.2. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 10
5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 12 3.3. Free Versus Subscription Services . . . . . . . . . . . . 10
5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 12 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 10
6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 13 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 13
6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 13
6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 14 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 13
7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15 6. Possible Deployment Scenarios . . . . . . . . . . . . . . . . 14
7.1. Architectural Implications . . . . . . . . . . . . . . . . 15 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 14
7.2. Public IPv6 Address Reachability Implications . . . . . . 16 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 15
7.3. Operational Implications . . . . . . . . . . . . . . . . . 17 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 16
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 17 7.1. Architectural Implications . . . . . . . . . . . . . . . . 16
7.3.2. Authoritative DNS Server Operational Implications . . 17 7.2. Public IPv6 Address Reachability Implications . . . . . . 17
7.3. Operational Implications . . . . . . . . . . . . . . . . . 18
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 18
7.3.2. Authoritative DNS Server Operational Implications . . 18
7.3.3. DNS Recursive Resolver Server Operational 7.3.3. DNS Recursive Resolver Server Operational
Implications . . . . . . . . . . . . . . . . . . . . . 18 Implications . . . . . . . . . . . . . . . . . . . . . 19
7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 19 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 20
7.3.5. Implications of Operational Momentum . . . . . . . . . 19 7.3.5. Implications of Operational Momentum . . . . . . . . . 21
7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 20 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 21
7.3.7. Additional Implications If Deployed On An Ad Hoc 7.3.7. Additional Implications If Deployed On An Ad Hoc
Basis . . . . . . . . . . . . . . . . . . . . . . . . 20 Basis . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 20 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 22
7.5. Technology Policy Implications . . . . . . . . . . . . . . 21 7.5. Technology Policy Implications . . . . . . . . . . . . . . 22
7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 24
8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.7. Implications with Poor IPv4 and Good IPv6 Transport . . . 24
8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 23 7.8. Implications for Users of Third-Party DNS Recursive
8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 23 Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 23 8. General Implementation Variations . . . . . . . . . . . . . . 26
8.3.1. Solving Current End User IPv6 Impairments . . . . . . 24 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 26
8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 24 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 26
9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 24 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.3.1. Solve Current End User IPv6 Impairments . . . . . . . 26
10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 25 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 27
10.2. Authoritative DNS Response Consistency Considerations . . 26 8.3.3. Implement DNS Blacklisting . . . . . . . . . . . . . . 27
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 29
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 10.2. Authoritative DNS Response Consistency Considerations . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30
15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . . 29 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32
15.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
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, hereafter recursive resolvers in order to limit AAAA resource record (RR)
referred to as DNS whitelisting. The document explores the responses, which contain IPv6 addresses, hereafter referred to as DNS
implications of this emerging practice are and what alternatives may Whitelisting. The document explores the implications of this
exist. emerging practice are and what alternatives may exist. When
implemented, DNS Whitelisting in practice means that a domain's
The practice of DNS whitelisting appears to have first been used by
major web content sites (sometimes described herein as "highly-
trafficked domains" or "major domains"). These web site operators,
or domain operators, observed that when they added AAAA resource
records to their authoritative DNS servers in order to support IPv6
access to their content that a small fraction of end users had slow
or otherwise impaired access to a given web site with both AAAA and A
resource records. The fraction of users with such impaired access
has been estimated to be roughly 0.078% of total Internet users
[IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
Brokenness]. Thus, in an example Internet Service Provider (ISP)
network of 10 million users, approximately 7,800 of those users may
experience such impaired access.
As a result of this impairment affecting end users of a given domain,
a few major domains have either implemented DNS whitelisting or are
considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
When 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.
is important to note that these major domains are motivated by a This practice is a type of IPv6 transition mechanism used by domains,
desire to maintain a high-quality user experience for all of their as a method for incrementally transitioning inbound traffic to a
users. By engaging in DNS whitelisting, they are attempting to domain from IPv4 to IPv6 transport. The practice appears to have
shield users with impaired access from the symptoms of those first been used by major web content sites (sometimes described
impairments. herein as "high-traffic domains"), which have specific concerns
relating to maintain a high-quality user experience for all of their
users during their transition to IPv6.
Critics of the practice of DNS whitelisting have articulated several Critics of the practice of DNS Whitelisting have articulated several
concerns. Among these are that: concerns. Among these are that:
o DNS whitelisting is a very different behavior from the current o DNS Whitelisting is a very different behavior from the current
practice concerning the publishing of IPv4 address resource practice concerning the publishing of IPv4 address resource
records, records,
o that it may create a two-tiered Internet, o that it may create a two-tiered Internet,
o that policies concerning whitelisting and de-whitelisting are o that policies and decision-making for whitelisting and de-
opaque, whitelisting are opaque or likely to cause conflict,
o that DNS whitelisting reduces interest in the deployment of IPv6, o that DNS Whitelisting reduces interest in the deployment of IPv6,
o that new operational and management burdens are created, o that new operational and management burdens are created,
o and that the costs and negative implications of DNS whitelisting o that the practice does not scale,
outweigh the perceived benefits, compared to fixing underlying
impairments. o that it violates a basic premise of cross-Internet
interoperability by requiring prior arrangements,
o and that the costs and negative implications of DNS Whitelisting
outweigh the perceived benefits.
This document explores the reasons and motivations for DNS This document explores the reasons and motivations for DNS
whitelisting. It also explores the outlined concerns regarding this Whitelisting Section 3. It also explores the concerns regarding this
practice. Readers will hopefully better understand what DNS practice, and whether and when the practice is recommended Section 9.
whitelisting is, why some parties are implementing it, and what Readers will hopefully better understand what DNS Whitelisting is,
criticisms of the practice exist. why some parties are implementing it, and what criticisms of the
practice exist.
2. How DNS Whitelisting Works 2. How DNS Whitelisting Works
DNS whitelisting is implemented in authoritative DNS servers. These At a high level, using a whitelist means no traffic is permitted to
servers implement IP address-based restrictions on AAAA query the destination host unless the originating host's IP address is
responses. So far, DNS whitelisting has been primarily implemented contained in the whitelist. In contrast, using a blacklist means
by web server operators deploying IPv6-enabled services. For a given that all traffic is permitted to the destination host unless the
operator of a website, such as www.example.com, the operator originating host's IP address is contained in the blacklist.
essentially applies an access control list (ACL) on the authoritative
DNS servers for the domain example.com. The ACL is populated with
the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive
resolvers on the Internet, which have been authorized to receive AAAA
resource record responses. These DNS recursive resolvers are
operated by third parties, such as ISPs, universities, governments,
businesses, and individual end users. If a DNS recursive resolver IS
NOT matched in the ACL, then AAAA resource records will NOT be sent
in response to a query for a hostname in the example.com domain.
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
hostname in the example.com domain. While these are not network-
layer access controls they are nonetheless access controls that are a
factor for end users and other parties like network operators,
especially as networks and hosts transition from one network address
family to another (IPv4 to IPv6).
In practice, DNS whitelisting generally means that a very small DNS Whitelisting is implemented in authoritative DNS servers, not in
DNS recursive resolvers. These authoritative servers implement IP
address-based restrictions on AAAA query responses. So far, DNS
Whitelisting has been primarily implemented by web server operators
deploying IPv6-enabled services, though this practice would affect
any protocols and services within a domain. For a given operator of
a website, such as www.example.com, the operator essentially applies
an access control list (ACL) on the authoritative DNS servers for the
domain example.com. The ACL is populated with the IPv4 and/or IPv6
addresses or prefix ranges of DNS recursive resolvers on the
Internet, which have been authorized to receive AAAA resource record
responses. These DNS recursive resolvers are operated by third
parties, such as ISPs, universities, governments, businesses, and
individual end users. If a DNS recursive resolver IS NOT matched in
the ACL, then AAAA resource records will NOT be sent in response to a
query for a hostname in the example.com domain. 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 hostname in the
example.com domain. While these are not network-layer access
controls they are nonetheless access controls that are a factor for
end users and other parties like network operators, especially as
networks and hosts transition from one network address family to
another (IPv4 to IPv6).
In practice, DNS Whitelisting generally means that a very small
fraction of the DNS recursive resolvers on the Internet (those in the fraction of the DNS recursive resolvers on the Internet (those in the
whitelist ACL) will receive AAAA responses. The large majority of whitelist ACL) will receive AAAA responses. The large majority of
DNS resolvers on the Internet will therefore receive only A resource DNS resolvers on the Internet will therefore receive only A resource
records containing IPv4 addresses. Thus, quite simply, the records containing IPv4 addresses. Thus, quite simply, the
authoritative server hands out different answers depending upon who authoritative server hands out different answers depending upon who
is asking; with IPv4 and IPv6 resource records for some on the is asking; with IPv4 and IPv6 resource records for all those the
authorized whitelist, and only IPv4 resource records for everyone authorized whitelist, and only IPv4 resource records for everyone
else. See Section 2.1 and Figure 1 for a description of how this else. See Section 2.1 and Figure 1 for a description of how this
works. works.
Finally, DNS whitelisting can be deployed in two primary ways: DNS Whitelisting also works independently of whether an authoritative
DNS server, DNS recursive resolver, or end user host uses IPv4
transport, IPv6, or both. So, for example, whitelisting may prevent
sending AAAA responses even in those cases where the DNS recursive
resolver has queried the authoritative server over IPv6 transport, or
where the end user host's original query to the DNS recursive
resolver was over IPv6 transport. One important reason for this is
that even though the DNS recursive resolver may have no IPv6-related
impairments, this is not a reliable predictor of whether the same is
true of the end user host. This also means that a DNS whitelist can
contain both IPv4 and IPv6 addresses.
Finally, DNS Whitelisting can be deployed in two primary ways:
universally on a global basis, or on an ad hoc basis. Deployment on universally on a global basis, or on an ad hoc basis. Deployment on
a universal deployment basis means that DNS whitelisting is a universal deployment basis means that DNS Whitelisting is
implemented on all authoritative DNS servers, across the entire implemented on all authoritative DNS servers, across the entire
Internet. In contrast, deployment on an ad hoc basis means that only Internet. In contrast, deployment on an ad hoc basis means that only
some authoritative DNS servers, and perhaps even only a few, some authoritative DNS servers, and perhaps even only a few,
implement DNS whitelisting. These two potential deployment models implement DNS Whitelisting. These two potential deployment models
are described in Section 6. are described in Section 6.
2.1. Description of the Operation of DNS Whitelisting 2.1. Description of the Operation of DNS Whitelisting
The system logic of DNS whitelisting is as follows: The system logic of DNS Whitelisting is as follows:
1. The authoritative DNS server for example.com receives DNS queries 1. The authoritative DNS server for example.com receives DNS queries
for the A (IPv4) and AAAA (IPv6) address resource records for the for the A (IPv4) and/or AAAA (IPv6) address resource records for
FQDN www.example.com, for which AAAA (IPv6) resource records the FQDN www.example.com, for which AAAA (IPv6) resource records
exist. exist.
2. The authoritative DNS server examines the IP address of the DNS 2. The authoritative DNS server checks the IP address (IPv4, IPv6,
recursive resolver sending the AAAA (IPv6) query. or both) of the DNS recursive resolver sending the AAAA (IPv6)
query against the access control list (ACL) that is the DNS
3. The authoritative DNS server checks this IP address against the whitelist.
access control list (ACL) that is the DNS whitelist.
4. If the DNS recursive resolver's IP address IS matched in the ACL, 3. If the DNS recursive resolver's IP address IS matched in the ACL,
then the response to that specific DNS recursive resolver can then the response to that specific DNS recursive resolver can
contain AAAA (IPv6) address resource records. contain AAAA (IPv6) address resource records.
5. If the DNS recursive resolver's IP address IS NOT matched in the 4. If the DNS recursive resolver's IP address IS NOT matched in the
ACL, then the response to that specific DNS recursive resolver ACL, then the response to that specific DNS recursive resolver
cannot contain AAAA (IPv6) address resource records. In this cannot contain AAAA (IPv6) address resource records. In this
case, the server should return a response with the response code case, the server should return a response with the response code
(RCODE) being set to 0 (No Error) with an empty answer section (RCODE) being set to 0 (No Error) with an empty answer section
for the AAAA record query. 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:
skipping to change at page 8, line 23 skipping to change at page 7, line 23
|| || A | **IS NOT** | A | IN A exists | || || A | **IS NOT** | A | IN A exists |
+-++--++-+ ---------> | ON | ---------> | IN AAAA exists | +-++--++-+ ---------> | ON | ---------> | IN AAAA exists |
+--------+ A | example.com | A | | +--------+ A | example.com | A | |
Host <--------- | WHITELIST | <--------- | | Host <--------- | WHITELIST | <--------- | |
Computer A Record +-------------+ A Record +-----------------+ Computer A Record +-------------+ A Record +-----------------+
Response DNS Recursive Response example.com Response DNS Recursive Response example.com
(only IPv4) Resolver (only IPv4) Authoritative (only IPv4) Resolver (only IPv4) Authoritative
#1 Server #1 Server
--------------------------------------------------------------------- ---------------------------------------------------------------------
A query is sent from a DNS recursive resolver that IS on the DNS A query is sent from a DNS recursive resolver that IS 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** | A | IN A exists | || || A | **IS** | A | IN A exists |
+-++--++-+ ---------> | ON | ---------> | IN AAAA exists | +-++--++-+ ---------> | ON | ---------> | IN AAAA exists |
+--------+ 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 1: DNS Whitelisting - Functional Diagram Figure 1: DNS Whitelisting - Functional Diagram
3. What Problems Are Implementers Trying To Solve? ---------------------------------------------------------------------
Resolver 1 - IS NOT ON the DNS Whitelist
Resolver 2 - IS ON the DNS Whitelist
---------------------------------------------------------------------
Host 1 Resolver 1 Authoritative Server
Query A and AAAA -----> Query A and AAAA ----> Receive A and
for www.example.com for www.example.com AAAA queries
As noted in Section 1, domains which implement DNS whitelisting are A (IPv4) <------------- A (IPv4) <--------------- NOT on Whitelist
attempting to protect a few users of their domain, who have impaired response response return only A (IPv4)
IPv6 access, from having a negative experience (poor performance). ---------------------------------------------------------------------
While it is outside the scope of this document to explore the various Host 2 Resolver 2 Authoritative Server
reasons why a particular user's system (host) may have impaired IPv6 Query A and AAAA -----> Query A and AAAA ----> Receive A and
access, for the users who experience this impairment it is a very for www.example.com for www.example.com AAAA queries
real performance impact. It would affect access to all or most dual
stack services to which the user attempts to connect. This negative
end user experience can range from someone slower than usual (as
compared to native IPv4-based access), to extremely slow, to no
access to the domain whatsoever.
While one can debate whether DNS whitelisting is the optimal solution A (IPv4) <------------- A (IPv4) and <------------ IS on Whitelist
to the end user experience problem, it is quite clear that DNS AAAA (IPv6) AAAA (IPv6) return A (IPv4)
whitelisting implementers are interested in maximizing the responses responses and AAAA (IPv6)
performance of their services for end users as a primary motivation ---------------------------------------------------------------------
for implementation.
At least one highly-trafficked domain has noted that they have Figure 2: DNS Whitelisting - Request/Response Diagram
received requests to not send DNS responses with AAAA resource
records to particular resolvers. In this case, the operators of
those recursive resolvers have expressed a concern that their IPv6
network infrastructure is not yet ready to handle the large traffic
volume which may be associated with the hosts in their network
connecting to the websites of these domains. This concern is clearly
a temporary consideration relating to the deployment of IPv6 network
infrastructure on the part of networks with end user hosts, rather
than a long-term concern. These end user networks may also have
other tools at their disposal in order to address this concern,
including applying rules to network equipment such as routers and
firewalls (this will necessarily vary by the type of network, as well
as the technologies used and the design of a given network), 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 explained that 2.2. Comparison with Blacklisting
DNS whitelisting is a necessary, though temporary, risk reduction
tactic intended to ease their transition to IPv6 and minimize any With DNS Whitelisting, DNS recursive resolvers can receive AAAA
perceived risk in such a transition. As a result, they perceive this resource records only if they are on the whitelist. In contrast,
as a tactic to enable them to incrementally enable IPv6 connectivity blacklisting would be the opposite whereby all DNS recursive
to their domains during the early phases of their transition to IPv6. resolvers can receive AAAA resource records unless they are on the
blacklist. So a whitelist contains a list of hosts allowed
something, whereby a blacklist contains a list of hosts disallowed
something. While the distinction between the concepts of
whitelisting and blacklisting are important, this is noted
specifically since some implementers of DNS Whitelisting may choose
to transition to DNS Blacklisting before returning to a state without
address-family-related ACLs in their authoritative DNS servers. It
is unclear when and if it would be appropriate to change from
whitelisting to blacklisting. Nor is it clear how implementers will
judge the network conditions to have changed sufficiently to justify
disabling AAAA resource record access controls.
3. What Problems Are Implementers Trying To Solve?
Implementers are attempting to protect users of their domain from
having a negative experience (poor performance) when they receive DNS
response containing AAAA resource records or when attempting to use
IPv6 transport. Therefore there are two concerns which relate to
this practice; one of which relates to IPv6-related impairment and
the other which relates to the maturity or stability of IPv6
transport for high-traffic domains.
Finally, some domains, have run IPv6 experiments whereby they added Finally, some domains, have run IPv6 experiments whereby they added
AAAA resource records and observed and measured errors [Heise Online AAAA resource records and observed and measured errors [Heise Online
Experiment], which should be important reading for any domain Experiment], which should be important reading for any domain
contemplating either the use of DNS whitelisting or simply adding contemplating either the use of DNS Whitelisting or simply adding
IPv6 addressing to their site. IPv6 addressing to their site.
3.1. IPv6-Related Impairment
Some implementers have observed that when they added AAAA resource
records to their authoritative DNS servers in order to support IPv6
access to their content that a small fraction of end users had slow
or otherwise impaired access to a given web site with both AAAA and A
resource records. The fraction of users with such impaired access
has been estimated to be as high as 0.078% of total Internet users
[IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
Brokenness]. In these situations, DNS recursive resolvers are added
to the DNS Whitelist only when the measured level of impairment of
the hosts using that resolver declines to some level acceptable by
the implementer.
As a result of this impairment affecting end users of a given domain,
a few high-traffic domains have either implemented DNS Whitelisting
or are considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist
Operations]. While it is outside the scope of this document to
explore the various reasons why a particular user's system (host) may
have impaired IPv6 access, for the users who experience this
impairment it has a very real performance impact. It would affect
access to all or most dual stack services to which the user attempts
to connect. This negative end user experience can range from
somewhat slower than usual (as compared to native IPv4-based access),
to extremely slow, to no access to the domain whatsoever. In
essence, whether the end user even has an IPv6 address or not (they
probably only have an IPv4 address), merely by receiving a AAAA
record response the user either cannot access a FQDN or it is so slow
that the user gives up and assumes the destination is unreachable.
In addition, at least one high-traffic domain has noted that they
have received requests to not send DNS responses with AAAA resource
records to particular resolvers. In this case, DNS recursive
resolvers operators have expressed a short-term concern that their
IPv6 network infrastructure is not yet ready to handle the large
traffic volume that may be associated with the hosts in their network
connecting to the websites of these domains. These end user networks
may also have other tools at their disposal in order to address this
concern, including applying rules to network equipment such as
routers and firewalls (this will necessarily vary by the type of
network, as well as the technologies used and the design of a given
network), as well as configuration of their DNS 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).
3.2. Volume-Based Concerns
Some implementers are trying to gradually add IPv6 traffic to their
domain since they may find that network operations, tools, processes
and procedures are less mature for IPv6 as compared to IPv4. While
for domains with small to moderate traffic volumes, whether by the
count of end users or count of bytes transferred, high-traffic
domains receive such a level of usage that it is prudent to undertake
any network changes gradually or in a manner which minimizes any risk
of disruption. For example, one can imagine for one of the top ten
sites globally that the idea of suddenly turning on a significant
amount of IPv6 traffic might be quite daunting. DNS Whitelisting may
therefore offer such high-traffic domains one potential method for
incrementally enabling IPv6. Thus, some implementers with high-
traffic domains plan to use DNS Whitelisting is a necessary, though
temporary, risk reduction tactic intended to ease their transition to
IPv6 and minimize any perceived risk in such a transition.
3.3. Free Versus Subscription Services
It is also worth noting the differences between domains containing
primarily subscription-based services compared to those containing
primarily free services. In the case of free services, such as
search engines, end users have no direct billing relationship with
the domain and can switch sites simply by changing the address they
enter into their browser (ignoring other value added services which
may tie a user?s preference to a given domain or otherwise create
switching costs). As a result, such domains explain that they
believe they are more sensitive to the quality of the services within
their domain since if the user has issues when they turn on IPv6,
then that user could switch to another domain that is not using IPv6.
4. Concerns Regarding DNS Whitelisting 4. Concerns Regarding DNS Whitelisting
There are a number of potential implications relating to DNS The implications relating to DNS Whitelisting are further enumerated
whitelisting, which have been raised as concerns by some parts of the here and in Section 7.
Internet community. Many of those potential implications are further
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 the practice of DNS whitelisting for IPv6 address resource that the practice of DNS Whitelisting for IPv6 address resource
records represents a departure from the generally accepted practices records represents a departure from the generally accepted practices
regarding IPv4 address resource records in the DNS on the Internet regarding IPv4 address resource records in the DNS on the Internet
[Whitelisting Concerns]. These parties explain their belief that for [Whitelisting Concerns]. These parties explain their belief that
A resource records, containing IPv4 addresses, once an authoritative once an authoritative server operator adds an A record (IPv4) to the
server operator adds the A record to the DNS, then any DNS recursive DNS, then any DNS recursive resolver on the Internet can receive that
resolver on the Internet can receive that A record in response to a A record in response to a query. By extension, this means that any
query. By extension, this means that any of the hosts connected to of the hosts connected to any of these DNS recursive resolvers can
any of these DNS recursive resolvers can receive the IPv4 address receive the IPv4 address resource records for a given FQDN. This
resource records for a given FQDN. This enables new server hosts enables new server hosts which are connected to the Internet, and for
which are connected to the Internet, and for which a fully qualified which a fully qualified domain name (FQDN) such as www.example.com
domain name (FQDN) such as www.example.com has been added to the DNS has been 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, the concern is that DNS whitelisting may fundamentally In contrast, the concern is that DNS Whitelisting may fundamentally
change this model. In the altered DNS whitelisting end-to-end model, change this model. In the altered DNS Whitelisting end-to-end model,
one end (where the end user is located) cannot readily connect to the one end (where the end user is located) cannot readily connect to the
other end (where the content is located), without parts of the middle other end (where the content is located), without parts of the middle
(recursive resolvers) used by one end (the client, or end user hosts) (DNS recursive resolvers) used by one end (the client, or end user
being known to an intermediary (authoritative nameservers) and hosts) being known to an intermediary (authoritative nameservers) and
approved for access to the resource at the end. As new networks approved for access to the resource at the end. As new networks
connect to the Internet over time, those networks need to contact any connect to the Internet over time, those networks need to contact any
and all domains which have implemented DNS whitelisting in order to and all domains which have implemented DNS Whitelisting in order to
apply to be added to their DNS whitelist, in the hopes of making the apply to be added to their DNS whitelist, in the hopes of making the
content and applications residing on named server hosts in those content and applications residing on named server hosts in those
domains accessible by the end user hosts on that new network. domains accessible by the end user hosts on that new network.
Furthermore, this same need to contact all domains implementing DNS Furthermore, this same need to contact all domains implementing DNS
whitelisting also applies to all pre-existing (but not whitelisted) Whitelisting also applies to all pre-existing (but not whitelisted)
networks connected to the Internet. networks connected to the Internet.
In the current IPv4 Internet when a new server host is added to the In the current IPv4 Internet when a new server host is added to the
Internet it is generally widely available to all end user hosts and Internet it is generally widely available to all end user hosts; when
networks, when DNS whitelisting of IPv6 resource records is used, DNS Whitelisting of IPv6 resource records is used, these new server
these new server hosts are not accessible to any end user hosts or hosts are not accessible via a FQDN by any end user hosts until such
networks until such time as the operator of the authoritative DNS time as the operator of the authoritative DNS servers for those new
servers for those new server hosts expressly authorizes access to server hosts expressly authorizes access to those new server hosts by
those new server hosts by adding DNS recursive resolvers around the adding DNS recursive resolvers around the Internet to the ACL. This
Internet to the ACL. This has the potential to be a significant has the potential to be a significant change in reachability of
change in reachability of content and applications by end users and content and applications by end users and networks as these end user
networks as these end user hosts and networks transition to IPv6, hosts and networks transition to IPv6, resulting in more (but
resulting in more (but different) breakage. A concern expressed is different) breakage. A concern expressed is that if much of the
that if much of the content that end users are most interested in is content that end users are most interested in is not accessible as a
not accessible as a result, then end users and/or networks may resist result, then end users and/or networks may resist adoption of IPv6 or
adoption of IPv6 or actively seek alternatives to it, such as using actively seek alternatives to it, such as using multi-layer network
multi-layer network address translation (NAT) techniques like NAT444 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 could disrupt the continued increase in Internet
Internet adoption by end users if they cannot simply access new adoption by end users if they cannot simply access new content and
content and applications but must instead contact the operator of applications but must instead contact the operator of their DNS
their DNS recursive resolver, such as their ISP or another third recursive resolver, such as their ISP or another third party, to have
party, to have their DNS recursive resolver authorized for access to their DNS recursive resolver authorized for access to the content or
the content or applications that interests them. Meanwhile, these applications that interests them. Meanwhile, these parties say, over
parties say, over 99.9% of the other end users that are also using 99.9% of the other end users that are also using that same network or
that same network or DNS recursive resolver are unable to access the DNS recursive resolver are unable to access the IPv6-based content,
IPv6-based content, despite their experience being a positive one. despite their experience being a positive one.
While in Section 1 the level of IPv6-related impairment has been While in Section 1 the level of IPv6-related impairment has been
estimated to be as high as 0.078% of Internet users, which is a estimated to be as high as 0.078% of Internet users, which is a
primary motivation cited for the practice of DNS whitelisting, it is primary motivation cited for the practice of DNS Whitelisting, it is
not clear if the level of IPv4-related impairment is more or less not clear if the level of IPv4-related impairment is more or less
that this percentage (which in any case is likely to have declined that this percentage (which in any case is likely to have declined
since its original citation). Indeed, as at least one document since its original citation). Indeed, as at least one document
reviewer has pointed out, it may simply be that websites are only reviewer has pointed out, it may simply be that websites are only
measuring IPv6 impairments and not IPv4 impairments, whether because measuring IPv6 impairments and not IPv4 impairments, whether because
IPv6 is new or whether those websites are simply unable to or are IPv6 is new or whether those websites are simply unable to or are
otherwise not in a position to be able to measure IPv4 impairment otherwise not in a position to be able to measure IPv4 impairment
(since this could result in no Internet access whatsoever). As a (since this could result in no Internet access whatsoever). As a
result, it is worth considering that IPv4-related impairment could result, it is worth considering that IPv4-related impairment could
exceed that of IPv6-related impairment and that such IPv4-related exceed that of IPv6-related impairment and that such IPv4-related
impairment may have simply been accepted as "background noise" on the impairment may have simply been accepted as "background noise" on the
Internet for a variety of reasons. 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 An additional concern is that the IP address of a DNS recursive
is not a precise indicator of the IPv6 preparedness, or lack of IPv6- resolver is not a precise indicator of the IPv6 preparedness, or lack
related impairments, of end user hosts which query (use) a particular of IPv6-related impairments, of end user hosts which query (use) a
recursive resolver. While the recursive resolver may be an imperfect particular DNS recursive resolver. While the DNS recursive resolver
proxy for judging IPv6 preparedness, it is at least one of the best may be an imperfect proxy for judging IPv6 preparedness, it is at
available methods at the current time. 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 to other Some aspects of DNS Whitelisting may be considered similar to other
common DNS operational techniques which are explored below. common DNS operational techniques which are explored below.
5.1. Similarities to Split DNS 5.1. Similarities to Split DNS
DNS whitelisting has some similarities to so-called split DNS, DNS Whitelisting has some similarities to so-called split DNS,
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, networks. This is basically the way that DNS Whitelisting works,
whereby hosts on different networks, which use different DNS whereby hosts on different networks which use different DNS recursive
recursive resolvers, receive different answers if one DNS recursive resolvers, receive different answers if one DNS recursive resolver is
resolver is on the whitelist and the other is not. on the whitelist and the other is not.
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 of course many ways that DNS load balancing can be There are of course many ways that DNS load balancing can be
performed. In one example, multiple IP address resource records (A performed. In one example, multiple IP address resource records (A
and/or AAAA) can be added to the DNS for a given FQDN. This approach and/or AAAA) can be added to the DNS for a given FQDN. This approach
is referred to as DNS round robin [RFC1794]. DNS round robin may is referred to as DNS round robin [RFC1794]. DNS round robin may
also be employed where SRV resource records are used [RFC2782]. also be employed where SRV resource records are used [RFC2782].
In another example, one or more of the IP address resource records in In another example, one or more of the IP address resource records in
the DNS will direct traffic to a load balancer. That load balancer, the DNS will direct traffic to a load balancer. That load balancer,
in turn, may be application-aware, and pass the traffic on to one or in turn, may be application-aware, and pass the traffic on to one or
more hosts connected to the load balancer which have different IP more hosts connected to the load balancer which have different IP
addresses. In cases where private IPv4 addresses are used [RFC1918], addresses. In cases where private IPv4 addresses are used [RFC1918],
as well as when public IP addresses are used, those end hosts may not as well as when public IP addresses are used, those end hosts may not
be directly reachable without passing through the load balancer first be directly reachable without passing through the load balancer first
. As such, while the IP address resource records have been added to . As such, while the IP address resource records have been added to
the DNS, the end hosts are not necessarily directly reachable, which the DNS, the end hosts are not necessarily directly reachable, which
is in a small way similar to one aspect of DNS whitelisting. is in a small way similar to one aspect of DNS Whitelisting.
Additionally, a geographically-aware authoritative DNS server may be Additionally, a geographically-aware authoritative DNS server may be
used, as is common with Content Delivery Networks (CDNs) or Global used, as is common with Content Delivery Networks (CDNs) or Global
Load Balancing (GLB, also referred to as Global Server Load Load Balancing (GLB, also referred to as Global Server Load
Balancing, or GSLB), whereby the IP address resource records returned Balancing, or GSLB), whereby the IP address resource records returned
to a resolver in response to a query will vary based on the estimated to a resolver in response to a query will vary based on the estimated
geographic location of the resolver [Resolvers in the Wild]. CDNs geographic location of the resolver [Resolvers in the Wild]. CDNs
perform this function in order to attempt to direct hosts to connect perform this function in order to attempt to direct hosts to connect
to the nearest content cache. As a result, one can see some to the nearest content cache. As a result, one can see some
similarities with DNS whitelisting insofar as different IP address similarities with DNS Whitelisting insofar as different IP address
resource records are selectively returned to resolvers based on the resource records are selectively returned to resolvers based on the
IP address of each resolver (or other imputed factors related to that IP address of each resolver (or other imputed factors related to that
IP address). However, what is different is that in this case the IP address). However, what is different is that in this case the
resolvers are not deliberately blocked from receiving DNS responses resolvers are not deliberately blocked from receiving DNS responses
containing an entire class of addresses; this load balancing function containing an entire class of addresses; this load balancing function
strives to perform a content location-improvement function and not an strives to perform a content location-improvement function and not an
access control function. access control function.
6. Likely Deployment Scenarios 6. Possible Deployment Scenarios
In considering how DNS whitelisting may emerge more widely, there are In considering how DNS Whitelisting may emerge more widely, there are
two likely deployment scenarios, which are explored below. two main deployment scenarios, which are explored below.
In either of these deployment scenarios, it is possible that In either of these deployment scenarios, it is possible that
reputable third parties could create and maintain DNS whitelists, in reputable third parties could create and maintain DNS whitelists, in
much the same way that blacklists are used for reducing email spam. much the same way that blacklists are distributed and used for
In the email context, a mail operator subscribes to one or more of reducing email spam. In the email context, a mail operator
these lists and as such the operational processes for additions and subscribes to one or more of these lists and as such the operational
deletions to the list are managed by a third party. A similar model processes for additions and deletions to the list are managed by a
could emerge for DNS whitelisting, whether deployment occurs third party. A similar model could emerge for DNS Whitelisting,
universally or on an ad hoc basis. whether deployment occurs universally or on an ad hoc basis.
6.1. Deploying DNS Whitelisting On An Ad Hoc Basis An additional factor in either scenario is that a DNS recursive
resolver operator will have to determine whether or not DNS
Whitelisting has been 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 are using DNS Whitelisting. This will be
challenging at scale.
The seemingly most likely deployment scenario is where some 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis
authoritative DNS server operators implement 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 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 The most likely deployment scenario is where some authoritative DNS
Section 6.2, deployment on an ad hoc basis is likely to be server operators implement DNS Whitelisting but many or most others
significantly more challenging from an operational, monitoring, and do not do so. What can make this scenario challenging from the
troubleshooting standpoint. In this scenario, a DNS recursive standpoint of a DNS recursive resolver operator is determining which
resolver operator will have no way to systematically determine domains implement DNS Whitelisting, particularly since a domain may
whether DNS whitelisting is or is not implemented for a domain, since not do so as they initially transition to IPv6, and may instead do so
the absence of AAAA resource records may simply be indicative that later. Thus, a DNS recursive resolver operator may initially believe
the domain has not yet added IPv6 addressing for the domain, rather that they can receive AAAA responses as a domain adopts IPv6, but
than that they have done so but have restricted query access via DNS then notice via end user reports that they no longer receive AAAA
whitelisting. As a result, discovering which domains implement DNS responses due to that domain adopting DNS Whitelisting. Of course, a
whitelisting, in order to differentiate them from those that do not, domain's IPv6 transition may be effectively invisible to DNS
is likely to be challenging. recursive resolver operators due to the effect of DNS Whitelisting.
One benefit of DNS whitelisting being deployed on an ad hoc basis is 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 that only the domains that are interested in doing so would have to
upgrade their authoritative DNS servers in order to implement the upgrade their authoritative DNS servers in order to implement the
ACLs necessary to perform DNS whitelisting. ACLs necessary to perform DNS Whitelisting. Some domains have
proposed or are implementing this and are manually updating their
whitelist, while other such as CDNs have discussed the possibility of
an automated method for doing so.
In this potential deployment scenario, it is also possible that a In this potential deployment scenario, it is also possible that a
given domain will implement DNS whitelisting temporarily. A domain, given domain will implement DNS Whitelisting temporarily. A domain,
particularly a highly-trafficked domain, may choose to do so in order particularly a high-traffic domain, may choose to do so in order to
to ease their transition to IPv6 through a selective deployment and ease their transition to IPv6 through a selective deployment and
minimize any perceived risk in such a transition. minimize any perceived risk in such a transition. In addition, it is
possible that one or more DNS Whitelist clearinghouses may emerge,
providing implementers with a way to subscribe to a whitelist in a
manner similar to that used on email servers for blacklists.
6.2. Deploying DNS Whitelisting Universally 6.2. Deploying DNS Whitelisting Universally
The least likely deployment scenario is one where DNS whitelisting is The less likely deployment scenario is one where DNS Whitelisting is
implemented on all authoritative DNS servers, across the entire implemented on all authoritative DNS servers, across the entire
Internet. While this scenario seems less likely than ad hoc Internet. While this scenario seems less likely than ad hoc
deployment due to some parties not sharing the concerns that have so deployment due to some parties not sharing the concerns that have so
far motivated the use of DNS whitelisting, it is nonetheless far motivated the use of DNS Whitelisting, it is nonetheless
conceivable that it could be one of the ways in which DNS conceivable that it could be one of the ways in which DNS
whitelisting is deployed. Whitelisting is deployed, though such a universal deployment could be
considered harmful and problematic.
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. It is likely that new Internet Draft enable this functionality. It is likely that new IETF Request for
documents would need to be developed which describe how to properly Comment (RFC) documents would need to be developed which describe how
configure, deploy, and maintain DNS whitelisting. As a result, it is to properly configure, deploy, and maintain DNS Whitelisting. As a
unlikely that DNS whitelisting would, at least in the next several result, it is unlikely that DNS Whitelisting would, at least in the
years, become universally deployed. Furthermore, these DNS next several years, become universally deployed. Furthermore, these
whitelists are likely to vary on a domain-by-domain basis, depending DNS whitelists are likely to vary on a domain-by-domain basis,
upon a variety of factors. Such factors may include the motivation depending upon a variety of factors. Such factors may include the
of each domain owner, the location of the DNS recursive resolvers in motivation of each domain owner, the location of the DNS recursive
relation to the source content, as well as various other parameters resolvers in relation to the source content, as well as various other
that may be transitory in nature, or unique to a specific end user parameters that may be transitory in nature, or unique to a specific
host type. It is probably unlikely that a single clearinghouse for end user host type. It is probably unlikely that a single
managing whitelisting is possible; it will more likely be unique to clearinghouse for managing whitelisting is possible; it will more
the source content owners and/or domains which implement DNS likely be unique to the source content owners and/or domains which
whitelists. implement DNS whitelists (so multiple clearinghouses are certainly
possible).
While this scenario may be unlikely, it may carry some benefits.
First, parties performing troubleshooting would not have to determine
whether or not DNS whitelisting was being used, as it always would be
in use. In addition, if universally deployed, it is possible that
the criteria for being added to or removed from a DNS whitelist could
be standardized across the entire Internet. Nevertheless, even if
uniform DNS whitelisting policies were not standardized, is also
possible that a central registry of these policies could be developed
and deployed in order to make it easier to discover them, a key part
of achieving transparency regarding DNS whitelisting.
7. Implications of DNS Whitelisting 7. Implications of DNS Whitelisting
There are many potential implications of DNS whitelisting. The key There are many implications of DNS Whitelisting. The key
potential implications are detailed below. implications are detailed below.
7.1. Architectural Implications 7.1. Architectural Implications
DNS whitelisting could be perceived as modifying the end-to-end model DNS Whitelisting modifies the end-to-end model and the general notion
and/or the general notion of the architecture that prevails on the of spontaneous interoperability of the architecture that prevails on
Internet today. This is because this approach moves additional the Internet today. This is because this approach moves additional
access control information and policies into the middle of the DNS access control information and policies into the middle of the DNS
resolution path of the IPv6-addressed Internet, which generally did resolution path of the IPv6-addressed Internet, which generally did
not exist before on the IPv4-addressed Internet. This poses some not exist before on the IPv4-addressed Internet, and it requires some
risks noted in [RFC3724]. In explaining the history of the end-to- type of prior registration with authoritative servers. This poses
end principle [RFC1958] states that one of the goals is to minimize some risks noted in [RFC3724]. In explaining the history of the end-
the state, policies, and other functions needed in the middle of the to-end principle [RFC1958] states that one of the goals is to
network in order to enable end-to-end communications on the Internet. minimize the state, policies, and other functions needed in the
In this case, the middle network should be understood to mean middle of the network in order to enable end-to-end communications on
anything other than the end hosts involved in communicating with one the Internet. In this case, the middle network should be understood
another. Some state, policies, and other functions have always been to mean anything other than the end hosts involved in communicating
necessary to enable such end-to-end communication, but the goal of with one another. Some state, policies, and other functions have
the approach has been to minimize this to the greatest extent always been necessary to enable such end-to-end communication, but
possible. the goal of the approach has been to minimize this to the greatest
extent possible.
It is also possible that DNS whitelisting could place at risk some of It is also possible that DNS Whitelisting could place at risk some of
the observed benefits of the end-to-end principle, as listed in the observed benefits of the end-to-end principle, as listed in
Section 4.1 of [RFC3724], such as protection of innovation. 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, so there may also be parallel concerns with the DNS middleboxes, so there may also be parallel concerns with the DNS
whitelisting approach, especially concerning modified DNS servers Whitelisting approach, especially concerning modified DNS servers
noted in Section 2.16 of [RFC3234], as well as more general concerns noted in Section 2.16 of [RFC3234], as well as more general concerns
noted in Section 1.2 of [RFC3234] about the introduction of new noted in Section 1.2 of [RFC3234] about the introduction of new
failure modes. In particular, there may be concerns that failure modes. In particular, there may be concerns that
configuration is no longer limited to two ends of a session, and that configuration is no longer limited to two ends of a session, and that
diagnosis of failures and misconfigurations becomes more complex. diagnosis of failures and misconfigurations becomes more complex.
Two additional sources worth considering as far as implications for Two additional sources worth considering as far as implications for
the end-to-end model are concerned are [Tussle in Cyberspace] and the end-to-end model are concerned are [Tussle in Cyberspace] and
[Rethinking the Internet]. In [Tussle in Cyberspace], the authors [Rethinking the Internet]. In [Tussle in Cyberspace], the authors
note concerns regarding the introduction of new control points, as note concerns regarding the introduction of new control points, as
well as "kludges" to the DNS, as risks to the goal of network well as "kludges" to the DNS, as risks to the goal of network
transparency in the end-to-end model. Some parties concerned with transparency in the end-to-end model. Some parties concerned with
the emerging use of DNS whitelisting have shared similar concerns, the emerging use of DNS Whitelisting have shared similar concerns,
which may make [Tussle in Cyberspace] an interesting and relevant which may make [Tussle in Cyberspace] an interesting and relevant
document. In addition, [Rethinking the Internet] reviews similar document. In addition, [Rethinking the Internet] reviews similar
issues that may be of interest to readers of this document. issues that may be of interest to readers of this document.
Also, it is possible that DNS whitelisting could affect some of the Also, it is somewhat possible that DNS Whitelisting could affect some
architectural assumptions which underlie parts of Section 2 of of the architectural assumptions which underlie parts of Section 2 of
[RFC4213] which outlines the dual stack approach to the IPv6 [RFC4213] which outlines the dual stack approach to the IPv6
transition. DNS whitelisting could modify the behavior of the DNS, transition. DNS Whitelisting could modify the behavior of the DNS,
as described in Section 2.2 of [RFC4213] and could require different as described in Section 2.2 of [RFC4213] and could require different
sets of DNS servers to be used for hosts that are (using terms from sets of DNS servers to be used for hosts that are (using terms from
that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes. that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
As such, broad use of DNS whitelisting may necessitate the review As such, broad use of DNS Whitelisting may necessitate the review
and/or revision of standards documents which describe dual-stack and and/or revision (though revision is unlikely to be neccessary) of
IPv6 operating modes, dual-stack architecture generally, and IPv6 standards documents which describe dual-stack and IPv6 operating
transition methods, including but not limited to [RFC4213]. 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
It is a critical to understand that the concept of reachability
described here depends upon a knowledge of an address in the DNS.
Thus, in order to establish reachability to an end point, a host is
dependent upon looking up an IP address in the DNS when a FQDN is
used. When DNS Whitelisting is used, it is quite likely that an
IPv6-enabled end user host could connect to an example server host
using the IPv6 address, even though the FQDN associated with that
server host is restricted via a DNS whitelist. Since most Internet
applications and hosts such as web servers depend upon the DNS, and
as end users connect to FQDNs such as www.example.com and do not
remember or wish to type in an IP address, the notion of reachability
described here should be understood to include knowledge of how to
associate a name with a network address.
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 when a new server with a public IPv4 addressed Internet today is that when a new server with a public IPv4
address is added to the DNS, that it is then globally accessible by address is added to the DNS, that a FQDN is immediately useful for
IPv4-addressed hosts. This is a generalization and in Section 5 reaching it. This is a generalization and in Section 5 there are
there are examples of common cases where this may not necessarily be examples of common cases where this may not necessarily be the case.
the case. For the purposes of this argument, that concept of For the purposes of this argument, that concept of accessibility is
accessibility can be considered "pervasive reachability". It has so described as "pervasive reachability". It has so far been assumed
far been assumed that the same expectations of pervasive reachability that the same expectations of pervasive reachability would exist in
would exist in the IPv6-addressed Internet. However, if DNS the IPv6-addressed Internet. However, if DNS Whitelisting is
whitelisting is deployed, this will not be the case since only end deployed, this will not be the case since only end user hosts using
user hosts using DNS recursive resolvers which are included in the DNS recursive resolvers that are included in 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. The expectation of any end
of any end user host being able to connect to any server (essentially 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.
Establishing DNS whitelisting as an accepted practice in the early
phases of mass IPv6 deployment could well establish it as an integral
part of how IPv6 DNS resource records are deployed globally. As a
result, it is then possible that DNS whitelisting could live on for
decades on the Internet as a key foundational element of domain name
management that we will all live with for a long time.
It is a critical to understand that the concept of reachability Establishing DNS Whitelisting as an accepted practice in the early
described above depends upon a knowledge or awareness of an address phases of mass IPv6 deployment could establish it as an integral part
in the DNS. Thus, in order to establish reachability to an end of how IPv6 DNS resource records are deployed globally. This risks
point, a host is dependent upon looking up an IP address in the DNS DNS Whitelisting living on for decades as a key foundational element
when a FQDN is used. When DNS whitelisting is used, it is quite of domain name management on the Internet.
likely the case that an IPv6-enabled end user host could ping or
connect to an example server host, even though the FQDN associated
with that server host is restricted via a DNS whitelist. Since most
Internet applications and hosts such as web servers depend upon the
DNS, and as end users connect to FQDNs such as www.example.com and do
not remember or wish to type in an IP address, the notion of
reachability described here should be understood to include knowledge
how to associate a name with a network address.
7.3. Operational Implications 7.3. Operational Implications
This section explores some of the operational implications which may This section explores some of the operational implications which may
occur as a result of, are related to, or become 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
It is possible for a DNS recursive resolver added to a whitelist to It is possible for a DNS recursive resolver added to a whitelist to
then be removed from the whitelist, also known as de-whitelisting. then be removed from the whitelist, also known as de-whitelisting.
Since de-whitelisting can occur, through a decision by the Since de-whitelisting can occur, through a decision by the
authoritative server operator, the domain owner, or even due to a authoritative server operator, 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. One
particular risk is that, especially when a high-traffic domain de-
whitelists a large network, this may cause a sudden and dramatic
change to networks since a large volume of traffic will then switch
from IPv6 to IPv4. This can have dramatic effects on those being de-
whitelisted as well as on other interconnected networks. In some
cases, IPv4 network links may rapidly become congested and users of
affected networks will experience network access impairments well
beyond the domain which performed the de-whitelisting. Thus, once
"operational stability" has been achieved between a whitelisting and
whitelisted party, then de-whitelisting should generally not occur
except in cases of operational emergencies, and there should be
opportunities for joint troubleshooting or at least for advance
warning to affected parties.
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 DNS Whitelisting serves as a critical infrastructure service; to be
server-wide basis affecting all domains, on a domain-by-domain basis, useful it needs careful and extensive administration, monitoring and
as well as on a combination of the two. As a result, operational operation. Each new and essential mechanism creates substantial
practices and software capabilities may need to be developed in order follow-on support costs.
to support such functionality. In addition, processes may need to be
put in place to protect against inadvertently adding or removing IP Operators of authoritative servers (which are frequently
addresses, as well as systems and/or processes to respond to such authoritative for multiple domain names) will need to maintain an ACL
incidents if and when they occur. For example, a system may be on a server-wide basis affecting all domains, or on a domain-by-
needed to record DNS whitelisting requests, report on their status domain basis. As a result, operational practices and software
along a workflow, add IP addresses when whitelisting has been capabilities may need to be developed in order to support such
approved, remove IP addresses when they have been de-whitelisted, log functionality. In addition, processes may need to be put in place to
the personnel involved and timing of changes, schedule changes to protect against inadvertently adding or removing IP addresses, as
occur in the future, and to roll back any inadvertent changes. well as systems and/or processes to respond to such incidents if and
when they occur. For example, a system may be needed to record DNS
Whitelisting requests, report on their status along a workflow, add
IP addresses when whitelisting has been approved, remove IP addresses
when they have been de-whitelisted, log the personnel involved and
timing of changes, schedule changes to occur in the future, and to
roll back any inadvertent changes.
Operators may also need implement new forms of monitoring in order to Operators may also need implement new forms of monitoring in order to
apply change control, as noted briefly in Section 7.3.4. apply change control, as noted briefly in Section 7.3.4.
It is important for operators of authoritative servers to recognize
that the operational burden is likely to increase dramatically over
time, as more and more networks transition to IPv6. As a result, the
volume of new DNS Whitelisting requests will increase over time,
potentially at an extraordinary growth rate, which will place an
increasing burden on personnel, systems, and/or processes. Operators
should also consider that any supporting systems, including the
authoritative servers themselves, may experience reduced performance
when a DNS whitelist becomes quite large.
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, For operators of DNS recursive resolvers, coping with DNS
enterprises, universities, governments, individual end users, and Whitelisting becomes expensive in time and personnel as the practice
many other parties, are likely to need to implement new forms of scales up. These operators include ISPs, enterprises, universities,
governments; a wide range of organization types with a range of DNS-
related expertise. They will 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 will need to add people, processes, and systems in
order to manage large numbers of DNS whitelisting applications as order to manage large numbers of DNS Whitelisting applications.
part of their own IPv6 transition, for all domains that the end users Since there is no common method for determining whether or not a
of such servers are interested in now or in which they may be domain is engaged in DNS Whitelisting, operators will have to apply
interested in the future. As anticipation of interesting domains is to be whitelisted for a domain based upon one or more end user
likely infeasible, it is more likely that operators may either choose requests, which means systems, processes, and personnel for handling
to only apply to be whitelisted for a domain based upon one or more and responding to those requests will also be necessary.
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 operators apply for DNS whitelisting for all domains, that may When operators apply for DNS Whitelisting for all domains, that may
mean doing so for all registered domains. Thus, some system would mean doing so for all registered domains. Thus, some system 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.
These operators (of recursive resolvers) will need to develop These operators (of DNS recursive resolvers) will need to develop
processes and systems to track the status of all DNS whitelisting processes and systems to track the status of all DNS Whitelisting
applications, respond to requests for additional information related applications, respond to requests for additional information related
to these applications, determine when and if applications have been to these applications, determine when and if applications have been
denied, manage appeals, and track any de-whitelisting actions. denied, manage appeals, and track any de-whitelisting actions.
Given the large number of domains in existence, the ease with which a Given the large number of domains in existence, the ease with which a
new domain can be added, and the continued strong growth in the new domain can be added, and the continued strong growth in the
numbers of new domains, readers should not underestimate the numbers of new domains, readers should not underestimate the
potential significance in personnel and expense that this could potential significance in personnel and expense that this could
represent for such operators. In addition, it is likely that systems represent for such operators. In addition, it is likely that systems
and personnel may also be needed to handle new end user requests for and personnel may also be needed to handle new end user requests for
domains for which to apply for DNS whitelisting, and/or inquiries domains for which to apply for DNS Whitelisting, and/or inquiries
into the status of a whitelisting application, reports of de- into the status of a whitelisting application, reports of de-
whitelisting incidents, general inquiries related to DNS whitelisting incidents, general inquiries related to DNS
whitelisting, and requests for DNS whitelisting-related Whitelisting, and requests for DNS Whitelisting-related
troubleshooting by these end users. 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 DNS
whitelisting status in the future. This DNS recursive resolver Whitelisting in the future. This DNS recursive resolver operator
operator could configure a monitor to check for a AAAA response in could configure a monitor to check for a AAAA response in the
the whitelisted domain, as a check to validate continued status on whitelisted domain, as a check to validate continued status on the
the DNS whitelist. The monitor could then trigger an alert if at DNS whitelist. The monitor could then trigger an alert if at some
some point the AAAA responses were no longer received, so that point the AAAA responses were no longer received, so that operations
operations personnel could begin troubleshooting, as outlined in 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. Authoritative nameserver error such as the entire ACL being removed. Authoritative DNS server
operators may also wish to monitor their workflow process for operators may also wish to monitor their workflow process for
reviewing and acting upon DNS whitelisting applications and appeals, reviewing and acting upon DNS Whitelisting applications and appeals,
potentially measuring and reporting on service level commitments potentially measuring and reporting on service level commitments
regarding the time an application or appeal can remain at each step regarding the time an application or appeal can remain at each step
of the process, regardless of whether or not such information is of the process, regardless of whether or not such information is
shared with parties other than that authoritative DNS server shared with parties other than that authoritative DNS server
operator. operator.
7.3.5. Implications of Operational Momentum 7.3.5. Implications of Operational Momentum
It seems plausible that once DNS whitelisting is implemented it will It seems plausible that once DNS Whitelisting is implemented it will
be very difficult to deprecate such technical and operational be very difficult to deprecate such technical and operational
practices. This assumption is based in an understanding of human practices. This assumption is based on an understanding of human
nature, not to mention physics. For example, as Sir Issac Newton nature, not to mention physics. For example, as Sir Isaac Newton
noted, "Every object in a state of uniform motion tends to remain in noted, "Every object in a state of uniform motion tends to remain in
that state of motion unless an external force is applied to it" [Laws that state of motion unless an external force is applied to it" [Laws
of Motion]. Thus, once DNS whitelisting is implemented it is quite of Motion]. Thus, once DNS Whitelisting is implemented it is quite
likely that it would take considerable effort to deprecate the likely that it would take considerable effort to deprecate the
practice and remove it everywhere on the Internet - it will otherwise practice and remove it everywhere on the Internet; it may otherwise
simply remain in place in perpetuity. To better illustrate this simply remain in place in perpetuity. To illustrate this point, one
point, one could consider one example (of many) that there are many could consider for example that there are many email servers
email servers continuing to attempt to query or otherwise check anti- continuing to attempt to query anti-spam DNS blocklists which have
spam DNS blocklists which have long ago ceased to exist. long ago ceased to exist.
7.3.6. Troubleshooting Implications 7.3.6. Troubleshooting Implications
The implications of DNS whitelisted present many challenges, which The implications of DNS whitelisted present many challenges, as
have been detailed in Section 7. These challenges may negatively detailed throughout 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 via a FQDN
significantly more complex. significantly more complex and time-consuming.
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, As more domains choose to implement DNS Whitelisting, and more
could include scalability problems relating to operational processes, networks become IPv6-capable and request to be whitelisted, scaling
monitoring, and ACL updates. In particular, it seems likely that as up operational processes, monitoring, and ACL updates will become
the number of domains that are using DNS whitelisting increases, as more difficult. The increased rate of change and increased size of
well as the number of IPv6-capable networks requesting to be whitelists will increase the likelihood of configuration and other
whitelisted, that there is an increased likelihood of configuration operational errors.
and other operational errors, especially with respect to the ACLs
themselves.
It is unclear when and if it would be appropriate to change from 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. It is clear that trying to coordinate
be coordinated across the Internet, which may be proposed or this across the Internet is likely be be impossible, so such a change
implemented on an ad hoc basis when a majority of networks (or to blacklisting would happen on a domain-by-domain basis (if at all).
allocated IPv6 address blocks) have been whitelisted. Finally, some
parties implementing DNS whitelisting consider this to be a temporary
measure. As such, it is not clear how these parties will judge the
network conditions to have changed sufficiently to justify disabling
DNS whitelisting and/or what the process and timing will be in order
to discontinue this practice.
One further potential implication is that an end user with only an Finally, some implementers consider DNS Whitelisting to be a
IPv4 address, using a DNS resolver which has not been whitelisted by temporary measure. As such, it is not clear how these implementers
any domains, would not be able to get any AAAA resource records. In will judge the network conditions to have changed sufficiently to
such a case, this could give that end user the incorrect impression justify disabling DNS Whitelisting (or Blacklisting, or other AAAA
that there is no IPv6-based content on the Internet since they are resource record access controls) and/or what the process and timing
unable to discover any IPv6 addresses via the DNS. will be in order to discontinue this practice.
One further implication is that an end user with only an IPv4
address, using a DNS resolver which has not been whitelisted by any
domains, would not be able to get any AAAA resource records. In such
a case, this could give that end user the incorrect impression that
there is no IPv6-based content on the Internet since they are unable
to discover any IPv6 addresses via the DNS.
7.4. Homogeneity May Be Encouraged 7.4. Homogeneity May Be Encouraged
A broad trend which has existed on the Internet appears to be a move A broad trend on the Internet is a move toward more heterogeneity.
towards increasing levels of heterogeneity. One manifestation of One manifestation of this is in an increasing number, variety, and
this is in an increasing number, variety, and customization of end customization of end user hosts, including home networks, operating
user hosts, including home network, operating systems, client systems, client software, home network devices, and personal
software, home network devices, and personal computing devices. This computing devices. This trend appears to have had a positive effect
trend appears to have had a positive effect on the development and on the development and growth of the Internet. This trend has
growth of the Internet. A key facet of this that has evolved is the enabled end user to connect any technically compliant device or use
ability of the end user to connect any technically compliant device any technically compatible software to connect to the Internet. Not
or use any technically compatible software to connect to the only does this trend towards greater heterogeneity reduce the control
Internet. Not only does this trend towards greater heterogeneity which is exerted in the middle of the network, described positively
reduce the control which is exerted in the middle of the network, in [Tussle in Cyberspace], [Rethinking the Internet], and [RFC3724],
described in positive terms in [Tussle in Cyberspace], [Rethinking but it also appears to help to enable greater and more rapid
the Internet], and [RFC3724], but it can also help to enable greater innovation at the edges.
and more rapid innovation at the edges.
An unfortunate implication of the adoption of DNS whitelisting may be Some forms of so-called "network neutrality" principles around the
the encouragement of a reversal of this trend, which would be a move world include the notion that any IP-capable device should be able to
back towards greater levels of homogeneity. In this case, a domain connect to a network, which seems to encourage heterogeneity. These
owner which has implemented DNS whitelisting may prefer greater principles are often explicitly encouraged by application providers
levels of control be exerted over end user hosts (which broadly given the reasons noted above, though some of these same providers
includes all types of end user software and hardware) in order to may also be implementing DNS Whitelisting. This is ironic, as one
attempt to enforce technical standards relating to establishing implication of the adoption of DNS Whitelisting is that in encourages
certain IPv6 capabilities or the enforcing the elimination of or a move back towards homogeneity. This is because some implementers
restriction of certain end user hosts. While the domain operator is have expressed a preference for greater levels of control by networks
attempting to protect, maintain, and/or optimize the end user over end user hosts in order to attempt to enforce technical
experience for their domain, the collective result of many domains requirements intended to reduce IPv6-related impairments. This
implementing DNS whitelisting, or even a few major domains (meaning return to an environment of more homogenous and/or controlled end
domains which are a major destination of Internet traffic) user hosts could have unintended side effects on and counter-
implementing DNS whitelisting, may be to encourage a return to more productive implications for future innovation at the edges of the
homogenous and/or controlled end user hosts. This could have network.
unintended side effects on and counter-productive implications for
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 against adding a DNS
recursive resolver to the whitelist. Key questions here may include recursive resolver to the whitelist. Key questions here may include
whether appeals are allowed, what the process is, what the expected whether appeals are allowed, what the process is, what the expected
turn around time is, and whether the appeal will be handled by an turn around time is, and whether the appeal will be handled by an
independent third party or other entity/group. independent third party or other entity/group.
A further implications arises when de-whitelisting occurs. Questions Further implications arise when de-whitelisting occurs. Questions
that may naturally be raised in such a case include whether the that may naturally be raised in such a case include whether the
criteria for de-whitelisting have been fully and transparently criteria for de-whitelisting have been fully and transparently
disclosed, are non-discriminatory, and are not anti-competitive. disclosed, are non-discriminatory, and are not anti-competitive.
Additionally, the question of whether or not there was a cure period Additionally, the question of whether or not there was a cure period
available prior to de-whitelisting, during which troubleshooting available prior to de-whitelisting, during which troubleshooting
activities, complaint response work, and corrective actions may be activities, complaint response work, and corrective actions may be
attempted, and whether this cure period was a reasonable amount of attempted, and whether this cure period was a reasonable amount of
time. time.
It is also conceivable that whitelisting and de-whitelisting It is also conceivable that whitelisting and de-whitelisting
decisions could be quite sensitive to concerned parties beyond the decisions could be quite sensitive to concerned parties beyond the
operator of the domain which has implemented DNS whitelisting and the operator of the domain which has implemented DNS Whitelisting and the
operator of the DNS recursive resolver, including end users, operator of the DNS recursive resolver, including end users,
application developers, content providers, advertisers, public policy application developers, content providers, advertisers, public policy
groups, governments, and other entities, which may also seek to groups, governments, and other entities, which may also seek to
become involved in or express opinions concerning whitelisting and/or become involved in or express opinions concerning whitelisting and/or
de-whitelisting decisions. Lastly, it is conceivable that any of de-whitelisting decisions. Lastly, it is conceivable that any of
these interested parties or other related stakeholders may seek these interested parties or other related stakeholders may seek
redress outside of the process a domain has establishing for DNS redress outside of the process a domain has establishing for DNS
whitelisting and de-whitelisting. Whitelisting and de-whitelisting.
A final concern is that decisions relating to whitelisting and de- A final concern is that decisions relating to whitelisting and de-
whitelisting may occur as an expression of other commercial, whitelisting may occur as an expression of other commercial,
governmental, and/or cultural conflicts, given the new control point governmental, and/or cultural conflicts, given the new control point
which has be established with DNS whitelisting. For example, in one which has been established with DNS Whitelisting. For example, in
imagined scenario, a domain could withhold adding a network to their one imagined scenario, a domain could withhold adding a network to
DNS whitelisting unless that network agreed to some sort of financial their DNS Whitelisting unless that network agreed to some sort of
payment, legal agreement, agreement to sever a relationship with a financial payment, legal agreement, agreement to sever a relationship
competitor of the domain, etc. In another example, a music-oriented with a competitor of the domain, etc. In another example, a music-
domain may be engaged in some sort of dispute with an academic oriented domain may be engaged in some sort of dispute with an
network concerning copyright infringement concerns within that academic network concerning copyright infringement concerns within
network, and may choose to de-whitelist that network as a negotiating that network, and may choose to de-whitelist that network as a
technique in some sort of commercial discussion. In a final example, negotiating technique in some sort of commercial discussion. In a
a major email domain may choose to de-whitelist a network due to that final example, a major email domain may choose to de-whitelist a
network sending some large volume of spam, which would have the network due to that network sending some large volume of spam. Thus,
effect of preventing other, end users on that network from using it seems possible that DNS Whitelisting and de-whitelisting could
other, non-email-related applications within that domain. Thus, it become a vehicle for adjudicating other disputes, and that this may
seems possible that DNS whitelisting and de-whitelisting could become well have intended and unintended consequences for end users which
a vehicle for adjudicating other disputes, and that this may well are affected by such decisions and are unlikely to be able to express
have intended and unintended consequences for end users which are a strong voice in such decisions.
affected by such decisions and are unlikely to be able to express a
strong voice in such decisions.
7.6. IPv6 Adoption Implications 7.6. IPv6 Adoption Implications
As noted in Section 4, the implications of DNS whitelisting may drive As noted in Section 4, the implications of DNS Whitelisting may drive
end users and/or networks to delay, postpone, or cancel adoption of end users and/or networks to delay, postpone, or cancel adoption of
IPv6, or to actively seek alternatives to it. Such alternatives may IPv6, or to actively seek alternatives to it. Such alternatives may
include the use of multi-layer network address translation (NAT) include the use of multi-layer network address translation (NAT)
techniques like NAT444 [I-D.shirasaki-nat444], which these parties techniques like NAT444 [I-D.shirasaki-nat444], which these parties
may decide to pursue on a long-term basis to avoid the perceived may decide to pursue on a long-term basis to avoid the perceived
costs and aggravations related to DNS whitelisting. This could of costs and aggravations related to DNS Whitelisting. This could of
course come at the very time that the Internet community is trying to course come at the very time that the Internet community is trying to
get these very same parties interested in IPv6 and motivated to begin get these very same parties interested in IPv6 and motivated to begin
the transition to IPv6. As a result, parties that are likely to be the transition to IPv6. As a result, parties that are likely to be
concerned over the negative implications of DNS whitelisting could concerned over the negative implications of DNS Whitelisting could
logically be concerned of the negative effects that this practice logically be concerned of the negative effects that this practice
could have on the adoption of IPv6 if it became widespread or was could have on the adoption of IPv6 if it became widespread or was
adopted by majors Internet domains or other major parties in the adopted by majors Internet domains or other major parties in the
Internet ecosystem. Internet ecosystem.
At the same time, as noted in Section 3, some highly-trafficked At the same time, as noted in Section 3, some high-traffic domains
domains may find the prospect of transitioning to IPv6 daunting may find the prospect of transitioning to IPv6 daunting without
without having some short-term ability to incrementally control the having some short-term ability to incrementally control the amount
amount and source of IPv6 traffic to their domains. and source of IPv6 traffic to their domains. Lacking such controls,
some domains may choose to substantially delay their transition to
IPv6.
8. Solutions 7.7. Implications with Poor IPv4 and Good IPv6 Transport
This section outlines several possible solutions when considering DNS It is possible that there could be situations where the differing
whitelisting and associated IPv6-related issues. quality of the IPv4 and IPv6 connectivity of an end user could cause
complications in accessing content which is in a whitelisted domain,
when the end user's DNS recursive resolver is not on that whitelist.
While today most end users' IPv4 connectivity is typically superior
to IPv6 connectivity (if such connectivity exists at all), there
could be implications when the reverse is true and and end user has
markedly superior IPv6 connectivity as compared to IPv4. This is
admittedly theoretical but could become a factor as the transition to
IPv6 continues and IPv4 address availability within networks becomes
strained.
For example, in one possible scenario, a user is issued IPv6
addresses by their ISP and has a home network and devices or
operating systems which fully support IPv6. As a result this
theoretical user has very good IPv6 connectivity. However, this end
user's ISP may have exhausted their available pool of unique IPv4
address, and so that ISP uses NAT in order to reuse IPv4 addresses.
So for IPv4 content, the end user must send their IPv4 traffic
through some additional network element (e.g. NAT, proxy, tunnel
server). Use of this additional network element may cause the end
user to experience sub-optimal IPv4 connectivity when certain
protocols or applications are used. This user then has good IPv6
connectivity but impaired IPv4 connectivity. Furthermore, this end
user's DNS recursive resolver is not whitelisted by the authoritative
server for a domain that the user is trying to access, meaning the
end user only gets A record responses for their impaired IPv4
transport rather than also AAAA record responses for their stable and
well-performing IPv6 transport. Thus, the user's poor IPv4
connectivity situation is potentially exacerbated by not having
access to a given domain's IPv6 content since they must use the
address family with relatively poor performance.
7.8. Implications for Users of Third-Party DNS Recursive Resolvers
In most cases it is assumed that end users will make use of DNS
recursive resolvers which are operated by their network provider,
whether that is an ISP, campus network, enterprise network, or some
other type of access network. However there are also cases where an
end user has changed their DNS server IP addresses in their device's
operating system to those of another party which operates DNS
recursive resolvers independently of end user access networks. In
these cases, an authoritative DNS server may receive a query from a
DNS recursive resolver in one network, though the end user sending
the original query to the DNS recursive resolver is in an entirely
different network. It may therefore be more challenging for a DNS
whitelist implementer to determine the level of IPv6-related
impairment when such third-party DNS recursive resolvers are used,
given the wide variety of end user access networks which may be used
and that this mix may change in unpredictable ways over time.
There may also be cases where end users are using a network where the
assigned DNS recursive resolver has not been whitelisted by a
particular authoritative DNS server, but where the end user knows
that a particular third-party DNS recursive resolver has been
whitelisted. While in most cases the end user will be able to switch
to use that third-party's servers, some access networks may prevent
switching to any DNS recursive resolvers other than those authorized
by or residing within a given access network. While the blocking of
third-party DNS recursive resolvers may be observed in many types of
networks such as ISPs, campus networks, and enterprise networks, this
may most often be observed in the specialized networks setup in
hotels, conference centers, coffee shops, and similar access
networks. In these cases, end users may be frustrated at their
inability to access content over IPv6 as a result of their access
network preventing them from using a whitelisted third-party DNS
recursive resolver. This may also result in complaints to both the
operator of the authoritative DNS server which has implemented
whitelisting as well as to the access network operator.
8. General Implementation Variations
This section outlines several possible approaches which may be
followed when considering DNS Whitelisting and associated IPv6-
related issues.
8.1. Implement DNS Whitelisting Universally 8.1. Implement DNS Whitelisting Universally
One obvious solution is to implement DNS whitelisted universally, and One obvious approach 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. Such an
solution seems unlikely at the current time. approach is also considered harmful and problematic, and almost
certain not to happen.
8.2. Implement DNS Whitelisting On An Ad Hoc Basis 8.2. Implement DNS Whitelisting On An Ad Hoc Basis
If DNS whitelisting is to be adopted, it is likely to be adopted on DNS Whitelisting is now being adopted on an ad hoc, or domain-by-
this ad hoc, or domain-by-domain basis. Therefore, only those domain basis. Therefore, only those domains interested in DNS
domains interested in DNS whitelisting would need to adopt the Whitelisting would need to adopt the practice, though as noted herein
practice, though as noted herein discovering that they a given domain discovering that a given domain has done so may be problematic. Also
has done so may be problematic. Also in this scenario, ad hoc use by in this scenario, ad hoc use by a particular domain may be a
a particular domain may be a temporary measure that has been adopted temporary measure that has been adopted to ease the transition of the
to ease the transition of the domain to IPv6 over some short-term 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 generally can choose to take no action whatsoever, community generally can choose not to implement DNS Whitelisting,
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. As a result is is then up to end users with
impairments to discover and fix those impairments. IPv6-related impairments to discover and fix those impairments,
though clearly other parties including end user host operating system
developers can play a critical role [I-D.ietf-v6ops-happy-eyeballs].
8.3.1. Solving Current End User IPv6 Impairments 8.3.1. Solve 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. Section 11 may also be own, or where they can seek help in doing so. Section 11 may also be
relevant in this case. relevant in this case.
One challenge with this option is the potential difficulty of One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such towards this goal, sharing the labor, time, and costs related to such
an effort. Of course, since just such a community effort is now an effort. Of course, since just such a community effort is now
underway for IPv6, it is possible that this would call for only a underway for IPv6, it is possible that this would call for only a
moderate amount of additional work. moderate amount of additional work [World IPv6 Day].
Despite any potential challenges, many in the Internet community are Despite any potential challenges, many in the Internet community are
already working towards this goal and/or have expressed a general already working towards this goal and/or have expressed a general
preference for this approach. preference for this approach.
8.3.2. Gain Experience Using IPv6 Transition Names 8.3.2. Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN Another alternative is for domains to gain experience using an FQDN
which has become common for domains beginning the transition to IPv6; which has become common for domains beginning the transition to IPv6;
ipv6.example.com and www.ipv6.example.com. This can be a way for a ipv6.example.com and www.ipv6.example.com. This can be a way for a
domain to gain IPv6 experience and increase IPv6 use on a relatively domain to gain IPv6 experience and increase IPv6 use on a relatively
controlled basis, and to inform any plans for DNS whitelisting with controlled basis, and to inform any plans for DNS Whitelisting with
experience. experience. While this is a good first step to functionally test and
prepare a domain for IPv6, the utility of the tactic is limited since
users must know the transition name, the traffic volume will be low,
and the traffic is unlikely to be representative of the general
population of end users, among other reasons.
8.3.3. Implement DNS Blacklisting
Some domains may wish to be more permissive than if they adopted DNS
Whitelisting Section 8.2, but not still have some level of control
over returning AAAA record responses Section 8.3. An alternative in
this case may be to employ DNS blacklisting, which would enable all
DNS recursive resolvers to receive AAAA record responses except for
the relatively small number that are listed in the blacklist. This
could enable an implementer to only prevent such responses where
there has been a relatively high level of IPv6-related impairments,
until such time as these impairments can be fixed or otherwise
meaningfully reduced to an acceptable level.
This approach is likely to be significantly less labor intensive for
an authoritative DNS server operator, as they would presumably focus
on a smaller number of DNS recursive resolvers than if they
implemented whitelisting. Thus, these authoritative DNS server
operators would only need to communicate with a few DNS recursive
resolver operators rather than potentially all such operators. This
should result in lower labor, systems, and process requirements,
which should be beneficial to all parties. This is not to say that
there will be no time required to work with those operators affected
by a blacklist, simply that there are likely to be fewer such
interactions and that each such interaction may be shorter in
duration.
Of course one downside of this approach may be that the perception of
being blocked (blacklisted) is sometimes worse that not being
permitted to have access (whitelisted). However, the email industry
has a long experience with blacklists and, very generally speaking,
blacklists tend to be effective and well received when it is easy to
discover if a server is on a blacklist, if there is a transparent and
easily understood process for requesting removal from a blacklist,
and if the decision-making criteria for placing a server on a
blacklist is transparently disclosed and perceived as fair.
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 tactic a domain may choose to use as they transition
pursue as they prepare for the transition to IPv6. In particular, to IPv6. In particular, some high-traffic domains view DNS
some major domains view DNS whitelisting as one of the few practical Whitelisting as one of the few practical and low-risk approaches
and low risk approaches enabling them to prepare for the transition enabling them to transition to IPv6, without which their transition
to IPv6. Thus, DNS whitelisting is not a recommended practice over may not take place for some time. However, there is also consensus
the long-term. In addition, DNS whitelisting should be avoided is that this practice is acceptable only in the short-term and that
wherever possible in the short-term and its use is generally it will not scale over the long-term. Thus, some domains may find
discouraged. Nevertheless, major domains may find DNS whitelisting a DNS Whitelisting a beneficial temporary tactic in their transition to
beneficial temporary tactic in their transition to IPv6. Such IPv6. Such temporary use during the transition to IPv6 is broadly
temporary use during the transition to IPv6 is broadly accepted accepted within the community, so long as it does not become a long-
within the community, so long as it does not become a long-term term practice.
practice.
World IPv6 Day, sponsored by the Internet Society [World IPv6 Day], World IPv6 Day, sponsored by the Internet Society [World IPv6 Day],
is scheduled to occur on June 8, 2011. This will be an opportunity is scheduled to occur on June 8, 2011. This will be an opportunity
for domains to add AAAA resource records to the DNS without using DNS for domains to add AAAA resource records to the DNS without using DNS
whitelisting. As a result, this is likely an excellent opportunity Whitelisting. As a result, this is likely an excellent opportunity
for domains to evaluate the utility or necessity of DNS whitelisting, for domains to evaluate the utility or necessity of DNS Whitelisting,
even in the short-term. A major German news website, Heise Online, even in the short-term. A major German news website, Heise Online,
also ran a similar IPv6 experiment whereby they added AAAA resource also ran a similar IPv6 experiment whereby they added AAAA resource
records and observed and measured any errors [Heise Online records and observed and measured any errors [Heise Online
Experiment], which is important reading for any domain contemplating Experiment], which is important reading for any domain contemplating
either the use of DNS whitelisting or simply adding IPv6 addressing either the use of DNS Whitelisting or simply adding IPv6 addressing
to their site. to their site.
10. Security Considerations 10. Security Considerations
There are no particular security considerations if DNS whitelisting If DNS Whitelisting is adopted, then organizations which apply DNS
is not adopted, as this is how the public Internet works today with A Whitelisting policies in their authoritative servers should have
resource records.
However, if DNS whitelisting is adopted, organizations which apply
DNS whitelisting policies in their authoritative servers should have
procedures and systems which do not allow unauthorized parties to 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, just as all
unauthorized additions or removals from the whitelist can be quite configuration settings for name servers should be protected by
damaging, and result in content providers and/or ISPs to incur appropriate procedures and systems. Should such unauthorized
substantial support costs resulting from end user and/or customer additions or removals from the whitelist can be quite damaging, and
contacts. As such, great care must be taken to control access to the result in content providers and/or ISPs to incur substantial support
whitelist for an authoritative server. costs resulting from end user and/or customer contacts. As such,
great care must be taken to control access to the whitelist for an
authoritative server.
In addition, two other key security-related issues should be taken In addition, two other key security-related issues should be taken
into consideration: into consideration:
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. Even though the authoritative server will not always not altered. Even though the authoritative server will not always
return a AAAA resource record when one exists, respective A resource return a AAAA resource record when one exists, respective A resource
records and AAAA resource records can and should both be signed. records and AAAA resource records can and should both be signed.
Therefore there are no DNSSEC implications per se. However, any Therefore there are no DNSSEC implications per se. However, any
implementer of DNS whitelisting should be careful if they implement implementer of DNS Whitelisting should be careful if they implement
both DNSSEC signing of their domain and also DNS whitelisting of that both DNSSEC signing of their domain and also DNS Whitelisting of that
same domain. Specifically, those domains should ensure that resource same domain. Specifically, those domains should ensure that resource
records are being appropriately and reliably signed, which may records are being appropriately and reliably signed, which may
present incremental operational and/or technical challenges. present incremental operational and/or technical challenges.
However, as noted in Section 3, end user networks may also choose to However, as noted in Section 3, end user networks may also choose to
implement tools at their disposal in order to address IPv6-related implement tools at their disposal in order to address IPv6-related
impairments. One of those possible tools could involve unspecified impairments. One of those possible tools could involve unspecified
changes to the configuration of their recursive resolvers. If it is changes to the configuration of their DNS recursive resolvers. If it
a Security-Aware Resolver, modifying or suppressing AAAA resource is a Security-Aware Resolver, modifying or suppressing AAAA resource
records for a DNSSEC-signed domain will be problematic and could records for a DNSSEC-signed domain will be problematic and could
break the chain of trust established with DNSSEC. 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
this may seem a somewhat obscure concern, domains nonetheless may this may seem a somewhat obscure concern, domains nonetheless may
wish to consider this when contemplating whether or not to pursue DNS wish to consider this when contemplating whether or not to pursue DNS
whitelisting. Whitelisting.
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 automatically communicating to that end user that the domain has
particular impairment. However, if that domain decided to share detected a particular impairment. However, if that domain decided to
information concerning that particular end user with their network share information concerning that particular end user with their
operator or another party, then the visited domain may wish to in network operator or another party, then the visited domain may wish
some manner advise the end user of this or otherwise seek their to in some manner advise the end user of this or otherwise seek to
consent to such information sharing. This may be achieved in a wide obtain the user's consent to such information sharing. This may be
variety of ways, from presenting a message asking the user for achieved in a wide variety of ways, from presenting a message asking
consent (which will of course help them solve a technical problem of the user for consent (which will of course help them solve a
which they are likely unaware) to adding this to a domain's website technical problem of which they are likely unaware) to adding this to
terms of use / service. Such information sharing and communication a domain's website terms of use / service. Such information sharing
of such sharing to end users may well vary by geographic area and/or and communication of such sharing to end users may well vary by
legal jurisdiction. Thus, a domain should consider any potential geographic area and/or legal jurisdiction. Thus, a domain should
privacy issues these sorts of scenarios. consider any potential privacy issues these sorts of scenarios.
To the extent that domains or network operators decide to publish
impairment statistics, they should not identify individual hosts,
host identifiers, or users.
12. IANA Considerations 12. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
13. Contributors 13. Contributors
The following people made significant textual contributions to this The following people made significant textual contributions to this
document and/or played an important role in the development and document and/or played an important role in the development and
evolution of this document: evolution of this document:
skipping to change at page 27, line 24 skipping to change at page 31, line 4
The following people made significant textual contributions to this The following people made significant textual contributions to this
document and/or played an important role in the development and document and/or played an important role in the development and
evolution of this document: evolution of this document:
- John Brzozowski - John Brzozowski
- Chris Griffiths - Chris Griffiths
- Tom Klieber - Tom Klieber
- Yiu Lee - Yiu Lee
- Rich Woundy - Rich Woundy
14. Acknowledgements 14. Acknowledgements
The author and contributors also wish to acknowledge the assistance The author and contributors also wish to acknowledge the assistance
of the following individuals. Some of these people provided helpful of the following individuals or groups. Some of these people
and important guidance in the development of this document and/or in provided helpful and important guidance in the development of this
the development of the concepts covered in this document. Other document and/or in the development of the concepts covered in this
people assisted by performing a detailed review of this document, and document. Other people assisted by performing a detailed review of
then providing feedback and constructive criticism for revisions to this document, and then providing feedback and constructive criticism
this document. All of this was helpful and therefore the following for revisions to this document. All of this was helpful and
individuals merit acknowledgement: therefore the following individuals merit acknowledgement:
- Bernard Aboba - Bernard Aboba
- Jari Arkko
- Frank Bulk - Frank Bulk
- Brian Carpenter - Brian Carpenter
- Dave Crocker
- Ralph Droms
- Wesley Eddy
- Adrian Farrel
- Stephen Farrell
- Tony Finch
- Karsten Fleischhauer - Karsten Fleischhauer
- Wesley George - Wesley George
- Philip Homburg
- Jerry Huang - Jerry Huang
- Joel Jaeggli - Ray Hunter
- Joel Jaeggli
- Erik Kline - Erik Kline
- Suresh Krishnan - Suresh Krishnan
- Victor Kuarsingh - Victor Kuarsingh
- John Leslie
- John Mann
- Danny McPherson - Danny McPherson
- Martin Millnert - Martin Millnert
- Russ Mundy
- Thomas Narten - Thomas Narten
- Pekka Savola
- Robert Sparks
- Barbara Stark
- Joe Touch
- Hannes Tschofenig - Hannes Tschofenig
- Tina Tsou - Tina Tsou
- Members of the Broadband Internet Technical Advisory Group (BITAG)
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 29, line 34 skipping to change at page 33, line 45
"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.ietf-v6ops-happy-eyeballs]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
Towards Success with Dual-Stack Hosts",
draft-ietf-v6ops-happy-eyeballs-02 (work in progress),
May 2011.
[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] [IETF-77-DNSOP]
Gashinsky, I., "IPv6 & recursive resolvers: How do we make Gashinsky, I., "IPv6 & recursive resolvers: How do we make
the transition less painful?", IETF 77 DNS Operations the transition less painful?", IETF 77 DNS Operations
Working Group, March 2010, Working Group, March 2010,
<http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>. <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IPv6 Brokenness] [IPv6 Brokenness]
Anderson, T., "Measuring and Combating IPv6 Brokenness", Anderson, T., "Measuring and Combating IPv6 Brokenness",
Reseaux IP Europeens (RIPE) 61st Meeting, November 2011, Reseaux IP Europeens (RIPE) 61st Meeting, November 2010,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>. <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[IPv6 Whitelist Operations] [IPv6 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>.
[Laws of Motion] [Laws of Motion]
Newton, I., "Mathematical Principles of Natural Philosophy Newton, I., "Mathematical Principles of Natural Philosophy
skipping to change at page 31, line 22 skipping to change at page 35, line 40
[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]
-04: Made changed based on feedback received during IESG review.
This does NOT include updated from the more general IETF last call -
that will be in a -05 version of the document. Per Ralph Droms,
change the title of 6.2 from "Likely Deployment Scenarios" to
"Possible Deployment Scenarios", as well as changes to improve the
understanding of sentences in Sections 2, 3, 4, and 8.2. Per Adrian
Farrel, made a minor change to Section 3. Per Robert Sparks, to make
clear in Section 2 that whitelisting is done on authoritative servers
and not DNS recursive resolvers, and to improve Section 8.3 and add a
reference to I-D.ietf?v6ops?happy?eyeballs. Per Wesley Eddy, updated
Section 7.3.2 to address operational concerns and re-titled Section 8
from "Solutions" to "General Implementation Variations". Per Stephen
Farrell, added text to Section 8.1 and Section 6.2, with a reference
to 8.1 in the Introduction, to say that universal deployment is
considered harmful. Added text to Section 2 per the v6ops list
discussion to indicate that whitelisting is independent of the IP
address family of the end user host or resolver. There was also
discussion with the IESG to change the name of the draft to IPv6 DNS
Resolver Whitelisting or IPv6 AAAA DNS Resolver Whitelisting (as
suggested originally by John Mann) but there was not a strong
consensus to do so. Added a new section 7.7, at the suggestion of
Philip Homburg. Per Joe Touch, added a new Section 8.4 on
blacklisting as an alternative, mentioned blacklisting in Section 2,
added a new Section 7.8 on the use of 3rd party resolvers, and
updated section 6.2 to change Internet Draft documents to RFCs.
Minor changes from Barbara Stark. Changes to the Privacy
Considerations section based on feedback from Alissa Cooper. Changed
"highly-trafficked" domains to "high-traffic" domains. Per Bernard
Aboba, added text noting that a whitelist may be manually or
automatically updated, contrasting whitelisting with blacklisting,
reorganized Section 3, added a note on multiple clearinghouses being
possible. Per Pekka Savola, added a note regarding multiple
clearinghouses to the Ad Hoc section, corrected grammar in Section
7.5, reworded Section 7.3.7, corrected the year in a RIPE reference
citation. Also incorporated general feedback from the Broadband
Internet Technical Advisory Group. Per Jari Arkko, simplified the
introduction to the Implications section, played down possible
impacts on RFC 4213, added caveats to Section 8.3.2 on the utility of
transition names, re-wrote Section 9. Updated the Abstract and
Introduction, per errors noted by Tony Finch. Updated the Security
Considerations based on feedback from Russ Mundy. Per Ray Hunter,
added some text to the De-Whitelisting implications section regarding
effects on networks of switching from IPv6 to IPv4. Updated 7.3.1
per additional feedback from Karsten Fleischhauer. Per Dave Crocker,
added a complete description of the practice to the Abstract, added a
note to the Introduction that the operational impacts are
particularly acute at scale, added text to Intro to make clear this
practice affects all protocols and not just HTTP, added a new query/
response diagram, added text to the Abstract and Introduction noting
that this is an IPv6 transition mechanism, and too many other changes
to list.
-03: Several changes suggested by Joel Jaeggli at the end of WGLC. -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 This involved swapping the order of Section 6.1 and 6.2, among other
changes to make the document more readable, understandable, and changes to make the document more readable, understandable, and
tonally balanced. As suggested by Karsten Fleischhauer, added a tonally balanced. As suggested by Karsten Fleischhauer, added a
reference to RFC 4213 in Section 7.1, as well as other suggestions to 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 that section. As suggested by Tina Tsou, made some changes to the
DNSSEC section regarding signing. As suggested by Suresh Krishnan, DNSSEC section regarding signing. As suggested by Suresh Krishnan,
made several changes to improve various sections of the document, made several changes to improve various sections of the document,
such as adding an alternative concerning the use of ipv6.domain, such as adding an alternative concerning the use of ipv6.domain,
improving the system logic section, and shortening the reference improving the system logic section, and shortening the reference
titles. As suggested by Thomas Narten, added some text regarding the titles. As suggested by Thomas Narten, added some text regarding the
imperfection of making judgements as to end user host impairments imperfection of making judgements as to end user host impairments
based upon the recursive resolver's IP and/or network. Finally, made based upon the DNS recursive resolver's IP and/or network. Finally,
sure that variations in the use of 'records' and 'resource records' made sure that variations in the use of 'records' and 'resource
was updated to 'resource records' for uniformity and to avoid records' was updated to 'resource records' for uniformity and to
confusion. 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
skipping to change at page 32, line 25 skipping to change at page 38, line 4
-00: First version published as a v6ops WG draft. The preceding -00: First version published as a v6ops WG draft. The preceding
individual draft was individual draft was
draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE
that no changes have been made yet based on WG and list feedback. that no changes have been made yet based on WG and list feedback.
These are in queue for a -01 update. These are in queue for a -01 update.
Appendix B. Open Issues Appendix B. Open Issues
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
1. RFC Editor: Please consider shortening the names of the non-RFC
references.
1. Ensure references are in the proper section (normative/ 2. Ensure references are in the proper section (normative/
informative) informative)
3. JD Falk question - should I add a sub-section to 9 to explain how
best to implement if you did it? (transparent/published policies,
SLA on decision making,etc.)
4. Per Ray Hunter - "Which is why my original posting suggested that
the WG might wish to express a concern about anyone making
assumptions about any undocumented architectural links between
DNS and transport, and also suggest that operators of aaaa
whitelists (party X) should disclose their aaaa methodology and
data, and that they should not share whitelist data with other
aaaa operators in an uncontrolled manner, so that at least Party
Y could see what was happening and why, and also have a chance of
correcting it."
5. Per Joe Touch, consider moving section 8 to just after section 3.
(only do so after -04)
6. Per Dave Crocker, this is a bit long-winded and should be edited
down - in particular removing mentions of 'parties' in various
parts ("I suggest merely noting that there are concerns and then
listing and discussing the concerns, rather than adding text to
attribute the concerns to others, even if the conclusion of your
text is that a particular concern is not valid.") (and ""These
parties explain their belief" is an example of personalization
that is not needed. This isn't about the believers. It is about
possible problems."). John Leslie concurs - feels it should be
simplified.
7. Per Pekka Savola and Stephen Farrell, should universal deployment
be removed completely (consider after -04).
8. Per Jari Arkko, review the document again after -04 to ensure the
right tone and that all motivations are properly accounted for.
9. Per Dave Crocker - do we need to change the name from
whitelisting to an alternate term? Dave suggests "IPv6 Resolver
Whitelisting" or "IPv6 DNS Response Preference List" or "DNS
Response Content Preference List". Tony Finch suggests: So I
suggest retitling the document "IPv6 DNS resolver whitelisting"
and revising the terminology throughout to match. Mark Andrews
also suggests "DNS resolver whitelisting for AAAA resolution".
John Leslie suggests "AAAA-blocking".
Author's Address Author's Address
Jason Livingood Jason Livingood
Comcast Cable Communications Comcast Cable Communications
One Comcast Center One Comcast Center
1701 John F. Kennedy Boulevard 1701 John F. Kennedy Boulevard
Philadelphia, PA 19103 Philadelphia, PA 19103
US US
Email: jason_livingood@cable.comcast.com Email: jason_livingood@cable.comcast.com
 End of changes. 152 change blocks. 
604 lines changed or deleted 970 lines changed or added

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