|
Hi Joe – Thank you for your thorough review and detailed response. Your feedback will be incorporated into a –04 update with other changes received in last call and from the IESG. (I'm still working through all of the changes though.)
In any case, see my detailed responses inline below. I appreciate any suggested changes to the proposed new text of course.
Regards
Jason
On 4/28/11 4:38 PM, "Joe Touch" <touch@xxxxxxx> wrote:
[JL] Thanks for the general feedback. As for the inclusion of CPE homogeneity being encouraged (Section 7.4) as a result of whitelisting, I am attempting to highlight that on the one hand there is a natural trend towards greater heterogeneity while whitelisting
policies may encourage an opposite trend back towards homogeneity. In part this is due to the fact that so may different types of CPE exist and these vary widely with respect to IPv6-related impairments and capabilities. But it seems that whitelisting approvals
for domains may occur more readily for those networks with a greater level of control (or complete control) over endpoints, where less variation in those devices exists as a result of that control, since the network can then push out device fixes for IPv6
impairments and so on. This is a tension that I know I as an ISP feel – on the one hand it seems desirable to have greater control over and less variation of CPE in order to win approval to be added to whitelists, while on the other hand there is a great deal
of pressure in the opposite direction to enable any IP-capable CPE to connect (often this is encompassed in various countries' "open Internet" or "network neutrality" guidelines).
[JL] This is an excellent suggestion. I have acted on it in the following ways:
1 – Added this to Section 2, How DNS Whitelisting Works:
"At a high level, using a whitelist means no traffic 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."
2 – I have added a new section in the solutions/alternatives, 8.4 Implement DNS Blacklisting, with the following text:
"Some domains may wish to be more permissive than if they adopted DNS whitelisting [Section 8.2], but not still have some level of control over returning AAAA record responses [Section 8.3]. An alternative in this case may be to employ DNS blacklisting,
which would enable all DNS recursive resolvers to receive AAAA record responses except for the relatively small number that are listed in the blacklist. This could enable an implementer to only prevent such responses where there has been a relatively high
level of IPv6-related impairments, until such time as these impairments can be fixed or otherwise meaningfully reduced to an acceptable level.
This approach is likely to be significantly less labor intensive for 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, which should be beneficial to all parties. This
is not to say that there will be no time required to work with those operators affected by a blacklist, simply that there are likely to be fewer such interactions and that each such interaction may be shorter in duration.
Of course one downside of this approach may be that the perception of being blocked (blacklisted) is sometimes worse that not being permitted to have access (whitelisted). However, 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."
[JL] This is a fair suggestion worthy of suggestion. However, I'm going to defer consideration of it until after I post the –04 if for no other reason than feedback I have already given that changes from someone with appear in some numbered section will
all be thrown off by such a change. So I'll come back to this one after pushing out the –04 update…
[JL] Good suggestion. I have added the following text as a new section, 7.8, Implications for Users of Third-Party DNS Recursive Resolvers, as follows:
" In most cases it is assumed that end users will make use of DNS recursive resolvers which are operated by their network provider, whether that is an ISP, campus network, enterprise network, or some other type of access 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 another 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 to the DNS recursive resolver is in an entirely different network. It may therefore be more challenging for a DNS whitelist implementer to determine
the level of IPv6-related impairment when such third-party DNS recursive resolvers are used, given the wide variety of end user access networks which may be used and that this mix may change in unpredictable ways over time.
There may also be cases where end users are using a network where the assigned DNS recursive resolver has not been whitelisted by a particular authoritative DNS server, but where the end user knows that a particular third-party DNS recursive resolver
has been whitelisted. While in most cases the end user will be able to switch to use that third-party's servers, some access networks may prevent switching to any DNS recursive resolvers other than those authorized by or residing within a given access network.
While the blocking of third-party DNS recursive resolvers may be observed in many types of networks such as ISPs, campus networks, and enterprise networks, this may most often be observed in the specialized networks setup in hotels, conference centers, coffee
shops, and similar access networks. In these cases, end users may be frustrated at their inability to access content over IPv6 as a result of their access network preventing them from using a whitelisted third-party DNS recursive resolver. This may also result
in complaints to both the operator of the authoritative DNS server which has implemented whitelisting as well as to the access network operator."
[JL] Change made!
Thanks again,
Jason
|
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf