Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Ralf Weber wrote: 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. then a SERVFAIL will also result in an e-mail bounce that says connection refused instead of DNS error (assuming there's no e-mail sink on the host that is redirected to). Fun times for the helpdesk. I have the impression that even though it tries not to, the document still assumes that web==internet, mentioning problems 'non-web clients' only as a small side-effect, while imho it should be one of the main concerns (the www-case is the easy one). Also, I don't see how the ISP trust anchor for DNSSEC would work (not knowing the actual zone that it is supposed to cover in advance); it might be a better idea to simply disable all redirects on DO==1. Then again, I am of the persuasion that messing with a core protocol on the fly is simply asking for trouble, and disabling redirection should be top priority for everyone. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Ralf Weber: > 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. True, and some browser have code to deal with this. > 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. You can't create a CNAME alias to subdomain. And CNAMEs are not type-specific, so this would obscure SOA/NS/etc. at the zone apex. > 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. Can't you omit this stuff altogether? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Jul 9, 2009, at 5:23 PM, Livingood, Jason wrote: 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. This part of section 10 is troublesome: So the only case where DNS security extensions cause problems for DNS Redirect is with a validating stub resolver. This case doesn't have widespread deployment now and could be mitigated by using trust anchor, configured by the applicable ISP or DNS ASP, that could be used to sign the redirected answers. This mitigation strategy just doesn't work, and for a very good reason, as it allows a downgrade attack. As for the rest of the document, I think it overloads the term "redirection" by incorporating lawfully mandated filtering (whatever that means), and therefor wrongly justifying this practice altogether. In general, this kind of muddling with the DNS protocol assumes that the sole purpose of the DNS is to allow a web-browser find the address of a web-server. Clearly it is not. There are alternatives. I run unbound from my laptop. Windows users can do too: http://unbound.net/downloads/unbound_setup_1.3.1.exe Other alternatives are OARC's ODVR: https://www.dns-oarc.net/oarc/services/odvr Kind regards, Roy Arends ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Jelte Jansen: > Ralf Weber wrote: >>> 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. >> > > then a SERVFAIL will also result in an e-mail bounce that says > connection refused Not a hard 5xx error? > instead of DNS error (assuming there's no e-mail > sink on the host that is redirected to). Fun times for the helpdesk. Only if the mail server falls back to the A record if the MX lookup results in SERVFAIL, which seems like a questionable approach to me. Anyway, I think DNS rewriting is mainly for folks who also block 25/TCP in- and outgoing or list the address space on the PBL and similar DNSBLs, so the SMTP argument is not really valid anymore. > Also, I don't see how the ISP trust anchor for DNSSEC would work (not > knowing the actual zone that it is supposed to cover in advance); it > might be a better idea to simply disable all redirects on DO==1. You can't use trust anchors to guide rewriting. You need to look at the zone contents to see what can be done. With NSEC3 opt-out, there's still lots of wiggle room (at least initially). Generally not spoofing on DO==1 is easier, of course. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Florian Weimer wrote: * Jelte Jansen: Ralf Weber wrote: 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. then a SERVFAIL will also result in an e-mail bounce that says connection refused Not a hard 5xx error? not unless there's also a specific 5xx error generator listening on the host that is redirected to, i guess. instead of DNS error (assuming there's no e-mail sink on the host that is redirected to). Fun times for the helpdesk. Only if the mail server falls back to the A record if the MX lookup results in SERVFAIL, which seems like a questionable approach to me. is it? (i'm asking, i don't know; even the updated smtp rfc seems a bit unclear about that) Anyway, I think DNS rewriting is mainly for folks who also block 25/TCP in- and outgoing or list the address space on the PBL and similar DNSBLs, so the SMTP argument is not really valid anymore. well in that case it might be worth adding a section that your own services should definitely not have the same resolvers that you have set up for your customers, and that a separate non-lying resolver should be set up for those. But this is just an example of an unintended side effect from assuming that only web browsers ask for A/. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, 13 Jul 2009, Florian Weimer wrote: > * Jelte Jansen: > > > > then a SERVFAIL will also result in an e-mail bounce that says > > connection refused > > Not a hard 5xx error? No, both SERVFAIL and connection refused are equivalent to 4yz temporary failures. > > instead of DNS error (assuming there's no e-mail > > sink on the host that is redirected to). Fun times for the helpdesk. > > Only if the mail server falls back to the A record if the MX lookup > results in SERVFAIL, which seems like a questionable approach to me. Yes, it would be wrong to do that. > Anyway, I think DNS rewriting is mainly for folks who also block > 25/TCP in- and outgoing or list the address space on the PBL and > similar DNSBLs, so the SMTP argument is not really valid anymore. The draft should probably say something like that explicitly. However there's an unbounded number of similar problematic examples: what if the user is running an XMPP server? RFC 4084 is probably relevant. Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > -Original Message- > From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of > Stephane Bortzmeyer > Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00 > > Disclaimer: I find the whole idea a very bad one, a violation of > network neutrality and certainly a service I would never accept from > my ISP. While I strongly agree with Stephane's sentiment here, I do see some merits in describing why it is a bad idea instead of describing how it should be done with as little problems as possible (but still with problems). First thing that comes up is the lawyers and marketing concept that http is the Internet. The document is trying to avoid that discussion by saying that deep packet inspection should occur to determine that an http request was made, but then we're not talking DNS anymore. I get the strong feeling this is fundamentally against what RFC4367 is arguing about. Not only is it not true that the majority is only doing simple web browsing, but there are more and more applications and use of http, that would not allow a landing page to work. I can think of alternative ports of web pages that do http, but also application that use http on port 80 without it being a web browser. Think of embedded http video streaming, or other applications that use the http protocol without being a browser. More and more apps work like that. Another use case that I see a lot in small and medium size companies and even in the consumer market, and that I don't see described in the document is where a company runs 1 resolver on its own network and uses the resolver of its ISP as a backup or other redundancy reasons. If the ISP's resolver has a different truth than the own resolver, things will go very bad on the user experience side. The DNS is the DNS. There should not be multiple versions of the truth on the network. And finally, I also don't see a description on how things might go wrong if resolvers are behind a load balancer, and the 2 or more resolvers behind it don't have the same filtering policy in place. All in all I see more use cases where it degrades the user experience instead of improving it, and therefore it's a bad idea to do this in the network. It will force end-users to deploy their own resolvers and validators to get a better user experience, and while that might seem infeasible today for ordinary users, I can't wait for the first app to arrive that has a resolver built in instead of using the default OS resolver to bypass that trouble. Perhaps that built in resolver will even do DNS over http ! :-). Because that will downscale the use of cached responses, I wouldn't want to go that path as it would increase the load on authoritative servers. The only feasible use I see for a landing page is where it is invoked by an end-point in terms of a web browser that has it explicitly configured to go there when an NXDOMAIN is received by the application. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl http://www.sidn.nl/ -BEGIN PGP SIGNATURE- Version: 9.6.3 (Build 3017) wsBVAwUBSlsgUzqHrM883AgnAQgkFAgAjM/RguYXdKVL+/CeBK2OP2JsqsK1bVD6 nBmho2lpWNOh1pTllJYX5eaJzF24wDZ0P062u52P8qDMOuXOoKWP+pNRSvDKIzj6 XEyt5HazpnlY5+0mohuwDvNjRR9im2VN0vpt5LZhs3Z0EJR5ShHJJuU/xY6B5UoP QlEMyBfZZ3PPZSoR2AR4jJO9wTraDS5Q+zkwWSYUoIQskjBMGNjqhPfFF1m6IAoC UA4HWEDDQVfmY/mXtmCDigw4NorIJk2oakjSdYuF7MSaS3N3r1a0jnMNdHaV5LEg ddR2ieOc+VkXtLa7f+LNb2gJrtwaqlKoUKDWzFjVeAHzxzeLj9EydA== =eKJQ -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Jul 13, 2009, at 1:53 PM, Antoin Verschuren wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 -Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Stephane Bortzmeyer Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00 Disclaimer: I find the whole idea a very bad one, a violation of network neutrality and certainly a service I would never accept from my ISP. While I strongly agree with Stephane's sentiment here, I do see some merits in describing why it is a bad idea instead of describing how it should be done with as little problems as possible (but still with problems). SSAC's Report on DNS Response Modification http://www.icann.org/en/committees/security/sac032.pdf IAB Commentary Architectural Concerns on the use of DNS Wildcards http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html Kind regards, Roy Arends ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Good guidance on Informational vs. BCP. We may get there eventually, but I thought that starting as a draft BCP might provoke more detailed and useful debate. ;-) On the topic of lying resolvers¹ though, that seems a bit strong IMHO. But perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant RFC that you could refer me to? Jason On 7/11/09 7:59 PM, "Paul Hoffman" wrote: > It seems inappropriate for the IETF to bless lying resolvers as a Best Current > Practice. I doubt we as a community could have consensus on when lying is > good, when it is neutral, and when it is bad. Without such agreement, we can't > agree on how to run such servers. Having said that, the publication of a > document such as this (with more input from the community) as a Informational > RFC could indeed help the Internet. > > --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Thx for the feedback. I will try to address your concern in the 01 revision. If you have any specific textual recommendations, let me know. Jason On 7/12/09 3:34 AM, "Florian Weimer" wrote: > * 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. > 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
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
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" 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
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Good feedback, which I will take into consideration for our 01 revision. Please do note that Section 10 is definitely immature, as we noted in the Open Issues (#5) in Appendix B. We¹ll be developing this section quite a bit. Thanks Jason On 7/13/09 4:12 AM, "Roy Arends" wrote: > On Jul 9, 2009, at 5:23 PM, Livingood, Jason wrote: > >> > 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. > > This part of section 10 is troublesome: > > So the only case where DNS security extensions cause problems for > DNS Redirect is with a validating stub resolver. This case doesn't > have widespread deployment now and could be mitigated by using trust > anchor, configured by the applicable ISP or DNS ASP, that could be > used to sign the redirected answers. > > This mitigation strategy just doesn't work, and for a very good > reason, as it allows a downgrade attack. > > As for the rest of the document, I think it overloads the term > "redirection" by incorporating lawfully mandated filtering (whatever > that means), and therefor wrongly justifying this practice altogether. > > In general, this kind of muddling with the DNS protocol assumes that > the sole purpose of the DNS is to allow a web-browser find the address > of a web-server. Clearly it is not. > > There are alternatives. I run unbound from my laptop. Windows users > can do too: http://unbound.net/downloads/unbound_setup_1.3.1.exe > > Other alternatives are OARC's ODVR: > https://www.dns-oarc.net/oarc/services/odvr > > Kind regards, > > Roy Arends > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Thanks for the suggestion, Tony. I will add that to my tracking list for the next revision (and may email you to confirm what I have might be satisfactory). I think we probably also need to address the fact that mail servers should not use resolvers that perform DNS redirect (this was assumed but should be explicit). Regards Jason > >> > Anyway, I think DNS rewriting is mainly for folks who also block >> > 25/TCP in- and outgoing or list the address space on the PBL and >> > similar DNSBLs, so the SMTP argument is not really valid anymore. > The draft should probably say something like that explicitly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, 13 Jul 2009, Livingood, Jason wrote: > I think we probably also need to address the fact that mail servers > should not use resolvers that perform DNS redirect (this was assumed but > should be explicit). I think you need to widen that caveat: anything that isn't a web browser should not use a DNS server that misbehaves as described in this draft. Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On 7/13/09 10:08 AM, "Tony Finch" wrote: > On Mon, 13 Jul 2009, Livingood, Jason wrote: > >> I think we probably also need to address the fact that mail servers >> should not use resolvers that perform DNS redirect (this was assumed but >> should be explicit). > > I think you need to widen that caveat: anything that isn't a web browser > should not use a DNS server that misbehaves as described in this draft. > How would these servers identify themselves? And should clients believe servers that report they do not send back altered replies? This might work, but there would need to be a way for DNS resolvers to announce their configuration (e.g. redirect yes/no, DNSSEC yes/no, etc), which isn't available today. Scott > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > === Scott Rose NIST sco...@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ === ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
> I think we probably also need to address > the fact that mail servers should not use resolvers that perform DNS > redirect (this was assumed but should be explicit). At least when you do it on your recursive servers you're only affecting your own customers, who in most cases can vote with their wallets when they don't like it. When it's done on the authoritative servers no-one has a choice :( Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
At 9:55 AM -0400 7/13/09, Livingood, Jason wrote: >On the topic of 'lying resolvers' though, that seems a bit strong IMHO. But >perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant RFC >that you could refer me to? I am not aware of an RFC that says something to the effect of "when you are responsible for translating addresses and you get some information that was requrested, you MUST NOT lie about it to the requester", but it might exist. But that's immaterial. Even if the resolver has a good reason to lie, it is lying, and your document should encourage the resolver to be honest about that fact. The recipient might not care, or might very much want to be lied to to protect the recipient from doing something dangerous, but it should be made aware, if possible, that it is talking to a lying resolver. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, 13 Jul 2009, Tony Finch wrote: I think you need to widen that caveat: anything that isn't a web browser should not use a DNS server that misbehaves as described in this draft. I think you need to widen that caveat: anything should not use a DNS server that misbehaves as described in this draft. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Paul Hoffman wrote: At 9:55 AM -0400 7/13/09, Livingood, Jason wrote: On the topic of 'lying resolvers' though, that seems a bit strong IMHO. But perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant RFC that you could refer me to? I am not aware of an RFC that says something to the effect of "when you are responsible for translating addresses and you get some information that was requrested, you MUST NOT lie about it to the requester", but it might exist. That would be in the SLA the provider agrees to provide service under. Its part of the warranty for fitness, so while its not in the Standard itself - the use of the Standard to commit electronic fraud with will have criminal blow-back as well Paul. But that's immaterial. Even if the resolver has a good reason to lie, it is lying, and your document should encourage the resolver to be honest about that fact. The recipient might not care, or might very much want to be lied to to protect the recipient from doing something dangerous, but it should be made aware, if possible, that it is talking to a lying resolver. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.12/2234 - Release Date: 07/12/09 17:56:00 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
At 1:48 PM -0400 7/13/09, Paul Wouters wrote: >On Mon, 13 Jul 2009, Tony Finch wrote: > >>I think you need to widen that caveat: anything that isn't a web browser >>should not use a DNS server that misbehaves as described in this draft. > >I think you need to widen that caveat: anything should not use a DNS server >that misbehaves as described in this draft. Paul: that's over the top. Some of the services defined in the draft are highly desired by some Internet users. You may not like them, and that's fine. Your statement is akin to, and as useful as, the "NATs are bad so we shouldn't talk about them" debate that flares in the IETF approximately biannually. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Dear colleagues, On Thu, Jul 09, 2009 at 11:23:48AM -0400, Livingood, Jason wrote: > 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. I have read draft-livingood-dns-redirect-00. I have some (actually, many) comments. I write as a contributor of the DNS Operations working group and not in any other capacity (especially not as co-chair of DNSEXT). I will leave it for others to debate the extent to which the document actually proposes changes to the DNS protocol. I apologise for the length of this mail, but it seemed best to me to go over the document in detail. To begin with, I must state that I am opposed to adopting the draft as it stands as a working group item with a target of BCP. That said, I agree that if people are going to do these sorts of things, it'd be better that we have a document to explain what the least bad way to do them is (although one might be excused for wondering what "least bad" means in a context such as this). It is a fact that people are doing these DNS tricks, and we will not be saved from them by refusing to talk about them any more than we were saved from the stupidest possible NAT implementations by the IETF's collective refusal to work on NAT. Still, I am not sure that the document as it currently stands represents that "least bad", so there's some work to do. First, in section 3 we have a note that there are alternative strategies to DNS redirects. It is one thing to rule discussion of those alternatives out of scope; it is quite another to present the alternatives as completely neutral. This discussion should be strengthened to point out that performing redirects in the DNS have extremely wide consequences, and that the DNS-based approach is a terribly blunt instrument to perform what is intended to be surgical redirections, akin to doing an appendectomy with a club. In addition, I think the discussion should point out that DNS-based redirection violates the basic principle of the DNS: it is supposed to be a distributed, loosely-coherent database of records originally provided by authoritative sources of data. DNS redirections violate that principle by design, even if they do it for the noblest reasons. This is an important factor in the discussion of DNSSEC, to which I'll turn near the end of this message. I note this text in section 5.1.3: Design considerations for the Web Error Search and Malicious Site Protection services should include properly and promptly terminating non-HTTP connection requests. I would find it helpful if the draft included some text explaining how to terminate "non-HTTP connection requests" (and make a subsequent connection request operate correctly)? There's nothing in the DNS request that would tell a resolver whether the DNS query was happening because the client planned to make an http connection as opposed to something else. Is the idea to monitor DNS requests, then sniff the traffic to see if it's an HTTP request and then do something with that knowledge? (This sounds just shy of practically impossible to me, but I'd be happy to be wrong.) What about https requests? Surely, malware people will quickly learn to send the requests via https if that's a clear path, so that won't work. And anyway, one can't sniff encrypted traffic. In section 5.2.3, it says A range of resource records may be redirected, such as A, , MX, SRV, and NAPTR records, in order to fulfill the objective of preventing access to certain network elements containing malicious content or which and in some way used to transmit, relay, or otherwise transfer malicious content. All other resource record types must be answered as if there was no redirection. I think the last sentence is just a rhetorical flourish. It seems to say that any RR may be redirected, depending on the objective; but other ones must (MUST? I suppose this depends on where one stands on 2119 language in BCPs. If the authors want 2119 language, there are some other places that could do with it too) be answered as if there were no redirection. This boils down to, "Redirect whatever you think you need to." So the last sentence in the quoted bit is just decoration: it merely makes the passage read as though the technique isn't too invasive, but it has no practical effect. (Section 5.5 has this, too.) Section 5.3 ought to point out that legally-mandated DNS redirect may do harm, because the ability to send desirable traffic (such as cease-and-desist emails, for instance) is lost (this is especially important in light of the discussion of proxy servers at the end of 5.3.3). Section 5.3.3 reads like it was written by actual lawyers (note that in my idiolect, "lawyer" is not automatically a term of derision): there are here a lot of and/ors, other slashes, and lists of possible authoriti
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Great and detailed feedback on our first draft, Andrew. I'll take a reply in detail, point-by-point, when I start working on -01 with my co-authors and contributors. Thanks Jason On 7/13/09 4:29 PM, "Andrew Sullivan" wrote: > Dear colleagues, On Thu, Jul 09, 2009 at 11:23:48AM -0400, Livingood, Jason > wrote: > 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. I > have read draft-livingood-dns-redirect-00. I have some (actually, many) > comments. I write as a contributor of the DNS Operations working group and > not in any other capacity (especially not as co-chair of DNSEXT). I will > leave it for others to debate the extent to which the document actually > proposes changes to the DNS protocol. I apologise for the length of this > mail, but it seemed best to me to go over the document in detail. To begin > with, I must state that I am opposed to adopting the draft as it stands as a > working group item with a target of BCP. That said, I agree that if people > are going to do these sorts of things, it'd be better that we have a document > to explain what the least bad way to do them is (although one might be excused > for wondering what "least bad" means in a context such as this). It is a fact > that people are doing these DNS tricks, and we will not be saved from them by > refusing to talk about them any more than we were saved from the > stupidest possible NAT implementations by the IETF's collective refusal to > work on NAT. Still, I am not sure that the document as it currently > stands represents that "least bad", so there's some work to do. First, in > section 3 we have a note that there are alternative strategies to DNS > redirects. It is one thing to rule discussion of those alternatives out of > scope; it is quite another to present the alternatives as completely neutral. > This discussion should be strengthened to point out that performing redirects > in the DNS have extremely wide consequences, and that the DNS-based approach > is a terribly blunt instrument to perform what is intended to be > surgical redirections, akin to doing an appendectomy with a club. In > addition, I think the discussion should point out that DNS-based > redirection violates the basic principle of the DNS: it is supposed to be > a distributed, loosely-coherent database of records originally provided by > authoritative sources of data. DNS redirections violate that principle by > design, even if they do it for the noblest reasons. This is an important > factor in the discussion of DNSSEC, to which I'll turn near the end of this > message. I note this text in section 5.1.3: Design considerations for the > Web Error Search and Malicious Site Protection services should include > properly and promptly terminating non-HTTP connection requests. I would > find it helpful if the draft included some text explaining how to terminate > "non-HTTP connection requests" (and make a subsequent connection request > operate correctly)? There's nothing in the DNS request that would tell a > resolver whether the DNS query was happening because the client planned to > make an http connection as opposed to something else. Is the idea to monitor > DNS requests, then sniff the traffic to see if it's an HTTP request and then > do something with that knowledge? (This sounds just shy of practically > impossible to me, but I'd be happy to be wrong.) What about https requests? > Surely, malware people will quickly learn to send the requests via https > if that's a clear path, so that won't work. And anyway, one can't > sniff encrypted traffic. In section 5.2.3, it says A range of resource > records may be redirected, such as A, , MX, SRV, and NAPTR records, in > order to fulfill the objective of preventing access to certain network > elements containing malicious content or which and in some way used to > transmit, relay, or otherwise transfer malicious content. All other > resource record types must be answered as if there was no redirection. I > think the last sentence is just a rhetorical flourish. It seems to say that > any RR may be redirected, depending on the objective; but other ones must > (MUST? I suppose this depends on where one stands on 2119 language in BCPs. > If the authors want 2119 language, there are some other places that could do > with it too) be answered as if there were no redirection. This boils down to, > "Redirect whatever you think you need to." So the last sentence in the quoted > bit is just decoration: it merely makes the passage read as though the > technique isn't too invasive, but it has no practical effect. (Section 5.5 > has this, too.) Section 5.3 ought to point out that legally-mandated DNS > redirect may do harm, because the ability to send desirable traffic (such > as cease-
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Review of draft-livingood-dns-redirect-00I think that dns redirection is a double-sword. it will be good if it is used by good guy; it will be bad if it is used by bad guy. ICANN SSAC suggest to forbid the use of dns redirction. pls see http://syd.icann.org/files/meetings/sydney2009/presentation-ssac-prohibiting-redirection-22jun09-en.pdf. this draft is more suitable for informational. Yao Jiankang CNNIC - Original Message - From: Livingood, Jason To: dnsop@ietf.org Sent: Thursday, July 09, 2009 11:23 PM 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. Regards, Jason -- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, 09 Jul 2009, Livingood, Jason wrote: > 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). I think that this sort of lying recursive resolver is a bad idea. Instead, I suggest a new "SUGGESTION" RR type that could be returned in the additional section of an error message. For example, if you ask for www.example.invalid, you could get back an NXDOMAIN error, with "SUGGESTION URL=http://10.2.3.4/www.example.invalid"; in the additional section, and if you ask for censored.example. you could get back a SERVFAIL response with "SUGGESTION URL=http://10.2.3.4/why-we-censor.html"; in the additional section. Clients who want to follow such suggestions can then do so, without harming clients who don't want to be lied to. --apb (Alan Barrett) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
