Subject: Re: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 25 Jan 2011 18:54:39 +0000

Erik -- Replies inline below and cc'ing the v6ops list since this is now a WG I-D. The changes you have suggested below will be made shortly in a -01 update of this draft.

Thanks for your feedback!
- Jason

On 10/1/10 6:03 PM, "Erik Kline" <[email-masked]<mailto:[email-masked]>> wrote:
[Section 2]

Your examples/diagrams imply <snip>

Thanks -- feedback at IETF 79 was also that Figure 2 should be revised. I was attempting to do something simple (such as in slide 4 of http://sites.google.com/site/ipv6implementors/2010/agenda/IPv6_Whitelist_Operations.pdf and ended up with a terrible diagram. This will be fixed.

[Section 3]

"Some parties" requires a reference.  Otherwise "some parties" might
just be you.  Since I know this is not the case, and I also know that
references exist, please link to one from here (and elsewhere).

[JL] Good point. I have added some references as well as modified the relevant text. If you have additional references, please advise (I've only included my own). Some parties in the Internet community, including ISPs like Comcast, are concerned that this emerging practice of DNS whitelisting for IPv6 address records could represent a departure from the generally accepted practices regarding IPv4 address records in the DNS on the Internet.

The "model" of DNS described is also not quite the current state of
the world.  "Everyone", in deliberate quotation marks, employs DNS
load balancing and any specific A RR may never be seen by some
requesters (usually because of geographic/network latency
considerations).  Your text implies that DNS for A RRs is currently
vastly more egalitarian than it actually is.  Perhaps discussion of
DNS load balancing and its relationship to whitelisting could
supplement section 4, which might then be relabeled "Similarities to
other DNS Operations", or something.

[JL] Point well taken. I have retitled section 4 to "Similarities to Other DNS Operations." The first sub-section is the old section 4 on split DNS and then I have a new sub-section on DNS Load Balancing. When the next version is released, let me know if you would like to see any changes to that section.

[Section 6]

All basically true; it's mostly about the end user experience.  This
is also the primary motivation behind DNS load balancing, the way CDNs
do it.

Although I'll add this odd anecdote.  In the course of discussing
whitelisting with a few different organizations I have actually been
told by some operators/administrators that they did not want us to
serve them AAAAs.  Upon further discussion what became clear is that
some folks don't want the full load of youtube traffic to shift to
their IPv6 infrastructure until they're ready to support it.

So yes, we've had requests from folks to /not/ be served AAAAs.  At
first I was surprised, but now I understand.

[JL] Good example -- I have added that to the draft.

[Section 7.1]

The end-to-end model does not prevail on the IPv4 Internet today.  See
previous comment.

[JL] I may be misunderstanding your comment but I still think the end-to-end model has value.

It is not clear how operators of authoritative servers for domains are
somehow "in the middle" of the network, except possibly as transit
points on the resolution path to subdomains.  Perhaps you mean "in the
middle" in some social or political sense?  In which case you may wish
to select a different document, or different subsection, to reference.

[JL] I think this section still have value. What I am trying to communicate (perhaps inelegantly) is that a simpler network architecture is better and that applying policy controls on a widespread basis in the public DNS could be problematic (and at a minimum would represent a new evolution in how the public Internet functions). Nevertheless, your point
about what I mean by the "middle" where with respect to authoritative servers is quite well taken and I have made some changes to try to address your concern in full.

[Section 7.2]

Again: not true in the IPv4 Internet today where DNS load balancing is
employed.

Note also that "reachability", in the true sense, is unaffected by the
whitelisting you're talking about.  It's network "knowledge" or
"awareness" that's affected.  There is no discussion of ACLs that
prevent IPv6 connections from succeeding, just like there is no
discussion of ACLs that prevent IPv4 connections from succeeding.
Whitelisting, as I believe you're trying to discuss it, only refers to
a resolver's awareness that an IPv6 address is associated with a
hostname.  No barriers to true reachability exist.

[JL] I've made changes to address this in the upcoming document.

[Section 7.4]

What is the definition of an "important domain"?

[JL] Those which are a major destination of traffic. I have changes this sentence, based on your question, to make this more clear.

[Section 7.5]

The relationship to governmental censorship seems imprecise, or
inapplicable.  In the governmental censorship case, logical access to
a resource is denied, as mandated by law.  In the whitelisting case,
logical access to a resource /remains unrestricted/.

[JL] I made changes to that section based on your feedback. My intention was not to describe wholesale, government-mandated domain blocking (I can see the confusion). Rather, I am trying to describe situations where various parties may use de-whitelisting as a retaliatory tactic in commercial disputes, or where parties such as governments may use it (perhaps temporarily) to express some dissatisfaction with other governments, etc. By the same token, I can envision whitelisting decisions could be made based on commercial pressures as well (such as "we'll only whitelist you if you agree to do X for us, or pay us Y, or break your affiliate agreement with our competitor, etc.).

[Section 7.6]

Do you have a reference to anyone who has publicly stated they are not
deploying IPv6 and that the principal reason for their not deploying
IPv6 is somehow whitelisting-related?

[JL] I do not have any public references, which is why I used the speculative "may…" in the sentence. I can tell you it has been informally discussed in this way in network operator circles (networks here not being just ISPs of course). I did modify the last sentence though, to make clear this is a possible situation.

[Section 9.1]

Quite the contrary: any implementation of DNS whitelisting that also
seeks to support DNSSEC must be extremely careful in doing so.  The
implications are very similar to those of DNS64.

[JL] Good point. I added some text to explain that an implementing domain must take special care if mixing DNSSEC and whitelisting.

Thank you
Jason