Moneytizing error pages using DNS
Greetings to all, as you might guess from the subject, this mail is about a bad DNS trick. Our commercial people have been approached by some people in a subsidiary company trying to sell a "moneytizing product" that takes advantage of user error pages when serfing the web. In the subsidiary company the solution is already deployed in their production and it also involves cooperation with a search engine. The important thing is that Google refused to cooperate with them and they expressed their position against moneytizing error pages. Of course, the solution involves NXDOMAIN remapping. We as technical people are against the idea. Apart from technical implications that are difficult to explain to non-technical people, we would like to have some arguments supporting our position. Since a lot of people in this list might already have come across the problem (and some might already have implemented such a thing) I would be interested to hear your oppinions. Apart from respected voices expressing their opposition to such techniques [1], I would be interested in other arguments such as legal implications, costs or any other arguments anyone has used in a similar situation. By the way, there is an expired Informational rfc about the subject [2]. Cheers, Kostas [1] http://queue.acm.org/detail.cfm?id=1647302 [2] http://tools.ietf.org/html/draft-livingood-dns-redirect-03 -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\
On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote:
.... Of course, the solution involves NXDOMAIN remapping.
We as technical people are against the idea.
Well duh! :-)
Apart from technical implications that are difficult to explain to non-technical people, we would like to have some arguments supporting our position.
IMO Kostas, technical arguments are probably not going to be heard, no matter how distinguished the DNS experts are. Though one killer argument against NXDOMAIN rewriting could be DNSSEC. First off, it stops this nonsense. Or it reduces the scope for selling adverts when customers switch on DNSSEC or switch to a (paid for?) "secure" DNS resolving service. Next, DNSSEC deployment will be made more tricky for you if there are NXDOMAIN rewriters spreading their special kind of magic inside your network. Increased operating and support costs might support your position. For instance, maybe you'll need an extra DNS infrastructure: a "clean" one to run the network and another to do NXDOMAIN rewriting. [Maybe you'll have yet another for customers who expect a DNS service that doesn't tell lies.] This will of course complicate things and make life difficult for those doing customer support. For instance, what they see with the "clean" DNS is not the same as what the customers see. Bad Things happen to various services like email: mail goes to the IP address that serves up adverts instead of getting bounced. This could have all sorts of nasty legal issues: privacy, lawful intercept, etc. Remember the IAB statement on wildcarding which followed the SiteFinder debacle? However I doubt the beancounters and other members of the B ark will care about any of this. They will be salivating at the prospect of earning zillions from pay-per-click. So I think you need to construct arguments on business grounds: cost/benefit analysis, return on investment, customer support issues, etc. Questions that might be worth asking are how much money has the subsidiary spent on its NXDOMAIN solution, how much revenue it raises, what are the actual operating costs. I expect honest answers to these should settle the issue in your favour. Though the inevitable problem in most organisations is hadly anyone knows what DNS actually costs to run or the business impact of any service disruption.
On Oct 5, 2011, at 2:22 AM, Jim Reid wrote:
IMO Kostas, technical arguments are probably not going to be heard, no matter how distinguished the DNS experts are. Though one killer argument against NXDOMAIN rewriting could be DNSSEC. First off, it stops this nonsense.
Not necessarily. NXDOMAIN rewriting can occur _after_ validation. If you as an end user are relying on your ISP for resolution service, you are accepting whatever they tell you, be it truthful or lies. If your ISP blocks you from doing your own resolution, look for a new ISP (or VPN out to a resolver you trust).
However I doubt the beancounters and other members of the B ark will care about any of this.
Yep. On the brighter side, I've heard from folks involved in (very large) DNS infrastructure who have deployed NXDOMAIN redirection that the amount of money it brings in wasn't worth it and they're discontinuing the redirection stuff. Regards, -drc
On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote:
Apart from respected voices expressing their opposition to such techniques [1]
IMO it would be unwise to reference this article in any arguments you make. It could rebound on you very badly. BIND9.9 can do NXDOMAIN rewriting. So presumably ISC thinks this sort of thing is OK now. Sigh. If/when your opponents find this out, it fatally undermines the very sensible things said in that article.
On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote:
Apart from respected voices expressing their opposition to such techniques [1]
On 05.10.11 10:37, Jim Reid wrote:
IMO it would be unwise to reference this article in any arguments you make. It could rebound on you very badly. BIND9.9 can do NXDOMAIN rewriting. So presumably ISC thinks this sort of thing is OK now.
Actually, they do not. They only think that if someone should do it, (s)he should do it correctly and (they think) it's better to have the feature in BIND insteat of letting violators to implement it (and usually break it) themselves. I (and many other people) have disagreed with this point in bind-users mailing list.
Sigh. If/when your opponents find this out, it fatally undermines the very sensible things said in that article.
That's one of reason why I think it's bad feature to have in BIND. -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are...
On 5 Oct 2011, at 11:00, Matus UHLAR - fantomas wrote:
On 05.10.11 10:37, Jim Reid wrote:
IMO it would be unwise to reference this article in any arguments you make. It could rebound on you very badly. BIND9.9 can do NXDOMAIN rewriting. So presumably ISC thinks this sort of thing is OK now.
Actually, they do not.
Well it seems ISC has a rather strange way of showing their disapproval. If ISC truly thought NXDOMAIN rewriting was a Bad Idea, they would not have allowed this feature to embed itself in the reference DNS implementation. QED. IMO it sends out the wrong sort of messages and encourages those who advocate Stupid DNS Tricks. It's all very well for ISC to say they're just offering a "safer" way for people to play with these things. I take the view that this is a bit like letting children experiment with sharp objects when there's no responsible adult in charge.
Sigh. If/when your opponents find this out, it fatally undermines the very sensible things said in that article.
That's one of reason why I think it's bad feature to have in BIND.
+1. I'm very disappointed ISC has gone down this path.
Jim Reid <jim@rfc1035.com> writes:
On 5 Oct 2011, at 07:22, Kostas Zorbadelos wrote:
Thanks to everyone that provided feedback, on and off-list :) I think I have enough information to contruct my case.
Apart from respected voices expressing their opposition to such techniques [1]
IMO it would be unwise to reference this article in any arguments you make. It could rebound on you very badly. BIND9.9 can do NXDOMAIN rewriting. So presumably ISC thinks this sort of thing is OK now. Sigh. If/when your opponents find this out, it fatally undermines the very sensible things said in that article.
Now, this article also contains opinions on other matters I am not sure I support. For example, it also criticizes badly the use of DNS for load balancing on the grounds of "DNS was not designed to express policy". And what happens when a single machine is not enough to accomodate load? Do you employ NAT load balancers? Is this a better idea? Having a single "name" for a "service" seems to me like a good idea in general. Anyway, long talk, I guess it needs a thread of its own. Thanks again, Kostas PS1: Jim, you should REALLY reconsider your mail blacklist policies. Unless you do not prefer mail for person-to-person communication ;-) PS2: +1 against ISC for allowing the "feature" in bind. -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\
On Thu, 2011-10-06 at 15:17 +0300, Kostas Zorbadelos wrote:
Now, this article also contains opinions on other matters I am not sure I support. For example, it also criticizes badly the use of DNS for load balancing on the grounds of "DNS was not designed to express policy". And what happens when a single machine is not enough to accomodate load? Do you employ NAT load balancers? Is this a better idea? Having a single "name" for a "service" seems to me like a good idea in general. Anyway, long talk, I guess it needs a thread of its own.
Agreed, in particular NAT load balancers either limit the use of IPSEC in transport mode (which will become viable with ipv6), or will break horribly when people start using it. From my point of view, DNS seems to be the best load balancing strategy out there. Regards, Rasmus Larsen
Rasmus Larsen <rwl@tele.gl> writes:
On Thu, 2011-10-06 at 15:17 +0300, Kostas Zorbadelos wrote:
I don't know where it is best to start a discussion for this but I admit that load balancing interests me.
Now, this article also contains opinions on other matters I am not sure I support. For example, it also criticizes badly the use of DNS for load balancing on the grounds of "DNS was not designed to express policy". And what happens when a single machine is not enough to accomodate load? Do you employ NAT load balancers? Is this a better idea? Having a single "name" for a "service" seems to me like a good idea in general. Anyway, long talk, I guess it needs a thread of its own.
Agreed, in particular NAT load balancers either limit the use of IPSEC in transport mode (which will become viable with ipv6), or will break horribly when people start using it. From my point of view, DNS seems to be the best load balancing strategy out there.
This is a drawback in NAT load balancers I hadn't considered. Nice to know. Generally speaking, load balancing can be addressed either at the DNS or the routing layer. I am not aware of a "universal and clean" solution that would fit all purposes. An extra interesting thing is what will be used in IPv6 environments (which is a question posed also in the v6 WG in regards to RIPE 501)
Regards, Rasmus Larsen
-- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\
On Thu, 2011-10-06 at 15:17 +0300, Kostas Zorbadelos wrote:
Now, this article also contains opinions on other matters I am not sure I support. For example, it also criticizes badly the use of DNS for load balancing on the grounds of "DNS was not designed to express policy". And what happens when a single machine is not enough to accomodate load? Do you employ NAT load balancers? Is this a better idea? Having a single "name" for a "service" seems to me like a good idea in general. Anyway, long talk, I guess it needs a thread of its own.
On 06.10.11 11:04, Rasmus Larsen wrote:
Agreed, in particular NAT load balancers either limit the use of IPSEC in transport mode (which will become viable with ipv6), or will break horribly when people start using it. From my point of view, DNS seems to be the best load balancing strategy out there.
I'd say that's still problem of those load balancers, or their configuration (or IPSEC configuration). DNS is still one of worst place to try load balancing and failover switching. -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Matus UHLAR - fantomas wrote: [...]
DNS is still one of worst place to try load balancing and failover switching.
While I do agree with regard to failover, I am less convinced with regard to load balancing. Isn't that more like a question of: on which layer or plane do you want load balancing to happen? Like - fine-grained vs coarse-grained, TCP-connection-based, source-address of DNS client,...
* Kostas Zorbadelos:
We as technical people are against the idea. Apart from technical implications that are difficult to explain to non-technical people, we would like to have some arguments supporting our position. Since a lot of people in this list might already have come across the problem (and some might already have implemented such a thing) I would be interested to hear your oppinions.
BIND 9.9 will support NXDOMAIN and NODATA rewriting. This might change the trade-offs involved in a rather radical way. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Wed, Oct 5, 2011 at 9:22 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
We as technical people are against the idea. Apart from technical implications that are difficult to explain to non-technical people, we would like to have some arguments supporting our position. Since a lot of people in this list might already have come across the problem (and some might already have implemented such a thing) I would be interested to hear your oppinions.
Your best bet is to take this subject to the National Regulator (EETT). Since you cannot do this directly, you will insist on consulting with your legal department insisting that they research whether the National Regulator permits this, or it opens the possibility of a fine after users complain. Do not fight this inside the company. Change the terrain and take it where it really matters. -- http://gr.linkedin.com/in/yiorgos
Hi, There is a bunch of arguments in this document by ICANN's Security and Stability Advisory Committee: http://www.icann.org/en/committees/security/sac032.pdf -- Vladimir Vico
participants (9)
-
David Conrad -
Florian Weimer -
Jim Reid -
Kostas Zorbadelos -
Matus UHLAR - fantomas -
Rasmus Larsen -
Vladimir Vico -
Wilfried Woeber, UniVie/ACOnet -
Yiorgos Adamopoulos