draft-ietf-v6ops-v6-aaaa-whitelisting-implications-00.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational December 3, 2010 Intended status: Informational January 25, 2011
Expires: June 6, 2011 Expires: July 29, 2011
IPv6 AAAA DNS Whitelisting Implications IPv6 AAAA DNS Whitelisting Implications
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-00 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01
Abstract Abstract
The objective of this document is to describe what whitelisting of The objective of this document is to describe what whitelisting of
DNS AAAA resource records is, or DNS whitelisting for short, as well DNS AAAA resource records is, or DNS whitelisting for short, as well
as what the implications of this emerging practice are and what as what the implications of this emerging practice are and what
alternatives may exist. The audience for this document is the alternatives may exist. The audience for this document is the
Internet community generally, including the IETF and IPv6 Internet community generally, including the IETF and IPv6
implementers. implementers.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 6, 2011. This Internet-Draft will expire on July 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5
3. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 7 3. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 7
4. Similarities to Split DNS . . . . . . . . . . . . . . . . . . 9 4. Similarities to Other DNS Operations . . . . . . . . . . . . . 9
5. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 10 4.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 9
5.1. Deploying DNS Whitelisting Universally . . . . . . . . . . 10 4.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 10
5.2. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 11 5. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 11
5.1. Deploying DNS Whitelisting Universally . . . . . . . . . . 11
5.2. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 12
6. What Problems Are DNS Whitelisting Implementers Trying To 6. What Problems Are DNS Whitelisting Implementers Trying To
Solve? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Solve? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 12 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 13
7.1. Architectural Implications . . . . . . . . . . . . . . . . 12 7.1. Architectural Implications . . . . . . . . . . . . . . . . 13
7.2. Public IPv6 Address Reachability Implications . . . . . . 13 7.2. Public IPv6 Address Reachability Implications . . . . . . 14
7.3. Operational Implications . . . . . . . . . . . . . . . . . 13 7.3. Operational Implications . . . . . . . . . . . . . . . . . 15
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 13 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 15
7.3.2. Authoritative DNS Server Operational Implications . . 13 7.3.2. Authoritative DNS Server Operational Implications . . 16
7.3.3. DNS Recursive Resolver Server Operational 7.3.3. DNS Recursive Resolver Server Operational
Implications . . . . . . . . . . . . . . . . . . . . . 14 Implications . . . . . . . . . . . . . . . . . . . . . 16
7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 15 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 17
7.3.5. Troubleshooting Implications . . . . . . . . . . . . . 15 7.3.5. Implications of Operational Momentum . . . . . . . . . 17
7.3.6. Additional Implications If Deployed On An Ad Hoc 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 18
Basis . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3.7. Additional Implications If Deployed On An Ad Hoc
7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 16 Basis . . . . . . . . . . . . . . . . . . . . . . . . 18
7.5. Technology Policy Implications . . . . . . . . . . . . . . 17 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 18
7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 18 7.5. Technology Policy Implications . . . . . . . . . . . . . . 19
8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 20
8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 18 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 18 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 21
8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 19 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 21
8.3.1. Solving Current End User IPv6 Impairments . . . . . . 19 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 21
9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.2. Authoritative DNS Response Consistency Considerations . . 20 9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.2. Authoritative DNS Response Consistency Considerations . . 23
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
[EDITORIAL: This is a rough first -00 draft. Some sections have not
yet been completed but will be soon. Suggestions on all parts of
this document are eagerly solicited.]
This document describes the emerging practice of whitelisting of DNS This document describes the emerging practice of whitelisting of DNS
AAAA resource records (RRs), or DNS whitelisting for short. It also AAAA resource records (RRs), or DNS whitelisting for short. It also
explores the implications of this emerging practice are and what explores the implications of this emerging practice are and what
alternatives may exist. alternatives may exist.
The practice of DNS whitelisting appears to have first been used by The practice of DNS whitelisting appears to have first been used by
major web content sites. These web site operators observed that when major web content sites, such as Google's various websites. These
they added AAAA RRs to their authoritative DNS servers that a small web site operators, or domain operators, observed that when they
added AAAA RRs to their authoritative DNS servers that a small
fraction of end users had slow or otherwise impaired access to a fraction of end users had slow or otherwise impaired access to a
given web site with both AAAA and A RRs. The fraction of users with given web site with both AAAA and A RRs. The fraction of users with
such impaired access has been estimated to be roughly 0.078% of total such impaired access has been estimated to be roughly 0.078% of total
Internet users [IETF 77 DNSOP WG Presentation] [Network World Article Internet users [IETF 77 DNSOP WG Presentation] [Network World Article
on IETF 77 DNSOP WG Presentation]. Thus, in an example Internet on IETF 77 DNSOP WG Presentation]. Thus, in an example Internet
Service Provider (ISP) network of 10 million users, approximately Service Provider (ISP) network of 10 million users, approximately
7,800 of those users may experience such impaired access. 7,800 of those users may experience such impaired access.
As a result of this impairment affecting end users of a given domain, As a result of this impairment affecting end users of a given domain,
a few large web site operators have begun to either implement DNS a few large domains have begun to either implement DNS whitelisting
whitelisting or strongly consider the implementation of DNS or strongly consider the implementation of DNS whitelisting [Network
whitelisting [Network World Article on DNS Whitelisting]. When World Article on DNS Whitelisting] [IPv6 Whitelist Operations]. When
implemented, DNS whitelisting in practice means that a domain's implemented, DNS whitelisting in practice means that a domain's
authoritative DNS will return a AAAA RR to DNS recursive resolvers authoritative DNS will return a AAAA RR to DNS recursive resolvers
[RFC1035] on the whitelist, while returning no AAAA RRs to DNS [RFC1035] on the whitelist, while returning no AAAA RRs to DNS
resolvers which are not on the whitelist. It is important to note resolvers which are not on the whitelist. It is important to note
that these web site operators are motivated to maintain a high- that these web site operators are motivated to maintain a high-
quality user experience for all of their users, and that they are quality user experience for all of their users, and that they are
attempting to shield users with impaired access from the symptoms of attempting to shield users with impaired access from the symptoms of
these impairments that would negatively affect their access to these impairments that would negatively affect their access to
certain websites and related Internet resources. certain websites and related Internet resources.
[EDITORIAL: change web site operators --> domain operators?]
However, critics of this emerging practice of DNS whitelisting have However, critics of this emerging practice of DNS whitelisting have
articulated several concerns. Among these are that this is a very articulated several concerns. Among these are that this is a very
different behavior from the current practice concerning the different behavior from the current practice concerning the
publishing of IPv4 address records, that it may create a two-tiered publishing of IPv4 address records, that it may create a two-tiered
Internet, that policies concerning whitelisting and de-whitelisting Internet, that policies concerning whitelisting and de-whitelisting
are opaque, that DNS whitelisting reduces interest in the deployment are opaque, that DNS whitelisting reduces interest in the deployment
of IPv6, that new operational and management burdens are created, and of IPv6, that new operational and management burdens are created, and
that the costs and negative implications of DNS whitelisting outweigh that the costs and negative implications of DNS whitelisting outweigh
the perceived benefits as compared to fixing underlying impairments. the perceived benefits as compared to fixing underlying impairments.
skipping to change at page 5, line 30 skipping to change at page 5, line 24
example.com. The ACL is then configured with the IPv4 and/or IPv6 example.com. The ACL is then configured with the IPv4 and/or IPv6
addresses of DNS recursive resolvers on the Internet, which have been addresses of DNS recursive resolvers on the Internet, which have been
authorized to be added to the ACL and to therefore receive AAAA RR authorized to be added to the ACL and to therefore receive AAAA RR
responses. These DNS recursive resolvers are operated by other responses. These DNS recursive resolvers are operated by other
parties, such as ISPs, universities, governments, businesses, parties, such as ISPs, universities, governments, businesses,
individual end users, etc. If a DNS recursive resolver IS NOT on the individual end users, etc. If a DNS recursive resolver IS NOT on the
ACL, then NO AAAA RRs with IPv6 addresses will be sent in response to ACL, then NO AAAA RRs with IPv6 addresses will be sent in response to
a query for a given hostname in the example.com domain. However, if a query for a given hostname in the example.com domain. However, if
a DNS recursive resolver IS on the ACL, then AAAA RRs with IPv6 a DNS recursive resolver IS on the ACL, then AAAA RRs with IPv6
addresses will be sent in response to a query for a given hostname in addresses will be sent in response to a query for a given hostname in
the example.com domain. the example.com domain. While these are not network-layer access
controls, they are nonetheless access controls that are a factor for
both end users and are directly related to the transition of one
network address family to another (IPv4 to IPv6).
In practice this generally means that a very small fraction of the In practice this generally means that a very small fraction of the
DNS recursive resolvers on the Internet can receive AAAA responses DNS recursive resolvers on the Internet can receive AAAA responses
with IPv6 addresses, which means that the large majority of DNS with IPv6 addresses, which means that the large majority of DNS
resolvers on the Internet will receive only A RRs with IPv4 resolvers on the Internet will receive only A RRs with IPv4
addresses. Thus, quite simply, the authoritative server hands out addresses. Thus, quite simply, the authoritative server hands out
different answers depending upon who is asking; with IPv4 and IPv6 different answers depending upon who is asking; with IPv4 and IPv6
records for some on the authorized whitelist, and only IPv4 records records for some on the authorized whitelist, and only IPv4 records
for everyone else. See Figure 1 and Figure 2 for two different for everyone else. See Figure 1 and Figure 2 for two different
visual descriptions of how this works in practice. visual descriptions of how this works in practice.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
ACL, then the response to that specific DNS recursive resolver ACL, then the response to that specific DNS recursive resolver
can contain only A (IPv4) address records and therefore cannot can contain only A (IPv4) address records and therefore cannot
contain AAAA (IPv6) address records. contain AAAA (IPv6) address records.
Figure 1: DNS Whitelisting - System Logic Figure 1: DNS Whitelisting - System Logic
--------------------------------------------------------------------- ---------------------------------------------------------------------
A query is sent from a DNS recursive resolver that IS NOT on the DNS A query is sent from a DNS recursive resolver that IS NOT on the DNS
whitelist: whitelist:
Request Request Request Request
www.example.com www.example.com www.example.com www.example.com
+-------------+ +-----------------+ AAAA +-------------+ AAAA +-----------------+
++--++ ---------> | RESOLVER | ---------> | www.example.com | ++--++ ---------> | RESOLVER | ---------> | www.example.com |
|| || | **IS NOT** | | IN A exists | || || A | **IS NOT** | A | IN A exists |
+-++--++-+ | ON | | IN AAAA exists | +-++--++-+ ---------> | ON | ---------> | IN AAAA exists |
+--------+ | example.com | | | +--------+ A | example.com | A | |
Host <--------- | WHITELIST | <--------- | | Host <--------- | WHITELIST | <--------- | |
Computer A Record +-------------+ A Record +-----------------+ Computer A Record +-------------+ A Record +-----------------+
Response DNS Recursive Response example.com Response DNS Recursive Response example.com
(IPv4) Resolver (IPv4) Authoritative (only IPv4) Resolver (only IPv4) Authoritative
#1 Server #1 Server
--------------------------------------------------------------------- ---------------------------------------------------------------------
A query is sent from a DNS recursive resolver that IS on the DNS A query is sent from a DNS recursive resolver that IS on the DNS
whitelist: whitelist:
Request Request Request Request
www.example.com www.example.com www.example.com www.example.com
+-------------+ +-----------------+ AAAA +-------------+ AAAA +-----------------+
++--++ ---------> | RESOLVER | ---------> | www.example.com | ++--++ ---------> | RESOLVER | ---------> | www.example.com |
|| || | **IS** | | IN A exists | || || A | **IS** | A | IN A exists |
+-++--++-+ | ON | | IN AAAA exists | +-++--++-+ ---------> | ON | ---------> | IN AAAA exists |
+--------+ | example.com | | | +--------+ AAAA | example.com | AAAA | |
Host <--------- | WHITELIST | <--------- | | Host <--------- | WHITELIST | <--------- | |
Computer A and AAAA +-------------+ A and AAAA +-----------------+ Computer A | | A | |
<--------- | | <--------- | |
A and AAAA +-------------+ A and AAAA +-----------------+
Record DNS Recursive Record example.com Record DNS Recursive Record example.com
Responses Resolver Responses Authoritative Responses Resolver Responses Authoritative
(IPv4+IPv6) #2 (IPv4+IPv6) Server (IPv4+IPv6) #2 (IPv4+IPv6) Server
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 2: DNS Whitelisting - Functional Diagram Figure 2: DNS Whitelisting - Functional Diagram
3. Concerns Regarding DNS Whitelisting 3. Concerns Regarding DNS Whitelisting
There are a number of potential implications relating to DNS There are a number of potential implications relating to DNS
whitelisting, which have raised various concerns in some parts of the whitelisting, which have raised various concerns in some parts of the
Internet community. Many of those potential implications are Internet community. Many of those potential implications are
described in Section 7. described in Section 7.
Some parties in the Internet community are concerned that this Some parties in the Internet community, including ISPs like Comcast,
emerging practice of DNS whitelisting for IPv6 address records could are concerned that this emerging practice of DNS whitelisting for
represent a departure from the generally accepted practices regarding IPv6 address records could represent a departure from the generally
IPv4 address records in the DNS on the Internet. These parties accepted practices regarding IPv4 address records in the DNS on the
explain their belief that for A records, containing IPv4 addresses, Internet [IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?].
once an authoritative server operator adds the A record to the DNS, These parties explain their belief that for A records, containing
then any DNS recursive resolver on the Internet can receive that A IPv4 addresses, once an authoritative server operator adds the A
record in response to a query. By extension, this means that any of record to the DNS, then any DNS recursive resolver on the Internet
the hosts connected to any of these DNS recursive resolvers can can receive that A record in response to a query. By extension, this
receive the IPv4 address records for a given FQDN. This enables new means that any of the hosts connected to any of these DNS recursive
server hosts which are connected to the Internet, and for which a resolvers can receive the IPv4 address records for a given FQDN.
fully qualified domain name (FQDN) such as www.example.com has been This enables new server hosts which are connected to the Internet,
added to the DNS with an IPv4 address record, to be almost and for which a fully qualified domain name (FQDN) such as
immediately reachable by any host on the Internet. In this case, www.example.com has been added to the DNS with an IPv4 address
these new servers hosts become more and more widely accessible as new record, to be almost immediately reachable by any host on the
networks and new end user hosts connect to the Internet over time Internet. In this case, these new servers hosts become more and more
[EDITORIAL: consider reference to network effects]. It also means widely accessible as new networks and new end user hosts connect to
that the new server hosts do not need to know about these new the Internet over time [EDITORIAL: consider reference to network
networks and new end user hosts in order to make their content and effects]. It also means that the new server hosts do not need to
applications available to them, in essence that each end in this end- know about these new networks and new end user hosts in order to make
to-end model is responsible for connecting to the Internet and once their content and applications available to them, in essence that
they have done so they can connect to each other without additional each end in this end-to-end model is responsible for connecting to
impediments or middle networks or intervening networks or servers the Internet and once they have done so they can connect to each
knowing about these end points and whether one is allowed to contact other without additional impediments or middle networks or
the other. intervening networks or servers knowing about these end points and
whether one is allowed to contact the other.
In contrast, these parties are concerned that DNS whitelisting may In contrast, these parties are concerned that DNS whitelisting may
fundamentally change this model. As a result, in this altered end- fundamentally change this model. As a result, in this altered end-
to-end model, one end (where the end user is located) cannot readily to-end model, one end (where the end user is located) cannot readily
connect to the other end (where the content is located), without connect to the other end (where the content is located), without
parts of the middle used by one end being known by the other end and parts of the middle used by one end being known by the other end and
approved for access to that end. Thus, as new networks connect to approved for access to that end. Thus, as new networks connect to
the Internet over time, those networks need to contact any and all the Internet over time, those networks need to contact any and all
domains which have implemented DNS whitelisting in order to apply to domains which have implemented DNS whitelisting in order to apply to
be added to their DNS whitelist, in the hopes of making the content be added to their DNS whitelist, in the hopes of making the content
skipping to change at page 9, line 18 skipping to change at page 9, line 21
that this practice also could disrupt the continued increase in that this practice also could disrupt the continued increase in
Internet adoption by end users if they cannot simply access new Internet adoption by end users if they cannot simply access new
content and applications but must instead contact the operator of content and applications but must instead contact the operator of
their DNS recursive resolver, such as their ISP or another third their DNS recursive resolver, such as their ISP or another third
party, to have their DNS recursive resolver authorized for access to party, to have their DNS recursive resolver authorized for access to
the content or applications that interests them. Meanwhile, these the content or applications that interests them. Meanwhile, these
parties say, over 99.9% of all other end users that are also using parties say, over 99.9% of all other end users that are also using
that same network or DNS recursive resolver are unable to access the that same network or DNS recursive resolver are unable to access the
IPv6-based content, despite their experience being a positive one. IPv6-based content, despite their experience being a positive one.
[EDITORIAL: Are there additional concerns to add here?] 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.
4. Similarities to Split DNS 4. Similarities to Other DNS Operations
DNS whitelisting as described herein is in some ways similar to so- Some aspects of DNS whitelisting may be considered similar in some
called split DNS, which is briefly described in Section 3.8 of ways to other common DNS operational techniques, which is explored
[RFC2775]. When split DNS is used, the authoritative DNS server briefly below.
returns different responses depending upon what host has sent the
query. While [RFC2775] notes the typical use of split DNS is to 4.1. Similarities to Split DNS
provide one answer to hosts on an Intranet and a different answer to
hosts on the Internet, the essence is that different answers are DNS whitelisting has some similarities to so-called split DNS, which
provided to hosts on different networks. This is basically the way is briefly described in Section 3.8 of [RFC2775]. When split DNS is
that DNS whitelisting works, in so far as hosts of different used, the authoritative DNS server returns different responses
networks, which use different DNS recursive resolvers, receive depending upon what host has sent the query. While [RFC2775] notes
different answers if one DNS recursive resolver is on the whitelist the typical use of split DNS is to provide one answer to hosts on an
and the other is not. Thus, in a way, DNS whitelisting could in some Intranet and a different answer to hosts on the Internet, the essence
ways be considered split DNS on the public Internet, though with some is that different answers are provided to hosts on different
differences. networks. This is basically the way that DNS whitelisting works, in
so far as hosts of different networks, which use different DNS
recursive resolvers, receive different answers if one DNS recursive
resolver is on the whitelist and the other is not. Thus, in a way,
DNS whitelisting could in some ways be considered split DNS on the
public Internet, though with some differences.
In [RFC2956], Internet transparency and Internet fragmentation In [RFC2956], Internet transparency and Internet fragmentation
concerns regarding split DNS are detailed in Section 2.1. [RFC2956] concerns regarding split DNS are detailed in Section 2.1. [RFC2956]
further notes in Section 2.7, concerns regarding split DNS and that further notes in Section 2.7, concerns regarding split DNS and that
it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint
identifiers more complex." Section 3.5 of [RFC2956] further identifiers more complex." Section 3.5 of [RFC2956] further
recommends that maintaining a stable approach to DNS operations is recommends that maintaining a stable approach to DNS operations is
key during transitions such as the one to IPv6 that is underway now, key during transitions such as the one to IPv6 that is underway now,
stating that "Operational stability of DNS is paramount, especially stating that "Operational stability of DNS is paramount, especially
during a transition of the network layer, and both IPv6 and some during a transition of the network layer, and both IPv6 and some
network address translation techniques place a heavier burden on network address translation techniques place a heavier burden on
DNS." DNS."
4.2. Similarities to DNS Load Balancing
DNS whitelisting also has some similarities to DNS load balancing.
There are many ways that DNS load balancing can be performed, and of
course this can mean many things to different people. In one
example, multiple IP address resource records (A or AAAA) can be
added to the DNS to resolve a given FQDN, which is referred to as DNS
round robin [REFERENCE AVAILABLE?]. In another example, one or more
of the IP address resource records in the DNS will direct traffic to
a load balancer [REFERENCE AVAILABLE?]. That load balancer, 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
addresses. In cases where private IPv4 addresses are used [RFC1918],
as well as when public IP addresses are used, those end hosts may not
be directly reachable without passing through the load balancer first
. As such, while the IP address resource records have been added to
the DNS, the end hosts are not necessarily directly reachable, which
is in a small way similar to one aspect of DNS whitelisting. In
addition, a geographically-aware authoritative DNS server may be
used, as is common with Content Delivery Networks (CDNs), whereby the
IP address resource records returned to a resolver in response to a
query will vary based on the estimated geographic location of the
resolver [REFERENCE AVAILABLE?]. CDNs perform this function in order
to attempt to direct hosts to connect to the nearest content cache.
As a result, one can see some similarities with DNS whitelisting
insofar as different IP address resource records are returned to
resolvers based on the IP address of each resolver (or other imputed
factors related to that IP address). However, what is different of
course, if that in this case the resolvers are not necessarily
blocked from receiving DNS responses containing an entire class of
addresses; this load balancing function strives to perform a content
location-improvement function and not an access control function.
5. Likely Deployment Scenarios 5. Likely Deployment Scenarios
In considering how DNS whitelisting may emerge more widely, there are In considering how DNS whitelisting may emerge more widely, there are
two likely deployment scenarios, which are explored below. two likely deployment scenarios, which are explored below.
In either of these likely deployment scenarios below, it is possible
that reputable third parties could create and maintain these DNS
whitelists, in much the same way that blacklists are used for
reducing email spam. In this email example, 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. Thus, a similar model could emerge for DNS
whitelisting, whether deployment occurs universally or on an ad hoc
basis.
5.1. Deploying DNS Whitelisting Universally 5.1. Deploying DNS Whitelisting Universally
The least likely deployment scenario is one where DNS whitelisting The least likely deployment scenario is one where DNS whitelisting
becomes a standardized process across all authoritative DNS servers, becomes a standardized process across all authoritative DNS servers,
across the entire Internet. While this scenario is the least likely, across the entire Internet. While this scenario is the least likely,
due to some parties not sharing the concerns that have so far due to some parties not sharing the concerns that have so far
motivated the use of DNS whitelisting, it is nonetheless conceivable motivated the use of DNS whitelisting, it is nonetheless conceivable
that it could be one of the ways in which DNS whitelisting may be that it could be one of the ways in which DNS whitelisting may be
deployed. deployed.
skipping to change at page 10, line 50 skipping to change at page 12, line 17
First, parties performing troubleshooting would not have to determine First, parties performing troubleshooting would not have to determine
whether or not DNS whitelisting was being used, as it always would be whether or not DNS whitelisting was being used, as it always would be
in use. In addition, if universally deployed, it is possible that in use. In addition, if universally deployed, it is possible that
the criteria for being added to or removed from a DNS whitelist could the criteria for being added to or removed from a DNS whitelist could
be standardized across the entire Internet. Nevertheless, even if be standardized across the entire Internet. Nevertheless, even if
uniform DNS whitelisting policies were not standardized, is also uniform DNS whitelisting policies were not standardized, is also
possible that a central registry of these policies could be developed possible that a central registry of these policies could be developed
and deployed in order to make it easier to discover them, a key part and deployed in order to make it easier to discover them, a key part
of achieving transparency regarding DNS whitelisting. of achieving transparency regarding DNS whitelisting.
[EDITORIAL: Are there additional benefits or challenges to add here?]
5.2. Deploying DNS Whitelisting On An Ad Hoc Basis 5.2. Deploying DNS Whitelisting On An Ad Hoc Basis
This is the most likely deployment scenario for DNS whitelisting, as This is the most likely deployment scenario for DNS whitelisting, as
it seems today, is where some interested parties engage in DNS it seems today, is where some interested parties engage in DNS
whitelisting but many or most others do not do so. What can make whitelisting but many or most others do not do so. What can make
this scenario challenging from the standpoint of a DNS recursive this scenario challenging from the standpoint of a DNS recursive
resolver operator is determining which domains implement DNS resolver operator is determining which domains implement DNS
whitelisting, particularly since a domain may not do so as they whitelisting, particularly since a domain may not do so as they
initially transition to IPv6, and may instead do so later. Thus, a initially transition to IPv6, and may instead do so later. Thus, a
DNS recursive resolver operator may initially believe that they can DNS recursive resolver operator may initially believe that they can
skipping to change at page 11, line 37 skipping to change at page 13, line 5
but have restricted query access via DNS whitelisting. As a result, but have restricted query access via DNS whitelisting. As a result,
discovering which domains implement DNS whitelisting, in order to discovering which domains implement DNS whitelisting, in order to
differentiate them from those that do not, is likely to be differentiate them from those that do not, is likely to be
challenging. challenging.
On the other hand, one benefit of DNS whitelisting being deployed on On the other hand, one benefit of DNS whitelisting being deployed on
an ad hoc basis is that only the domains that are interested in doing an ad hoc basis is that only the domains that are interested in doing
so would have to upgrade their authoritative DNS servers in order to so would have to upgrade their authoritative DNS servers in order to
implement the ACLs necessary to perform DNS whitelisting. implement the ACLs necessary to perform DNS whitelisting.
[EDITORIAL: Additional benefits or challenges to add?]
6. What Problems Are DNS Whitelisting Implementers Trying To Solve? 6. What Problems Are DNS Whitelisting Implementers Trying To Solve?
As noted in Section 1, domains which implement DNS whitelisting are As noted in Section 1, domains which implement DNS whitelisting are
attempting to protect a few users of their domain, which happen to attempting to protect a few users of their domain, which happen to
have impaired IPv6 access, from having a negative end user have impaired IPv6 access, from having a negative end user
experience. While it is outside the scope of this document to experience. While it is outside the scope of this document to
explore the various reasons why a particular user may experience explore the various reasons why a particular user may experience
impaired IPv6 access, for the users which experience this it is a impaired IPv6 access, for the users which experience this it is a
very real effect and would of course affect access to all or most very real effect and would of course affect access to all or most
IPv4 and IPv6 dual stack servers. This negative end user experience IPv4 and IPv6 dual stack servers. This negative end user experience
can range from someone slower than usual (as compared to native IPv4- can range from someone slower than usual (as compared to native IPv4-
based access), to extremely slow, to no access to the domain based access), to extremely slow, to no access to the domain
whatsoever. whatsoever.
Thus, parties which implement DNS whitelisting are attempting to Thus, parties which implement DNS whitelisting are attempting to
provide a good experience to these end users. While one can debate provide a good experience to these end users. While one can debate
whether DNS whitelisting is the optimal solution, it is quite clear whether DNS whitelisting is the optimal solution, it is quite clear
that DNS whitelisting implementers are extremely interested in the that DNS whitelisting implementers are extremely interested in the
performance of their services for end users as a primary motivation. performance of their services for end users as a primary motivation.
[EDITORIAL 1: More motivations to add?] In addition, Google has noted that they have received requests to not
send DNS responses with AAAA resource records to particular
[EDITORIAL 2:Any good external references to consider adding?] resolvers. In these cases, the operators of those recursive
resolvers have expressed a concern that their IPv6 network
infrastructure is not yet ready to handle the traffic volume which
may be associated with the hosts in their network connecting to
Google websites, such as YouTube. In this case, this is clearly a
temporary concern relating to the deployment of IP network
infrastructure on the part of networks with end user hosts, rather
than a long-term concern. These end user networks may also have
other tools at their disposal in order to address this, including
applying rules to network equipment such as routers and firewalls
(this will necessarily vary by the type of network, as well as the
technologies used and the design of a given network).
7. Implications of DNS Whitelisting 7. Implications of DNS Whitelisting
There are many potential implications of DNS whitelisting. In the There are many potential implications of DNS whitelisting. In the
sections below, the key potential implications are listed in some sections below, the key potential implications are listed in some
detail. detail.
7.1. Architectural Implications 7.1. Architectural Implications
DNS whitelisting could be perceived as somewhat modifying the end-to- DNS whitelisting could be perceived as somewhat modifying the end-to-
end model that prevails on the IPv4 Internet today. This approach end model and/or the general notion of the architecture that prevails
moves additional access control information and policies into the on the Internet today. This is because this approach moves
middle of the network on the IPv6-addressed Internet, which did not additional access control information and policies into the middle of
the DNS resolution path on the IPv6-addressed Internet, which did not
exist before on the IPv4-addressed Internet. This could raise some exist before on the IPv4-addressed Internet. This could raise some
risks noted in [RFC3724], which in explaining the history of the end- risks noted in [RFC3724], which in explaining the history of the end-
to-end principle [RFC1958] explains that one of the goals is to to-end principle [RFC1958] explains 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. the Internet. In this case, the middle network should be understood
to mean anything other than the end hosts involved in communicating
with one another. Obviously some state, policies, and other
functions have always been necessary to enable such end-to-end
communication, but the goal of the approach has been to minimize this
to the greatest extent possible.
It is also possible that DNS whitelisting could place at risk some of It is also possible that DNS whitelisting could place at risk some of
the benefits of the end-to-end principle, as listed in Section 4.1 of the benefits of the end-to-end principle, as listed in Section 4.1 of
[RFC3724], such as protection of innovation. Further, while [RFC3724], such as protection of innovation. Further, while
[RFC3234] details issues and concerns regarding so-called [RFC3234] details issues and concerns regarding so-called
middleboxes, there may be parallels to DNS whitelisting, especially middleboxes, there may be parallels to DNS whitelisting, especially
concerning modified DNS servers noted in Section 2.16 of [RFC3234], concerning modified DNS servers noted in Section 2.16 of [RFC3234],
and more general concerns noted in Section 1.2 of [RFC3234] about the and more general concerns noted in Section 1.2 of [RFC3234] about the
introduction of new failure modes, that configuration is no longer introduction of new failure modes, that configuration is no longer
limited to two ends of a session, and that diagnosis of failures and limited to two ends of a session, and that diagnosis of failures and
skipping to change at page 13, line 15 skipping to change at page 14, line 46
In order to explore and better understand these high-level In order to explore and better understand these high-level
architectural implications and concerns in more detail, the following architectural implications and concerns in more detail, the following
sections explore more specific potential implications. sections explore more specific potential implications.
7.2. Public IPv6 Address Reachability Implications 7.2. Public IPv6 Address Reachability Implications
The predominant experience of end user hosts and servers on the IPv4- The predominant experience of end user hosts and servers on the IPv4-
addressed Internet today is that, very generally speaking, when a new addressed Internet today is that, very generally speaking, when a new
server with a public IPv4 address is added, that it is then globally server with a public IPv4 address is added, that it is then globally
accessible by IPv4-addressed hosts. For the purposes of this accessible by IPv4-addressed hosts. Of course, this is a
document, that concept can be considered "pervasive reachability". generalization and in Section 4 there are examples of common cases
It has so far been assumed that the same expectations of reachability where this may not necessarily be the case. In any case, for the
would exist in the IPv6-addressed Internet. However, if DNS purposes of this document, that concept of accessibility can be
whitelisting is deployed, this will not be the case since only end considered "pervasive reachability". It has so far been assumed that
user hosts using DNS recursive resolvers which have been added to the the same expectations of pervasive reachability would exist in the
ACL of a given domain using DNS whitelisting would be able to reach IPv6-addressed Internet. However, if DNS whitelisting is deployed,
new servers in that given domain via IPv6 addresses. this will not be the case since only end user hosts using DNS
recursive resolvers which have been added to the ACL of a given
domain using DNS whitelisting would be able to reach new servers in
that given domain via IPv6 addresses. Thus, the expectation of any
end user host being able to connect to any server (essentially both
hosts, just at either end of the network), defined here as "pervasive
reachability", will change to "restricted reachability" with IPv6.
Thus, the expectation of any end user host being able to connect to In addition, establishing DNS whitelisting as an accepted practice in
any server (essentially both hosts, just at either end of the the early phases of mass IPv6 deployment could well establish DNS
network), defined here as "pervasive reachability", will change to whitelisting as an integral part of how IPv6 is deployed globally.
"restricted reachability" with IPv6. As a result, it is then possible that DNS whitelisting could live on
for decades on the Internet as a key foundational element of the
Internet of the future that we will all live with for a long time.
[EDITORIAL: Additional implications?] However, it is a critical to understand that the concept of
reachability described above depends upon a knowledge or awareness of
an address in the DNS. Thus, in order to establish reachability to
an end point, a host is dependent upon looking up an IP address in
the DNS when a FQDN is used. Thus, when DNS whitelisting is used, it
is quite likely the case that a end user host could ping a example
server host, even though the FQDN associated with that server host is
restricted via a DNS whitelist. But since most Internet applications
and hosts such as web servers depend upon the DNS, and as end users
connect to FQDNs such as www.example.com and do not remember or wish
to type in an IP address, the notion of reachability described here
should be understood to include knowledge how to associate a name
with a network address.
7.3. Operational Implications 7.3. Operational Implications
This section explores some of the operationally related implications This section explores some of the operationally related implications
which may occur as a result of, related to, or necessary when which may occur as a result of, related to, or necessary when
engaging in the practice of DNS whitelisting. engaging in the practice of DNS whitelisting.
7.3.1. De-Whitelisting May Occur 7.3.1. De-Whitelisting May Occur
If it is possible for a DNS recursive resolver to be added to a If it is possible for a DNS recursive resolver to be added to a
whitelist, then it is also possible for that resolver to be removed whitelist, then it is also possible for that resolver to be removed
from the whitelist, also known as de-whitelisting. Since de- from the whitelist, also known as de-whitelisting. Since de-
whitelisting can occur, whether through a decision by the whitelisting can occur, whether through a decision by the
authoritative server operator or the domain owner, or even due to a authoritative server operator or the domain owner, or even due to a
technical error, an operator of a DNS recursive resolver will have technical error, an operator of a DNS recursive resolver will have
new operational and monitoring requirements and/or needs as noted in new operational and monitoring requirements and/or needs as noted in
Section 7.3.3, Section 7.3.4, Section 7.3.5, and Section 7.5. Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.
7.3.2. Authoritative DNS Server Operational Implications 7.3.2. Authoritative DNS Server Operational Implications
Operators of authoritative servers may need to maintain an ACL a Operators of authoritative servers may need to maintain an ACL a
server-wide basis affecting all domains, on a domain-by-domain basis, server-wide basis affecting all domains, on a domain-by-domain basis,
as well as on a combination of the two. As a result, operational as well as on a combination of the two. As a result, operational
practices and software capabilities may need to be developed in order practices and software capabilities may need to be developed in order
to support such functionality. In addition, processes may need to be to support such functionality. In addition, processes may need to be
put in place to protect against inadvertently adding or removing IP put in place to protect against inadvertently adding or removing IP
addresses, as well as systems and/or processes to respond to such addresses, as well as systems and/or processes to respond to such
incidents if and when they occur. For example, a system may be incidents if and when they occur. For example, a system may be
needed to record DNS whitelisting requests, report on their status needed to record DNS whitelisting requests, report on their status
along a workflow, add IP addresses when whitelisting has been along a workflow, add IP addresses when whitelisting has been
approved, remove IP addresses when they have been de-whitelisted, log approved, remove IP addresses when they have been de-whitelisted, log
the personnel involved and timing of changes, schedule changes to the personnel involved and timing of changes, schedule changes to
occur in the future, and to roll back any inadvertent changes. occur in the future, and to roll back any inadvertent changes.
Such operators may also need implement new forms of monitoring in Such operators may also need implement new forms of monitoring in
order to apply change control, as noted briefly in Section 7.3.4. order to apply change control, as noted briefly in Section 7.3.4.
[EDITORIAL: Additional implications?]
7.3.3. DNS Recursive Resolver Server Operational Implications 7.3.3. DNS Recursive Resolver Server Operational Implications
Operators of DNS recursive resolvers, which may include ISPs, Operators of DNS recursive resolvers, which may include ISPs,
enterprises, universities, governments, individual end users, and enterprises, universities, governments, individual end users, and
many other parties, are likely to need to implement new forms of many other parties, are likely to need to implement new forms of
monitoring, as noted briefly in Section 7.3.4. But more critically, monitoring, as noted briefly in Section 7.3.4. But more critically,
such operators may need to add people, processes, and systems in such operators may need to add people, processes, and systems in
order to manage countless DNS whitelisting applications, for all order to manage countless DNS whitelisting applications, for all
domains that the end users of such servers are interested in now or domains that the end users of such servers are interested in now or
in which they may be interested in the future. As such anticipation in which they may be interested in the future. As such anticipation
skipping to change at page 15, line 11 skipping to change at page 17, line 13
domain can be added, and the continued strong growth in the numbers domain can be added, and the continued strong growth in the numbers
of new domains, readers should not underestimate the potential of new domains, readers should not underestimate the potential
significance in personnel and expense that this could represent for significance in personnel and expense that this could represent for
such operators. In addition, it is likely that systems and personnel such operators. In addition, it is likely that systems and personnel
may also be needed to handle new end user requests for domains for may also be needed to handle new end user requests for domains for
which to apply for DNS whitelisting, and/or inquiries into the status which to apply for DNS whitelisting, and/or inquiries into the status
of a whitelisting application, reports of de-whitelisting incidents, of a whitelisting application, reports of de-whitelisting incidents,
general inquiries related to DNS whitelisting, and requests for DNS general inquiries related to DNS whitelisting, and requests for DNS
whitelisting-related troubleshooting by these end users. whitelisting-related troubleshooting by these end users.
[EDITORIAL: Additional implications?]
7.3.4. Monitoring Implications 7.3.4. Monitoring Implications
Once a DNS recursive resolver has been whitelisted for a particular Once a DNS recursive resolver has been whitelisted for a particular
domain, then the operator of that DNS recursive resolver may need to domain, then the operator of that DNS recursive resolver may need to
implement monitoring in order to detect the possible loss of implement monitoring in order to detect the possible loss of
whitelisting status in the future. This DNS recursive resolver whitelisting status in the future. This DNS recursive resolver
operator could configure a monitor to check for a AAAA response in operator could configure a monitor to check for a AAAA response in
the whitelisted domain, as a check to validate continued status on the whitelisted domain, as a check to validate continued status on
the DNS whitelist. The monitor could then trigger an alert if at the DNS whitelist. The monitor could then trigger an alert if at
some point the AAAA responses were no longer received, so that some point the AAAA responses were no longer received, so that
operations personnel could begin troubleshooting, as outlined in operations personnel could begin troubleshooting, as outlined in
Section 7.3.5. Section 7.3.6.
Also, authoritative DNS server operators are likely to need to Also, authoritative DNS server operators are likely to need to
implement new forms of monitoring. In this case, they may desire to implement new forms of monitoring. In this case, they may desire to
monitor for significant changes in the size of the whitelist within a monitor for significant changes in the size of the whitelist within a
certain period of time, which might be indicative of a technical certain period of time, which might be indicative of a technical
error such as the entire ACL being removed. These operators may also error such as the entire ACL being removed. These operators may also
wish to monitor their workflow process for reviewing and acting upon wish to monitor their workflow process for reviewing and acting upon
DNS whitelisting applications and appeals, potentially measuring and DNS whitelisting applications and appeals, potentially measuring and
reporting on service level commitments regarding the time an reporting on service level commitments regarding the time an
application or appeal can remain at each step of the process, application or appeal can remain at each step of the process,
regardless of whether or not such information is shared with parties regardless of whether or not such information is shared with parties
other than that authoritative DNS server operator. other than that authoritative DNS server operator.
These are but a few examples of the types of monitoring that may be These are but a few examples of the types of monitoring that may be
called for as a result of DNS whitelisting, among what are likely called for as a result of DNS whitelisting, among what are likely
many other types and variations. many other types and variations.
[EDITORIAL: Additional implications?] 7.3.5. Implications of Operational Momentum
7.3.5. Troubleshooting Implications It seems plausible that once DNS whitelisting is implemented it will
be very difficult to deprecate such technical and operational
practices. This assumption is based in an understanding of human
nature, not to mention physics. For example, as Sir Issac Newton
noted, "Every object in a state of uniform motion tends to remain in
that state of motion unless an external force is applied to it"
[Newton's Laws of Motion]. Thus, once DNS whitelisting is
implemented it is quite likely that it would take considerable effort
to deprecate the practice and remove it everywhere on the Internet -
it will otherwise simply remain in place in perpetuity. To better
illustrate this point, one could consider in one example (of many)
that here are likely many email servers continuing to attempt to
query or otherwise check anti-spam DNS blocklists which have long ago
ceased to exist.
7.3.6. Troubleshooting Implications
The implications of DNS whitelisted present many challenges, which The implications of DNS whitelisted present many challenges, which
have been detailed in Section 7. These challenges may negatively have been detailed in Section 7. These challenges may negatively
affect the end users' ability to troubleshoot, as well as that of DNS affect the end users' ability to troubleshoot, as well as that of DNS
recursive resolver operators, ISPs, content providers, domain owners recursive resolver operators, ISPs, content providers, domain owners
(where they may be different from the operator of the authoritative (where they may be different from the operator of the authoritative
DNS server for their domain), and other third parties. This may make DNS server for their domain), and other third parties. This may make
the process of determining why a server is not reachable the process of determining why a server is not reachable
significantly more complex. significantly more complex.
[SECTION INCOMPLETE - MIGHT LIKE TO ADD SOME EXAMPLES HERE] 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis
[EDITORIAL: Additional implications?]
7.3.6. Additional Implications If Deployed On An Ad Hoc Basis
[SECTION INCOMPLETE - IS THIS NEEDED? - PLACEHOLDER FOR NOW]
[EDITORIAL: Additional implications?] Additional implications, should this be deployed on an ad hoc basis,
could include scalability problems relating to operational processes,
monitoring, and ACL updates. In particular, it seems quite likely
that as the number of domains that are whitelisted increases, as well
as the number of IPv6-capable networks requesting to be whitelisted,
that there is an increased likelihood of configuration and other
operational errors, especially with respect to the ACLs themselves.
It is also unclear when and if it would be appropriate to change from
whitelisting to blacklisting, and whether/how this could feasibly be
coordinated across the Internet, which may be proposed when a
majority of networks (or allocated IPv6 address blocks) have been
whitelisted. Finally, some parties implementing DNS whitelisting
consider this to be a temporary measure. As such, it is not clear
how these parties will judge the network conditions to have changed
sufficiently to justify disabling DNS whitelisting and/or what the
process and timing will be in order to turn off and stop this
practice.
7.4. Homogeneity May Be Encouraged 7.4. Homogeneity May Be Encouraged
A broad trend which has existed on the Internet appears to be a move A broad trend which has existed on the Internet appears to be a move
towards increasing levels of heterogeneity. One manifestation of towards increasing levels of heterogeneity. One manifestation of
this is in an increasing number, variety, and customization of end this is in an increasing number, variety, and customization of end
user hosts, including home network, operating systems, client user hosts, including home network, operating systems, client
software, home network devices, and personal computing devices. This software, home network devices, and personal computing devices. This
trend appears to have had a positive effect on the development and trend appears to have had a positive effect on the development and
growth of the Internet. A key facet of this that has evolved is the growth of the Internet. A key facet of this that has evolved is the
skipping to change at page 16, line 45 skipping to change at page 19, line 22
the encouragement of a reversal of this trend, which would be a move the encouragement of a reversal of this trend, which would be a move
back towards greater levels of homogeneity. In this case, a domain back towards greater levels of homogeneity. In this case, a domain
owner which has implemented DNS whitelisting may prefer greater owner which has implemented DNS whitelisting may prefer greater
levels of control be exerted over end user hosts (which broadly levels of control be exerted over end user hosts (which broadly
includes all types of end user software and hardware) in order to includes all types of end user software and hardware) in order to
attempt to enforce technical standards relating to establishing attempt to enforce technical standards relating to establishing
certain IPv6 capabilities or the enforcing the elimination of or certain IPv6 capabilities or the enforcing the elimination of or
restriction of certain end user hosts. While the domain operator is restriction of certain end user hosts. While the domain operator is
attempting to protect, maintain, and/or optimize the end user attempting to protect, maintain, and/or optimize the end user
experience for their domain, the collective result of many domains experience for their domain, the collective result of many domains
implementing DNS whitelisting, or even a few important domains implementing DNS whitelisting, or even a few major domains (meaning
domains which are a major destination of Internet traffic)
implementing DNS whitelisting, may be to encourage a return to more implementing DNS whitelisting, may be to encourage a return to more
homogenous and/or controlled end user hosts. Unfortunately, this homogenous and/or controlled end user hosts. Unfortunately, this
could have unintended side effects on and counter-productive could have unintended side effects on and counter-productive
implications for future innovation at the edges of the network. implications for future innovation at the edges of the network.
7.5. Technology Policy Implications 7.5. Technology Policy Implications
A key technology policy implication concerns the policies relating to A key technology policy implication concerns the policies relating to
the process of reviewing an application for DNS whitelisting, and the the process of reviewing an application for DNS whitelisting, and the
decision-making process regarding whitelisting for a domain. decision-making process regarding whitelisting for a domain.
skipping to change at page 17, line 45 skipping to change at page 20, line 21
become involved in or express opinions concerning whitelisting and/or become involved in or express opinions concerning whitelisting and/or
de-whitelisting decisions. Lastly, it is conceivable that any of de-whitelisting decisions. Lastly, it is conceivable that any of
these interested parties or other related stakeholders may seek these interested parties or other related stakeholders may seek
redress outside of the process a domain has establishing for DNS redress outside of the process a domain has establishing for DNS
whitelisting and de-whitelisting. whitelisting and de-whitelisting.
A final concern is that decisions relating to whitelisting and de- A final concern is that decisions relating to whitelisting and de-
whitelisting may occur as an expression of other commercial, whitelisting may occur as an expression of other commercial,
governmental, and/or cultural conflicts, given the new control point governmental, and/or cultural conflicts, given the new control point
which has be established with DNS whitelisting. For example, in one which has be established with DNS whitelisting. For example, in one
imagined scenario, it may be conceivable that one government is imagined scenario, a domain could withhold adding a network to their
unhappy with a news story or book published in a particular country, DNS whitelisting unless that network agreed to some sort of financial
and that this government may retaliate against or protest this news payment, legal agreement, agreement to sever a relationship with a
story or book by requiring domains operating within that government's competitor of the domain, etc. In another example, a music-oriented
territory to de-whitelist commercial, governmental, or other entities domain may be engaged in some sort of dispute with an academic
involved in or related to (however tangentially) publishing the news network concerning copyright infringement concerns within that
story or book. By the same token, a news site operating in multiple network, and may choose to de-whitelist that network as a negotiating
territories may be unhappy with governmental policies in one technique in some sort of commercial discussion. In a final example,
particular territory and may choose to express dissatisfaction in a major email domain may choose to de-whitelist a network due to that
that territory by de-whitelisting commercial, governmental, or other network sending some large volume of spam, which would have the
entities in that territory. Thus, it seems possible that DNS effect of preventing other, end users on that network from using
whitelisting and de-whitelisting could become a vehicle for other, non-email-related applications within that domain. Thus, it
adjudicating other disputes, and that this may well have intended and seems possible that DNS whitelisting and de-whitelisting could become
unintended consequences for end users which are affected by such a vehicle for adjudicating other disputes, and that this may well
decisions and are unlikely to be able to express a strong voice in have intended and unintended consequences for end users which are
such decisions. affected by such decisions and are unlikely to be able to express a
strong voice in such decisions.
7.6. IPv6 Adoption Implications 7.6. IPv6 Adoption Implications
As noted in Section 3, the implications of DNS whitelisting may drive As noted in Section 3, the implications of DNS whitelisting may drive
end users and/or networks to delay, postpone, or cancel adoption of end users and/or networks to delay, postpone, or cancel adoption of
IPv6, or to actively seek alternatives to it. Such alternatives may IPv6, or to actively seek alternatives to it. Such alternatives may
include the use of multi-layer network address translation (NAT) include the use of multi-layer network address translation (NAT)
techniques like NAT444 [I-D.shirasaki-nat444], which these parties techniques like NAT444 [I-D.shirasaki-nat444], which these parties
may decide to pursue on a long-term basis to avoid the perceived may decide to pursue on a long-term basis to avoid the perceived
costs and aggravations related to DNS whitelisting. This could of costs and aggravations related to DNS whitelisting. This could of
course come at the very time that the Internet community is trying to course come at the very time that the Internet community is trying to
get these very same parties interested in IPv6 and motivated to begin get these very same parties interested in IPv6 and motivated to begin
the transition to IPv6. As a result, parties concerned over the the transition to IPv6. As a result, parties that are likely to be
negative implications of DNS whitelisting have said they are very concerned over the negative implications of DNS whitelisting could
concerned of the negative effects that this practice could have on logically be concerned of the negative effects that this practice
the adoption of IPv6 if it became widespread or was adopted by key could have on the adoption of IPv6 if it became widespread or was
parties in the Internet ecosystem. adopted by majors Internet domains or other major parties in the
Internet ecosystem.
[EDITORIAL: Additional implications?]
8. Solutions 8. Solutions
This section outline several possible solutions when considering DNS
whitelisting and associated IPv6-related issues.
8.1. Implement DNS Whitelisting Universally 8.1. Implement DNS Whitelisting Universally
One obvious solution is to implement DNS whitelisted universally, and One obvious solution is to implement DNS whitelisted universally, and
to do so using some sort of centralized registry of DNS whitelisting to do so using some sort of centralized registry of DNS whitelisting
policies, contracts, processes, or other information. This potential policies, contracts, processes, or other information. This potential
solution seems unlikely at the current time. solution seems unlikely at the current time.
[EDITORIAL: More to add?]
8.2. Implement DNS Whitelisting On An Ad Hoc Basis 8.2. Implement DNS Whitelisting On An Ad Hoc Basis
If DNS whitelisting was to be adopted more widely, it is likely to be If DNS whitelisting was to be adopted, it is likely to be adopted on
adopted on this ad hoc, or domain-by-domain basis. Therefore, only this ad hoc, or domain-by-domain basis. Therefore, only those
those domains interested in DNS whitelisting would need to adopt the domains interested in DNS whitelisting would need to adopt the
practice, though as noted herein discovering that they a given domain practice, though as noted herein discovering that they a given domain
has done so may be problematic. has done so may be problematic. Also in this scenario, ad hoc use by
a particular domain may also be a temporary measure that has been
[EDITORIAL: More to add?] adopted to ease the transition of the domain to IPv6 over some short-
term timeframe.
8.3. Do Not Implement DNS Whitelisting 8.3. Do Not Implement DNS Whitelisting
As an alternative to adopting DNS whitelisting, the Internet As an alternative to adopting DNS whitelisting, the Internet
community can instead choose to take no action whatsoever, community can instead choose to take no action whatsoever,
perpetuating the current predominant authoritative DNS operational perpetuating the current predominant authoritative DNS operational
model on the Internet, and leave it up to end users with IPv6-related model on the Internet, and leave it up to end users with IPv6-related
impairments to discover and fix those impairments. impairments to discover and fix those impairments.
8.3.1. Solving Current End User IPv6 Impairments 8.3.1. Solving Current End User IPv6 Impairments
skipping to change at page 19, line 36 skipping to change at page 22, line 13
given careful and detailed advice on how to resolve this on their given careful and detailed advice on how to resolve this on their
own, or where they can seek help in doing so. own, or where they can seek help in doing so.
One challenge with this option is the potential difficulty of One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such towards this goal, sharing the labor, time, and costs related to such
an effort. Of course, since just such a community effort is now an effort. Of course, since just such a community effort is now
underway for IPv6, it is possible that this would call for only a underway for IPv6, it is possible that this would call for only a
moderate amount of additional work. moderate amount of additional work.
[EDITORIAL: More to add?] Despite any potential challenges, many in the Internet community are
already working towards this goal and/or have expressed a preference
for this approach.
9. Security Considerations 9. Security Considerations
There are no particular security considerations if DNS whitelisting There are no particular security considerations if DNS whitelisting
is not adopted, as this is how the public Internet works today with A is not adopted, as this is how the public Internet works today with A
records. records.
However, if DNS whitelisting is adopted, organizations which apply However, if DNS whitelisting is adopted, organizations which apply
DNS whitelisting policies in their authoritative servers should have DNS whitelisting policies in their authoritative servers should have
procedures and systems which do not allow unauthorized parties to procedures and systems which do not allow unauthorized parties to
skipping to change at page 20, line 20 skipping to change at page 22, line 47
9.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 server, which provides different answers depending upon
which resolver server has sent a query, the DNSSEC chain of trust is which resolver server has sent a query, the DNSSEC chain of trust is
not altered. Therefore there are no DNSSEC implications per se, and not altered. Therefore there are no DNSSEC implications per se.
thus no specific DNSSEC considerations to be listed. However, any implementer of DNS whitelisting should be quite careful
if they implement both DNSSEC signing of their domain and also DNS
whitelisting of that same domain. Specifically, those domains should
ensure that records are being appropriately and reliably signed,
which may well prove operationally and/or technically challenging.
9.2. Authoritative DNS Response Consistency Considerations 9.2. Authoritative DNS Response Consistency Considerations
[INCOMPLETE!!] In addition to the considerations raised in Section 9.1, it is
conceivable that security concerns may arise when end users or other
While Section 9.1 does not contain any specific DNSSEC parties notice that the responses sent from an authoritative DNS
considerations. However, it is certainly conceivable that security server appear to vary from one network or one DNS recursive resolver
concerns may arise when end users or other parties notice that the to another. This may give rise to concerns that, since the
responses sent from an authoritative DNS server appear to vary from authoritative responses vary that there is some sort of security
one network or one DNS recursive resolver to another. This may give issue and/or some or none of the responses can be trusted. While
rise to concerns that, since the authoritative responses vary that this may seem a somewhat obscure concern, domains nonetheless may
there is some sort of security issue and/or some or none of the wish to consider this when contemplating whether or not to pursue DNS
responses can be trusted. whitelisting.
10. IANA Considerations 10. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
11. Contributors 11. 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
Yiu Lee - Tom Klieber
Rich Woundy - Yiu Lee
- Rich Woundy
12. Acknowledgements 12. Acknowledgements
The authors and contributors also wish to acknowledge the assistance The author and contributors also wish to acknowledge the assistance
of the following individuals in helping us to develop and/or review of the following individuals. Some of these people provided helpful
this document: and important guidance in the development of this document and/or in
the development of the concepts covered in this document. Other
people assisted by performing a detailed review of this document, and
then providing feedback and constructive criticism for revisions to
this document. All of this was helpful and therefore the following
individuals merit acknowledgement:
- Bernard Aboba
- Frank Bulk
- Brian Carpenter
- Wesley George
- Erik Kline
- Danny McPherson
- Hannes Tschofenig
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
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.
[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
skipping to change at page 22, line 9 skipping to change at page 25, line 17
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
13.2. Informative References 13.2. Informative References
[I-D.shirasaki-nat444] [I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-02 (work and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), July 2010. in progress), January 2011.
[IETF 77 DNSOP WG Presentation] [IETF 77 DNSOP WG Presentation]
Gashinsky, I., "IPv6 & recursive resolvers: How do we make Gashinsky, I., "IPv6 & recursive resolvers: How do we make
the transition less painful?", IETF 77 DNS Operations the transition less painful?", IETF 77 DNS Operations
Working Group, March 2010, Working Group, March 2010,
<http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>. <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?]
Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y.,
Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting -
Could It Hinder IPv6 Adoption?", ISOC Internet Society
IPv6 Deployment Workshop, April 2010, <http://
www.comcast6.net/
IPv6_DNS_Whitelisting_Concerns_20100416.pdf>.
[IPv6 Whitelist Operations]
Kline, E., "IPv6 Whitelist Operations", Google Google IPv6
Implementors Conference, June 2010, <http://
sites.google.com/site/ipv6implementors/2010/agenda/
IPv6_Whitelist_Operations.pdf>.
[Network World Article on DNS Whitelisting] [Network World Article on DNS Whitelisting]
Marsan, C., "Google, Microsoft, Netflix in talks to create Marsan, C., "Google, Microsoft, Netflix in talks to create
shared list of IPv6 users", Network World , March 2010, <h shared list of IPv6 users", Network World , March 2010, <h
ttp://www.networkworld.com/news/2010/ ttp://www.networkworld.com/news/2010/
032610-dns-ipv6-whitelist.html>. 032610-dns-ipv6-whitelist.html>.
[Network World Article on IETF 77 DNSOP WG Presentation] [Network World Article on IETF 77 DNSOP WG Presentation]
Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Marsan, C., "Yahoo proposes 'really ugly hack' to DNS",
Network World , March 2010, <http://www.networkworld.com/ Network World , March 2010, <http://www.networkworld.com/
news/2010/032610-yahoo-dns.html>. news/2010/032610-yahoo-dns.html>.
[Newton's Laws of Motion]
Newton, I., "Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica)",
Principia Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica), July 1687,
<http://en.wikipedia.org/wiki/Newton's_laws_of_motion>.
[Rethinking the design of the Internet] [Rethinking the design of the Internet]
Blumenthal, M. and D. Clark, "Rethinking the design of the Blumenthal, M. and D. Clark, "Rethinking the design of the
Internet: The end to end arguments vs. the brave new Internet: The end to end arguments vs. the brave new
world", ACM Transactions on Internet Technology Volume 1, world", ACM Transactions on Internet Technology Volume 1,
Number 1, Pages 70-109, August 2001, <http:// Number 1, Pages 70-109, August 2001, <http://
dspace.mit.edu/bitstream/handle/1721.1/1519/ dspace.mit.edu/bitstream/handle/1721.1/1519/
TPRC_Clark_Blumenthal.pdf>. TPRC_Clark_Blumenthal.pdf>.
[Tussle in Cyberspace] [Tussle in Cyberspace]
Braden, R., Clark, D., Sollins, K., and J. Wroclawski, Braden, R., Clark, D., Sollins, K., and J. Wroclawski,
"Tussle in Cyberspace: Defining Tomorrow's Internet", "Tussle in Cyberspace: Defining Tomorrow's Internet",
Proceedings of ACM Sigcomm 2002, August 2002, <http:// Proceedings of ACM Sigcomm 2002, August 2002, <http://
groups.csail.mit.edu/ana/Publications/PubPDFs/ groups.csail.mit.edu/ana/Publications/PubPDFs/
Tussle2002.pdf>. Tussle2002.pdf>.
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]
-01: Incorporated feedback received from Brian Carpenter (from 10/19/
2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010).
Also added an informative reference at the suggestion of Wes George
(from from 10/22/2010). Closed out numerous editorial notes, and
made a variety of other changes.
-00: First version published as a v6ops WG draft. The preceding -00: First version published as a v6ops WG draft. The preceding
individual draft was individual draft was
draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE
that no changes have been made yet based on WG and list feedback. that no changes have been made yet based on WG and list feedback.
These are in queue for a -01 update. These are in queue for a -01 update.
Appendix B. Open Issues Appendix B. Open Issues
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
1. Incorporate any feedback received at IETF 79 1. Close the issues below and any feedback from the v6ops and dnsop
mailing lists in a -02 update, then request WGLC
2. Incorporate feedback from Erik Kline, received 10/1/2010
3. Incorporate feedback from Brian Carpenter, received 10/19/2010
4. Incorporate feedback from Wesley George, received 10/XX/2010
5. Bring on new contributors: Hannes Tschofenig and Danny McPherson
has so far offered to contribute.
6. Close out any EDITORIAL notes 2. Perform an second review of notes from IETF 79 to ensure that all
feedback received then has been fully taken into account!
7. Add any good references throughout the document 3. Add any good references throughout the document - posed in
question to v6ops
8. Add reviewers to the acknowledgements section 4. Ensure references are in the proper section (normative/
informative)
9. Ensure references are in the proper section (normative/ 5. Include a number of references from RFC3724?
informative)
10. Include a number of references from RFC3724? 6. Add brokenness reference to
http://ripe61.ripe.net/presentations/162-ripe61.pdf
11. Call DNS WL something else or add note to the effect that this 7. Should I include a full list or other details of the root causes
is unrelated to DNS WL used for email - such as www.dnswl.org of IPv6 brokenness? - posed in question to v6ops
Author's Address Author's Address
Jason Livingood Jason Livingood
Comcast Cable Communications Comcast Cable Communications
One Comcast Center One Comcast Center
1701 John F. Kennedy Boulevard 1701 John F. Kennedy Boulevard
Philadelphia, PA 19103 Philadelphia, PA 19103
US US
 End of changes. 68 change blocks. 
223 lines changed or deleted 397 lines changed or added

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