draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational May 30, 2011 Intended status: Informational June 8, 2011
Expires: December 1, 2011 Expires: December 10, 2011
IPv6 AAAA DNS Whitelisting Implications IPv6 AAAA DNS Whitelisting Implications
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06
Abstract Abstract
The objective of this document is to describe the practice of This document describes the practice and implications of whitelisting
whitelisting of DNS recursive resolvers in order to limit AAAA DNS recursive resolvers in order to limit AAAA resource record
resource records responses, which contain IPv6 addresses, hereafter responses (which contain IPv6 addresses) sent by authoritative DNS
referred to as DNS Whitelisting, as well as the implications of this servers. This is an IPv6 transition mechanism used by domains as a
emerging practice and what alternatives or variations may exist. method for incrementally transitioning inbound traffic to a domain
This practice is a type of IPv6 transition mechanism used by domains, from IPv4 to IPv6 transport. The audience for this document is the
as a method for incrementally transitioning inbound traffic to a Internet community generally, particularly IPv6 implementers.
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 December 1, 2011. This Internet-Draft will expire on December 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 12
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5
2.1. Description of the Operation of DNS Whitelisting . . . . . 6 2.1. Description of the Operation of DNS Whitelisting . . . . . 6
2.2. Comparison with Blacklisting . . . . . . . . . . . . . . . 8 2.2. Comparison with Blacklisting . . . . . . . . . . . . . . . 9
3. What Problems Are Implementers Trying To Solve? . . . . . . . 8 3. Similarities to Other DNS Operations . . . . . . . . . . . . . 9
3.1. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 9 3.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 9
3.2. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 10 3.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 10
3.3. Free Versus Subscription Services . . . . . . . . . . . . 10 4. What Problems Are Implementers Trying To Solve? . . . . . . . 10
4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 10 4.1. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 11
5. Similarities to Other DNS Operations . . . . . . . . . . . . . 13 4.2. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 11
5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 13 4.3. Free Versus Subscription Services . . . . . . . . . . . . 13
5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 13 5. General Implementation Variations . . . . . . . . . . . . . . 13
6. Possible Deployment Scenarios . . . . . . . . . . . . . . . . 14 5.1. Implement DNS Whitelisting Universally . . . . . . . . . . 13
6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 15 5.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 14
6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 15 5.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 14
7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 16 5.3.1. Solve Current End User IPv6 Impairments . . . . . . . 14
7.1. Architectural Implications . . . . . . . . . . . . . . . . 16 5.3.2. Gain Experience Using IPv6 Transition Names . . . . . 15
7.2. Public IPv6 Address Reachability Implications . . . . . . 17 5.3.3. Implement DNS Blacklisting . . . . . . . . . . . . . . 15
7.3. Operational Implications . . . . . . . . . . . . . . . . . 18 6. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 16
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 18 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 17
7.3.2. Authoritative DNS Server Operational Implications . . 18 7.1. Architectural Implications . . . . . . . . . . . . . . . . 17
7.2. Public IPv6 Address Reachability Implications . . . . . . 18
7.3. Operational Implications . . . . . . . . . . . . . . . . . 19
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 19
7.3.2. Authoritative DNS Server Operational Implications . . 19
7.3.3. DNS Recursive Resolver Server Operational 7.3.3. DNS Recursive Resolver Server Operational
Implications . . . . . . . . . . . . . . . . . . . . . 19 Implications . . . . . . . . . . . . . . . . . . . . . 20
7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 20 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 21
7.3.5. Implications of Operational Momentum . . . . . . . . . 20 7.3.5. Implications of Operational Momentum . . . . . . . . . 22
7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 21 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 22
7.3.7. Additional Implications If Deployed On An Ad Hoc 7.3.7. Additional Implications If Deployed On An Ad Hoc
Basis . . . . . . . . . . . . . . . . . . . . . . . . 21 Basis . . . . . . . . . . . . . . . . . . . . . . . . 22
7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 22 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 23
7.5. Technology Policy Implications . . . . . . . . . . . . . . 22 7.5. Technology Policy Implications . . . . . . . . . . . . . . 23
7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 23 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 24
7.7. Implications with Poor IPv4 and Good IPv6 Transport . . . 24 7.7. Implications with Poor IPv4 and Good IPv6 Transport . . . 25
7.8. Implications for Users of Third-Party DNS Recursive 7.8. Implications for Users of Third-Party DNS Recursive
Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 25 Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 25
8. General Implementation Variations . . . . . . . . . . . . . . 25 8. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 26
8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 26 9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 27
8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 26 9.2. Authoritative DNS Response Consistency Considerations . . 27
8.3.1. Solve Current End User IPv6 Impairments . . . . . . . 26
8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 27 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
8.3.3. Implement DNS Blacklisting . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 28 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Authoritative DNS Response Consistency Considerations . . 29 14.1. Normative References . . . . . . . . . . . . . . . . . . . 30
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 33
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document describes the emerging practice of whitelisting of DNS This document describes the practice and implications of whitelisting
recursive resolvers in order to limit AAAA resource record (RR) DNS recursive resolvers in order to limit AAAA resource record (RR)
responses, which contain IPv6 addresses, hereafter referred to as DNS responses (which contain IPv6 addresses) sent by authoritative DNS
Whitelisting. The document explores the implications of this servers. This is referred to hereafter as DNS Whitelisting. This is
emerging practice are and what alternatives may exist. When an IPv6 transition mechanism used by domains as a method for
implemented, DNS Whitelisting in practice means that a domain's incrementally transitioning inbound traffic to a domain from IPv4 to
authoritative DNS will return a AAAA resource record to DNS recursive IPv6 transport. When implemented, a domain's authoritative DNS will
resolvers [RFC1035] on the whitelist, while returning no AAAA return a AAAA resource record to DNS recursive resolvers [RFC1035] on
resource records to DNS resolvers which are not on the whitelist. the whitelist, while returning no AAAA resource records to DNS
This practice is a type of IPv6 transition mechanism used by domains, recursive resolvers which are not on the whitelist. The practice
as a method for incrementally transitioning inbound traffic to a appears to have first been used by major web content sites (sometimes
domain from IPv4 to IPv6 transport. The practice appears to have described hereafter as "high-traffic domains"), which have specific
first been used by major web content sites (sometimes described concerns relating to maintaining a high-quality user experience for
herein as "high-traffic domains"), which have specific concerns all of their users during their transition to IPv6.
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,
skipping to change at page 4, line 49 skipping to change at page 4, line 47
o that the practice does not scale, o that the practice does not scale,
o that it violates a basic premise of cross-Internet o that it violates a basic premise of cross-Internet
interoperability by requiring prior arrangements, interoperability by requiring prior arrangements,
o and that the costs and negative implications of DNS Whitelisting o and that the costs and negative implications of DNS Whitelisting
outweigh the perceived benefits. outweigh the perceived benefits.
This document explores the reasons and motivations for DNS This document explores the reasons and motivations for DNS
Whitelisting Section 3. It also explores the concerns regarding this Whitelisting Section 4. It also explores the concerns regarding this
practice, and whether and when the practice is recommended Section 9. practice, and whether and when the practice is recommended Section 8.
Readers will hopefully better understand what DNS Whitelisting is, Readers will hopefully better understand what DNS Whitelisting is,
why some parties are implementing it, and what criticisms of the why some domains are implementing it, and what the implications are.
practice exist.
2. How DNS Whitelisting Works 2. How DNS Whitelisting Works
At a high level, using a whitelist means no traffic is permitted to Generally, using a whitelist means no traffic (or traffic of a
certain type) is permitted to the destination host unless the
originating host's IP address is contained in the whitelist. In
contrast, using a blacklist means that all traffic is permitted to
the destination host unless the originating host's IP address is the destination host unless the originating host's IP address is
contained in the whitelist. In contrast, using a blacklist means contained in the blacklist.
that all traffic is permitted to the destination host unless the
originating host's IP address is contained in the blacklist.
DNS Whitelisting is implemented in authoritative DNS servers, not in DNS Whitelisting is implemented in authoritative DNS servers, not in
DNS recursive resolvers. These authoritative servers implement IP DNS recursive resolvers. These authoritative DNS servers implement
address-based restrictions on AAAA query responses. So far, DNS IP address-based restrictions on AAAA query responses. So far, DNS
Whitelisting has been primarily implemented by web server operators Whitelisting has been primarily implemented by web site operators
deploying IPv6-enabled services, though this practice would affect deploying IPv6-enabled services, though this practice could affect
any protocols and services within a domain. For a given operator of all protocols and services within a domain. For a given operator of
a website, such as www.example.com, the operator essentially applies a website, such as www.example.com, the domain operator essentially
an access control list (ACL) on the authoritative DNS servers for the applies an access control list (ACL) on the authoritative DNS servers
domain example.com. The ACL is populated with the IPv4 and/or IPv6 for the domain example.com. The ACL is populated with the IPv4
addresses or prefix ranges of DNS recursive resolvers on the and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on
Internet, which have been authorized to receive AAAA resource record the Internet, which have been authorized to receive (or access) AAAA
responses. These DNS recursive resolvers are operated by third resource record responses. These DNS recursive resolvers are
parties, such as ISPs, universities, governments, businesses, and operated by third parties, such as Internet Service Providers (ISPs),
individual end users. If a DNS recursive resolver IS NOT matched in universities, governments, businesses, and individual end users. If
the ACL, then AAAA resource records will NOT be sent in response to a a DNS recursive resolver IS NOT matched in the ACL, then AAAA
query for a hostname in the example.com domain. However, if a DNS resource records WILL NOT be sent in response to a query for a
recursive resolver IS matched in the ACL, then AAAA resource records hostname in the example.com domain. However, if a DNS recursive
will be sent in response to a query for a given hostname in the resolver IS matched in the ACL, then AAAA resource records WILL be
example.com domain. While these are not network-layer access sent in response to a query for a given hostname in the example.com
controls they are nonetheless access controls that are a factor for domain. While these are not network-layer access controls (as many
end users and other parties like network operators, especially as ACLs are) they are nonetheless access controls that are a factor for
networks and hosts transition from one network address family to end users and other organizations such as network operators,
another (IPv4 to IPv6). especially as networks and hosts transition from one network address
family to another (IPv4 to IPv6). Thus, if a DNS recursive resolver
is on the ACL (whitelist) then they have access to AAAA resource
records for the domain.
In practice, DNS Whitelisting generally means that a very small 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 or ACL) will receive AAAA responses. The large majority of
DNS resolvers on the Internet will therefore receive only A resource DNS recursive resolvers on the Internet will therefore receive only A
records containing IPv4 addresses. Thus, quite simply, the resource 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 all those 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 more details.
works.
DNS Whitelisting also works independently of whether an authoritative DNS Whitelisting also works independently of whether an authoritative
DNS server, DNS recursive resolver, or end user host uses IPv4 DNS server, DNS recursive resolver, or end user host uses IPv4
transport, IPv6, or both. So, for example, whitelisting may prevent transport, IPv6, or both. So, for example, whitelisting may prevent
sending AAAA responses even in those cases where the DNS recursive sending AAAA responses even in those cases where the DNS recursive
resolver has queried the authoritative server over IPv6 transport, or resolver has queried the authoritative server over IPv6 transport, or
where the end user host's original query to the DNS recursive where the end user host's original query to the DNS recursive
resolver was over IPv6 transport. One important reason for this is resolver was over IPv6 transport. One important reason for this is
that even though the DNS recursive resolver may have no IPv6-related that even though the DNS recursive resolver may have no IPv6-related
impairments, this is not a reliable predictor of whether the same is impairments, this is not a reliable predictor of whether the same is
true of the end user host. This also means that a DNS whitelist can true of the end user host. This also means that a DNS whitelist can
contain both IPv4 and IPv6 addresses. contain both IPv4 and IPv6 addresses.
Finally, DNS Whitelisting could possibly be deployed in two ways: Finally, DNS Whitelisting could possibly be deployed in two ways:
universally on a global basis, (though that would be considered universally on a global basis (though that would be considered
harmful and is just covered to explain why this is the case), or, harmful and is just covered to explain why this is the case), or,
more realistically, on an ad hoc basis. Deployment on a universal more realistically, on an ad hoc basis. Deployment on a universal
deployment basis means that DNS Whitelisting is implemented on all deployment basis means that DNS Whitelisting is implemented on all
authoritative DNS servers, across the entire Internet. In contrast, authoritative DNS servers, across the entire Internet. In contrast,
deployment on an ad hoc basis means that only some authoritative DNS deployment on an ad hoc basis means that only some authoritative DNS
servers, and perhaps even only a few, implement DNS Whitelisting. servers, and perhaps even only a few, implement DNS Whitelisting.
These two potential deployment models are described in Section 6. These two potential deployment models are described in Section 5.
Specific implementations will vary from domain to domain, based on a
range of factors such as the technical capabilities of a given
domain. As such, any examples listed herein should be considered
general examples and are not intended to be exhaustive.
2.1. Description of the Operation of DNS Whitelisting 2.1. Description of the Operation of DNS Whitelisting
The system logic of DNS Whitelisting is as follows: The system logic of DNS Whitelisting is as follows:
1. The authoritative DNS server for example.com receives DNS queries 1. The authoritative DNS server for example.com receives DNS queries
for the A (IPv4) and/or AAAA (IPv6) address resource records for for the A (IPv4) and/or AAAA (IPv6) address resource records for
the FQDN www.example.com, for which AAAA (IPv6) resource records the Fully Qualified Domain Name (FQDN) www.example.com, for which
exist. AAAA (IPv6) resource records exist.
2. The authoritative DNS server checks the IP address (IPv4, IPv6, 2. The authoritative DNS server checks the IP address (IPv4, IPv6,
or both) of the DNS recursive resolver sending the AAAA (IPv6) or both) of the DNS recursive resolver sending the AAAA (IPv6)
query against the access control list (ACL) that is the DNS query against the access control list (ACL) that is the DNS
whitelist. Whitelist.
3. 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.
4. 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 will likely return a response with the response
(RCODE) being set to 0 (No Error) with an empty answer section code (RCODE) being set to 0 (No Error) with an empty answer
for the AAAA record query. section for the AAAA record query.
---------------------------------------------------------------------
A query is sent from a DNS recursive resolver that IS NOT on the DNS
whitelist:
Request Request
www.example.com www.example.com
AAAA +-------------+ AAAA +-----------------+
++--++ ---------> | RESOLVER | ---------> | www.example.com |
|| || A | **IS NOT** | A | IN A exists |
+-++--++-+ ---------> | ON | ---------> | IN AAAA exists |
+--------+ A | example.com | A | |
Host <--------- | WHITELIST | <--------- | |
Computer A Record +-------------+ A Record +-----------------+
Response DNS Recursive Response example.com
(only IPv4) Resolver (only IPv4) Authoritative
#1 Server
---------------------------------------------------------------------
A query is sent from a DNS recursive resolver that IS on the DNS
Whitelist:
Request Request
www.example.com www.example.com
AAAA +-------------+ AAAA +-----------------+
++--++ ---------> | RESOLVER | ---------> | www.example.com |
|| || A | **IS** | A | IN A exists |
+-++--++-+ ---------> | ON | ---------> | IN AAAA exists |
+--------+ AAAA | example.com | AAAA | |
Host <--------- | WHITELIST | <--------- | |
Computer A | | A | |
<--------- | | <--------- | |
A and AAAA +-------------+ A and AAAA +-----------------+
Record DNS Recursive Record example.com
Responses Resolver Responses Authoritative
(IPv4+IPv6) #2 (IPv4+IPv6) Server
---------------------------------------------------------------------
Figure 1: DNS Whitelisting - Functional Diagram
---------------------------------------------------------------------
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
A (IPv4) <------------- A (IPv4) <--------------- NOT on Whitelist +--------------------------------------------------------------------+
response response return only A (IPv4) | Caching Server 1 - IS NOT ON the DNS Whitelist |
--------------------------------------------------------------------- | Caching Server 2 - IS ON the DNS Whitelist |
Host 2 Resolver 2 Authoritative Server | Note: Transport between each host can be IPv4 or IPv6. |
Query A and AAAA -----> Query A and AAAA ----> Receive A and +--------------------------------------------------------------------+
for www.example.com for www.example.com AAAA queries +----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| Resolver | | Server 1 | | Server |
+----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | NOT on Whitelist
| | DNS Response: |
| | example.com A |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A | |
|<----------------------| |
A (IPv4) <------------- A (IPv4) and <------------ IS on Whitelist +----------+ +---------------+ +---------------+
AAAA (IPv6) AAAA (IPv6) return A (IPv4) | Stub | | DNS Caching | | DNS |
responses responses and AAAA (IPv6) | Resolver | | Server 2 | | Server |
--------------------------------------------------------------------- +----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | IS on Whitelist
| | DNS Response: |
| | example.com A, AAAA |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A, AAAA | |
|<----------------------| |
Figure 2: DNS Whitelisting - Request/Response Diagram Figure 1: DNS Whitelisting Diagram
2.2. Comparison with Blacklisting 2.2. Comparison with Blacklisting
With DNS Whitelisting, DNS recursive resolvers can receive AAAA With DNS Whitelisting, DNS recursive resolvers can receive AAAA
resource records only if they are on the whitelist. In contrast, resource records only if they are on the whitelist. In contrast,
blacklisting would be the opposite whereby all DNS recursive blacklisting would be the opposite whereby all DNS recursive
resolvers can receive AAAA resource records unless they are on the resolvers can receive AAAA resource records unless they are on the
blacklist. So a whitelist contains a list of hosts allowed blacklist. So a whitelist contains a list of hosts allowed
something, whereby a blacklist contains a list of hosts disallowed something, whereby a blacklist contains a list of hosts disallowed
something. While the distinction between the concepts of something. While the distinction between the concepts of
whitelisting and blacklisting are important, this is noted whitelisting and blacklisting is important, this is noted
specifically since some implementers of DNS Whitelisting may choose specifically since some implementers of DNS Whitelisting may choose
to transition to DNS Blacklisting before returning to a state without to transition to DNS Blacklisting before returning to a state without
address-family-related ACLs in their authoritative DNS servers. It address-family-related ACLs in their authoritative DNS servers. It
is unclear when and if it would be appropriate to change from is unclear when and if it would be appropriate to change from
whitelisting to blacklisting. Nor is it clear how implementers will whitelisting to blacklisting. Nor is it clear how implementers will
judge the network conditions to have changed sufficiently to justify judge the network conditions to have changed sufficiently to justify
disabling AAAA resource record access controls. disabling such 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
AAAA resource records and observed and measured errors [Heise], which
should be important reading for any domain contemplating either the
use of DNS Whitelisting or simply adding 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] [IPv6-Growth] [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] [WL-Ops]. 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 as 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
The implications relating to DNS Whitelisting are further enumerated
here and in Section 7.
Some parties in the Internet community, including ISPs, are concerned
that the practice of DNS Whitelisting for IPv6 address resource
records represents a departure from the generally accepted practices
regarding IPv4 address resource records in the DNS on the Internet
[WL-Concerns]. These parties explain their belief that once an
authoritative server operator adds an A record (IPv4) to the DNS,
then any DNS recursive resolver on the Internet can receive that A
record in response to a query. By extension, this means that any of
the hosts connected to any of these DNS recursive resolvers can
receive the IPv4 address resource records for a given FQDN. This
enables new server hosts which are connected to the Internet, and for
which a fully qualified domain name (FQDN) such as www.example.com
has been added to the DNS with an IPv4 address record, to be almost
immediately reachable by any host on the Internet. In this case,
these new servers hosts become more and more widely accessible as new
networks and new end user hosts connect to the Internet over time,
capitalizing on and increasing so-called "network effects" (also
called network externalities). It also means that the new server
hosts do not need to know about these new networks and new end user
hosts in order to make their content and applications available to
them, in essence that each end in this end-to-end model is
responsible for connecting to the Internet and once they have done so
they can connect to each other without additional impediments or
middle networks or intervening networks or servers knowing about
these end points and whether one is allowed to contact the other.
In contrast, the concern is that DNS Whitelisting may fundamentally
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
other end (where the content is located), without parts of the middle
(DNS recursive resolvers) used by one end (the client, or end user
hosts) being known to an intermediary (authoritative nameservers) and
approved for access to the resource at the end. As new networks
connect to the Internet over time, those networks need to contact any
and all domains which have implemented DNS Whitelisting in order to
apply to be added to their DNS whitelist, in the hopes of making the
content and applications residing on named server hosts in those
domains accessible by the end user hosts on that new network.
Furthermore, this same need to contact all domains implementing DNS
Whitelisting also applies to all pre-existing (but not whitelisted)
networks connected to the Internet.
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; when
DNS Whitelisting of IPv6 resource records is used, these new server
hosts are not accessible via a FQDN by any end user hosts until such
time as the operator of the authoritative DNS servers for those new
server hosts expressly authorizes access to those new server hosts by
adding DNS recursive resolvers around the Internet to the ACL. This
has the potential to be a significant change in reachability of
content and applications by end users and networks as these end user
hosts and networks transition to IPv6, resulting in more (but
different) breakage. A concern expressed is that if much of the
content that end users are most interested in is not accessible as a
result, then end users and/or networks may resist adoption of IPv6 or
actively seek alternatives to it, such as using multi-layer network
address translation (NAT) techniques like NAT444
[I-D.shirasaki-nat444] on a long-term basis. There is also concern
that this practice could disrupt the continued increase in Internet
adoption by end users if they cannot simply access new content and
applications but must instead contact the operator of their DNS
recursive resolver, such as their ISP or another third party, to have
their DNS recursive resolver authorized for access to the content or
applications that interests them. Meanwhile, these parties say, over
99.9% of the other end users that are also using that same network or
DNS recursive resolver are unable to access the IPv6-based content,
despite their experience being a positive one.
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
primary motivation cited for the practice of DNS Whitelisting, it is
not clear if the level of IPv4-related impairment is more or less
that this percentage (which in any case is likely to have declined
since its original citation). Indeed, as at least one document
reviewer has pointed out, it may simply be that websites are only
measuring IPv6 impairments and not IPv4 impairments, whether because
IPv6 is new or whether those websites are simply unable to or are
otherwise not in a position to be able to measure IPv4 impairment
(since this could result in no Internet access whatsoever). As a
result, it is worth considering that IPv4-related impairment could
exceed that of IPv6-related impairment and that such IPv4-related
impairment may have simply been accepted as "background noise" on the
Internet for a variety of reasons. Of course, this comparison of the
level of worldwide IPv6 impairments to IPv4 impairments is
speculation, as the author is not aware of any good measurement of
IPv4-related impairments which are comparable in nature to the IPv6-
related impairment measurements which have recently been conducted
around the world.
An additional concern is that the IP address of a DNS recursive
resolver is not a precise indicator of the IPv6 preparedness, or lack
of IPv6-related impairments, of end user hosts which query (use) a
particular DNS recursive resolver. While the DNS recursive resolver
may be an imperfect proxy for judging IPv6 preparedness, it is at
least one of the best available methods at the current time.
5. Similarities to Other DNS Operations 3. 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 3.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 recursive whereby hosts on different networks which use different DNS recursive
skipping to change at page 13, line 36 skipping to change at page 10, line 6
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 3.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 necessarily be directly reachable without passing through the load
. As such, while the IP address resource records have been added to balancer first.
the DNS, the end hosts are not necessarily directly reachable, which
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 [Wild-Resolvers]. CDNs perform geographic location of the resolver [Wild-Resolvers]. CDNs perform
this function in order to attempt to direct hosts to connect to the this function in order to attempt to direct hosts to connect to the
nearest content cache. As a result, one can see some similarities nearest content cache. As a result, one can see some similarities
with DNS Whitelisting insofar as different IP address resource with DNS Whitelisting insofar as different IP address resource
records are selectively returned to resolvers based on the IP address records are selectively returned to resolvers based on the IP address
of each resolver (or other imputed factors related to that IP of each resolver (or other imputed factors related to that IP
address). However, what is different is that in this case the address). However, what is different is that in this case the
resolvers are not deliberately blocked from receiving DNS responses resolvers are not deliberately blocked from receiving DNS responses
containing an entire class of addresses; this load balancing function containing an entire class of addresses; this load balancing function
strives to perform a content location-improvement function and not an strives to perform a content location-improvement function and not an
access control function. access control function.
6. Possible Deployment Scenarios 4. What Problems Are Implementers Trying To Solve?
In considering how DNS Whitelisting may emerge more widely, there are Implementers are attempting to protect users of their domain from
two deployment scenarios explored below, one of which, the ad-hoc having a negative experience (poor performance) when they receive DNS
case, is realistic and may happen. The other, universal deployment, response containing AAAA resource records or when attempting to use
is only described for the sake of completeness, to highlight its IPv6 transport. There are two concerns which relate to this
difficulties, and to explain why it would be considered harmful. 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. Both can negatively affect the experience
of end users.
In either of these deployment scenarios, it is possible that Not all domains may face these challenges, though some clearly do,
reputable third parties could create and maintain DNS whitelists, in since the user base of each domain, traffic sources, traffic volumes,
much the same way that blacklists are distributed and used for and other factors obviously varies between domains. For example,
reducing email spam. In the email context, a mail operator while some domains have implemented DNS Whitelisting, others have run
subscribes to one or more of these lists and as such the operational IPv6 experiments whereby they added AAAA resource records and
processes for additions and deletions to the list are managed by a observed and measured errors, and then decided not to implement DNS
third party. A similar model could emerge for DNS Whitelisting, Whitelisting [Heise]. A more widespread such experiment was World
whether deployment occurs universally or on an ad hoc basis. IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011.
This was a unique opportunity for hundreds of domains to add AAAA
resource records to the DNS without using DNS Whitelisting, all at
the same time. Domains can run their own independent experiments in
the future, adding AAAA resource records for a period of time, and
then analyzing any impacts or effects on traffic and the experience
of end users.
An additional factor in either scenario is that a DNS recursive 4.1. Volume-Based Concerns
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.
6.1. Deploying DNS Whitelisting On An Ad Hoc Basis 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.
Compared to 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.
The most likely deployment scenario is where some authoritative DNS For example, one can imagine for one of the top ten sites globally
server operators implement DNS Whitelisting but many or most others that the idea of suddenly turning on a significant amount of IPv6
do not do so. What can make this scenario challenging from the traffic is quite daunting. DNS Whitelisting may therefore offer such
standpoint of a DNS recursive resolver operator is determining which high-traffic domains one potential method for incrementally enabling
domains implement DNS Whitelisting, particularly since a domain may IPv6. Thus, some implementers with high-traffic domains plan to use
not do so as they initially transition to IPv6, and may instead do so DNS Whitelisting as a necessary, though temporary, risk reduction
later. Thus, a DNS recursive resolver operator may initially believe tactic intended to ease their transition to IPv6 and minimize any
that they can receive AAAA responses as a domain adopts IPv6, but perceived risk in such a transition.
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 DNS
recursive resolver operators due to the effect of DNS Whitelisting.
One benefit of DNS Whitelisting being deployed on an ad hoc basis is 4.2. IPv6-Related Impairment
that only the domains that are interested in doing so would have to
upgrade their authoritative DNS servers in order to implement the
ACLs necessary to perform DNS Whitelisting. 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 Some implementers have observed that when they added AAAA resource
given domain will implement DNS Whitelisting temporarily. A domain, records to their authoritative DNS servers in order to support IPv6
particularly a high-traffic domain, may choose to do so in order to access to their content that a small fraction of end users had slow
ease their transition to IPv6 through a selective deployment and or otherwise impaired access to a given web site with both AAAA and A
minimize any perceived risk in such a transition. In addition, it is resource records. The fraction of users with such impaired access
possible that one or more DNS Whitelist clearinghouses may emerge, has been estimated to be as high as 0.078% of total Internet users
providing implementers with a way to subscribe to a whitelist in a [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness],
manner similar to that used on email servers for blacklists. though more recent measurements indicate this is declining
[Impairment-Tracker]. 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 domain.
6.2. Deploying DNS Whitelisting Universally It is not clear if the level of IPv4-related impairment is more or
less that IPv6-related impairment. As one document reviewer has
pointed out, it may simply be that websites are only measuring IPv6
impairments and not IPv4 impairments, whether because IPv6 is new or
whether those websites are simply unable to or are otherwise not in a
position to be able to measure IPv4 impairment (since this could
result in no Internet access whatsoever).
This deployment scenario is one where DNS Whitelisting is implemented As a result of this impairment affecting end users of a given domain,
on all authoritative DNS servers, across the entire Internet, which a few high-traffic domains have either implemented DNS Whitelisting
is highly unlikely and unrealistic. While this scenario seems far or are considering doing so [NW-Article-DNS-WL] [WL-Ops]. While it
less likely than ad hoc deployment due to many parties not sharing is outside the scope of this document to explore the various reasons
the concerns that have so far motivated the use of DNS Whitelisting, why a particular user's system (host) may have impaired IPv6 access,
it is nonetheless conceivable that it could be one of the ways in for the users who experience this impairment it has a very real
which DNS Whitelisting is deployed, though such a universal performance impact. It would affect access to all or most dual stack
deployment could be considered harmful and problematic. services to which the user attempts to connect. This negative end
user experience can range from somewhat slower than usual access (as
compared to native IPv4-based access), to extremely slow access, to
no access to the domain whatsoever. In essence, whether the end user
even has an IPv6 address or not, 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 DNS recursive resolvers. In this case, a DNS
recursive resolver operator expressed a short-term concern that their
IPv6 network infrastructure was 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 9.1).
It is worth noting that the IP address of a DNS recursive resolver is
not a precise indicator of the IPv6 preparedness, or lack of IPv6-
related impairment, of end user hosts which query (use) a particular
DNS recursive resolver. While the DNS recursive resolver may be an
imperfect proxy for judging IPv6 preparedness, it is at least one of
the best available methods at the current time.
4.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 may be more sensitive to
IPv6 transition issues since their users can quickly switch to
another domain that is not using IPv6.
5. General Implementation Variations
In considering how DNS Whitelisting may emerge more widely, there are
two deployment scenarios explored below, one of which, the ad-hoc
case Section 5.2, is realistic and is happening now. The other,
universal deployment Section 5.1, is only described for the sake of
completeness, to highlight its difficulties, and to explain why it
would be considered harmful. Other possible alternative or
supplementary approaches are also outlined.
In evaluating implementing DNS Whitelisting universally and on an ad
hoc basis, it is possible that reputable third parties could create
and maintain DNS whitelists, in much the same way that blacklists are
distributed and used for reducing email spam. In the email context,
a mail operator subscribes to one or more of these lists and as such
the operational processes for additions and deletions to the list are
managed by a third party. A similar model could emerge for DNS
Whitelisting.
In either of those scenarios 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.
5.1. Implement DNS Whitelisting Universally
One approach is to implement DNS Whitelisting universally, which
could also involve using some sort of centralized registry of DNS
Whitelisting policies, contracts, processes, or other information.
For this deployment scenario to occur, DNS Whitelisting functionality For this deployment scenario to occur, DNS Whitelisting functionality
would need to be built into all authoritative DNS server software, would need to be built into all authoritative DNS server software,
and that all operators of authoritative DNS servers would have to and all operators of authoritative DNS servers would have to upgrade
upgrade their software in order to enable this functionality. New their software in order to enable this functionality. New IETF
IETF Request for Comment (RFC) documents would need to be completed Request for Comment (RFC) documents may need to be completed to
to describe how to properly configure, deploy, and maintain DNS describe how to properly configure, deploy, and maintain DNS
Whitelisting across the entire Internet. As a result, it is highly Whitelisting across the entire Internet. As a result, it is highly
unlikely that DNS Whitelisting will become universally deployed. unlikely that DNS Whitelisting will become universally deployed.
Such an approach is considered harmful and problematic, and almost
certain not to happen.
5.2. Implement DNS Whitelisting On An Ad Hoc Basis
DNS Whitelisting is now being adopted on an ad hoc, or domain-by-
domain basis. Therefore, only those domains interested in DNS
Whitelisting would need to adopt the practice. Also in this
scenario, ad hoc use by a particular domain is likely to be a
temporary measure that has been adopted to ease the transition of the
domain to IPv6. A domain, particularly a high-traffic domain, may
choose to do so in order to ease their transition to IPv6 through a
selective deployment so as to minimize any risks or disruptions in
such a transition.
One benefit of DNS Whitelisting being deployed on an ad hoc basis is
that only the domains that are interested in doing so would have to
upgrade their authoritative DNS servers (or take other steps) in
order to implement DNS Whitelisting. Some domains that plan to or
already have implemented this and are manually updating their
whitelist, while others such as CDNs have discussed the possibility
of an automated method for doing so.
5.3. Do Not Implement DNS Whitelisting
As an alternative to adopting DNS Whitelisting, domains can choose
not to implement DNS Whitelisting, continuing the current predominant
authoritative DNS operational model on the Internet. It is then up
to end users with 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. However, the
concerns and risks related to traffic volume Section 4.1 should still
be considered since those are not directly related to such
impairments.
5.3.1. Solve Current End User IPv6 Impairments
A further extension of not implementing DNS Whitelisting, is to also
endeavor fix the underlying technical problems experienced by end
users during the transition to IPv6. A first step is to identify
which users have such impairments and then to communicate this
information to affected users. Such end user communication is likely
to be most helpful if the end user is not only alerted to a potential
problem but is given careful and detailed advice on how to resolve
this on their own, or where they can seek help in doing so.
Section 10 may also be relevant in this case.
One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such
an effort. However, World IPv6 Day [W6D] shows that such community
efforts are possible and despite any potential challenges, the
Internet community continues to work to solve end user IPv6
impairments.
However, as noted above, the concerns and risks related to traffic
volume Section 4.1 should still be considered since those are not
directly related to such impairments.
5.3.2. Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN
which has become common for domains beginning the transition to IPv6;
ipv6.example.com and www.ipv6.example.com. This can be a way for a
domain to gain IPv6 experience and increase IPv6 use on a relatively
controlled basis, and to inform any plans for DNS Whitelisting with
experience.
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. Thus, as noted above,
the concerns and risks related to traffic volume Section 4.1 should
still be considered.
5.3.3. Implement DNS Blacklisting
Some domains may wish to be more permissive than if they adopted DNS
Whitelisting, but still have some level of control over returning
AAAA record responses. In this case an alternative 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, for example, 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.
This is not to say that there will be no time required to work with
those parties affected by a blacklist, simply that there are likely
to be fewer such interactions and that each such interaction could be
shorter in duration.
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.
As noted in Section 7.3.7, it is also possible that a domain may
choose to first implement DNS Whitelisting and then migrate to DNS
Blacklisting.
6. Concerns Regarding DNS Whitelisting
There is concern that the practice of DNS Whitelisting for IPv6
address resource records represents a departure from the generally
accepted practices regarding IPv4 address resource records in the DNS
on the Internet [WL-Concerns]. Generally, once an authoritative
server operator adds an A record (IPv4) to the DNS, then any DNS
recursive resolver on the Internet can receive that A record in
response to a query. This enables new server hosts that are
connected to the Internet, and for which a FQDN such as
www.example.com has been added to the DNS with an IPv4 address
record, to be almost immediately reachable by any host on the
Internet. Each end in this end-to-end model is responsible for
connecting to the Internet and once they have done so they can
connect to each other without additional impediments, middle
networks, intervening networks, or servers either knowing about all
end points or whether one is allowed to discover and contact the
other. The end result is that new server hosts become more and more
widely accessible as new networks and new hosts connect to the
Internet over time, capitalizing on and increasing so-called "network
effects" (also called network externalities).
In contrast, DNS Whitelisting may fundamentally change this model.
In the altered DNS Whitelisting end-to-end model, one end (where the
end user is located) cannot readily discover the other end (where the
content is located), without parts of the middle (authoritative DNS
servers) making a new type of access control decision in the DNS. So
in the current IPv4-based Internet when a new server host is added to
the Internet it is generally widely available to all end user hosts
via a FQDN. When DNS Whitelisting of IPv6 resource records is used,
these new server hosts are not accessible via a FQDN by any end user
hosts until such time as the operator of the authoritative DNS
servers adds DNS recursive resolvers around the Internet to the DNS
Whitelist.
7. Implications of DNS Whitelisting 7. Implications of DNS Whitelisting
There are many implications of DNS Whitelisting. The key The key DNS Whitelisting implications are detailed below.
implications are detailed below.
7.1. Architectural Implications 7.1. Architectural Implications
DNS Whitelisting modifies the end-to-end model and the general notion DNS Whitelisting modifies the end-to-end model and the general notion
of spontaneous interoperability of the architecture that prevails on of spontaneous interoperability of the architecture that prevails on
the 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, and it requires some not exist before on the IPv4-addressed Internet, and it requires some
type of prior registration with authoritative servers. This poses type of prior registration with authoritative servers. This poses
some risks noted in [RFC3724]. In explaining the history of the end- some risks noted in [RFC3724]. In explaining the history of the end-
to-end principle [RFC1958] states that one of the goals is to to-end principle, [RFC1958] states that one of the goals is to
minimize the state, policies, and other functions needed in the minimize the state, policies, and other functions needed in the
middle of the network in order to enable end-to-end communications on middle of the network in order to enable end-to-end communications on
the Internet. In this case, the middle network should be understood the Internet. In this case, the middle network should be understood
to mean anything other than the end hosts involved in communicating to mean anything other than the end hosts involved in communicating
with one another. Some state, policies, and other functions have with one another. Some state, policies, and other functions have
always been necessary to enable such end-to-end communication, but always been necessary to enable such end-to-end communication, but
the goal of the approach has been to minimize this to the greatest the goal of the approach has been to minimize this to the greatest
extent possible. 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
skipping to change at page 16, line 49 skipping to change at page 18, line 9
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] and [Rethinking]. In the end-to-end model are concerned are [Tussle] and [Rethinking]. In
[Tussle], the authors note concerns regarding the introduction of new [Tussle], the authors note concerns regarding the introduction of new
control points, as well as "kludges" to the DNS, as risks to the goal control points, as well as "kludges" to the DNS, as risks to the goal
of network transparency in the end-to-end model. Some parties of network transparency in the end-to-end model. Given the emerging
concerned with the emerging use of DNS Whitelisting have shared use of DNS Whitelisting [Tussle] is an interesting and relevant
similar concerns, which may make [Tussle] an interesting and relevant document. In addition, [Rethinking] reviews similar issues that are
document. In addition, [Rethinking] reviews similar issues that may of interest to readers of this document.
be of interest to readers of this document.
Also, it is somewhat possible that DNS Whitelisting could affect some Also, it is somewhat possible that DNS Whitelisting could affect some
of the architectural assumptions which underlie parts of Section 2 of of the architectural assumptions which underlie parts of Section 2 of
[RFC4213] which outlines the dual stack approach to the IPv6 [RFC4213] which outlines the dual stack approach to the IPv6
transition. DNS Whitelisting could modify the behavior of the DNS, transition. DNS Whitelisting could modify the behavior of the DNS,
as described in Section 2.2 of [RFC4213] and could require different as described in Section 2.2 of [RFC4213] and could require different
sets of DNS servers to be used for hosts that are (using terms from sets of DNS servers to be used for hosts that are (using terms from
that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes. that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
As such, broad use of DNS Whitelisting may necessitate the review As such, broad use of DNS Whitelisting may necessitate the review
and/or revision (though revision is unlikely to be neccessary) of and/or revision (though revision is unlikely to be necessary) of
standards documents which describe dual-stack and IPv6 operating standards documents which describe dual-stack and IPv6 operating
modes, dual-stack architecture generally, and IPv6 transition modes, dual-stack architecture generally, and IPv6 transition
methods, including but not limited to [RFC4213]. 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 It is a critical to understand that the concept of reachability
described here depends upon a knowledge of an address in the DNS. 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 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 dependent upon looking up an IP address in the DNS when a FQDN is
skipping to change at page 17, line 40 skipping to change at page 18, line 46
server host is restricted via a DNS whitelist. Since most Internet server host is restricted via a DNS whitelist. Since most Internet
applications and hosts such as web servers depend upon the DNS, and 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 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 remember or wish to type in an IP address, the notion of reachability
described here should be understood to include knowledge of how to described here should be understood to include knowledge of how to
associate a name with a network address. 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 a FQDN is immediately useful for address is added to the DNS, that a FQDN is immediately useful for
reaching it. This is a generalization and in Section 5 there are reaching it. This is a generalization and in Section 3 there are
examples of common cases where this may not necessarily be the case. examples of common cases where this may not necessarily be the case.
For the purposes of this argument, that concept of accessibility is For the purposes of this argument, that concept of accessibility is
described as "pervasive reachability". It has so far been assumed described as "pervasive reachability". It has so far been assumed
that the same expectations of pervasive reachability would exist in that the same expectations of pervasive reachability would exist in
the IPv6-addressed Internet. However, if DNS Whitelisting is the IPv6-addressed Internet. However, if DNS Whitelisting is
deployed, this will not be the case since only end user hosts using deployed, this will not be the case since only end user hosts using
DNS recursive resolvers that are included in the ACL of a given DNS recursive resolvers that are included in the ACL of a given
domain using DNS Whitelisting would be able to reach new servers in domain using DNS Whitelisting would be able to reach new servers in
that given domain via IPv6 addresses. The expectation of any end that given domain via IPv6 addresses. The expectation of any end
user host being able to connect to any server (essentially both user host being able to connect to any server (essentially both
hosts, just at either end of the network), defined here as "pervasive hosts, just at either end of the network), defined here as "pervasive
reachability", will change to "restricted reachability" with IPv6. reachability", will change to "restricted reachability" with IPv6.
Establishing DNS Whitelisting as an accepted practice in the early Establishing DNS Whitelisting as an accepted practice in the early
phases of mass IPv6 deployment could establish it as an integral part phases of mass IPv6 deployment could establish it as an integral part
of how IPv6 DNS resource records are deployed globally. This risks of how IPv6 DNS resource records are deployed globally. This risks
DNS Whitelisting living on for decades as a key foundational element DNS Whitelisting living on for many years as a key foundational
of domain name management on the Internet. element of domain name management on the Internet.
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
skipping to change at page 19, line 47 skipping to change at page 20, line 52
order to manage large numbers of DNS Whitelisting applications. order to manage large numbers of DNS Whitelisting applications.
Since there is no common method for determining whether or not a Since there is no common method for determining whether or not a
domain is engaged in DNS Whitelisting, operators will have to apply domain is engaged in DNS Whitelisting, operators will have to apply
to be whitelisted for a domain based upon one or more end user to be whitelisted for a domain based upon one or more end user
requests, which means systems, processes, and personnel for handling requests, which means systems, processes, and personnel for handling
and responding to those requests will also be necessary. and responding to those requests will also be necessary.
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 5 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 DNS 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
skipping to change at page 21, line 35 skipping to change at page 22, line 42
7.3.7. Additional Implications If Deployed On An Ad Hoc Basis 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis
As more domains choose to implement DNS Whitelisting, and more As more domains choose to implement DNS Whitelisting, and more
networks become IPv6-capable and request to be whitelisted, scaling networks become IPv6-capable and request to be whitelisted, scaling
up operational processes, monitoring, and ACL updates will become up operational processes, monitoring, and ACL updates will become
more difficult. The increased rate of change and increased size of more difficult. The increased rate of change and increased size of
whitelists will increase the likelihood of configuration and other whitelists will increase the likelihood of configuration and other
operational errors. operational errors.
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. It is clear that trying to coordinate whitelisting to blacklisting. It also seems unlikely for such a
this across the Internet is likely be be impossible, so such a change change from whitelisting to blacklisting to be coordinated across the
to blacklisting would happen on a domain-by-domain basis (if at all). Internet, so such a change to blacklisting will likely occur on an
ad-hoc basis as well (if at all).
Finally, some implementers consider DNS Whitelisting to be a Finally, some implementers consider DNS Whitelisting to be a
temporary measure. As such, it is not clear how these implementers temporary measure. As such, it is not clear how these implementers
will judge the network conditions to have changed sufficiently to will judge the network conditions to have changed sufficiently to
justify disabling DNS Whitelisting (or Blacklisting, or other AAAA justify disabling DNS Whitelisting (or blacklisting, or other AAAA
resource record access controls) and/or what the process and timing resource record access controls) and/or what the process and timing
will be in order to discontinue this practice. 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 on the Internet is a move toward more heterogeneity. A broad trend on the Internet is a move toward more heterogeneity.
One manifestation of this is in an increasing number, variety, and One manifestation of this is in an increasing number, variety, and
customization of end user hosts, including home networks, operating customization of end user hosts, including home networks, operating
systems, client software, home network devices, and personal systems, client software, home network devices, and personal
computing devices. This trend appears to have had a positive effect computing devices. This trend appears to have had a positive effect
on the development and growth of the Internet. This trend has on the development and growth of the Internet and has enabled end
enabled end user to connect any technically compliant device or use users to connect any technically compliant device or use any
any technically compatible software to connect to the Internet. Not technically compatible software to connect to the Internet. Not only
only does this trend towards greater heterogeneity reduce the control does this trend towards greater heterogeneity reduce the control
which is exerted in the middle of the network, described positively which is exerted in the middle of the network, described positively
in [Tussle], [Rethinking], and [RFC3724], but it also appears to help in [Tussle], [Rethinking], and [RFC3724], but it also appears to help
to enable greater and more rapid innovation at the edges. to enable greater and more rapid innovation at the edge of the
network.
Some forms of so-called "network neutrality" principles around the Some forms of so-called "network neutrality" principles around the
world include the notion that any IP-capable device should be able to world include the notion that any IP-capable device should be able to
connect to a network, which seems to encourage heterogeneity. These connect to a network, encouraging heterogeneity. These principles
principles are often explicitly encouraged by application providers are often explicitly encouraged by application providers, though some
given the reasons noted above, though some of these same providers of these same providers may be using DNS Whitelisting. This is
may also be implementing DNS Whitelisting. This is ironic, as one ironic, as one implication of the adoption of DNS Whitelisting is
implication of the adoption of DNS Whitelisting is that in encourages that it could encourage a move back towards homogeneity resulting
a move back towards homogeneity. This is because some implementers from greater control over devices in order to attempt to enforce
have expressed a preference for greater levels of control by networks technical requirements intended to reduce IPv6-related impairments.
over end user hosts in order to attempt to enforce technical This return to an environment of more homogenous and/or controlled
requirements intended to reduce IPv6-related impairments. This end user hosts could have unintended side effects on and counter-
return to an environment of more homogenous and/or controlled end productive implications for future innovation at the edge of the
user hosts could have unintended side effects on and counter-
productive implications for future innovation at the edges of the
network. 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 and
the process of reviewing an application for DNS Whitelisting, and the processes related to reviewing and making decisions on DNS
decision-making process regarding whitelisting for a domain. Whitelisting applications for a domain, as well as making any
Important questions may include whether these policies have been possible de-whitelisting decisons. Important questions may include
fully and transparently disclosed, are non-discriminatory, and are whether these policies have been fully and transparently disclosed,
not anti-competitive. A related implication is whether and what the are non-discriminatory, and are not anti-competitive. Key questions
process for appeals is, when a domain decides against adding a DNS here may include whether appeals are allowed, what the process is,
recursive resolver to the whitelist. Key questions here may include what the expected turn around time is, and whether the appeal will be
whether appeals are allowed, what the process is, what the expected handled by an independent third party.
turn around time is, and whether the appeal will be handled by an
independent third party or other entity/group.
Further implications arise when de-whitelisting occurs. Questions
that may naturally be raised in such a case include whether the
criteria for de-whitelisting have been fully and transparently
disclosed, are non-discriminatory, and are not anti-competitive.
Additionally, the question of whether or not there was a cure period
available prior to de-whitelisting, during which troubleshooting
activities, complaint response work, and corrective actions may be
attempted, and whether this cure period was a reasonable amount of
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 operator and the operator of the DNS recursive
operator of the DNS recursive resolver, including end users, resolver, including end users, application developers, content
application developers, content providers, advertisers, public policy providers, advertisers, public policy groups, governments, and other
groups, governments, and other entities, which may also seek to entities. These concerned parties may seek to become involved in or
become involved in or express opinions concerning whitelisting and/or express opinions concerning whitelisting and/or de-whitelisting
de-whitelisting decisions. Lastly, it is conceivable that any of decisions.
these interested parties or other related stakeholders may seek
redress outside of the process a domain has establishing for DNS
Whitelisting and de-whitelisting.
A final concern is that decisions relating to whitelisting and de- 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 been established with DNS Whitelisting. For example, in which has been established with DNS Whitelisting. For example, in
one imagined scenario, a domain could withhold adding a network to one imagined scenario, a domain could withhold adding a network to
their DNS Whitelisting unless that network agreed to some sort of their DNS Whitelisting unless that network agreed to some sort of
financial payment, legal agreement, agreement to sever a relationship financial payment, legal agreement, agreement to sever a relationship
with a competitor of the domain, etc. In another example, a music- with a competitor of the domain, etc. In another example, a music-
oriented domain may be engaged in some sort of dispute with an oriented domain may be engaged in some sort of dispute with an
academic network concerning copyright infringement concerns within academic network concerning copyright infringement concerns within
that network, and may choose to de-whitelist that network as a that network, and may choose to de-whitelist that network as a
negotiating technique in some sort of commercial discussion. In a negotiating technique in some sort of commercial discussion. In a
final example, a major email domain may choose to de-whitelist a final example, a major email domain may choose to de-whitelist a
network due to that network sending some large volume of spam. Thus, network due to that network sending some large volume of spam. Thus,
it seems possible that DNS Whitelisting and de-whitelisting could it seems possible that whitelisting and de-whitelisting could become
become a vehicle for adjudicating other disputes, and that this may a vehicle for adjudicating other disputes, and that this may well
well have intended and unintended consequences for end users which have consequences for end users which are affected by such decisions
are affected by such decisions and are unlikely to be able to express and are unable to express a strong voice in such decisions.
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 6, 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 or large scale network address
techniques like NAT444 [I-D.shirasaki-nat444], which these parties translation (NAT) techniques, which these parties may decide to
may decide to pursue on a long-term basis to avoid the perceived pursue on a long-term basis to avoid the perceived costs and
costs and aggravations related to DNS Whitelisting. This could of aggravations related to DNS Whitelisting. This could of course come
course come at the very time that the Internet community is trying to at the very time that the Internet community is trying to get these
get these very same parties interested in IPv6 and motivated to begin very same parties interested in IPv6 and motivated to begin the
the transition to IPv6. As a result, parties that are likely to be 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.
adopted by majors Internet domains or other major parties in the
Internet ecosystem.
At the same time, as noted in Section 3, some high-traffic domains At the same time, as noted in Section 4, some high-traffic domains
may find the prospect of transitioning to IPv6 daunting without may find the prospect of transitioning to IPv6 daunting without
having some short-term ability to incrementally control the amount having some short-term ability to incrementally control the amount
and source of IPv6 traffic to their domains. Lacking such controls, and source of IPv6 traffic to their domains. Lacking such controls,
some domains may choose to substantially delay their transition to some domains may choose to substantially delay their transition to
IPv6. IPv6.
7.7. Implications with Poor IPv4 and Good IPv6 Transport 7.7. Implications with Poor IPv4 and Good IPv6 Transport
It is possible that there could be situations where the differing It is possible that there could be situations where the differing
quality of the IPv4 and IPv6 connectivity of an end user could cause quality of the IPv4 and IPv6 connectivity of an end user could cause
skipping to change at page 25, line 10 skipping to change at page 25, line 43
end user only gets A record responses for their impaired IPv4 end user only gets A record responses for their impaired IPv4
transport rather than also AAAA record responses for their stable and transport rather than also AAAA record responses for their stable and
well-performing IPv6 transport. Thus, the user's poor IPv4 well-performing IPv6 transport. Thus, the user's poor IPv4
connectivity situation is potentially exacerbated by not having connectivity situation is potentially exacerbated by not having
access to a given domain's IPv6 content since they must use the access to a given domain's IPv6 content since they must use the
address family with relatively poor performance. address family with relatively poor performance.
7.8. Implications for Users of Third-Party DNS Recursive Resolvers 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 In most cases it is assumed that end users will make use of DNS
recursive resolvers which are operated by their network provider, recursive resolvers which are operated by their access network
whether that is an ISP, campus network, enterprise network, or some provider, whether that is an ISP, campus network, enterprise network,
other type of access network. However there are also cases where an or some other type of network. However there are also cases where an
end user has changed their DNS server IP addresses in their device's end user has changed their DNS server IP addresses in their device's
operating system to those of another party which operates DNS operating system to those of a third party which operates DNS
recursive resolvers independently of end user access networks. In recursive resolvers independently of end user access networks.
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
One seemingly obvious approach is to implement DNS whitelisted
universally, and to do so using some sort of centralized registry of
DNS Whitelisting policies, contracts, processes, or other
information. Such an approach is considered harmful and problematic,
and almost certain not to happen.
8.2. Implement DNS Whitelisting On An Ad Hoc Basis
DNS Whitelisting is now being adopted on an ad hoc, or domain-by-
domain basis. Therefore, only those domains interested in DNS
Whitelisting would need to adopt the practice, though as noted herein
discovering that a given domain has done so may be problematic. Also
in this scenario, ad hoc use by a particular domain may be a
temporary measure that has been adopted to ease the transition of the
domain to IPv6 over some short-term timeframe.
8.3. Do Not Implement DNS Whitelisting
As an alternative to adopting DNS Whitelisting, the Internet
community generally can choose not to implement DNS Whitelisting,
perpetuating the current predominant authoritative DNS operational
model on the Internet. As a result is is then up to end users with
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. Solve Current End User IPv6 Impairments
A further extension of not implementing DNS Whitelisting, is to also
endeavor to actually fix the underlying technical problems that have
prompted the consideration of DNS Whitelisting in the first place, as
an alternative to trying to apply temporary workarounds to avoid the
symptoms of underlying end user IPv6 impairments. A first step is
obviously to identify which users have such impairments, which would
appear to be possible, and then to communicate this information to
end users. Such end user communication is likely to be most helpful
if the end user is not only alerted to a potential problem but is
given careful and detailed advice on how to resolve this on their
own, or where they can seek help in doing so. Section 11 may also be
relevant in this case.
One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such
an effort. Of course, since just such a community effort is now
underway for IPv6, it is possible that this would call for only a
moderate amount of additional work [W6D].
Despite any potential challenges, many in the Internet community are
already working towards this goal and/or have expressed a general
preference for this approach.
8.3.2. Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN
which has become common for domains beginning the transition to IPv6;
ipv6.example.com and www.ipv6.example.com. This can be a way for a
domain to gain IPv6 experience and increase IPv6 use on a relatively
controlled basis, and to inform any plans for DNS Whitelisting with
experience. 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 In these cases, an authoritative DNS server may receive a query from
an authoritative DNS server operator, as they would presumably focus a DNS recursive resolver in one network, though the end user sending
on a smaller number of DNS recursive resolvers than if they the original query is in an entirely different network. It may
implemented whitelisting. Thus, these authoritative DNS server therefore be more challenging for a DNS Whitelist implementer to
operators would only need to communicate with a few DNS recursive determine the level of IPv6-related impairment when such third-party
resolver operators rather than potentially all such operators. This DNS recursive resolvers are used, given the wide variety of end user
should result in lower labor, systems, and process requirements, access networks which may be used and that this mix may change in
which should be beneficial to all parties. This is not to say that unpredictable ways over time.
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 There may also be cases where end users' assigned DNS recursive
being blocked (blacklisted) is sometimes worse that not being resolvers have not been whitelisted for a particular domain, but
permitted to have access (whitelisted). However, the email industry where the end user tries to switch to a third-party DNS recursive
has a long experience with blacklists and, very generally speaking, resolver that has been whitelisted. While in most cases the end user
blacklists tend to be effective and well received when it is easy to will be able to switch to use that third-party's DNS servers, some
discover if a server is on a blacklist, if there is a transparent and specialized access networks, such as in hotels and conference
easily understood process for requesting removal from a blacklist, centers, may prevent using third-party DNS servers. In these cases,
and if the decision-making criteria for placing a server on a end users may be frustrated at their inability to access certain
blacklist is transparently disclosed and perceived as fair. content over IPv6, resulting in complaints to both a particular
domain as well as the access network operator.
9. Is DNS Whitelisting a Recommended Practice? 8. 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 can
at best a useful tactic a domain may choose to use as they transition be a useful tactic a domain may choose to use as they transition to
to IPv6. In particular, some high-traffic domains view DNS IPv6. In particular, some high-traffic domains view DNS Whitelisting
Whitelisting as one of the few practical and low-risk approaches as one of the few practical and low-risk approaches enabling them to
enabling them to transition to IPv6, without which their transition transition to IPv6, without which their transition may not take place
may not take place for some time. However, there is also consensus for some time. However, there is also consensus is that this
is that this practice is acceptable only in the short-term and that practice is workable only in the short-term and that it will not
it will not scale over the long-term. Thus, some domains may find scale over the long-term. Thus, some domains may find DNS
DNS Whitelisting a beneficial temporary tactic in their transition to Whitelisting a beneficial temporary tactic in their transition to
IPv6. Such temporary use during the transition to IPv6 is broadly IPv6. Such temporary use during the transition to IPv6 is broadly
accepted within the community, so long as it does not become a long- accepted within the community, so long as it does not become a long-
term practice. term practice.
World IPv6 Day, sponsored by the Internet Society [W6D], is scheduled 9. Security Considerations
to occur on June 8, 2011. This will be an opportunity for domains to
add AAAA resource records to the DNS without using DNS Whitelisting.
As a result, this is likely an excellent opportunity for domains to
evaluate the utility or necessity of DNS Whitelisting, even in the
short-term. A major German news website, Heise Online, also ran a
similar IPv6 experiment whereby they added AAAA resource records and
observed and measured any errors [Heise], which is important reading
for any domain contemplating either the use of DNS Whitelisting or
simply adding IPv6 addressing to their site.
10. Security Considerations
If DNS Whitelisting is adopted, then organizations which apply DNS If DNS Whitelisting is adopted, then organizations which apply DNS
Whitelisting policies in their authoritative servers should have Whitelisting policies in their authoritative servers should have
procedures and systems which do not allow unauthorized parties to procedures and systems which do not allow unauthorized parties to
either remove whitelisted DNS resolvers from the whitelist or add either remove whitelisted DNS recursive resolvers from the whitelist
non-whitelisted DNS resolvers to the whitelist, just as all or add non-whitelisted DNS recursive resolvers to the whitelist, just
configuration settings for name servers should be protected by as all configuration settings for name servers should be protected by
appropriate procedures and systems. Should such unauthorized appropriate procedures and systems. Should such unauthorized
additions or removals from the whitelist can be quite damaging, and additions or removals from the whitelist can be quite damaging, and
result in content providers and/or ISPs to incur substantial support result in content providers and/or ISPs to incur substantial support
costs resulting from end user and/or customer contacts. As such, costs resulting from end user and/or customer contacts. As such,
great care must be taken to control access to the whitelist for an great care must be taken to control access to the whitelist for an
authoritative server. 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 9.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 DNS server, which provides different answers depending
which resolver server has sent a query, the DNSSEC chain of trust is upon which DNS resolver has sent a query, the DNSSEC chain of trust
not altered. Even though the authoritative server will not always is not altered. Even though the authoritative DNS server will not
return a AAAA resource record when one exists, respective A resource always return a AAAA resource record when one exists, respective A
records and AAAA resource records can and should both be signed. resource records and AAAA resource records can and should both be
Therefore there are no DNSSEC implications per se. However, any signed. Therefore there are no DNSSEC implications per se. However,
implementer of DNS Whitelisting should be careful if they implement any implementer of DNS Whitelisting should be careful if they
both DNSSEC signing of their domain and also DNS Whitelisting of that implement both DNSSEC signing of their domain and also DNS
same domain. Specifically, those domains should ensure that resource Whitelisting of that same domain. Specifically, those domains should
records are being appropriately and reliably signed, which may ensure that resource records are being appropriately and reliably
present incremental operational and/or technical challenges. signed, which may present modest incremental operational and/or
technical challenges.
However, as noted in Section 3, end user networks may also choose to However, as noted in fourth paragraph of Section 4.2, end user
implement tools at their disposal in order to address IPv6-related networks may also choose to implement tools at their disposal in
impairments. One of those possible tools could involve unspecified order to address IPv6-related impairments. One of those tools could
changes to the configuration of their DNS recursive resolvers. If it involve unspecified changes to the configuration of their DNS
is a Security-Aware Resolver, modifying or suppressing AAAA resource recursive resolvers. If those are Security-Aware Resolvers,
records for a DNSSEC-signed domain will be problematic and could modifying or suppressing AAAA resource records for a DNSSEC-signed
break the chain of trust established with DNSSEC. domain will be problematic and could break the chain of trust
established with DNSSEC.
10.2. Authoritative DNS Response Consistency Considerations 9.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 9.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 10. Privacy Considerations
As noted in Section 8.3.1, there may be methods to detect IPv6- As noted in Section 5.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 automatically communicating to that end user that the domain has in automatically communicating to that end user that the domain has
detected a particular impairment. However, if that domain decided to detected a particular impairment. However, if that domain decided to
share information concerning that particular end user with their share information concerning that particular end user with their
network operator or another party, then the visited domain may wish network operator or another party, then the visited domain may wish
to in some manner advise the end user of this or otherwise seek to to in some manner advise the end user of this or otherwise seek to
obtain the user's consent to such information sharing. This may be obtain the user's consent to such information sharing. This may be
achieved in a wide variety of ways, from presenting a message asking achieved in a wide variety of ways, from presenting a message asking
skipping to change at page 30, line 29 skipping to change at page 28, line 29
technical problem of which they are likely unaware) to adding this to technical problem of which they are likely unaware) to adding this to
a domain's website terms of use / service. Such information sharing a domain's website terms of use / service. Such information sharing
and communication of such sharing to end users may well vary by and communication of such sharing to end users may well vary by
geographic area and/or legal jurisdiction. Thus, a domain should geographic area and/or legal jurisdiction. Thus, a domain should
consider any potential 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 To the extent that domains or network operators decide to publish
impairment statistics, they should not identify individual hosts, impairment statistics, they should not identify individual hosts,
host identifiers, or users. host identifiers, or users.
12. IANA Considerations 11. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
13. Contributors 12. Contributors
The following people made significant textual contributions to this The following people made significant textual contributions to this
document and/or played an important role in the development and document and/or played an important role in the development and
evolution of this document: evolution of this document:
- John Brzozowski - John Brzozowski
- Chris Griffiths - Chris Griffiths
- Tom Klieber - Tom Klieber
- Yiu Lee - Yiu Lee
- Rich Woundy - Rich Woundy
14. Acknowledgements 13. 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 or groups. Some of these people of the following individuals or groups. Some of these people
provided helpful and important guidance in the development of this provided helpful and important guidance in the development of this
document and/or in the development of the concepts covered in this document and/or in the development of the concepts covered in this
document. Other people assisted by performing a detailed review of document. Other people assisted by performing a detailed review of
this document, and then providing feedback and constructive criticism this document, and then providing feedback and constructive criticism
for revisions to this document. All of this was helpful and for revisions to this document, or engaged in a healthy debate over
therefore the following individuals merit acknowledgement: the subject of the document. All of this was helpful and therefore
the following individuals merit acknowledgement:
- Bernard Aboba - Bernard Aboba
- Jari Arkko - Jari Arkko
- Frank Bulk - Frank Bulk
- Brian Carpenter - Brian Carpenter
- Lorenzo Colitti
- Alissa Cooper
- Dave Crocker - Dave Crocker
- Ralph Droms - Ralph Droms
- Wesley Eddy - Wesley Eddy
- J.D. Falk
- Adrian Farrel - Adrian Farrel
- Stephen Farrell - Stephen Farrell
- Tony Finch - Tony Finch
- Karsten Fleischhauer - Karsten Fleischhauer
- Wesley George - Wesley George
skipping to change at page 31, line 45 skipping to change at page 30, line 4
- Karsten Fleischhauer - Karsten Fleischhauer
- Wesley George - Wesley George
- Philip Homburg - Philip Homburg
- Jerry Huang - Jerry Huang
- Ray Hunter - Ray Hunter
- Joel Jaeggli - Joel Jaeggli
- Erik Kline - Erik Kline
- Suresh Krishnan - Suresh Krishnan
- Victor Kuarsingh - Victor Kuarsingh
- John Leslie - John Leslie
- John Mann - John Mann
- Danny McPherson - Danny McPherson
- Milo Medin
- Martin Millnert - Martin Millnert
- Russ Mundy - Russ Mundy
- Thomas Narten - Thomas Narten
- Pekka Savola - Pekka Savola
- Robert Sparks - Robert Sparks
- Barbara Stark - Barbara Stark
- Joe Touch - Joe Touch
- Hannes Tschofenig - Hannes Tschofenig
- Tina Tsou - Tina Tsou
- Members of the Broadband Internet Technical Advisory Group (BITAG) - Members of the Broadband Internet Technical Advisory Group (BITAG)
15. References 14. References
15.1. Normative References 14.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.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996. RFC 1958, June 1996.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000. February 2000.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop",
RFC 2956, October 2000. RFC 2956, October 2000.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
[RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle
and the Future of End-to-End: Reflections on the Evolution and the Future of End-to-End: Reflections on the Evolution
of the Internet Architecture", RFC 3724, March 2004. of the Internet Architecture", RFC 3724, March 2004.
skipping to change at page 33, line 25 skipping to change at page 31, line 42
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
15.2. Informative References 14.2. Informative References
[Heise] Heise.de, "The Big IPv6 Experiment", Heise.de [Heise] Heise.de, "The Big IPv6 Experiment", 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]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), January 2011.
[IETF-77-DNSOP] [IETF-77-DNSOP]
Gashinsky, I., "IPv6 & recursive resolvers: How do we make Gashinsky, I., "IPv6 & recursive resolvers: How do we make
the transition less painful?", IETF 77 DNS Operations the transition less painful?", IETF 77 DNS Operations
Working Group, March 2010, Working Group, March 2010,
<http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>. <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IPv6-Brokenness] [IPv6-Brokenness]
Anderson, T., "Measuring and Combating IPv6 Brokenness", Anderson, T., "Measuring and Combating IPv6 Brokenness",
Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, Reseaux IP Europeens (RIPE) 61st Meeting, November 2010,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>. <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[IPv6-Growth] [IPv6-Growth]
Colitti, L., Gunderson, S., Kline, E., and T. Refice, Colitti, L., Gunderson, S., Kline, E., and T. Refice,
"Evaluating IPv6 adoption in the Internet", Passive and "Evaluating IPv6 adoption in the Internet", Passive and
Active Management (PAM) Conference 2010, April 2010, Active Management (PAM) Conference 2010, April 2010,
<http://www.google.com/research/pubs/archive/36240.pdf>. <http://www.google.com/research/pubs/archive/36240.pdf>.
[Impairment-Tracker]
Anderson, T., "IPv6 dual-stack client loss in Norway",
Website , May 2011, <http://www.fud.no/ipv6/>.
[Motion] Newton, I., "Mathematical Principles of Natural Philosophy [Motion] Newton, I., "Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica)", (Philosophiae Naturalis Principia Mathematica)",
Principia Mathematical Principles of Natural Philosophy Principia Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica), July 1687, (Philosophiae Naturalis Principia Mathematica), July 1687,
<http://en.wikipedia.org/wiki/Newton's_laws_of_motion>. <http://en.wikipedia.org/wiki/Newton's_laws_of_motion>.
[NW-Article-DNS-WL] [NW-Article-DNS-WL]
Marsan, C., "Google, Microsoft, Netflix in talks to create Marsan, C., "Google, Microsoft, Netflix in talks to create
shared list of IPv6 users", Network World , March 2010, <h shared list of IPv6 users", Network World , March 2010, <h
ttp://www.networkworld.com/news/2010/ ttp://www.networkworld.com/news/2010/
032610-dns-ipv6-whitelist.html>. 032610-dns-ipv6-whitelist.html>.
[NW-Article-DNSOP] [NW-Article-DNSOP]
Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Marsan, C., "Yahoo proposes 'really ugly hack' to DNS",
Network World , March 2010, <http://www.networkworld.com/ Network World , March 2010, <http://www.networkworld.com/
news/2010/032610-yahoo-dns.html>. news/2010/032610-yahoo-dns.html>.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[Rethinking] [Rethinking]
Blumenthal, M. and D. Clark, "Rethinking the design of the Blumenthal, M. and D. Clark, "Rethinking the design of the
Internet: The end to end arguments vs. the brave new Internet: The end to end arguments vs. the brave new
world", ACM Transactions on Internet Technology Volume 1, world", ACM Transactions on Internet Technology Volume 1,
Number 1, Pages 70-109, August 2001, <http:// Number 1, Pages 70-109, August 2001, <http://
dspace.mit.edu/bitstream/handle/1721.1/1519/ dspace.mit.edu/bitstream/handle/1721.1/1519/
TPRC_Clark_Blumenthal.pdf>. TPRC_Clark_Blumenthal.pdf>.
[Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski, [Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski,
"Tussle in Cyberspace: Defining Tomorrow's Internet", "Tussle in Cyberspace: Defining Tomorrow's Internet",
skipping to change at page 35, line 29 skipping to change at page 33, line 32
[Wild-Resolvers] [Wild-Resolvers]
Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig,
"Comparing DNS Resolvers in the Wild", ACM Sigcomm "Comparing DNS Resolvers in the Wild", ACM Sigcomm
Internet Measurement Conference 2010, November 2010, Internet Measurement Conference 2010, November 2010,
<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>. <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
Appendix A. Document Change Log Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-06: Removed the Open Issue #8 concerning the document name, at the
direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and
removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG
mailing list. Revised the Abstract and Intro as recommended by Tony
Finch. Per Dave Crocker, updated the diagram following remedial
ASCII art assistance, added a reference regarding IPv4-brokenness
statistics. Removed Open Issue #1, after validating proper reference
placement and removing NAT444 reference. Updates per Ralph Droms'
review for the IESG. Closed Open Issue #4, Per Joe Touch, moved
section 8 to just after section 3 - and also moved up section 6 and
merged it. Closed Open Issue #5, per Dave Crocker and John Leslie,
simplifying the document more, consolidating sections, etc. Closed
Open Issue #6. Closed Open Issue #7, per Jari Arkko, ensuring all
motivations are accounted for, etc. Closed Open Issue #9, per
Stephen Farrell, re. World IPv6 Day (retained reference but re-
worded those sections). Removed the happy-eyeballs reference since
this was an informative reference and the draft could be delayed due
to that dependency. ALL OPEN ITEMS ARE NOW CLOSED.
-05: Additional changes requested by Stephen Farrell intended to -05: Additional changes requested by Stephen Farrell intended to
close his Discuss on the I-D. These changes were in Sections 6.2 and close his Discuss on the I-D. These changes were in Sections 6.2 and
8.3. Also shortened non-RFC references at Stephen's request. 8.3. Also shortened non-RFC references at Stephen's request.
-04: Made changed based on feedback received during IESG review. -04: Made changed based on feedback received during IESG review.
This does NOT include updated from the more general IETF last call - This does NOT include updated from the more general IETF last call -
that will be in a -05 version of the document. Per Ralph Droms, that will be in a -05 version of the document. Per Ralph Droms,
change the title of 6.2 from "Likely Deployment Scenarios" to change the title of 6.2 from "Likely Deployment Scenarios" to
"Possible Deployment Scenarios", as well as changes to improve the "General Implementation Variations", as well as changes to improve
understanding of sentences in Sections 2, 3, 4, and 8.2. Per Adrian the understanding of sentences in Sections 2, 3, 4, and 8.2. Per
Farrel, made a minor change to Section 3. Per Robert Sparks, to make Adrian Farrel, made a minor change to Section 3. Per Robert Sparks,
clear in Section 2 that whitelisting is done on authoritative servers to make clear in Section 2 that whitelisting is done on authoritative
and not DNS recursive resolvers, and to improve Section 8.3 and add a servers and not DNS recursive resolvers, and to improve Section 8.3
reference to I-D.ietf?v6ops?happy?eyeballs. Per Wesley Eddy, updated and add a reference to I-D.ietf-v6ops-happy-eyeballs. Per Wesley
Section 7.3.2 to address operational concerns and re-titled Section 8 Eddy, updated Section 7.3.2 to address operational concerns and re-
from "Solutions" to "General Implementation Variations". Per Stephen titled Section 8 from "Solutions" to "General Implementation
Farrell, added text to Section 8.1 and Section 6.2, with a reference Variations". Per Stephen Farrell, added text to Section 8.1 and
to 8.1 in the Introduction, to say that universal deployment is Section 6.2, with a reference to 8.1 in the Introduction, to say that
considered harmful. Added text to Section 2 per the v6ops list universal deployment is considered harmful. Added text to Section 2
discussion to indicate that whitelisting is independent of the IP per the v6ops list discussion to indicate that whitelisting is
address family of the end user host or resolver. There was also independent of the IP address family of the end user host or
discussion with the IESG to change the name of the draft to IPv6 DNS resolver. There was also discussion with the IESG to change the name
Resolver Whitelisting or IPv6 AAAA DNS Resolver Whitelisting (as of the draft to IPv6 DNS Resolver Whitelisting or IPv6 AAAA DNS
suggested originally by John Mann) but there was not a strong Resolver Whitelisting (as suggested originally by John Mann) but
consensus to do so. Added a new section 7.7, at the suggestion of there was not a strong consensus to do so. Added a new section 7.7,
Philip Homburg. Per Joe Touch, added a new Section 8.4 on at the suggestion of Philip Homburg. Per Joe Touch, added a new
blacklisting as an alternative, mentioned blacklisting in Section 2, Section 8.4 on blacklisting as an alternative, mentioned blacklisting
added a new Section 7.8 on the use of 3rd party resolvers, and in Section 2, added a new Section 7.8 on the use of 3rd party
updated section 6.2 to change Internet Draft documents to RFCs. resolvers, and updated section 6.2 to change Internet Draft documents
Minor changes from Barbara Stark. Changes to the Privacy to RFCs. Minor changes from Barbara Stark. Changes to the Privacy
Considerations section based on feedback from Alissa Cooper. Changed Considerations section based on feedback from Alissa Cooper. Changed
"highly-trafficked" domains to "high-traffic" domains. Per Bernard "highly-trafficked" domains to "high-traffic" domains. Per Bernard
Aboba, added text noting that a whitelist may be manually or Aboba, added text noting that a whitelist may be manually or
automatically updated, contrasting whitelisting with blacklisting, automatically updated, contrasting whitelisting with blacklisting,
reorganized Section 3, added a note on multiple clearinghouses being reorganized Section 3, added a note on multiple clearinghouses being
possible. Per Pekka Savola, added a note regarding multiple possible. Per Pekka Savola, added a note regarding multiple
clearinghouses to the Ad Hoc section, corrected grammar in Section clearinghouses to the Ad Hoc section, corrected grammar in Section
7.5, reworded Section 7.3.7, corrected the year in a RIPE reference 7.5, reworded Section 7.3.7, corrected the year in a RIPE reference
citation. Also incorporated general feedback from the Broadband citation. Also incorporated general feedback from the Broadband
Internet Technical Advisory Group. Per Jari Arkko, simplified the Internet Technical Advisory Group. Per Jari Arkko, simplified the
skipping to change at page 37, line 42 skipping to change at page 36, line 15
-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. Ensure references are in the proper section (normative/
informative)
2. JD Falk question - should I add a sub-section to 9 to explain how
best to implement if you did it? (transparent/published policies,
SLA on decision making,etc.)
3. 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."
4. Per Joe Touch, consider moving section 8 to just after section 3.
(only do so after -04)
5. 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.
6. Per Pekka Savola and Stephen Farrell, should universal deployment
be removed completely (consider after -04).
7. Per Jari Arkko, review the document again after -04 to ensure the
right tone and that all motivations are properly accounted for.
8. 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".
9. Per Stephen Farrell, consider removing W6D references.
Author's Address Author's Address
Jason Livingood Jason Livingood
Comcast Cable Communications Comcast Cable Communications
One Comcast Center One Comcast Center
1701 John F. Kennedy Boulevard 1701 John F. Kennedy Boulevard
Philadelphia, PA 19103 Philadelphia, PA 19103
US US
Email: jason_livingood@cable.comcast.com Email: jason_livingood@cable.comcast.com
 End of changes. 98 change blocks. 
815 lines changed or deleted 660 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/