| IPv6 Operations | J. Livingood |
| Internet-Draft | Comcast |
| Intended status: Informational | June 08, 2011 |
| Expires: December 10, 2011 |
IPv6 AAAA DNS Whitelisting Implications
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06
This document describes the practice and implications of whitelisting DNS recursive resolvers in order to limit AAAA resource record responses (which contain IPv6 addresses) sent by authoritative DNS servers. This is an IPv6 transition mechanism used by domains as a method for incrementally transitioning inbound traffic to a domain from IPv4 to IPv6 transport. The audience for this document is the Internet community generally, particularly IPv6 implementers.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2011.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes the practice and implications of whitelisting DNS recursive resolvers in order to limit AAAA resource record (RR) responses (which contain IPv6 addresses) sent by authoritative DNS servers. This is referred to hereafter as DNS Whitelisting. This is an IPv6 transition mechanism used by domains as a method for incrementally transitioning inbound traffic to a domain from IPv4 to IPv6 transport. When implemented, a domain's authoritative DNS will return a AAAA resource record to DNS recursive resolvers [RFC1035] on the whitelist, while returning no AAAA resource records to DNS recursive resolvers which are not on the whitelist. The practice appears to have first been used by major web content sites (sometimes described hereafter as "high-traffic domains"), which have specific concerns relating to maintaining 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 concerns. Among these are that:
This document explores the reasons and motivations for DNS Whitelisting Section 4. It also explores the concerns regarding this practice, and whether and when the practice is recommended Section 8. Readers will hopefully better understand what DNS Whitelisting is, why some domains are implementing it, and what the implications are.
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 contained in the blacklist.
DNS Whitelisting is implemented in authoritative DNS servers, not in DNS recursive resolvers. These authoritative DNS servers implement IP address-based restrictions on AAAA query responses. So far, DNS Whitelisting has been primarily implemented by web site operators deploying IPv6-enabled services, though this practice could affect all protocols and services within a domain. For a given operator of a website, such as www.example.com, the domain operator essentially applies an access control list (ACL) on the authoritative DNS servers for the domain example.com. The ACL is populated with the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on the Internet, which have been authorized to receive (or access) AAAA resource record responses. These DNS recursive resolvers are operated by third parties, such as Internet Service Providers (ISPs), universities, governments, businesses, and individual end users. If a DNS recursive resolver IS NOT matched in the ACL, then AAAA resource records WILL NOT be sent in response to a query for a hostname in the example.com domain. However, if a DNS recursive resolver IS matched in the ACL, then AAAA resource records WILL be sent in response to a query for a given hostname in the example.com domain. While these are not network-layer access controls (as many ACLs are) they are nonetheless access controls that are a factor for end users and other organizations such as network operators, 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 fraction of the DNS recursive resolvers on the Internet (those in the whitelist or ACL) will receive AAAA responses. The large majority of DNS recursive resolvers on the Internet will therefore receive only A resource records containing IPv4 addresses. Thus, quite simply, the authoritative server hands out different answers depending upon who is asking; with IPv4 and IPv6 resource records for all those the authorized whitelist, and only IPv4 resource records for everyone else. See Section 2.1 and Figure 1 for more details.
DNS Whitelisting also works independently of whether an authoritative DNS server, DNS recursive resolver, or end user host uses IPv4 transport, IPv6, or both. So, for example, whitelisting may prevent sending AAAA responses even in those cases where the DNS recursive resolver has queried the authoritative server over IPv6 transport, or where the end user host's original query to the DNS recursive resolver was over IPv6 transport. One important reason for this is that even though the DNS recursive resolver may have no IPv6-related impairments, this is not a reliable predictor of whether the same is true of the end user host. This also means that a DNS whitelist can contain both IPv4 and IPv6 addresses.
Finally, DNS Whitelisting could possibly be deployed in two ways: universally on a global basis (though that would be considered harmful and is just covered to explain why this is the case), or, more realistically, on an ad hoc basis. Deployment on a universal deployment basis means that DNS Whitelisting is implemented on all authoritative DNS servers, across the entire Internet. In contrast, deployment on an ad hoc basis means that only some authoritative DNS servers, and perhaps even only a few, implement DNS Whitelisting. These two potential deployment models are described in Section 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.
The system logic of DNS Whitelisting is as follows:
+--------------------------------------------------------------------+
| Caching Server 1 - IS NOT ON the DNS Whitelist |
| Caching Server 2 - IS ON the DNS Whitelist |
| Note: Transport between each host can be IPv4 or IPv6. |
+--------------------------------------------------------------------+
+----------+ +---------------+ +---------------+
| 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 | |
|<----------------------| |
+----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| 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 | |
|<----------------------| |
With DNS Whitelisting, DNS recursive resolvers can receive AAAA resource records only if they are on the whitelist. In contrast, blacklisting would be the opposite whereby all DNS recursive resolvers can receive AAAA resource records unless they are on the blacklist. So a whitelist contains a list of hosts allowed something, whereby a blacklist contains a list of hosts disallowed something. While the distinction between the concepts of whitelisting and blacklisting is important, this is noted specifically since some implementers of DNS Whitelisting may choose to transition to DNS Blacklisting before returning to a state without address-family-related ACLs in their authoritative DNS servers. It is unclear when and if it would be appropriate to change from whitelisting to blacklisting. Nor is it clear how implementers will judge the network conditions to have changed sufficiently to justify disabling such controls.
Some aspects of DNS Whitelisting may be considered similar to other common DNS operational techniques which are explored below.
DNS Whitelisting has some similarities to so-called split DNS, briefly described in Section 3.8 of [RFC2775]. When split DNS is used, the authoritative DNS server returns different responses 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 Intranet and a different answer to hosts on the Internet, the essence is that different answers are provided to hosts on different networks. This is basically the way that DNS Whitelisting works, whereby hosts on 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.
In [RFC2956], Internet transparency and Internet fragmentation concerns regarding split DNS are detailed in Section 2.1. [RFC2956] further notes in Section 2.7, concerns regarding split DNS and that it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complex." Section 3.5 of [RFC2956] further recommends that maintaining a stable approach to DNS operations is key during transitions such as the one to IPv6 that is underway now, stating that "Operational stability of DNS is paramount, especially during a transition of the network layer, and both IPv6 and some network address translation techniques place a heavier burden on DNS."
DNS Whitelisting also has some similarities to DNS load balancing. There are of course many ways that DNS load balancing can be 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 is referred to as DNS round robin [RFC1794]. DNS round robin may also be employed where SRV resource records are used [RFC2782].
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, 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 necessarily be directly reachable without passing through the load balancer first.
Additionally, a geographically-aware authoritative DNS server may be used, as is common with Content Delivery Networks (CDNs) or Global Load Balancing (GLB, also referred to as Global Server Load Balancing, or GSLB), 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 [Wild-Resolvers]. 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 selectively returned to resolvers based on the IP address of each resolver (or other imputed factors related to that IP address). However, what is different is that in this case the resolvers are not deliberately blocked from receiving DNS responses containing an entire class of addresses; this load balancing function strives to perform a content location-improvement function and not an access control function.
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. 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. Both can negatively affect the experience of end users.
Not all domains may face these challenges, though some clearly do, since the user base of each domain, traffic sources, traffic volumes, and other factors obviously varies between domains. For example, while some domains have implemented DNS Whitelisting, others have run IPv6 experiments whereby they added AAAA resource records and observed and measured errors, and then decided not to implement DNS Whitelisting [Heise]. A more widespread such experiment was World 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.
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.
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 is 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.
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], 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.
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).
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 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.
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.
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.
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 would need to be built into all authoritative DNS server software, and all operators of authoritative DNS servers would have to upgrade their software in order to enable this functionality. New IETF Request for Comment (RFC) documents may need to be completed to describe how to properly configure, deploy, and maintain DNS Whitelisting across the entire Internet. As a result, it is highly unlikely that DNS Whitelisting will become universally deployed.
Such an approach is considered harmful and problematic, and almost certain not to happen.
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.
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.
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.
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.
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.
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.
The key DNS Whitelisting implications are detailed below.
DNS Whitelisting modifies the end-to-end model and the general notion of spontaneous interoperability of the architecture that prevails on the Internet today. This is because this approach moves additional access control information and policies into the middle of the DNS resolution path of the IPv6-addressed Internet, which generally did not exist before on the IPv4-addressed Internet, and it requires some type of prior registration with authoritative servers. This poses some risks noted in [RFC3724]. In explaining the history of the end-to-end principle, [RFC1958] states that one of the goals is to minimize the state, policies, and other functions needed in the middle of the network in order to enable end-to-end communications on 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. 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 the observed benefits of the end-to-end principle, as listed in Section 4.1 of [RFC3724], such as protection of innovation. [RFC3234] details issues and concerns regarding so-called middleboxes, so there may also be parallel concerns with the DNS Whitelisting approach, especially concerning modified DNS servers 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 failure modes. In particular, there may be concerns that configuration is no longer limited to two ends of a session, and that diagnosis of failures and misconfigurations becomes more complex.
Two additional sources worth considering as far as implications for the end-to-end model are concerned are [Tussle] and [Rethinking]. In [Tussle], the authors note concerns regarding the introduction of new control points, as well as "kludges" to the DNS, as risks to the goal of network transparency in the end-to-end model. Given the emerging use of DNS Whitelisting [Tussle] is an interesting and relevant document. In addition, [Rethinking] reviews similar issues that are of interest to readers of this document.
Also, it is somewhat possible that DNS Whitelisting could affect some of the architectural assumptions which underlie parts of Section 2 of [RFC4213] which outlines the dual stack approach to the IPv6 transition. DNS Whitelisting could modify the behavior of the DNS, as described in Section 2.2 of [RFC4213] and could require different sets of DNS servers to be used for hosts that are (using terms from that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes. As such, broad use of DNS Whitelisting may necessitate the review and/or revision (though revision is unlikely to be necessary) of standards documents which describe dual-stack and IPv6 operating modes, dual-stack architecture generally, and IPv6 transition methods, including but not limited to [RFC4213].
It is a critical to understand that the concept of reachability described here depends upon a knowledge of an address in the DNS. Thus, in order to establish reachability to an end point, a host is dependent upon looking up an IP address in the DNS when a FQDN is used. When DNS Whitelisting is used, it is quite likely that an IPv6-enabled end user host could connect to an example server host using the IPv6 address, even though the FQDN associated with that server host is restricted via a DNS whitelist. Since most Internet applications and hosts such as web servers depend upon the DNS, and as end users connect to FQDNs such as www.example.com and do not remember or wish to type in an IP address, the notion of reachability described here should be understood to include knowledge of how to associate a name with a network address.
The predominant experience of end user hosts and servers on the IPv4-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 reaching it. This is a generalization and in Section 3 there are examples of common cases where this may not necessarily be the case. For the purposes of this argument, that concept of accessibility is described as "pervasive reachability". It has so far been assumed that the same expectations of pervasive reachability would exist in the IPv6-addressed Internet. However, if DNS Whitelisting is 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 domain using DNS Whitelisting would be able to reach new servers in that given domain via IPv6 addresses. 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.
Establishing DNS Whitelisting as an accepted practice in the early phases of mass IPv6 deployment could establish it as an integral part of how IPv6 DNS resource records are deployed globally. This risks DNS Whitelisting living on for many years as a key foundational element of domain name management on the Internet.
This section explores some of the operational implications which may occur as a result of, are related to, or become necessary when engaging in the practice of DNS Whitelisting.
It is possible for a DNS recursive resolver added to a whitelist to then be removed from the whitelist, also known as de-whitelisting. Since de-whitelisting can occur, through a decision by the authoritative server operator, the domain owner, or even due to a technical error, an operator of a DNS recursive resolver will have new operational and monitoring requirements and/or needs as noted in Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. One particular risk is that, especially when a high-traffic domain de-whitelists a large network, this may cause a sudden and dramatic change to networks since a large volume of traffic will then switch from IPv6 to IPv4. This can have dramatic effects on those being de-whitelisted as well as on other interconnected networks. In some cases, IPv4 network links may rapidly become congested and users of affected networks will experience network access impairments well beyond the domain which performed the de-whitelisting. Thus, once "operational stability" has been achieved between a whitelisting and whitelisted party, then de-whitelisting should generally not occur except in cases of operational emergencies, and there should be opportunities for joint troubleshooting or at least for advance warning to affected parties.
DNS Whitelisting serves as a critical infrastructure service; to be useful it needs careful and extensive administration, monitoring and operation. Each new and essential mechanism creates substantial follow-on support costs.
Operators of authoritative servers (which are frequently authoritative for multiple domain names) will need to maintain an ACL on a server-wide basis affecting all domains, or on a domain-by-domain basis. As a result, operational practices and software capabilities may need to be developed in order to support such functionality. In addition, processes may need to be put in place to protect against inadvertently adding or removing IP addresses, as well as systems and/or processes to respond to such incidents if and when they occur. For example, a system may be needed to record DNS Whitelisting requests, report on their status along a workflow, add IP addresses when whitelisting has been approved, remove IP addresses when they have been de-whitelisted, log the personnel involved and timing of changes, schedule changes to occur in the future, and to roll back any inadvertent changes.
Operators may also need implement new forms of monitoring in order to apply change control, as noted briefly in Section 7.3.4.
It is important for operators of authoritative servers to recognize that the operational burden is likely to increase dramatically over time, as more and more networks transition to IPv6. As a result, the volume of new DNS Whitelisting requests will increase over time, potentially at an extraordinary growth rate, which will place an increasing burden on personnel, systems, and/or processes. Operators should also consider that any supporting systems, including the authoritative servers themselves, may experience reduced performance when a DNS whitelist becomes quite large.
For operators of DNS recursive resolvers, coping with DNS Whitelisting becomes expensive in time and personnel as the practice scales up. These operators include ISPs, enterprises, universities, governments; a wide range of organization types with a range of DNS-related expertise. They will need to implement new forms of monitoring, as noted briefly in Section 7.3.4. But more critically, such operators will need to add people, processes, and systems in order to manage large numbers of DNS Whitelisting applications. Since there is no common method for determining whether or not a domain is engaged in DNS Whitelisting, operators will have to apply to be whitelisted for a domain based upon one or more end user requests, which means systems, processes, and personnel for handling and responding to those requests will also be necessary.
When operators apply for DNS Whitelisting for all domains, that may mean doing so for all registered domains. Thus, some system would have to be developed to discover whether each domain has been whitelisted or not, which is touched on in Section 5 and may vary depending upon whether DNS Whitelisting is universally deployed or is deployed on an ad hoc basis.
These operators (of DNS recursive resolvers) will need to develop processes and systems to track the status of all DNS Whitelisting applications, respond to requests for additional information related to these applications, determine when and if applications have been denied, manage appeals, and track any de-whitelisting actions.
Given the large number of domains in existence, the ease with which a new domain can be added, and the continued strong growth in the numbers of new domains, readers should not underestimate the potential significance in personnel and expense that this could represent for such operators. In addition, it is likely that systems and personnel 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 of a whitelisting application, reports of de-whitelisting incidents, general inquiries related to DNS Whitelisting, and requests for DNS Whitelisting-related troubleshooting by these end users.
Once a DNS recursive resolver has been whitelisted for a particular domain, then the operator of that DNS recursive resolver may need to implement monitoring in order to detect the possible loss of DNS Whitelisting in the future. This DNS recursive resolver operator could configure a monitor to check for a AAAA response in the whitelisted domain, as a check to validate continued status on the DNS whitelist. The monitor could then trigger an alert if at some point the AAAA responses were no longer received, so that operations personnel could begin troubleshooting, as outlined in Section 7.3.6.
Also, authoritative DNS server operators are likely to need 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 certain period of time, which might be indicative of a technical error such as the entire ACL being removed. Authoritative DNS server operators may also wish to monitor their workflow process for reviewing and acting upon DNS Whitelisting applications and appeals, potentially measuring and reporting on service level commitments regarding the time an application or appeal can remain at each step of the process, regardless of whether or not such information is shared with parties other than that authoritative DNS server operator.
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 on an understanding of human nature, not to mention physics. For example, as Sir Isaac 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" [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 may otherwise simply remain in place in perpetuity. To illustrate this point, one could consider for example that there are many email servers continuing to attempt to query anti-spam DNS blocklists which have long ago ceased to exist.
The implications of DNS whitelisted present many challenges, as detailed throughout Section 7. These challenges may negatively affect the end users' ability to troubleshoot, as well as that of DNS recursive resolver operators, ISPs, content providers, domain owners (where they may be different from the operator of the authoritative DNS server for their domain), and other third parties. This may make the process of determining why a server is not reachable via a FQDN significantly more complex and time-consuming.
As more domains choose to implement DNS Whitelisting, and more networks become IPv6-capable and request to be whitelisted, scaling up operational processes, monitoring, and ACL updates will become more difficult. The increased rate of change and increased size of whitelists will increase the likelihood of configuration and other operational errors.
It is unclear when and if it would be appropriate to change from whitelisting to blacklisting. It also seems unlikely for such a change from whitelisting to blacklisting to be coordinated across the 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 temporary measure. As such, it is not clear how these implementers will judge the network conditions to have changed sufficiently to justify disabling DNS Whitelisting (or blacklisting, or other AAAA resource record access controls) and/or what the process and timing will be in order to discontinue this practice.
A broad trend on the Internet is a move toward more heterogeneity. One manifestation of this is in an increasing number, variety, and customization of end user hosts, including home networks, operating systems, client software, home network devices, and personal computing devices. This trend appears to have had a positive effect on the development and growth of the Internet and has enabled end users to connect any technically compliant device or use any technically compatible software to connect to the Internet. Not only does this trend towards greater heterogeneity reduce the control which is exerted in the middle of the network, described positively in [Tussle], [Rethinking], and [RFC3724], but it also appears to help to enable greater and more rapid innovation at the edge of the network.
Some forms of so-called "network neutrality" principles around the world include the notion that any IP-capable device should be able to connect to a network, encouraging heterogeneity. These principles are often explicitly encouraged by application providers, though some of these same providers may be using DNS Whitelisting. This is ironic, as one implication of the adoption of DNS Whitelisting is that it could encourage a move back towards homogeneity resulting from greater control over devices in order to attempt to enforce technical requirements intended to reduce IPv6-related impairments. This return to an environment of more homogenous and/or controlled end user hosts could have unintended side effects on and counter-productive implications for future innovation at the edge of the network.
A key technology policy implication concerns the policies and processes related to reviewing and making decisions on DNS Whitelisting applications for a domain, as well as making any possible de-whitelisting decisons. Important questions may include whether these policies have been fully and transparently disclosed, are non-discriminatory, and are not anti-competitive. Key questions here may include whether appeals are allowed, what the process is, what the expected turn around time is, and whether the appeal will be handled by an independent third party.
It is also conceivable that whitelisting and de-whitelisting decisions could be quite sensitive to concerned parties beyond the operator of the domain operator and the operator of the DNS recursive resolver, including end users, application developers, content providers, advertisers, public policy groups, governments, and other entities. These concerned parties may seek to become involved in or express opinions concerning whitelisting and/or de-whitelisting decisions.
A final concern is that decisions relating to whitelisting and de-whitelisting may occur as an expression of other commercial, governmental, and/or cultural conflicts, given the new control point which has been established with DNS Whitelisting. For example, in one imagined scenario, a domain could withhold adding a network to their DNS Whitelisting unless that network agreed to some sort of financial payment, legal agreement, agreement to sever a relationship with a competitor of the domain, etc. In another example, a music-oriented domain may be engaged in some sort of dispute with an academic network concerning copyright infringement concerns within that network, and may choose to de-whitelist that network as a negotiating technique in some sort of commercial discussion. In 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, it seems possible that whitelisting and de-whitelisting could become a vehicle for adjudicating other disputes, and that this may well have consequences for end users which are affected by such decisions and are unable to express a strong voice in such decisions.
As noted in Section 6, the implications of DNS Whitelisting may drive end users and/or networks to delay, postpone, or cancel adoption of IPv6, or to actively seek alternatives to it. Such alternatives may include the use of multi-layer or large scale network address translation (NAT) techniques, which these parties may decide to pursue on a long-term basis to avoid the perceived costs and aggravations related to DNS Whitelisting. This could of 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 the transition to IPv6. As a result, parties that are likely to be concerned over the negative implications of DNS Whitelisting could logically be concerned of the negative effects that this practice could have on the adoption of IPv6 if it became widespread.
At the same time, as noted in Section 4, some high-traffic domains may find the prospect of transitioning to IPv6 daunting without having some short-term ability to incrementally control the amount and source of IPv6 traffic to their domains. Lacking such controls, some domains may choose to substantially delay their transition to IPv6.
It is possible that there could be situations where the differing quality of the IPv4 and IPv6 connectivity of an end user could cause complications in accessing content which is in a whitelisted domain, when the end user's DNS recursive resolver is not on that whitelist. While today most end users' IPv4 connectivity is typically superior to IPv6 connectivity (if such connectivity exists at all), there could be implications when the reverse is true and and end user has markedly superior IPv6 connectivity as compared to IPv4. This is admittedly theoretical but could become a factor as the transition to IPv6 continues and IPv4 address availability within networks becomes strained.
For example, in one possible scenario, a user is issued IPv6 addresses by their ISP and has a home network and devices or operating systems which fully support IPv6. As a result this theoretical user has very good IPv6 connectivity. However, this end user's ISP may have exhausted their available pool of unique IPv4 address, and so that ISP uses NAT in order to reuse IPv4 addresses. So for IPv4 content, the end user must send their IPv4 traffic through some additional network element (e.g. NAT, proxy, tunnel server). Use of this additional network element may cause the end user to experience sub-optimal IPv4 connectivity when certain protocols or applications are used. This user then has good IPv6 connectivity but impaired IPv4 connectivity. Furthermore, this end user's DNS recursive resolver is not whitelisted by the authoritative server for a domain that the user is trying to access, meaning the end user only gets A record responses for their impaired IPv4 transport rather than also AAAA record responses for their stable and well-performing IPv6 transport. Thus, the user's poor IPv4 connectivity situation is potentially exacerbated by not having access to a given domain's IPv6 content since they must use the address family with relatively poor performance.
In most cases it is assumed that end users will make use of DNS recursive resolvers which are operated by their access network provider, whether that is an ISP, campus network, enterprise network, 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 operating system to those of a third party which operates DNS recursive resolvers independently of end user access networks.
In these cases, an authoritative DNS server may receive a query from a DNS recursive resolver in one network, though the end user sending the original query 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' assigned DNS recursive resolvers have not been whitelisted for a particular domain, but where the end user tries to switch to a third-party DNS recursive resolver that has been whitelisted. While in most cases the end user will be able to switch to use that third-party's DNS servers, some specialized access networks, such as in hotels and conference centers, may prevent using third-party DNS servers. In these cases, end users may be frustrated at their inability to access certain content over IPv6, resulting in complaints to both a particular domain as well as the access network operator.
Opinions in the Internet community concerning whether or not DNS Whitelisting is a recommended practice are understandably quite varied. However, there is clear consensus that DNS Whitelisting can be a useful tactic a domain may choose to use as they transition to IPv6. In particular, some high-traffic domains view DNS Whitelisting as one of the few practical and low-risk approaches enabling them to transition to IPv6, without which their transition may not take place for some time. However, there is also consensus is that this practice is workable only in the short-term and that it will not scale over the long-term. Thus, some domains may find DNS Whitelisting a beneficial temporary tactic in their transition to IPv6. Such temporary use during the transition to IPv6 is broadly accepted within the community, so long as it does not become a long-term practice.
If DNS Whitelisting is adopted, then organizations which apply DNS Whitelisting policies in their authoritative servers should have procedures and systems which do not allow unauthorized parties to either remove whitelisted DNS recursive resolvers from the whitelist or add non-whitelisted DNS recursive resolvers to the whitelist, just as all configuration settings for name servers should be protected by appropriate procedures and systems. Should such unauthorized additions or removals from the whitelist can be quite damaging, and result in content providers and/or ISPs to incur substantial support costs resulting from end user and/or customer contacts. As such, great care must be taken to control access to the whitelist for an authoritative server.
In addition, two other key security-related issues should be taken into consideration:
DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Security-Aware Resolvers to verify the answers. Since DNS Whitelisting is implemented on an authoritative DNS server, which provides different answers depending upon which DNS resolver has sent a query, the DNSSEC chain of trust is not altered. Even though the authoritative DNS server will not always return a AAAA resource record when one exists, respective A resource records and AAAA resource records can and should both be signed. Therefore there are no DNSSEC implications per se. However, any implementer of DNS Whitelisting should be careful if they implement both DNSSEC signing of their domain and also DNS Whitelisting of that same domain. Specifically, those domains should ensure that resource records are being appropriately and reliably signed, which may present modest incremental operational and/or technical challenges.
However, as noted in fourth paragraph of Section 4.2, end user networks may also choose to implement tools at their disposal in order to address IPv6-related impairments. One of those tools could involve unspecified changes to the configuration of their DNS recursive resolvers. If those are Security-Aware Resolvers, modifying or suppressing AAAA resource records for a DNSSEC-signed domain will be problematic and could break the chain of trust established with DNSSEC.
In addition to the considerations raised in Section 9.1, it is conceivable that security concerns may arise when end users or other parties notice that the responses sent from an authoritative DNS server appear to vary from one network or one DNS recursive resolver to another. This may give rise to concerns that, since the authoritative responses vary that there is some sort of security issue and/or some or none of the responses can be trusted. While this may seem a somewhat obscure concern, domains nonetheless may wish to consider this when contemplating whether or not to pursue DNS Whitelisting.
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 be possible when an end user visits the website of a particular domain. In that example, there are likely no privacy considerations in automatically communicating to that end user that the domain has detected a particular impairment. However, if that domain decided to share information concerning that particular end user with their network operator or another party, then the visited domain may wish to in some manner advise the end user of this or otherwise seek to obtain the user's consent to such information sharing. This may be achieved in a wide variety of ways, from presenting a message asking the user for consent (which will of course help them solve a technical problem of which they are likely unaware) to adding this to a domain's website terms of use / service. Such information sharing and communication of such sharing to end users may well vary by geographic area and/or legal jurisdiction. Thus, a domain should consider any potential privacy issues these sorts of scenarios.
To the extent that domains or network operators decide to publish impairment statistics, they should not identify individual hosts, host identifiers, or users.
There are no IANA considerations in this document.
The following people made significant textual contributions to this document and/or played an important role in the development and evolution of this document:
- John Brzozowski
- Chris Griffiths
- Tom Klieber
- Yiu Lee
- Rich Woundy
The author and contributors also wish to acknowledge the assistance of the following individuals or groups. Some of these people provided helpful 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, or engaged in a healthy debate over the subject of the document. All of this was helpful and therefore the following individuals merit acknowledgement:
- Bernard Aboba
- Jari Arkko
- Frank Bulk
- Brian Carpenter
- Lorenzo Colitti
- Alissa Cooper
- Dave Crocker
- Ralph Droms
- Wesley Eddy
- J.D. Falk
- Adrian Farrel
- Stephen Farrell
- Tony Finch
- Karsten Fleischhauer
- Wesley George
- Philip Homburg
- Jerry Huang
- Ray Hunter
- Joel Jaeggli
- Erik Kline
- Suresh Krishnan
- Victor Kuarsingh
- John Leslie
- John Mann
- Danny McPherson
- Milo Medin
- Martin Millnert
- Russ Mundy
- Thomas Narten
- Pekka Savola
- Robert Sparks
- Barbara Stark
- Joe Touch
- Hannes Tschofenig
- Tina Tsou
- Members of the Broadband Internet Technical Advisory Group (BITAG)
| [IPv6-Brokenness] | Anderson, T., "Measuring and Combating IPv6 Brokenness", Reseaux IP Europeens (RIPE) 61st Meeting, November 2010. |
| [Impairment-Tracker] | Anderson, T., "IPv6 dual-stack client loss in Norway", Website , May 2011. |
| [Wild-Resolvers] | Ager, B., Smaragdakis, G., Muhlbauer, W. and S. Uhlig, "Comparing DNS Resolvers in the Wild", ACM Sigcomm Internet Measurement Conference 2010, November 2010. |
| [Heise] | Heise.de, "The Big IPv6 Experiment", Heise.de Website http://www.h-online.com, January 2011. |
| [W6D] | The Internet Society, "World IPv6 Day - June 8, 2011", Internet Society Website http://www.isoc.org, January 2011. |
| [WL-Ops] | Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 Implementors Conference, June 2010. |
| [IPv6-Growth] | Colitti, L., Gunderson, S.H., Kline, E. and T. Refice, "Evaluating IPv6 adoption in the Internet", Passive and Active Management (PAM) Conference 2010, April 2010. |
| [WL-Concerns] | Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., Livingood, J. and R. Woundy, "IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?", ISOC Internet Society IPv6 Deployment Workshop, April 2010. |
| [IETF-77-DNSOP] | Gashinsky, I., "IPv6 & recursive resolvers: How do we make the transition less painful?", IETF 77 DNS Operations Working Group, March 2010. |
| [NW-Article-DNSOP] | Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Network World , March 2010. |
| [NW-Article-DNS-WL] | Marsan, C., "Google, Microsoft, Netflix in talks to create shared list of IPv6 users", Network World , March 2010. |
| [Tussle] | Braden, R., Clark, D., Sollins, K. and J. Wroclawski, "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of ACM Sigcomm 2002, August 2002. |
| [Rethinking] | Blumenthal, M. and D. Clark, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world", ACM Transactions on Internet Technology Volume 1, Number 1, Pages 70-109, August 2001. |
| [Motion] | Newton, I., "Mathematical Principles of Natural Philosophy (Philosophiae Naturalis Principia Mathematica)", Principia Mathematical Principles of Natural Philosophy (Philosophiae Naturalis Principia Mathematica), July 1687. |
[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 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.
-04: Made changed based on feedback received during IESG review. This does NOT include updated from the more general IETF last call - that will be in a -05 version of the document. Per Ralph Droms, change the title of 6.2 from "Likely Deployment Scenarios" to "General Implementation Variations", as well as changes to improve the understanding of sentences in Sections 2, 3, 4, and 8.2. Per Adrian Farrel, made a minor change to Section 3. Per Robert Sparks, to make clear in Section 2 that whitelisting is done on authoritative servers and not DNS recursive resolvers, and to improve Section 8.3 and add a reference to I-D.ietf-v6ops-happy-eyeballs. Per Wesley Eddy, updated Section 7.3.2 to address operational concerns and re-titled Section 8 from "Solutions" to "General Implementation Variations". Per Stephen Farrell, added text to Section 8.1 and Section 6.2, with a reference to 8.1 in the Introduction, to say that universal deployment is considered harmful. Added text to Section 2 per the v6ops list discussion to indicate that whitelisting is independent of the IP address family of the end user host or resolver. There was also discussion with the IESG to change the name of the draft to IPv6 DNS Resolver Whitelisting or IPv6 AAAA DNS Resolver Whitelisting (as suggested originally by John Mann) but there was not a strong consensus to do so. Added a new section 7.7, at the suggestion of Philip Homburg. Per Joe Touch, added a new Section 8.4 on blacklisting as an alternative, mentioned blacklisting in Section 2, added a new Section 7.8 on the use of 3rd party resolvers, and updated section 6.2 to change Internet Draft documents to RFCs. Minor changes from Barbara Stark. Changes to the Privacy Considerations section based on feedback from Alissa Cooper. Changed "highly-trafficked" domains to "high-traffic" domains. Per Bernard Aboba, added text noting that a whitelist may be manually or automatically updated, contrasting whitelisting with blacklisting, reorganized Section 3, added a note on multiple clearinghouses being possible. Per Pekka Savola, added a note regarding multiple clearinghouses to the Ad Hoc section, corrected grammar in Section 7.5, reworded Section 7.3.7, corrected the year in a RIPE reference citation. Also incorporated general feedback from the Broadband Internet Technical Advisory Group. Per Jari Arkko, simplified the introduction to the Implications section, played down possible impacts on RFC 4213, added caveats to Section 8.3.2 on the utility of transition names, re-wrote Section 9. Updated the Abstract and Introduction, per errors noted by Tony Finch. Updated the Security Considerations based on feedback from Russ Mundy. Per Ray Hunter, added some text to the De-Whitelisting implications section regarding effects on networks of switching from IPv6 to IPv4. Updated 7.3.1 per additional feedback from Karsten Fleischhauer. Per Dave Crocker, added a complete description of the practice to the Abstract, added a note to the Introduction that the operational impacts are particularly acute at scale, added text to Intro to make clear this practice affects all protocols and not just HTTP, added a new query/response diagram, added text to the Abstract and Introduction noting that this is an IPv6 transition mechanism, and too many other changes to list.
-03: Several changes suggested by Joel Jaeggli at the end of WGLC. This involved swapping the order of Section 6.1 and 6.2, among other changes to make the document more readable, understandable, and tonally balanced. As suggested by Karsten Fleischhauer, added a reference to RFC 4213 in Section 7.1, as well as other suggestions to that section. As suggested by Tina Tsou, made some changes to the DNSSEC section regarding signing. As suggested by Suresh Krishnan, made several changes to improve various sections of the document, such as adding an alternative concerning the use of ipv6.domain, improving the system logic section, and shortening the reference titles. As suggested by Thomas Narten, added some text regarding the imperfection of making judgements as to end user host impairments based upon the DNS recursive resolver's IP and/or network. Finally, made sure that variations in the use of 'records' and 'resource records' was updated to 'resource records' for uniformity and to avoid confusion.
-02: Called for and closed out feedback on dnsop and v6ops mailing lists. Closed out open feedback items from IETF 79. Cleared I-D nits issues, added a section on whether or not this is recommended, made language less company-specific based on feedback from Martin Millnert, Wes George, and Victor Kuarsingh. Also mentioned World IPv6 Day per Wes George's suggestion. Added references to the ISOC World IPv6 Day and the Heise.de test at the suggestion of Jerry Huang, as well as an additional implication in 7.3.7. Made any speculation on IPv4 impairment noted explicitly as such, per feedback from Martin Millnert. Added a reference to DNS SRV in the load balancing section. Added various other references. Numerous changes suggested by John Brzozowski in several sections, to clean up the document. Moved up the section on why whitelisting is performed to make the document flow more logically. Added a note in the ad hoc deployment scenario explaining that a deployment may be temporary, and including more of the perceived benefits of this tactic. Added a Privacy Considerations section to address end-user detection and communication.
-01: Incorporated feedback received from Brian Carpenter (from 10/19/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 individual draft was draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE that no changes have been made yet based on WG and list feedback. These are in queue for a -01 update.
[RFC Editor: This section is to be removed before publication]