I disagree that "whitelisting" is a reserved trademark of the anti-abuse community. It's a general term for a list of things that are granted something. Likewise with "blacklist" and "deny". Which means it's perfectly appropriate for this document. <http://en.wikipedia.org/wiki/Whitelist> On Apr 30, 2011, at 1:32 AM, Dave CROCKER wrote: > > Review: > > Title: IPv6 AAAA DNS Whitelisting Implications > I-D: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 > > By: D. Crocker <dcrocker@xxxxxxxx> > Date: 29 April 2011 > > > Summary: > > This draft is a discussion of a technique for resolving a dual-stack problem between IPv4 and IPv6, through the use of special DNS records. > > The document appears to continue a recent use of the term 'whitelisting' that strongly conflicts with long-standing use of the term by the anti-abuse community. > > The document needs to do a more careful job of introducing the problem it is solving and the explaining the way the 'whitelisting' mechanism works. > > I also very strongly encourage finding a different term. > > d/ > > >> Abstract >> >> The objective of this document is to describe what the whitelisting >> of DNS AAAA resource records is, hereafter referred to as DNS > > RRs are whitelisted? Isn't it the addresses and not the records that are whitelisted? > > Does this mean putting whitelisting records into the DNS or does it mean something else? > > Comcast's own considerable expertise notwithstanding, has this doc been vetted with a range of organizations that actually DO whitelisting? Has it been circulated through MAAWG and APWG? Any comments from Spamhaus? The Acknowledgements list does not seem to indicate a range of whitelist ops folks whose names I know. (But then, I only know a few...) > > >> whitelisting, as well as the implications of this emerging practice >> and what alternatives may exist. The audience for this document is >> the Internet community generally, including the IETF and IPv6 >> implementers. > > I suspect that product marketers won't have much interest in this. I suspect that the target for this is anti-abuse technical and operations staff. > > >> Status of this Memo >> >> 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 August 26, 2011. >> >> Copyright Notice >> >> 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 >> >> >> >> Livingood Expires August 26, 2011 [Page 1] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> described in the Simplified BSD License. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Livingood Expires August 26, 2011 [Page 2] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >> 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 6 >> 2.1. Description of the Operation of DNS Whitelisting . . . . . 7 >> 3. What Problems Are Implementers Trying To Solve? . . . . . . . 8 >> 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 9 >> 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 12 >> 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 12 >> 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 12 >> 6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 13 >> 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13 >> 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 14 >> 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15 >> 7.1. Architectural Implications . . . . . . . . . . . . . . . . 15 >> 7.2. Public IPv6 Address Reachability Implications . . . . . . 16 >> 7.3. Operational Implications . . . . . . . . . . . . . . . . . 17 >> 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 17 >> 7.3.2. Authoritative DNS Server Operational Implications . . 17 >> 7.3.3. DNS Recursive Resolver Server Operational >> Implications . . . . . . . . . . . . . . . . . . . . . 18 >> 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 19 >> 7.3.5. Implications of Operational Momentum . . . . . . . . . 19 >> 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 20 >> 7.3.7. Additional Implications If Deployed On An Ad Hoc >> Basis . . . . . . . . . . . . . . . . . . . . . . . . 20 >> 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 20 >> 7.5. Technology Policy Implications . . . . . . . . . . . . . . 21 >> 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22 >> 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 23 >> 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 23 >> 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 23 >> 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 23 >> 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 24 >> 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 24 >> 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 24 >> 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 >> 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 25 >> 10.2. Authoritative DNS Response Consistency Considerations . . 26 >> 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26 >> 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 >> 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 >> 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 >> 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 >> 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 >> 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 >> Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 31 >> Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 32 >> >> >> >> Livingood Expires August 26, 2011 [Page 3] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Livingood Expires August 26, 2011 [Page 4] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> 1. Introduction >> >> This document describes the emerging practice of whitelisting of DNS >> AAAA resource records (RRs), which contain IPv6 addresses, hereafter >> referred to as DNS whitelisting. The document explores the >> implications of this emerging practice are and what alternatives may >> exist. >> >> The practice of DNS whitelisting appears to have first been used by >> major web content sites (sometimes described herein as "highly- > > Really? Not for email first? > > >> trafficked domains" or "major domains"). These web site operators, >> or domain operators, observed that when they added AAAA resource >> records to their authoritative DNS servers in order to support IPv6 > > Oh. You mean /IPv6/ whitelisting. > > >> access to their content that a small fraction of end users had slow >> or otherwise impaired access to a given web site with both AAAA and A >> resource records. The fraction of users with such impaired access >> has been estimated to be roughly 0.078% of total Internet users >> [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 >> Brokenness]. Thus, in an example Internet Service Provider (ISP) >> network of 10 million users, approximately 7,800 of those users may >> experience such impaired access. > > At a minimum, these sorts of statistics need to be normalized across IPv6 users/traffic, given how small a percentage that is in total users and total traffice. If that's what is meant it should be stated. If it isn't, the statistic should be recalculated. > > >> As a result of this impairment affecting end users of a given domain, >> a few major domains have either implemented DNS whitelisting or are >> considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations]. > > How or why does whitelisting affect slow performance for these folk? > > >> When implemented, DNS whitelisting in practice means that 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 resolvers which are not on the whitelist. It > > Oh. The whitelisting is for resolving a conflict between AAAA and A record choices? > > Normally, the term 'whitelisting' is used to refer to bypass anti-abuse mechanisms. This appears to be for something else and it seems odd to call it whitelisting. > > Note the more typical use of the term: > > <http://www.dnswl.org/> > > <http://en.wikipedia.org/wiki/DNSBL> > > <http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.help.domino.admin.doc/DOC/H_USING_DNS_whitelists_OVER.html> > > It appears that some v6 folks have chosen to co-opt a distinctive and very well established anti-abuse term for an entirely different purpose. > > > >> is important to note that these major domains are motivated by a >> desire to maintain a high-quality user experience for all of their >> users. By engaging in DNS whitelisting, they are attempting to >> shield users with impaired access from the symptoms of those >> impairments. >> >> Critics of the practice of DNS whitelisting have articulated several >> concerns. Among these are that: >> >> o DNS whitelisting is a very different behavior from the current >> practice concerning the publishing of IPv4 address resource >> records, >> >> o that it may create a two-tiered Internet, >> >> o that policies concerning whitelisting and de-whitelisting are >> opaque, >> >> >> >> >> >> Livingood Expires August 26, 2011 [Page 5] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> o that DNS whitelisting reduces interest in the deployment of IPv6, > > Well, it certainly suggests that there is a problem handling v4/v6 in dual stack environments cleanly. And it certainly seems that dealing with the underlying problem would be better. > > Beyond that, this appears to be a hack that is useful but not scalable. > > >> >> o that new operational and management burdens are created, > > well, yeah... > > >> o and that the costs and negative implications of DNS whitelisting >> outweigh the perceived benefits, compared to fixing underlying >> impairments. >> >> This document explores the reasons and motivations for DNS >> whitelisting. It also explores the outlined concerns regarding this >> practice. Readers will hopefully better understand what DNS >> whitelisting is, why some parties are implementing it, and what >> criticisms of the practice exist. > > > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf