Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Great feedback, Dave. Thank you and we¹ll take it into account as we work on a revision. Jason On 7/17/09 1:02 PM, Dave CROCKER d...@dcrocker.net wrote: Jason, et al, This note suggests changes in both style and detail in draft-livingood-dns-redirect-00. All of the points made here have been made or suggested by others in this thread; my intent is to underscore and elaborate on those points, rather than to challenge development and publication of the draft. I¹ve seen enough postings to convince me that there actual is existing practice with significant deployment. The goal of the draft is to document that behavior. Debating whether the mechanism is ever reasonable or appropriate to deploy and what alternatives might be more reasonable and appropriate might be productive, but not as part of the current exercise. The current exercise is one of technical specification. Given the coincidental timing, however, it¹s worth citing a paper being presented at the CEAS conference today: Anti-Phishing Landing Page: Turning a 404 into a Teachable Moment for End Users http://ceas.cc/papers-2009/ceas2009-paper-37.pdf A few specific points: As with others, I think the draft needs to remove its promotional, persuasive or legalistic vocabulary. It¹s a technical document, attempting to specify existing practice. So it should focus on technical details and operational trade-offs, without trying to sell the reader or protect against lawsuits. When the document recommends a particular choice, it should simply use RFC 2119 vocabulary. To the extent that there are tradeoffs, simply state what they are and which one(s) the document prefers (and possibly in what context.) That is, what technical or operational characteristics provide the basis for a particular recommendation? The long thread of discussion on the dnsop list has cited a number of alternative mechanisms for accomplishing the same, or similar, goals as the one described in the draft. To properly establish the context for use of this particular mechanism, the draft should diligently include all of these in its discussion of background, choices and tradeoffs. Not to debate the alternatives, and not to provide an extensive tutorial, but to explain the pragmatic reasons that the mechanism being specified is (regularly?) chosen in preference to those alternatives. The thread discussion has also produced references to a small, but very interesting, set of RFCs. These documents provide a rich background of relevant material; so the draft should carefully include each of these citations and discuss them in terms of the draft. Besides being basic due diligence, such a discussion might mitigate some people¹s concerns about the mechanism specified in the draft. The draft¹s discussion about the presence of DNSSec contains a nice case analysis of various configurations and scenarios, explaining how the mechanism works within each scenario. However it is easy to miss a key fact that the draft should provide in a simple, summary statement: When DNSSec validation is performed by the user¹s resolver, this mechanism will fail. While the user will be denied access to the potentially problematic address, they will not not land at the alternative address. That is, this mechanism has long-term viability only when a user¹s resolver does not implement DNSSec and, instead, relies on their operational infrastructure to validate DNS data. The draft specifies a mechanism that appears to work properly only for a single application service, namely the Web. Yet it characterizes all other services as exceptions. Instead, the draft should cast the mechanism as intended only for a single application and should provide substantive discussion about either how other services will continue to operate or why disrupting them is acceptable. This discussion is really the basis for understanding when the mechanism can be practical to deploy and when it cannot. A deeper issue: The draft demonstrates some confusion about the architectural role of the service it is specifyhing. Various postings on the mailing list discussion have offered a variety of alternative labels to refer to the mechanism; this serves to highlight the potential for misunderstanding what the specified service really is and when it is really reasonable to use. This could be caused by a pervasive confusion about the model for DNS service that this draft is affecting. A cliché in the technical community is that the only lesson of the Internet is scaling. While scaling to the level of a global Internet does teach quite a lot, its lesson does not seem to be as challenging as that of mediation. Networking is about mediated exchange. At every level, and for nearly all services, mediation mechanisms come into play: Between two principals, there are typically agents in the path, providing
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 David Conrad Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00 As far as I can tell, Comcast's network and their recursive servers are not a public resource. As folks on Comcast's network are not forced to be Comcast's customer nor (as far as I know) are they required to use Comcast's name servers, I don't see where you, this working group, or the IETF has a right to determine what Comcast does. I tend to disagree with you here. If Comcast is selling it's service as Internet service the general public might think that that's the way it should work, and we would all suffer from that general public's perception. If it would break some applications, a general user would think that the application is broken, not The Internet as offered by Comcast. So application builders will design their products to work on the broken Comcast network, or go bankrupt. I'm actually thinking that we are fighting this war on a wrong battleground. Just because DNS is wrongly considered to be the easiest hammer doesn't mean it fits every nail. I very much see the benefits of protecting innocent users from the bad of the Internet. But if it's web pages that are the bad thing, fight that. I'm very much in favor of writing a draft-arends-dns-response-modification-considered-harmful-00 I'll explain further on. At the same time, if I had enough knowledge of http(s), I would even want to contribute to a draft draft-verschuren-http(s)-intercept-and-redirect-00 Because I think that is the right battleground for this. I don't know where such a discussion should take place though, but certainly not here. So for harmful content of web pages, intercept and redirect http(s) traffic. For unclear errors in browsers when typos are made, fix the browsers. I'll explain where I see the conflicts. The Internet has gone above a technical definition. It's considered a brand name or at least a steady concept. (forgive my searching for the correct term as non-native speaker) The same is true, or even more, for domain names. TLD's and domain owners consider their domains as brand names, and might fight if somebody is affecting their autonomy. Since the game that's being played here is not about technology but about dollars, image, politics and policy, consider where this fight might end. The suggestion I'm making is not one I favor, but just as an indication of where the DNS redirection path might end: If ISP's start to mess up the authoritative answers for my TLD, I might consider protecting my brand name with a split view on my TLD. One view for proper resolvers, with real answers and NXdomains. The other view would be for lying resolvers where I would enter a wildcard so that my brand name TLD would show a proper error message without adds, preferred search engines or harmful content instead of the one from the lying resolver. I would do this to protect the image of the TLD as being a safe TLD to register your name in. It would protect my TLD against redirects that are not considered appropriate for the image or local policy under my TLD. I would make a blacklist of resolvers I know are lying, and redirect them to the wildcard view of the DNS infrastructure. This might even be imposed by ignorant local governments. This would be a war without an end, so again, I don't want to go this path. It will be a war between the ones with power and the ones with money, and in the end, it does not help the Internet user. So please, if harmful web content is the problem, fix that. Perhaps we need a screwdriver instead of a hammer. If unclear error messages in browsers are the problem, fix that. Perhaps we need a saw instead of a hammer. The dollars against politics war is one we're not going to win on instable technical solutions. 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) wsBVAwUBSmA6dzqHrM883AgnAQhTqggAsrRaGi/ZPuJ7ZnKUYtaKdxz7iaeyi2nU nCT/YXI4w/OudjyRapMmTvKGgb2tmGnN1nEPUXnwraDGV628HkqU/GJG6AwTq8X+ k3S7YGC5MUjgUVG/O1fux7oSMY4YmHhMngJWpBzhsAosA1yRtAGW/9iKZTs01t1S hYWssFkjLh+MGNn2t+FD93p8HsY4fiYcO2QZh8KZOTHPMCeezyni+ODxEMftbD+L aQLk8Hw/xJEf3TIfR8NE1csL+jV32yWKBFAebjq3+cNtGgH7eHRHuetHjxl2L5nW X3NK+zHswu9vvckmg5mTAoJ5u188Hgv2njS0DKFe8YdUKNK0DgNoVg== =ib4t -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
Livingood, Jason wrote: TLDs, including your own zones. This is indeed not just Site Finder all over again - it's far worse, and breaks far more applications than Site Finder did. Please do send me that list of applications. I would very much like to describe these use cases in the next version of the draft. No one said anything about a list. I'm merely making the general point that the more zones affected, the more applications affected. But to give one concrete example, DNS-based blacklists and whitelists will be impacted as they rely on NXDOMAIN responses to indicate that an address or name is not listed. -- Andreas Gustafsson, g...@araneus.fi ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On 16 Jul 2009, at 13:32, Livingood, Jason wrote: Please do send me that list of applications. I would very much like to describe these use cases in the next version of the draft. Yet another example. Many mail servers (including mine) reject SMTP connections from hosts that don't have reverse DNS. That's usually a strong indicator of a likely spam source. If some DNS redirector changes those NXDOMAIN/NOHOST responses to something else, those mail servers will accept inbound mail from places they wanted to reject. Many anonymous FTP servers behave(d)this way too, at least in the pre- web era. IIRC, some of the most useful/popular FTP servers did this to encourage people to fix their reverse DNS setup. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
At 9:15 AM +0200 7/16/09, Stephane Bortzmeyer wrote: On Mon, Jul 13, 2009 at 01:59:46PM +0200, Roy Arends r...@dnss.ec wrote a message of 33 lines which said: SSAC's Report on DNS Response Modification http://www.icann.org/en/committees/security/sac032.pdf Indeed. Good document. There is no need to discuss about draft-livingood-dns-lie, all the issues raised here in this WG were already in the SSAC document one year ago. I regret one thing with SSAC 032: they mix wildcards in the zone and lying resolvers. True, they have similarities but also differences (for instance, wildcards in a zone follow the DNS protocol, and therefore are compatible with DNSSEC) and I'm a bit tired of Slashdot discussions starting with Comcast == Sitefinder. I noticed this as well. Can someone from SSAC discuss here why that is the case? It is fairly relevant to this thread, given that a few people have wanted to see SAC032 discussed in the draft, but it doesn't seem relevant because of the difference. --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
At 8:16 AM -0400 7/16/09, Livingood, Jason wrote: I'll speak for my parents here: a DNS resolver that reduces the chance that they'll get a drive-by malware infection is something they would happily use. Having said that, a DNS resolver that gives them a page of search results instead of the browser's error page when they mistype a URL is something the *do not* want because it increases their confusion. IMHO malicious bots are an extremely concerning problem, and the problem of bot infections is much more widespread than many people realize. I'm in the early stages of contributing to a bot-related draft at http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 in case anyone is interested in providing private feedback (haven't really found a WG appropriate for the work). I hope that redirection is not an indicator that the -01 draft will continue to talk about the two scenarios as if they are somewhat equivalent. At 4:14 PM + 7/16/09, Suzanne Woolf wrote: I hope redirect-01 is more strictly descriptive and can drop defensive terms for DNS redirect, like enhancement of the user experience, since it's by no means agreed that crippling DNSSEC (for example) enhances the value of the Internet for anyone. +1. You can talk about why you are doing what you are doing without making it seem that the positive values are going to be be worth the negative side-effects. --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
Along with these good suggestions, the next draft should include a brief description of why the desired behavior (as seen by the user) is better performed through DNS tricks than through HTTP tricks. John On 2009Jul17, at 12:04 PM, Paul Hoffman wrote: At 8:16 AM -0400 7/16/09, Livingood, Jason wrote: I'll speak for my parents here: a DNS resolver that reduces the chance that they'll get a drive-by malware infection is something they would happily use. Having said that, a DNS resolver that gives them a page of search results instead of the browser's error page when they mistype a URL is something the *do not* want because it increases their confusion. IMHO malicious bots are an extremely concerning problem, and the problem of bot infections is much more widespread than many people realize. I'm in the early stages of contributing to a bot-related draft at http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 in case anyone is interested in providing private feedback (haven't really found a WG appropriate for the work). I hope that redirection is not an indicator that the -01 draft will continue to talk about the two scenarios as if they are somewhat equivalent. At 4:14 PM + 7/16/09, Suzanne Woolf wrote: I hope redirect-01 is more strictly descriptive and can drop defensive terms for DNS redirect, like enhancement of the user experience, since it's by no means agreed that crippling DNSSEC (for example) enhances the value of the Internet for anyone. +1. You can talk about why you are doing what you are doing without making it seem that the positive values are going to be be worth the negative side-effects. --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
Jason, et al, This note suggests changes in both style and detail in draft-livingood-dns-redirect-00. All of the points made here have been made or suggested by others in this thread; my intent is to underscore and elaborate on those points, rather than to challenge development and publication of the draft. I’ve seen enough postings to convince me that there actual is existing practice with significant deployment. The goal of the draft is to document that behavior. Debating whether the mechanism is ever reasonable or appropriate to deploy – and what alternatives might be more reasonable and appropriate might be productive, but not as part of the current exercise. The current exercise is one of technical specification. Given the coincidental timing, however, it’s worth citing a paper being presented at the CEAS conference today: Anti-Phishing Landing Page: Turning a 404 into a Teachable Moment for End Users http://ceas.cc/papers-2009/ceas2009-paper-37.pdf A few specific points: As with others, I think the draft needs to remove its promotional, persuasive or legalistic vocabulary. It’s a technical document, attempting to specify existing practice. So it should focus on technical details and operational trade-offs, without trying to sell the reader or protect against lawsuits. When the document recommends a particular choice, it should simply use RFC 2119 vocabulary. To the extent that there are tradeoffs, simply state what they are and which one(s) the document prefers (and possibly in what context.) That is, what technical or operational characteristics provide the basis for a particular recommendation? The long thread of discussion on the dnsop list has cited a number of alternative mechanisms for accomplishing the same, or similar, goals as the one described in the draft. To properly establish the context for use of this particular mechanism, the draft should diligently include all of these in its discussion of background, choices and tradeoffs. Not to debate the alternatives, and not to provide an extensive tutorial, but to explain the pragmatic reasons that the mechanism being specified is (regularly?) chosen in preference to those alternatives. The thread discussion has also produced references to a small, but very interesting, set of RFCs. These documents provide a rich background of relevant material; so the draft should carefully include each of these citations and discuss them in terms of the draft. Besides being basic due diligence, such a discussion might mitigate some people’s concerns about the mechanism specified in the draft. The draft’s discussion about the presence of DNSSec contains a nice case analysis of various configurations and scenarios, explaining how the mechanism works within each scenario. However it is easy to miss a key fact that the draft should provide in a simple, summary statement: When DNSSec validation is performed by the user’s resolver, this mechanism will fail. While the user will be denied access to the potentially problematic address, they will not not land at the alternative address. That is, this mechanism has long-term viability only when a user’s resolver does not implement DNSSec and, instead, relies on their operational infrastructure to validate DNS data. The draft specifies a mechanism that appears to work properly only for a single application service, namely the Web. Yet it characterizes all other services as exceptions. Instead, the draft should cast the mechanism as intended only for a single application and should provide substantive discussion about either how other services will continue to operate or why disrupting them is acceptable. This discussion is really the basis for understanding when the mechanism can be practical to deploy and when it cannot. A deeper issue: The draft demonstrates some confusion about the architectural role of the service it is specifyhing. Various postings on the mailing list discussion have offered a variety of alternative labels to refer to the mechanism; this serves to highlight the potential for misunderstanding what the specified service really is and when it is really reasonable to use. This could be caused by a pervasive confusion about the model for DNS service that this draft is affecting. A cliché in the technical community is that the only lesson of the Internet is scaling. While scaling to the level of a global Internet does teach quite a lot, its lesson does not seem to be as challenging as that of mediation. Networking is about mediated exchange. At every level, and for nearly all services, mediation mechanisms come into play: Between two principals, there are typically agents in the path, providing assistance. Some assistance is simply routing and forwarding. Other assistance plays with the payload. Assistance can be supplied by an agent of one of the principals – that is, at one end of the path – or by an independent operator along the path. These are
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, Jul 13, 2009 at 01:59:46PM +0200, Roy Arends r...@dnss.ec wrote a message of 33 lines which said: SSAC's Report on DNS Response Modification http://www.icann.org/en/committees/security/sac032.pdf Indeed. Good document. There is no need to discuss about draft-livingood-dns-lie, all the issues raised here in this WG were already in the SSAC document one year ago. I regret one thing with SSAC 032: they mix wildcards in the zone and lying resolvers. True, they have similarities but also differences (for instance, wildcards in a zone follow the DNS protocol, and therefore are compatible with DNSSEC) and I'm a bit tired of Slashdot discussions starting with Comcast == Sitefinder. IAB Commentary Architectural Concerns on the use of DNS Wildcards http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html Irrelevant since it talks only about wildcards in the zone. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, Jul 13, 2009 at 12:01:51PM -0700, Paul Hoffman paul.hoff...@vpnc.org wrote a message of 17 lines which said: Some of the services defined in the draft are highly desired by some Internet users. I did not hear them so this sort of users is obviously not in the dnsop WG :-) More seriously, noone mentioned here any survey about this. So, we can just guess and speculate. If there is really a demand of some users, I have no problem with a opt-in service, honestly explained to the users (We will modify legitimate DNS responses to blacklist some domains, to redirect you to other sites, if you agree, click here). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Alan Barrett: 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. This would be protocol development, so it's out of the scope of this WG. There's also the problem that some folks want to do DNS rewriting *now*. If client-side changes are required, they fear that they will out of business before they are implemented. (But I agree that a clean solution requires protocol development.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Paul Hoffman: Paul: that's over the top. Some of the services defined in the draft are highly desired by some Internet users. Which ones? Currently, when a user enters mcrsoft in the address bar, many browsers will automatically send her to the Microsoft homepage. With spoofed answers, he reaches some intermediate page instead, which may or may not be helpful. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, 16 Jul 2009, Mark Andrews wrote: The problem is not resolving portal.isp.com. The problem is that mail.xelerance.com resolves to portal.isp.com, but never makes it because my validating stub resolver has a DNSSEC key loaded for xelerance.com. A problem that in the future will become worse when the majority of the domains (and the root) is signed. Paul Well if xelerance.com is signed then internal (split dns) representations also need to be signed. I am not talking about internal. I am talking about a single DNSSEC signed zone that becomes unreachable because I'm behind a hotspot. this has nothing to do with split DNS and signing internal/eternal zones. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Stephane Bortzmeyer wrote: I regret one thing with SSAC 032: they mix wildcards in the zone and lying resolvers. True, they have similarities but also differences (for instance, wildcards in a zone follow the DNS protocol, and therefore are compatible with DNSSEC) and I'm a bit tired of Slashdot discussions starting with Comcast == Sitefinder. Another difference compared to Site Finder is that while Site Finder only added wildcards to the zones of certain top-level domains, web error redirection as described in the draft effectively behaves as if a wildcard had been added to every single zone in the DNS, not just every TLD but also the root zone and every zone delegated from the TLDs, including your own zones. This is indeed not just Site Finder all over again - it's far worse, and breaks far more applications than Site Finder did. -- Andreas Gustafsson, g...@araneus.fi ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
At 9:22 AM +0200 7/16/09, Stephane Bortzmeyer wrote: On Mon, Jul 13, 2009 at 12:01:51PM -0700, Paul Hoffman paul.hoff...@vpnc.org wrote a message of 17 lines which said: Some of the services defined in the draft are highly desired by some Internet users. I did not hear them so this sort of users is obviously not in the dnsop WG :-) More seriously, noone mentioned here any survey about this. So, we can just guess and speculate. I'll speak for my parents here: a DNS resolver that reduces the chance that they'll get a drive-by malware infection is something they would happily use. Having said that, a DNS resolver that gives them a page of search results instead of the browser's error page when they mistype a URL is something the *do not* want because it increases their confusion. --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
I'll speak for my parents here: a DNS resolver that reduces the chance that they'll get a drive-by malware infection is something they would happily use. Having said that, a DNS resolver that gives them a page of search results instead of the browser's error page when they mistype a URL is something the *do not* want because it increases their confusion. IMHO malicious bots are an extremely concerning problem, and the problem of bot infections is much more widespread than many people realize. I¹m in the early stages of contributing to a bot-related draft at http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 in case anyone is interested in providing private feedback (haven¹t really found a WG appropriate for the work). Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, Jul 16, 2009 at 08:07:50AM -0400, Livingood, Jason jason_living...@cable.comcast.com wrote a message of 76 lines which said: FWIW, I think most ISPs that introduce such services see around a 0.1% opt-out rate. What does it prove? Most ISP that introduces lying resolvers as an opt-in service see a 0.1 % opt-out rate, too. It proves only that most users do not dare to change the settings or are not informed or have no time to play with settings. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
SSAC's Report on DNS Response Modification http://www.icann.org/en/committees/security/sac032.pdf Indeed. Good document. There is no need to discuss about draft-livingood-dns-lie, Is that really necessary? all the issues raised here in this WG were already in the SSAC document one year ago. Indeed. **However,** the SSAC document seems to me to speak to TLD operators and registries, not ISPs. To wit, please refer to page 16, Preliminary Recommendations. With the exception of recommendation #4, these appear to me to all be related to actions by registrars and TLD operators. And Preliminary Recommendation #4 states that Third parties [defined in the paper to include ISPs] should disclose that they practice NXDomain response modification and provide opportunities for customers to opt out. You may wish to note that I expand at length on this preliminary recommendation from the SSAC paper in my draft. Regards, Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
TLDs, including your own zones. This is indeed not just Site Finder all over again - it's far worse, and breaks far more applications than Site Finder did. Please do send me that list of applications. I would very much like to describe these use cases in the next version of the draft. Thanks Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
FWIW, I think most ISPs that introduce such services see around a 0.1% opt-out rate. What does it prove? Most ISP that introduces lying resolvers as an opt-in service see a 0.1 % opt-out rate, too. It proves only that most users do not dare to change the settings or are not informed or have no time to play with settings. With respect, I am not trying to prove anything. I am merely providing data which you and others may find interesting and which may just inform debate a tiny bit. In terms of notifying users, I agree that this is important, and that settings (opt-out and opt-in) should be both easy to use and not take much time. I believe we even describe this in some detail in the draft, and I am happy to take specific feedback on those areas, as I would be delighted to be able to use your and others feedback to improve them. Thanks Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, 16 Jul 2009, Florian Weimer wrote: (But I agree that a clean solution requires protocol development.) No, it just requires browser user interface improvements. Tony. -- f.anthony.n.finch d...@dotat.at http://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
* Tony Finch: On Thu, 16 Jul 2009, Florian Weimer wrote: (But I agree that a clean solution requires protocol development.) No, it just requires browser user interface improvements. If you want to address the issue with hotspot doorway pages, you need protocol changes. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Livingood, Jason wrote: TLDs, including your own zones. This is indeed not just Site Finder all over again - it's far worse, and breaks far more applications than Site Finder did. Please do send me that list of applications. I would very much like to describe these use cases in the next version of the draft. Please list The Internet as one of them, it kinda encompasses a lot of others too. I am *VERY* happy that DNSSEC is moving along perfectly fine which will kill any kind of changing DNS results. Just a little example that even clued operators(*) get it wrong: https://lists.dns-oarc.net/pipermail/dns-operations/2009-July/004217.html Btw it also does it for IPv4 IPs: $ dig +short @208.67.220.220 127.0.0.1 67.215.65.132 $ dig +short @208.67.220.220 1.2.3.4 67.215.65.132 For that matter when the Internet in general gets too filtered by the ISPs in the middle, people will start using other methods. Cryptingsigning data to avoid modification will be the first steps. Those kind of applications, like BitTorrent which is a great example will rise outside of any IETF and get deployed and there is nothing that an ISP will be able to do about it unless they wall-garden the whole thing to just allow direct talking to specific servers and nothing else, but that won't be the Internet anymore of course Greets, Jeroen * = IMHO OpenDNS folks are doing a good job and they definitely know about the technical problems/challenges involved in the service they are providing, but they, like everybody else, are simply unable to catch all problems and foresee how applications (mis)use the DNS. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Jason Livingood: Actual consumer behavior doesn¹t really seem to work that way, but I¹m not a behavioral psychologist. ;-) FWIW, I think most ISPs that introduce such services see around a 0.1% opt-out rate. I would expect a higher rate of Dnschange/Zlob infections at a typical U.S. ISP. IOW, the 0.1% number doesn't seem to include users who just use some external DNS service. Anyway, for many users, the browser interface really doesn't change much. That's why it's hard for me to believe that this is done to improve user experience. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, 16 Jul 2009, Florian Weimer wrote: If you want to address the issue with hotspot doorway pages, you need protocol changes. Better to use an intercepting proxy in that case, and for quarantining infected hosts. Protocol changes aren't sufficient because if you just extend DNS without adding restrictions then cunning people can obtain connectivity via your resolver. I think these cases are qualitatively different from the main goal of this draft. A captive portal completely blocks normal connectivity, whereas this draft talks about selective blocks. Tony. -- f.anthony.n.finch d...@dotat.at http://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 Jul 16, 2009, at 5:43 AM, Jeroen Massar wrote: Livingood, Jason wrote: Please do send me that list of applications. I would very much like to describe these use cases in the next version of the draft. Please list The Internet as one of them, it kinda encompasses a lot of others too. Please. Enough hyperbole. I am *VERY* happy that DNSSEC is moving along perfectly fine which will kill any kind of changing DNS results. DNSSEC doesn't touch anything after the validator. It will have no effect on the vast majority of Comcast (or other consumer oriented) ISPs' customers. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Wed, Jul 15, 2009 at 09:16:06PM +0200, Roy Arends wrote: If you want a real analogy, think alternative roots. From the users perspective, that is what is happening here: an alternative namespace is created. Would we have a discussion at all if this perspective was used? Yes, we would. Well, maybe not we who have been contributing to this discussion on this list. But I've observed that telling people something they want to do is evil doesn't really help them decide not to do it. Telling them what harm will be done, or telling them that there's a better way to accomplish their business or operational objectives, is often more productive. I find myself in discussions of alternate roots on a regular basis. The most effective ones neither begin nor end with anyone being accused of anything except trying to meet legitimate objectives by the most effective means available. I'll go further and say that most of the time, they'd even prefer to minimize harm to others along the way. Even when the discussion is a disguise for an extortion play (Give us what we want or we'll take our toys and go home), asserting that the subject is not even to be raised merely gives it more power as a threat. Some people are going to read an informational RFC documenting use cases and mechanisms for DNS redirect as endorsement by the IETF. I submit, however, that the same people were going to do it anyway, probably in ignorance that there was any particular downside to it or really with any more knowledge about it than they get from their vendors. I would like to see some guidance from the WG chairs here. What is the next step. In lieu I propose the following: [1] Gauge consensus about adopting draft-livingood-dns-redirect-00 as a WG document. [2] if this draft is not adopted, we should at least get another work item on the list that documents the necessity to preserve the consistency of the namespace, adhering to the end to end principle, and educate folk that the DNS is not the web. All important points, and all belong in a discussion of the downsides of DNS redirect. Not that we should sit still and let this one go by. I actually think that the effort of writing a new draft might be lesser than the effort of trying to change draft-livingood-dns-redirect. I'll wait for redirect-01 and decide if its worth spending time on draft-arends-dns- response-modification-considered-harmful-00. I hope redirect-01 is more strictly descriptive and can drop defensive terms for DNS redirect, like enhancement of the user experience, since it's by no means agreed that crippling DNSSEC (for example) enhances the value of the Internet for anyone. (My defense of the draft is by no means to be read as endorsing DNS redirect. I don't, for reasons I believe are so compelling that I'm willing to try to work with others to articulate them and let people decide for themselves.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, 16 Jul 2009, David Conrad wrote: I am *VERY* happy that DNSSEC is moving along perfectly fine which will kill any kind of changing DNS results. DNSSEC doesn't touch anything after the validator. It will have no effect on the vast majority of Comcast (or other consumer oriented) ISPs' customers. Fedora 12 is slated to run with a validator on every machine. I would not be surprised if OSX and Microsoft go in the same direction. And the reason for that move is precisely because the enduser cannot distinguish malicious DNS modifications and beneign DNS modifications. So it is better to accept none. We are looking at how to resolve the DNS portal issues and non-dnsssec aware resolvers in the forwarder chain. There are some ideas that need more attention and thoughts. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Tony Finch: On Thu, 16 Jul 2009, Florian Weimer wrote: If you want to address the issue with hotspot doorway pages, you need protocol changes. Better to use an intercepting proxy in that case, and for quarantining infected hosts. Doesn't work if the user uses the employer's filtering proxy for web access. Protocol changes aren't sufficient because if you just extend DNS without adding restrictions then cunning people can obtain connectivity via your resolver. This would have to be part of DHCP, I think. DNS s too late. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
David Conrad wrote: On Jul 16, 2009, at 5:43 AM, Jeroen Massar wrote: Livingood, Jason wrote: Please do send me that list of applications. I would very much like to describe these use cases in the next version of the draft. Please list The Internet as one of them, it kinda encompasses a lot of others too. Please. Enough hyperbole. Unless you state that The Internet is only The Web, there are other users of The Internet though. Don't try and limit what other people can do with this public resource. I suggest that Internet Providers that are going to do these kind of filtering techniques rename themselves to Limited Web Providers. That is much more appropriate it seems. Or we'll just have to change IETF into OIETF for the Open Internet ETF. I am *VERY* happy that DNSSEC is moving along perfectly fine which will kill any kind of changing DNS results. DNSSEC doesn't touch anything after the validator. It will have no effect on the vast majority of Comcast (or other consumer oriented) ISPs' customers. The vast majority aha, so discrimination of the people who do want to actually have real truthful Internet is acceptable I know that certain countries claim to be all about 'freedom' and 'democracy' and I don't know what, but clearly those countries and the network operators in those countries want to restrict people more than the countries which simply state that they are doing that on purpose. As a user of the Internet I *am* running a validating DNSSEC recursor on my hosts. Thanks to ISC for the DLV :) I am fairly sure that a lot of other people will also want to do this. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, 16 Jul 2009, Florian Weimer wrote: * Tony Finch: On Thu, 16 Jul 2009, Florian Weimer wrote: If you want to address the issue with hotspot doorway pages, you need protocol changes. Better to use an intercepting proxy in that case, and for quarantining infected hosts. Doesn't work if the user uses the employer's filtering proxy for web access. I don't see why not, but even so, if they're already using a filtering proxy they are already safe, and the proxy is responsible for handling DNS lookup failures. Which reminds me, another way to solve this problem is using a proxy auto-config file. Tony. -- f.anthony.n.finch d...@dotat.at http://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 Jul 16, 2009, at 11:43 AM, Jeroen Massar wrote: Please. Enough hyperbole. Unless you state that The Internet is only The Web, there are other users of The Internet though. Don't try and limit what other people can do with this public resource. Could we ratchet down the rhetoric? DNS redirection does not break the Internet. DNS redirection can result in unanticipated responses. Some applications can behave in sub-optimal ways in the face of these unanticipated responses. This is a far cry from breaking the Internet. As far as I can tell, Comcast's network and their recursive servers are not a public resource. As folks on Comcast's network are not forced to be Comcast's customer nor (as far as I know) are they required to use Comcast's name servers, I don't see where you, this working group, or the IETF has a right to determine what Comcast does. The point Andrew tried to make is that the lesson we (should have) learned with NAT is that folks are going to deploy technologies that some may consider ill-advised or impure or evil or whatever if they find it to be in their interests to do so, regardless of what this working group or the IETF may say. In order to limit the proliferation of 'solutions', it is in the best interests of operators to standardize on an agreed upon approach and document the implications of that approach (both positive and negative) to ensure everyone understands what they're doing. Blocking these efforts resulting in various broken ways of doing the same thing are far more detrimental to the Internet than the existence of the standardized solution. DNSSEC doesn't touch anything after the validator. It will have no effect on the vast majority of Comcast (or other consumer oriented) ISPs' customers. The vast majority aha, so discrimination of the people who do want to actually have real truthful Internet is acceptable Might I suggest switching to decaffeinated? My statement is merely the truth. The vast majority of consumer oriented ISPs supply the DNS resolver settings to their customers. As such, validation would occur prior to the insertion of redirected responses. The exceptionally few applications that try to do validation on their own are so far in the noise as to be irrelevant. As a user of the Internet I *am* running a validating DNSSEC recursor on my hosts. Thanks to ISC for the DLV :) I am fairly sure that a lot of other people will also want to do this. A little perspective please. I'm fairly sure that you and everyone else who runs a validating DNSSEC recursor on their host are an infinitesimal minority of Internet users. More to the point, DNS redirection does not imply running your own recursor is disallowed. Yes, it can be implemented in such a way as break running your own recursor, but if this occurs, the right answer is to vote with your feet. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Jul 16, 2009, at 10:27 AM, Paul Wouters wrote: DNSSEC doesn't touch anything after the validator. It will have no effect on the vast majority of Comcast (or other consumer oriented) ISPs' customers. Fedora 12 is slated to run with a validator on every machine. This is the right direction to go. I would not be surprised if OSX and Microsoft go in the same direction. I would be. Quite. And the reason for that move is precisely because the enduser cannot distinguish malicious DNS modifications and beneign DNS modifications. So it is better to accept none. Except for most users, accepting none means the Internet is broken which will result in ISP or OS vendor support calls which will undoubtedly result in users being instructed to turn off validation (like they get told to turn off IPv6 today). We are looking at how to resolve the DNS portal issues and non-dnsssec aware resolvers in the forwarder chain. There are some ideas that need more attention and thoughts. Yep. It is annoying to have to stop using my local (validating) resolver any time I use T-Mobile hotspot service. I've given up using T-Mobile hotspot (where possible) for precisely that reason. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
In message 20090716110830.ga7...@shinkuro.com, Andrew Sullivan writes: Well, I'd discuss it, anyway. I know that if someone came with a document outlining the best way to do split-brain DNS -- which is widely deployed and an alternative namespace if ever I've seen one -- and especially how _not_ to do it, I would take it to be a serious contribution. Similarly, I am listed as one of the authors of the DNS64 draft, which is (let's face it) a way to configure an interative-mode resolver so that it consistently replaces one kind of answer with another kind (or lies, if you like). Yet nobody seems to have thought so far that _that_ is an especially bad idea. The big difference is that you still ultimately go to the machine that you are looking up. You are not changing the namespace by adding or removing names. Additionally the amount rewriting of queries will reduce over time as the world moves to IPv6. There is very little collateral damage being done by DNS64. There is a lot of collateral damage when you map NXDOMAIN/NXRRSET to a search page. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Wed, 15 Jul 2009, Andrew Sullivan wrote: Just because I know how to avoid going to phishing and malware sites does not mean it is within the competence of the average user. A better way for ISPs to address that problem is to run an intercepting web proxy that traps connections to infested web servers. The proxy can then intercept HTTP requests to malware-carrying URLs. (The UK's IWF blacklist is often implemented this way.) The intercept can be made specific to particular ports so it doesn't affect non-web protocols. It is consistent with what RFC 4084 calls firewalled internet connectivity. Even better would be for users to upgrade to a browser that implements its own safe browsing checks, and which has a decent user interface when DNS lookups fail. It's probably cheaper for ISPs to provide a local download site for a supported web browser than to implement a lying DNS resolver. Tony. -- f.anthony.n.finch d...@dotat.at http://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
At 2:47 PM -0400 7/15/09, Paul Wouters wrote: Tell me, what is the goal of this informational rfc? I can only tell you my goal, and I am not the author. My goal is to describe different types of lying resolvers so that someone can ask what type of resolver is that, based on the RFC WXYZ langauge? and get a reply. To list common methods for not adhering to standards and how to classify them? That works for me. and condemn some of them as bad? That works for me too, although I think it is not that useful to do so in an Informational RFC. Some marketing person is going to wave the RFC number and say It's allright, and my saying But it was only an informational is not going to make a difference. Oh, please. If you want to re-ignite the period flamewar about what RFCs should and should not be published, that's fine, but don't waste our time here with it. The DNSOP WG has no control over that issue. RFC 2026 is the reference, and repeated attempts to change it have met with failure. --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 Jul 15, 2009, at 6:29 PM, Andrew Sullivan wrote: On Tue, Jul 14, 2009 at 11:26:42PM +0200, Stephane Bortzmeyer wrote: DNS lying resolvers are not a solution to an actual problem (otherwise, doing it as an opt-in service would be sufficient). I cannot agree, as much as I would like to. If there weren't an actual problem here to be solved, nobody would be trying to do it. Just because I don't think typos in DNS names are hard to fix does not mean that there isn't a service there some people like (I have no idea whether they actually like it; I have seen zero studies of actual user impressions of these things). Just because I know how to avoid going to phishing and malware sites does not mean it is within the competence of the average user. And just because I think the cost of running a DNS server that generates no revenue is just the cost of doing business does not mean that the CFO of my favourite ISP agrees. Dismissing the things that people are actually doing on the network as solutions to non-problems is, I say, _exactly_ how we got to the point where NATs are used even when they're not needed, how we got firewalls that refuse to allow TCP over port 53, and so on. We can either listen to those who are proposing to do things, and try to come up with ways to limit the harm while pointing out the harm that is thereby done, or we can stamp our little feet and insist that they run their networks by our rules. I have little faith that path 2 will work. There is something fundamentally wrong with your statement, besides the incredible pedantic remark about stamping our little feet that seems to completely dismiss the overall sentiment of the WG. Dare I say consensus. If you want a real analogy, think alternative roots. From the users perspective, that is what is happening here: an alternative namespace is created. Would we have a discussion at all if this perspective was used? I would like to see some guidance from the WG chairs here. What is the next step. In lieu I propose the following: [1] Gauge consensus about adopting draft-livingood-dns-redirect-00 as a WG document. [2] if this draft is not adopted, we should at least get another work item on the list that documents the necessity to preserve the consistency of the namespace, adhering to the end to end principle, and educate folk that the DNS is not the web. We might not be able get folks to listen to our stamping little feet, but that is just far more preferable then to add to the tragedy of the commons and seeing rcode=3 go extinct. Not that we should sit still and let this one go by. I actually think that the effort of writing a new draft might be lesser than the effort of trying to change draft-livingood-dns-redirect. I'll wait for redirect-01 and decide if its worth spending time on draft-arends-dns- response-modification-considered-harmful-00. Kind regards, Roy Arends Nominet UK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Wed, 15 Jul 2009, Paul Hoffman wrote: and working with it. With manipulating my laptop's DNS asking for MY OWN cryptographically signed data, you are asking me to throw out the crypto protection and make me accept a downgrade attack. Then use a different DNS resolver. If I use my own validating stub resolver I can't make it to the portal page. If I use the dhcp supplied dns server, i cannot securely get to my sites. This document is about how to do one type of resolution, not all types. The document seems to list what it considers tolerable and intolerable DNS manipulations. My whole point is that no one will ever agree on those categorisations, and it is easier to draw the line at no endorsements. The IETF allowing or endorsing any kind of DNS forging in the age of DNSSEC is simply wrong. This is more hyperbole that does not help the discussion. The IETF is not in the position to not allow anything, and it never has been. An Informational RFC is not endorsing anything. If you want to endorse not doing what this proposed Informational RFC describes, write such a document and have it on standards track, or BCP. Tell me, what is the goal of this informational rfc? To list common methods for not adhering to standards and how to classify them? and condemn some of them as bad? Who is meant to be informed, and what is the goal of this information to such a person? Will this person be better able to design new protocols? deal with the current standards-breaking? Some marketing person is going to wave the RFC number and say It's allright, and my saying But it was only an informational is not going to make a difference. So I can clearly see the abuse of such an informational RFC, but I have yet to understand who this draft will benefit the community. And by classifying some DNS rewrites as bad and some as non-bad, this rfc becomes more then just a bit of information. It becomes an endorsement. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Wed, 15 Jul 2009, Paul Hoffman wrote: and condemn some of them as bad? That works for me too, although I think it is not that useful to do so in an Informational RFC. Then merge Section 7 Practices to Avoid with Section 8 Functional Design and leave out any (intended or not) judgement on what kind of DNS lying is to be avoided or tolerated, as there is clearly no concensus on which to avoid and which to tolerate. And change the title from Recommended Configuration and Use of DNS Redirect to something like Recommended Configuration to limit harm of DNS Redirect, and preface the document with a statement that all DNS manipulation is error prone, disfunctional with DNSSEC, and better done in other ways. Oh, please. If you want to re-ignite the period flamewar about what RFCs should and should not be published, that's fine, but don't waste our time here with it. The DNSOP WG has no control over that issue. RFC 2026 is the reference, and repeated attempts to change it have met with failure. This informational is suggesting via the recommended configuration to be a BCP document, not an informational. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
In message alpine.lfd.1.10.0907151439100.31...@newtla.xelerance.com, Paul Wou ters writes: On Wed, 15 Jul 2009, Paul Hoffman wrote: and working with it. With manipulating my laptop's DNS asking for MY OWN cryptographically signed data, you are asking me to throw out the crypto protection and make me accept a downgrade attack. Then use a different DNS resolver. If I use my own validating stub resolver I can't make it to the portal page. With proper configuration of the validating stub resolver and the recursive servers your validating stub resolver are using you should be able to make it to the portal page. I do agree that it makes it more complicated. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Thu, 16 Jul 2009, Mark Andrews wrote: If I use my own validating stub resolver I can't make it to the portal page. With proper configuration of the validating stub resolver and the recursive servers your validating stub resolver are using you should be able to make it to the portal page. I do agree that it makes it more complicated. With DNS redirection? I can see it with http redirection, but with my validating resolver, I would only be getting servfails? They either modify the data and invalidate the signature, or they strip out the DNSSEC and cause my validating to servfail? How would this work? I just wish there was a dhcp option for this. Then we could signal a landing page, and we could even signal the browser to wait and not try to reload (and destroy) all my tabs into 20 copies of the landing page. Paul ___ 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: Roy Arends r...@dnss.ec .. If you want a real analogy, think alternative roots. From the users perspective, that is what is happening here: an alternative namespace is created. Would we have a discussion at all if this perspective was used? I agree. This document is describing an alternative namespace, and this practice is harmful. It should be made clear that the IETF is firmly opposed to this practice. I would like to see some guidance from the WG chairs here. What is the next step. In lieu I propose the following: [1] Gauge consensus about adopting draft-livingood-dns-redirect-00 as a WG document. [2] if this draft is not adopted, we should at least get another work item on the list that documents the necessity to preserve the consistency of the namespace, adhering to the end to end principle, and educate folk that the DNS is not the web. We might not be able get folks to listen to our stamping little feet, but that is just far more preferable then to add to the tragedy of the commons and seeing rcode=3 go extinct. Not that we should sit still and let this one go by. I actually think that the effort of writing a new draft might be lesser than the effort of trying to change draft-livingood-dns-redirect. I'll wait for redirect-01 and decide if its worth spending time on draft-arends-dns- response-modification-considered-harmful-00. +1 I believe that draft-livingood-dns-redirect-00 is fundamentally misconceived and wrong. I oppose it's adoption as a WG document. You can put lipstick on a pig, but it's still a pig. Best wishes, George Barwood UK Kind regards, Roy Arends Nominet UK ___ 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
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On 7/14/09 8:58 AM, Suzanne Woolf wo...@isc.org wrote: In this case, we're talking about resolvers replacing authoritative server data with their own. Actually, I thought the case was resolvers providing an alternate response, where NO authoritative data exists. ?? To the draft specifically: the goal behind it is laudable, and a lot of the complaints about it are in the nature of shooting the messenger. I'm one of the people who shares the belief that there's no Best in this space to justify the BCP tag, but an informational document will be useful. I look forward to the -01 and the discussion in Stockholm. Yes, I suspect you may well be right on Informational vs. BCP. But I'm pleased with the detailed feedback I have thus far received. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Actually, I thought the case was resolvers providing an alternate response, where NO authoritative data exists. ?? An NXDOMAIN response is still authoritative data. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: r...@nominet.org.uk, t: +44 1865 332211 ___ 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, Andrew Sullivan wrote: Section 7.5 seems to suggest that there are cases where it is acceptable to intercept DNS queries and redirect them silently. These cases are typified as being reasonable, justifiable, c. The problem with any of this sort of thing is that it is the ISP who gets to decide what is reasonable. I presume that those ISPs who are capturing and blocking or, worse, redirecting all DNS traffic think it _is_ reasonable and justifiable. Since what is reasonable and justifiable is right at the core of disagreement, reasonableness and justifiability can't be the criteria. I suggest that discussion be removed: there just is no reason to capture the DNS traffic. If you want to turn someone off, _turn them off_. Captive portals come to mind, e.g. to authenticate to a wireless access point, or to quarantine a customer's virus-infested computer. Tony. -- f.anthony.n.finch d...@dotat.at http://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 Mon, Jul 13, 2009 at 09:55:42AM -0400, 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? It's always seemed to me that it was implicit in the DNS model that properly delegated authoritative servers determine what's true about a given portion of the namespace. That's why they're authoritative. Recursive resolvers ask for data, and they use data they got from authoritative servers to answer queries. They don't generate data from whole cloth. In contexts where I'm a domain owner, or responsible for the correct propagation of zone data from authoritative servers, I'm not going to be happy about intermediate resolvers rewriting my data on the fly. It renders the whole concept of the hierarchical namespace, with delegations of authority over various pieces of it, pretty much meaningless. DNS redirect is a fundamental violation of the assumptions behind the protocola philosophical violation, if you will. This means that it's esthetically unpleasant to a lot of people, but more to the point, that it's impossible to do cleanly. It's understood that service providers live in a world where such philosophical violations occur regularly, for all kinds of reasons. But you can't make people like it, particularly not by trying to dress it up. In this case, we're talking about resolvers replacing authoritative server data with their own. If you believe the model of DNS that I asserted above, lying is a defensible description. To the draft specifically: the goal behind it is laudable, and a lot of the complaints about it are in the nature of shooting the messenger. I'm one of the people who shares the belief that there's no Best in this space to justify the BCP tag, but an informational document will be useful. I look forward to the -01 and the discussion in Stockholm. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Tue, Jul 14, 2009 at 09:15:24AM -0400, Livingood, Jason wrote: On 7/14/09 8:58 AM, Suzanne Woolf wo...@isc.org wrote: In this case, we're talking about resolvers replacing authoritative server data with their own. Actually, I thought the case was resolvers providing an alternate response, where NO authoritative data exists. ?? I'm authoritative for this domain, and there's no such RR in it. The assertion there's no data at that name is part of the scope of authority, and NXDOMAIN is an authoritative answer. (See also the various tussles over empty non-terminals, authenticated proof of non-existence, and the precise semantics of DS records alongside a delegation in the parent zone.) Yes, I suspect you may well be right on Informational vs. BCP. But I'm pleased with the detailed feedback I have thus far received. Documented is better than not. Carry on. :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
At 9:15 AM -0400 7/14/09, Livingood, Jason wrote: On 7/14/09 8:58 AM, Suzanne Woolf wo...@isc.org wrote: In this case, we're talking about resolvers replacing authoritative server data with their own. Actually, I thought the case was resolvers providing an alternate response, where NO authoritative data exists. ?? The draft in question covers multiple scenarios, including the one in section 5.2, Malicious Site Protection. In that scenario, the lying resolver is purposely provides an alternate response authoritative date exists but the service provider wants to protect the querier from being harmed. Thus, your response above is wrong. By grouping different scenarios together in one document, it is difficult to differentiate obviously dangerous behaviors from potentially valuable behavior that queriers might want. --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 Tue, Jul 14, 2009 at 02:25:33PM +0100, Tony Finch wrote: Captive portals come to mind, e.g. to authenticate to a wireless access point, or to quarantine a customer's virus-infested computer. There are in fact ways to do that without mucking with DNS answers. Some portals do such things, and I contend that such approaches are always preferable. Ay -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Sat, Jul 11, 2009 at 04:59:38PM -0700, Paul Hoffman paul.hoff...@vpnc.org wrote a message of 8 lines which said: 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. I doubt it. IMHO, giving the amount of money at stake, there is a big risk that *any* RFC published on this topic, even Experimental or Historic, will be used by Comcast (or Verizon or Road Runner or another) in its advertisments The IETF approved today the RFC written by Comcast about the DNS Helper service. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, Jul 13, 2009 at 03:27:56PM +0100, ray.bel...@nominet.org.uk ray.bel...@nominet.org.uk wrote a message of 51 lines which said: 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. No, as I explained here: 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 is a very serious problem: when rewriting the NXDOMAIN of www.doesnotexistatall.com, you only harm the user. When rewriting the NXDOMAIN of .afnic.fr, you harm the holder of afnic.fr as well, since the ad Web site will appear to be under this SLD. Searching for a zone cut and not rewriting answers when there is a non-delegation domain in the path may be a solution, although I'm not sure it is possible to do it properly. (And I won't try since modifying DNS answers is a bad idea, anyway). When it's done on the authoritative servers no-one has a choice :( But at least you do not violate the DNS protocol (unlike what the DNS lying resolvers do). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, Jul 13, 2009 at 04:29:49PM -0400, Andrew Sullivan a...@shinkuro.com wrote a message of 33 lines which said: It is a fact that people are doingthese DNS tricks, and we will not be saved from them by refusing totalk about them any more than we were saved from the stupidestpossible NAT implementations by the IETF's collective refusal to workon NAT. There is a huge difference here: NAT was a solution to an existing problem, the lack of IPv4 addresses (remember that, when NAT started, the RIR were not even distributing IPv6 addresses, not to mention actual routing). Therefore, whatever the opinion of the IETF was, NAT were going to be a success. DNS lying resolvers are not a solution to an actual problem (otherwise, doing it as an opt-in service would be sufficient). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, Jul 13, 2009 at 09:20:12PM -0400, Livingood, Jason wrote:
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
jason
andrew pretty much covered it but just to be explicit,
my two biggest issues:
(1) for each proposed scenario, need to explain why not only is
it possible to incur some collateral benefits by falsifying
DNS responses, but why falsifying DNS responses is the Best
or Only way to achieve those benefits.
(2) especially given its legalistic tone, should acknowledge
that the legal territory this behavior occupies is unresolved,
and will likely be answered differently by different national
laws. somewhere near where you acknowledge explicitly this does
violate the intended use of this protocol \cite{}, and here
are the bad things that can happen as a result.
k
On 7/13/09 4:29 PM, Andrew Sullivan a...@shinkuro.com 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
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
On Mon, 13 Jul 2009, Paul Hoffman 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. There is a huge difference here. With NAT, one is putting some inconvenience to the end user and the server administrator that requires some clarifications in protocols and some support with detecting it and working with it. With manipulating my laptop's DNS asking for MY OWN cryptographically signed data, you are asking me to throw out the crypto protection and make me accept a downgrade attack. The IETF allowing or endorsing any kind of DNS forging in the age of DNSSEC is simply wrong. There can be other methods, such as DHCP related options, that can be used to notify or redirect a user without resorting to crippling DNSSEC security. I have serious problems with: 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. Validating stub resolvers will become the norm, with more and more devices connecting to whatever they can get (and not trust). Modifying DNS answers was a hack because there is no Please go here first with a browser DHCP option. We need to phase outsuch practises, and not endorse them in any way. In fact, most hotspots now grab port 80 for their redirects and allow DNS requests to go out unmodified, which is a much better way of handling the hot spot scenario. As for the various commercial races on who gets to sell ads on typoed domains, non-existing domains et. all, I think the IETF should not participate either. These fall in the same domain as the MIME type wars, the search engine setting wars, the home page changing wars, the file extension changing wars. Whatever the IETF would recommend, some vendor will override it because they are losing revenue because of it. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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
* 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.finch d...@dotat.at http://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 paul.hoff...@vpnc.org 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
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 r...@dnss.ec 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.finch d...@dotat.at http://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
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
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
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 authorities. For
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 a...@shinkuro.com 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-and-desist emails, for instance) is lost (this is
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
* 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
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
On Thu, Jul 09, 2009 at 11:23:48AM -0400, Livingood, Jason jason_living...@cable.comcast.com wrote a message of 69 lines which said: If anyone is interested and has time before IETF 75, I¹m happy to take feedback before then obviously. 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. 1) There is a lot of vocabulary which is more propaganda than technical description such as pretending in section 2 that it is an enhanced DNS service, which is very questionable. 2) ISPs and DNS ASPs must provide their users with a method to opt into (opt-in) or out (opt-out) of some or all DNS Redirect services. You need to add without delay or payment. 3) Only A and resource records should be redirected, all other resource record types must be answered as if there was no redirection. Does it mean that a request for MX or SRV, with the same owner name, will return NXDOMAIN? If so, it seems to me a strong violation of the DNS protocol. 4) About DNSSEC, 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. That's the most newspeak sentence of the I-D. I suggest to call this feature Authenticated Lie. 5) I find no reference to the two most relevant RFC here, RFC 4084 and RFC 4924 (section 2.5.2). For instance, ISP in France which have these services never advertise the fact to prospective customers, thus violating RFC 4084. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[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
