Thx for the **very detailed** and thoughtful feedback. I will review & respond in detail when I start working on the 01 revision.
Jason On 7/12/09 4:30 AM, "Florian Weimer" <f...@deneb.enyo.de> wrote: > * Jason Livingood: > >> > If anyone is interested and has time before IETF 75, I¹m happy to take >> > feedback before then obviously. > > Few players perform NXDOMAIN rewriting. Instead, ANCOUNT=0 rewriting > is used. This causes all kinds of problems, including redirections > for example.com when it hasn't got an A record (where some browser > would just fall back to www.example.com), and bad interactions with > IPv6 deployment (because all IPv6-only hosts suddenly have got an A > record). > > The malicious site protection does not work reliably because it can be > easily bypassed by the attacker, using IP addresses. > > Section 5.3 is pretty explicit in that government-mandated filtering > decisions should be made by executive organs, and not the judiciary. > The IETF should not try to regulate this and should certainly show > more respect for separation of powers. It should mention that > DNS-based filtering is not acceptable to many governments because it > can be bypassed easily, and it is not possible to block content on > popular sites where the collateral damage of a domain-wide block would > be problematic. > > Section 7.1 should be more strongly worded. Rewriting stuff like > search.msn.com (and reverse-proxying the HTTP traffic) must not be > condoned by a RFC. Such things are just evil. > > No redirection on SERVFAIL seems to be a strange recommendation. > Wouldn't this be a very good reason to provide a diagnostics page, > especially if there's been a DNSSEC validation failure? > > As it stands, the product list in Section 8.3 serves no particular > purpose. Some analysis which browser-based mechanisms are broken by > DNS redirection might be helpful, but this could be done in a > product-independet manner. > > Section 8.4 should mention that some (most?) rewriters do not rewrite > subtrees which involve a delegation from the TLD level. This > addresses a huge range of technical issues. > > DNSSEC interoperability doesn't work the way you expect because once > the resolver is security-aware, it will set the DO bit queries, and > you cant tell the non-validating resolvers from the validating ones. > It's also not an all-or-nothing thing because validation depends on > availability of trust anchors. So you'd have to spoof your answer > according what's permitted by the signed data (particularly the > NSEC(3) records; you don't have to validate the signatures yourself). > > The draft must mention DNSBL interactions (and, more generally, the > impact on applications which use DNS as a transport for RPC). It > should describe approaches how to mitigate issues identified (such as > the IPv6 problem), and show the impact in terms of increased query > count. > > There's also a policy impact for ICANN. Restricted TLDs such as .tel > are not feasible if DNS rewriting essentially removes restriction on > TLD contents. This also applies to e164.arpa subtrees, where some > national regulators have requested that their subtrees can only be > used for ENUM (and not arbitrary DNS information). > > While I'm mostly with Stephane regarding the merits of DNS rewriting, > I think the IETF could still publish a draft on this topic. However, > it should present pretty stringent requirements which ensure that > rewriting does not adversely impact operations. The current draft is > closer to a fig leaf, I'm afraid. > Regards, Jason Jason Livingood Executive Director Internet Systems Engineering National Engineering & Technical Operations Comcast Cable Communications 215-286-7813 jason_living...@cable.comcast.com This message and any attachments to it may contain PROPRIETARY AND CONFIDENTIAL INFORMATION exclusively for intended recipients. Please DO NOT FORWARD OR DISTRIBUTE to anyone else. If you are not the intended recipient, please contact the sender and delete all copies of this e-mail from your system.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
