* 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
