Having just gone through this entire thread again as prep for tomorow's WG meeting, I have a few minor comments that attempt to answer a few of the dangling questions:
1) Stephane is correct that http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html is talking about wildcards rather than redirect, but is (IMHO) wrong that in saying that this makes it irrelevant. That document includes a non-exhaustive list of things that were seen to break when RCODE 3 responses suddenly turned into redirections to an unexpected location. While the mechanism involved was different, many of the effects are the same regardless of the mechanism, so that list may provide a partial answer to Jason's request for information about things that redirection hacks break. 2) Without getting into whether one -should- do any of this, I don't think the DNSSEC "workaround" for validating stub resolvers even "works" (please don't give me a hard time about that word in this context) at a technical level. Others have hinted at this but not stated the reason, so, at least for Jason's benefit, here it is: unless I'm confused, this hack only "works" if the redirector strips off -all- DNSSEC data in -all- traffic to this resolver and replaces it with its own. In other words, this hack pretty much requires sign-on-the-fly for all DNSSEC traffic, which is unlikely to scale well. It also reduces the entire function of DNSSEC in this context to a weird and not very efficient form of channel security, and it seems unlikely that anyone would choose to get channel security this way. 3) As far as I can recall there is no explicit prohibition against modifying DNS data in transit in any standards track RFC, but there's something pretty close in an RFC old enough that it predates the current standards process. See RFC 973, specifically the section "Making up data". It doesn't talk about DNS redirect per se, but the overall intent seems reasonably clear (YMMV). --Rob _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
