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] DNS redirection for fun and profit
Jim, On Jul 16, 2009, at 1:30 PM, Jim Reid wrote: On 16 Jul 2009, at 20:58, David Conrad wrote: 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). OTOH, one might hope that if customer support got flooded with such calls the message that Tampering With DNS Responses Is A Very Bad Thing would eventually get through to those responsible for that behaviour and they'd take action to stop doing that. I can dream, can't I? Sure, but I was talking about was doing DNSSEC in a local resolver in the general case, not DNS redirection. BTW, almost all of the scenarios in Section 5 of draft-livingood-dns- redirect-00 are concerned with browser activity and HTTP redirection. So it seems to be wrong to (ab)use the DNS to solve what looks like a web problem. That appears to be a layering violation. Sure. I would agree with those who argue that DNS redirection is the wrong answer, pretty much regardless of what the question is. However, I'd prefer to have _one_ wrong answer instead of a myriad slightly different wrong answers. If you have a single wrong answer, you have a much better chance of being able to programmatically get around it. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS redirection for fun and profit
On 16 Jul 2009, at 20:58, David Conrad wrote: 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). OTOH, one might hope that if customer support got flooded with such calls the message that Tampering With DNS Responses Is A Very Bad Thing would eventually get through to those responsible for that behaviour and they'd take action to stop doing that. I can dream, can't I? BTW, almost all of the scenarios in Section 5 of draft-livingood-dns- redirect-00 are concerned with browser activity and HTTP redirection. So it seems to be wrong to (ab)use the DNS to solve what looks like a web problem. That appears to be a layering violation. I'm not sure it's wise to document DNS redirection as a BCP. [DNS redirection may well be a current practice, but is it a best practice?] I think this draft's next iteration should say a *lot* more about the dangers of fiddling with DNS data, particularly in the context of the impact on Internet applications that are not web browsers. ___ 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
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 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.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
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
* 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
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
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 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 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.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* 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
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. Crypting&signing 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
* 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
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.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
>> 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
> 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
>> 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
On Thu, Jul 16, 2009 at 08:07:50AM -0400, Livingood, Jason 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
Folks, I'd like to see descriptions of the major isp-initiated intercepts: o cn's provisioning of a name space that includes two entries not present in the iana root (ok, this may be less of a dynamic re-write feature), o idns's provisioning of name spaces with "idns", o other actors provisioning of name spaces with "other stuff" (new.net and its cognates), o vendor intercepts where (apparently) non-cached data is (apparently) pre-replaced with monitized data (ask for google, get google, ask for odd, get ppc, repeat twice to get odd instead of ppc), o ... Descriptions. Discussion of incoherence issues. Author-of-dork-asserted necessity-and-value. I also want to point out to recursive resolver opeators that there is a vehicle for policy development at ICANN, the ISP Constituency, which to date is simply been where major ISPs clutter up the landscape with their trademark lawyers and ignore all operational issues other than trademarks in the DNS. I'm always happy to learn what TimeWarner's trademarks portfolio manager's views are, but those happy moments have a home in the Intellectually Property Constituency and need not elbow all the operator issues out to ... the security and stability box of last-responders. Eric 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. 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
>> > 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 7/16/09 3:22 AM, "Stephane Bortzmeyer" wrote: > >> > 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. > > You can probably safely assume that any large ISP, as with any large company > that is relatively deliberate in their service offerings, might choose to > conduct usability studies, focus groups, and other user surveys prior to > introducing such services... > >> > If there is really a demand of some users, I have no problem with a > opt-in service, honestly explained to the users 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. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
[As before, my hat is off. Especially to Roy Arends and Tony Finch.] On Wed, Jul 15, 2009 at 07:46:17PM +0100, Tony Finch wrote: > A better way for ISPs to address that problem […] I am not trying to argue that the proposed solution is right; I am just pointing out that there is in fact a problem, as is shown by people trying to do something about it. On Wed, Jul 15, 2009 at 09:16:06PM +0200, Roy Arends wrote: > 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. I apologise: I'm not trying to suggest anyone here is having a tantrum. I assuredly do not wish to cast aspersions on Stephane or any other participant in DNSOP. I regard it entirely as a privilege to participate in these debates, and I have nothing but the deepest respect for other participants. I _am_, however, attempting to point out that there are some people interested in this topic who will think we are (collectively) having a tantrum. Hence the "stamping" remark. I want to argue, very strongly, that we need to be aware of the audience of which I am thinking, and be prepared to address their concerns too. Saying the identified issues are a non-problem is a good way to be dismissed as foolish purists who can't be taken seriously. Some of the use cases in the draft are not completely insane. I may not agree with the solution proposed, but I think one needs a better response than, "The DNS messages are sacrosanct," because we already accept some violations of the uniform namespace. > 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? 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. There is a legitimate issue in all this, and it is the deep philosophical one that Suzanne called out explicitly and to which I attempted to refer in my review of the draft. But the issues are subtle and not just simple things about namespace control and such like, because we have a lot of deployed systems and because the early standards documents don't offer anything in the way of definition of terms like "authoritative" or even, really, "answer". Our ultimate response to the proposal in the draft may well be, "It is a bad idea, and in its own terms here is why." But I feel very strongly that a response of, "That's not a real problem," is how we DNS weenies get to be dismissed as "ivory tower" types who don't understand how the world works. We can engage this problem face on now, or we can charter the DNS-BEHAVE working group in the future. The draft under discussion is our chance to decide. A -- 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
At 9:22 AM +0200 7/16/09, Stephane Bortzmeyer wrote: >On Mon, Jul 13, 2009 at 12:01:51PM -0700, > Paul Hoffman 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
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
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
* 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
* 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
On Mon, Jul 13, 2009 at 12:01:51PM -0700,
Paul Hoffman 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
On Mon, Jul 13, 2009 at 01:59:46PM +0200, Roy Arends 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
