Jason, et al,
This note suggests changes in both style and detail in draft-livingood-dns-redirect-00. All of the points made here have been made or suggested by others in this thread; my intent is to underscore and elaborate on those points, rather than to challenge development and publication of the draft. I’ve seen enough postings to convince me that there actual is existing practice with significant deployment. The goal of the draft is to document that behavior. Debating whether the mechanism is ever reasonable or appropriate to deploy – and what alternatives might be more reasonable and appropriate might be productive, but not as part of the current exercise. The current exercise is one of technical specification. Given the coincidental timing, however, it’s worth citing a paper being presented at the CEAS conference today: Anti-Phishing Landing Page: Turning a 404 into a Teachable Moment for End Users <http://ceas.cc/papers-2009/ceas2009-paper-37.pdf> A few specific points: As with others, I think the draft needs to remove its promotional, persuasive or legalistic vocabulary. It’s a technical document, attempting to specify existing practice. So it should focus on technical details and operational trade-offs, without trying to sell the reader or protect against lawsuits. When the document recommends a particular choice, it should simply use RFC 2119 vocabulary. To the extent that there are tradeoffs, simply state what they are and which one(s) the document prefers (and possibly in what context.) That is, what technical or operational characteristics provide the basis for a particular recommendation? The long thread of discussion on the dnsop list has cited a number of alternative mechanisms for accomplishing the same, or similar, goals as the one described in the draft. To properly establish the context for use of this particular mechanism, the draft should diligently include all of these in its discussion of background, choices and tradeoffs. Not to debate the alternatives, and not to provide an extensive tutorial, but to explain the pragmatic reasons that the mechanism being specified is (regularly?) chosen in preference to those alternatives. The thread discussion has also produced references to a small, but very interesting, set of RFCs. These documents provide a rich background of relevant material; so the draft should carefully include each of these citations and discuss them in terms of the draft. Besides being basic due diligence, such a discussion might mitigate some people’s concerns about the mechanism specified in the draft. The draft’s discussion about the presence of DNSSec contains a nice case analysis of various configurations and scenarios, explaining how the mechanism works within each scenario. However it is easy to miss a key fact that the draft should provide in a simple, summary statement: When DNSSec validation is performed by the user’s resolver, this mechanism will fail. While the user will be denied access to the potentially problematic address, they will not not land at the alternative address. That is, this mechanism has long-term viability only when a user’s resolver does not implement DNSSec and, instead, relies on their operational infrastructure to validate DNS data. The draft specifies a mechanism that appears to work properly only for a single application service, namely the Web. Yet it characterizes all other services as exceptions. Instead, the draft should cast the mechanism as intended only for a single application and should provide substantive discussion about either how other services will continue to operate or why disrupting them is acceptable. This discussion is really the basis for understanding when the mechanism can be practical to deploy and when it cannot. A deeper issue: The draft demonstrates some confusion about the architectural role of the service it is specifyhing. Various postings on the mailing list discussion have offered a variety of alternative labels to refer to the mechanism; this serves to highlight the potential for misunderstanding what the specified service really is and when it is really reasonable to use. This could be caused by a pervasive confusion about the model for DNS service that this draft is affecting. A cliché in the technical community is that the only lesson of the Internet is scaling. While scaling to the level of a global Internet does teach quite a lot, its lesson does not seem to be as challenging as that of mediation. Networking is about mediated exchange. At every level, and for nearly all services, mediation mechanisms come into play: Between two principals, there are typically agents in the path, providing assistance. Some assistance is simply routing and forwarding. Other assistance plays with the payload. Assistance can be supplied by an agent of one of the principals – that is, at one end of the path – or by an independent operator along the path. These are important differences. IP routers and email relays, for example, route and forward an object (and its header) without modifying either. NATs, v4/v6 gateways and email gateways dive into the object (and its header) and make substantive – semantic – changes. Changing the endpoint identifier – that is, specification of the target address – is a major change, every bit as much as changing the “content”. The draft specifies a mechanism that does both. DNS vocabulary uses the word “resolver” to refer to one of the end-points and potentially one or more of the mediators in an exchange. This can be confusing. Equally, the term “redirect” is historically used to refer to a response by a principal, to specify an alternative address for the desired information. In contrast, in the draft, the term is used by 1) an intermediary, 2) to change the underlying nature of the provided information. As such, the mechanism is not a “resolver”. It is something else. In other words, the nature and details of the specified mechanism are quite different than what its terminology is typically used for. So I suggest changing the vocabulary and discussion, to avoid the confusion. Getting a usable term that is both noticeably different from “resolver” and meaningfully descriptive appears to be a challenge. “Intercept” is tantalizing but semantically inaccurate. “Proxy” might be the best compromise term, since other proxies tend to do translations, too. Personally, I’d wish for a word that is a little more striking, since the function is striking, but “proxy” is the best I’ve been able to come up with. What is essential is to make sure that the label does not permit one to think that this module is anything like a normal resolver. As with others, I suspect it is important to have the document more strongly distinguish between modified behaviors that occur because a government requires it, versus those triggered by some sort of blocklist, versus a simple NXDomain response. While the draft already cites these distinctions, I suspect there are design and/or operational differences for the different cases. At the least, the potential for differential handling should be discussed. If they all result in the same processing, that should be explained. Most importantly, the specification needs to characterize the environments in which it can be successfully deployed, versus others whereas it cannot. My current understanding is that the mechanism can work acceptably only in walled gardens (edge networks), where the operator has defined a substantially constrained user environment. In such places, email and other services are highly mediated by the operator. So the describee mechanism does not get in their way. Being clear about the pragmatic constraints that are required appears to be an interesting challenge for the paper. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop