5 ms·

DNS redirection (and the monetization thereof) is kind of a moot point in the mid/long term in light of DNSSEC. Consider the example of comcast, an ISP that us

by trotsky 16y ago

DNS redirection (and the monetization thereof) is kind of a moot point in the mid/long term in light of DNSSEC. Consider the example of comcast, an ISP that uses opt-out DNS redirection advertising, but has been forced to give up the practice for its DNSSEC resolvers: * We believe that the web error redirection function of Comcast Domain Helper is technically incompatible with DNSSEC. * Comcast has always known this and plans to turn off such redirection when DNSSEC is fully implemented. * The production network DNSSEC servers do not have Comcast Domain Helper's DNS redirect functionality enabled. * We recently updated our IETF Internet Draft on this subject, available at http://tools.ietf.org/html/draft-livingood-dns-redirect http://tools.ietf.org/html/draft-livingood-dns-redirect, to reflect this. -- http://www.dnssec.comcast.net/faq.htm http://www.dnssec.comcast.net/faq.htm

iopuy 16y ago
I'm sorry but where does Comcast come into play? Besides throttling my Internet connection.
- trotsky 16y ago
  By being one of the first commercial ISPs with a user facing DNSSEC deployment. The issue of DNS redirection being incompatible with DNSSEC is a technical one, here comcast is just an early report of the fact that they will cease all DNS redirection once DNSSEC resolvers are the default solution. Verizon and openDNS both will be in the same boat once client resolvers demand signed zones. It's no different than hearing about the results of a new RFC from google even if you use bing for search.
sp332 16y ago
Whoa, will DNSSEC prevent all DNS-level hijacking? OpenDNS has a DNS-level blacklist option (totally opt-in) which redirects to their own servers. Will that still be possible with DNSSEC?
- trotsky 16y ago
  As this amounts to A record forgery, yes DNSSEC clients will prevent this. There is really no technical difference between this practice and the poisoning that DNSSEC is defined to defeat. Of course there are plenty of other ways to blacklist or redirect IPs - using routes, RBL subscriptions in software firewalls or through browsers like the google safe browsing subscriptions. DNSSEC won't be the place to do it, though.
- blasdel 16y ago
  OpenDNS has a whole bunch of other opt-out (per IP) features that depend on DNS-level hijacking. By default they point NXDOMAIN to their own landing page, blacklist 'known phishing sites', and proxy some Google requests through their own servers to defeat clever browser address bars.
A1kmm 16y ago
I don't think that DNSSEC is going to be a sufficient hurdle: "When you first set up your Acme Internet Services account, you will need to set up your domain name servers correctly. This is a two step process which requires setting up your computer to use our DNS servers, and adding our security key as authorised on your computer". Most Internet users believe everything that their ISPs tell them about what is necessary to use their service, especially when it doesn't work until they do it, so getting users to add a new authorised root DNSSEC key is not going to be an impossible hurdle.
- trotsky 16y ago
  That's certainly possible, but I'd be surprised if it came to pass. Anyone who stopped by your house and used your wifi would need to take on your ISP keys, your DVD player would need to be able to accept them, etc. At this point the ad revenue wouldn't seem to make up for the bad user experience. It would be similar to an ISP requiring you to trust their root CA so they could MITM your SSL sessions. Sure, some enterprises do this through their management systems, but a big ISP that required this would likely get hit by a large amount of negative reactions.
tptacek 16y ago
I don't think this matters as much as you think it does for two reasons. First, the relationship your computer has with the DNS is as a "stub resolver", meaning that you rely on real DNS resolver hosted somewhere else to do the walk from the roots to the leaf names. DNSSEC doesn't protect (or, more appropriately, disrupt) stub resolution (a different protocol, TSIG, does this instead). If Comcast operates the real resolver and all you do is aim your computer at it, you have little opportunity to "disagree" with the results they feed you. Secondly, regardless of how much noise people may be making about DNSSEC's impending deployment (and it's been impending about as long as IPv6), the prospects for widespread DNSSEC adoption aren't great. It solves very few problems, is a bear to administer, and creates operational problems. Most of the Internet is (thankfully) oblivious to its attempted deployment.
- trotsky 16y ago
  You really think resolvers are going to be willing to forge the AD (authenticated data) bit when the data isn't authenticated? Even when it's so easy for a client or downstream caching only server to be set to validating and thus discover the forgery? Once you've determined that your server is willing to forge AD surely you'd have no reason to trust any other response it gives. DNSSEC deployment seems to be going rather well to me, compared to a year ago the root servers are signing, several major TLD's are signed, and common registrars support signed zones in those TLDs. Individual zone signing really isn't that difficult, and besides, almost everyone uses third party DNS hosting. Once a few major DNS hosters start signing zones by default you'll see adoption skyrocketing, don't you think?
  - davidu 16y ago
    No. tptacek is entirely correct. DNSSEC won't help here. DNSSEC is not exposed to applications the way SSL is and so you will never see widespread adoption. Take Chrome for example. Chrome is in the best position to make use of DNSSEC since it does it's own resolving, and even they don't see the value in it. They may do it in the background, but they won't make it user visible any time soon. Reasons from Chrome devs are very well articulated here: http://code.google.com/p/chromium/issues/detail?id=50874 http://code.google.com/p/chromium/issues/detail?id=50874 That said, I do believe that stub resolvers will go away, with every client running a full-blown recursor, but that still won't make DNSSEC solve the problems that need solving.

by trotsky 16y ago

iopuy 16y ago

I'm sorry but where does Comcast come into play? Besides throttling my Internet connection.

trotsky 16y ago
By being one of the first commercial ISPs with a user facing DNSSEC deployment. The issue of DNS redirection being incompatible with DNSSEC is a technical one, here comcast is just an early report of the fact that they will cease all DNS redirection once DNSSEC resolvers are the default solution. Verizon and openDNS both will be in the same boat once client resolvers demand signed zones. It's no different than hearing about the results of a new RFC from google even if you use bing for search.

sp332 16y ago

Whoa, will DNSSEC prevent all DNS-level hijacking? OpenDNS has a DNS-level blacklist option (totally opt-in) which redirects to their own servers. Will that still be possible with DNSSEC?

trotsky 16y ago
As this amounts to A record forgery, yes DNSSEC clients will prevent this. There is really no technical difference between this practice and the poisoning that DNSSEC is defined to defeat. Of course there are plenty of other ways to blacklist or redirect IPs - using routes, RBL subscriptions in software firewalls or through browsers like the google safe browsing subscriptions. DNSSEC won't be the place to do it, though.
blasdel 16y ago
OpenDNS has a whole bunch of other opt-out (per IP) features that depend on DNS-level hijacking. By default they point NXDOMAIN to their own landing page, blacklist 'known phishing sites', and proxy some Google requests through their own servers to defeat clever browser address bars.

A1kmm 16y ago

I don't think that DNSSEC is going to be a sufficient hurdle: "When you first set up your Acme Internet Services account, you will need to set up your domain name servers correctly. This is a two step process which requires setting up your computer to use our DNS servers, and adding our security key as authorised on your computer". Most Internet users believe everything that their ISPs tell them about what is necessary to use their service, especially when it doesn't work until they do it, so getting users to add a new authorised root DNSSEC key is not going to be an impossible hurdle.

trotsky 16y ago
That's certainly possible, but I'd be surprised if it came to pass. Anyone who stopped by your house and used your wifi would need to take on your ISP keys, your DVD player would need to be able to accept them, etc. At this point the ad revenue wouldn't seem to make up for the bad user experience. It would be similar to an ISP requiring you to trust their root CA so they could MITM your SSL sessions. Sure, some enterprises do this through their management systems, but a big ISP that required this would likely get hit by a large amount of negative reactions.

tptacek 16y ago

I don't think this matters as much as you think it does for two reasons. First, the relationship your computer has with the DNS is as a "stub resolver", meaning that you rely on real DNS resolver hosted somewhere else to do the walk from the roots to the leaf names. DNSSEC doesn't protect (or, more appropriately, disrupt) stub resolution (a different protocol, TSIG, does this instead). If Comcast operates the real resolver and all you do is aim your computer at it, you have little opportunity to "disagree" with the results they feed you. Secondly, regardless of how much noise people may be making about DNSSEC's impending deployment (and it's been impending about as long as IPv6), the prospects for widespread DNSSEC adoption aren't great. It solves very few problems, is a bear to administer, and creates operational problems. Most of the Internet is (thankfully) oblivious to its attempted deployment.

trotsky 16y ago
You really think resolvers are going to be willing to forge the AD (authenticated data) bit when the data isn't authenticated? Even when it's so easy for a client or downstream caching only server to be set to validating and thus discover the forgery? Once you've determined that your server is willing to forge AD surely you'd have no reason to trust any other response it gives. DNSSEC deployment seems to be going rather well to me, compared to a year ago the root servers are signing, several major TLD's are signed, and common registrars support signed zones in those TLDs. Individual zone signing really isn't that difficult, and besides, almost everyone uses third party DNS hosting. Once a few major DNS hosters start signing zones by default you'll see adoption skyrocketing, don't you think?
- davidu 16y ago
  No. tptacek is entirely correct. DNSSEC won't help here. DNSSEC is not exposed to applications the way SSL is and so you will never see widespread adoption. Take Chrome for example. Chrome is in the best position to make use of DNSSEC since it does it's own resolving, and even they don't see the value in it. They may do it in the background, but they won't make it user visible any time soon. Reasons from Chrome devs are very well articulated here: http://code.google.com/p/chromium/issues/detail?id=50874 http://code.google.com/p/chromium/issues/detail?id=50874 That said, I do believe that stub resolvers will go away, with every client running a full-blown recursor, but that still won't make DNSSEC solve the problems that need solving.