In addition, there is now also http://tools.ietf.org/html/draft-livingood-dns-malwareprotect-01, which is the malware redirect draft. The WG requested that this be split off from the original draft, which we've now done.
Also in that original DNS redirect was a summary of redirect based on legal mandate and one for content filtering. I plan to hold off on investing time in either of those for now, unless the WG would like to see those specified in a new document. Jason On 9/6/10 2:30 PM, "Livingood, Jason" <[email protected]> wrote: >It's been a little over a year since the first draft on this subject was >submitted. I received a lot of feedback on that draft from the WG, >including a request to remove all forms of redirect mentioned other than >web error redirection (such as malware protection) and to add a much more >pointed section concerning DNSSEC. All of that should now be completed. > >I welcome any review and comment on >http://tools.ietf.org/html/draft-livingood-dns-redirect-02. > >Some key notes: >- snippet from Abstract: This document specifically and narrowly >addresses those cases where DNS Redirect is being utilized to provide a >web error redirect service to end users, and describes the critical >implications for DNS Redirect when DNSSEC is deployed. > >- snippet from new Section 4: DNSSEC Considerations and Implications: It >is critically important that service providers understand that adoption >of DNSSEC is technically incompatible with DNS redirect. As such, in >order to properly implement DNSSEC and maintain a valid chain of trust, >DNS redirect MUST NOT be used any longer. Thus, once DNSSEC is in >widespread use, this document should be considered historical. That being >said, sections of this document concerning opt-in and opt-out practices >may be useful for future reference in other, unrelated documents. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
