Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Stephane Bortzmeyer: > Unless I'm wrong, the I-D about lying resolvers do not discuss the > issue of zone cuts. > > If I type www.doesnotexistatall.com (the SLD does not exist and so I > should get a NXDOMAIN), I get the IP address of the ad Web server. If > I type .afnic.fr, I will get this IP address as well, since the > QNAME does not exist (four 'w' instead of three) despite the fact that > the SLD does exist. This also interacts very badly the subdomain-based web trust model, so it should be mentioned in the Security Considerations section. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* 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
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
> -Original Message- > From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] > On Behalf Of Livingood, Jason > Sent: Thursday, July 09, 2009 8:24 AM > To: dnsop@ietf.org > Subject: [DNSOP] Review of draft-livingood-dns-redirect-00 > > I submitted this draft, which you can find at > http://tools.ietf.org/html/draft-livingood-dns-redirect-00, > before the -00 cutoff on Monday, and it will be discussed in > the DNSOP WG meeting at IETF 75 (it is listed on the agenda). > > If anyone is interested and has time before IETF 75, I'm > happy to take feedback before then obviously. Please note > that there is a list of open items at the end, which we plan > to address in subsequent versions. The draft would benefit from a discussion of the interaction with DNS64, draft-ietf-behave-dns64. The specific case that would be a problem is if the end user's host (or site) is doing its own DNS64 synthesis, which is necessary if the host (or site) is doing its own DNSSEC validation. -d ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Moin! On 12.07.2009, at 10:30, Florian Weimer wrote: 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). That really is an issue and could be addressed, there are a lot of case where a A record for a domain doesn't exists, but one for www.domain does exist. Question then would be how that rewrite should be presented. As a normal A answer or as CNAME referral which might be better as the underlying web server might not answer for the domain without www. The malicious site protection does not work reliably because it can be easily bypassed by the attacker, using IP addresses. Correct, but that hasn't stopped several governments from passing laws that exactly mandate this. 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. That is not the intention and not what I read there. Diversion of powers is a concept that is not even common among "western democracies". The text tries to stay away from these political issues, and instead makes clear that the local law, goverenment or jurisdictions should be honored where appropriate. 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. Again this is out of scope of the document. There may be countries that don't see it appropriate, but there are also countries that see it as appropriate including the one we two live in. [..] 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? This sounds like an excellent idea to help DNSSEC adoption and is something that should go into the draft. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: r...@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
