Bell Starts Hijacking NX Domain Queries

inject_hotmail.com writes "Bell Canada started hijacking non-existent domains (in the same manner as Rogers), redirecting NX-response queries to themselves, of course. Before opting-out, you get their wonderfully self-promoting and self-serving search page. When you 'opt-out,' your browser receives a cookie (isn't that nice) that tells them that you don't want the search page. It will still use their broken DNS server's non-NX response, but it will show a 'Domain Not Found' mock-up page that they (I surmise) tailor to your browser-agent string. During the opt-out process, they claim to be interested in feedback, but provide no method on that page (or any other page within the 'domainnotfound.ca' site) to contact them with complaints. They note that opting-in is 'recommended' (!), and that 'In order for opt-out to work properly, you need to accept a "cookie" indicating that you have opted out of this service. If you use a program that removes cookies, you will have to repeat this opt-out process when the cookie is deleted. The cookie placed on your computer will contain the site name: "www.domainnotfound.ca."' Unfortunately most Bell Internet users won't understand the difference between their true NX domain response, and Bell's injected NX response."

Comments

Well, that's the bad old bell...

[Pig Hogger]

Well, that's the bad old ma Bell that's still alive and kicking in Canada.

Re:Well, that's the bad old bell...

[YayaY]

I can't wait to see this go in front of the CRTC.

Re:Well, that's the bad old bell...

[Anonymous Coward]

Why? Do you really expect them to bite the hand that feeds in any significant way?

Re:Well, that's the bad old bell...

[Trails]

Two points:

1) You will wait. A very long time.
2) When the waiting is over, nothing will happen. Rogers has been running this annoying crap for months and nothing's happened

To anyone annoyed at this from rogers or bell, point your dns to opendns, the rogers (at least) name servers suck balls anyways.

Re:Well, that's the bad old bell...

[KillerBob]

I did write a letter to the CRTC about Rogers' practices, and CC'd Rogers. If enough people do it, they'll do something about it... When I called Rogers to complain, they suggested I use OpenDNS, but OpenDNS does the same thing. Does anybody know a free/open DNS server that doesn't do that kind of crap?

*sighs* for now, I've taken some clock cycles on my internal fileserver, and set up a DNS server. Not happy with Rogers at all. But don't have any alternatives where I live.

Re:Well, that's the bad old bell...

[AvitarX]

I think you can configure OpenDNS to not do it if you setup an account.

Re:Well, that's the bad old bell...

[mmkkbb]

Here are some. I don't know which ones hijack NX responses, but the 4.2.2.x entries seem reliable.

Re:Well, that's the bad old bell...

[TikiTDO]

They're alive, and not doing too badly. I was actually planning on switching soon, as they were advertising 16Mbps service for way cheaper than Rogers. Of course if they're pulling crap like this, I'd rather stay with the evil I know and have learned to tolerate.

It does not help that Bell has a strangle hold on half of the Canadian internet infrastructure. Combine with Rogers, and trash likes this becomes common place with next to no recourse.

Re:Well, that's the bad old bell...

[Magic5Ball]

At least OpenDNS is clueful enough to filter out BS like the following:

http://www.domainnotfound.ca/bellassist/dnsassist/content/ErrorPage/_iceUrlFlag=15?_IceUrl=true&q=www.non-existent-domain.com-INSERT-MALWARE-HERE%3CSCRIPT%3E

Re:Well, that's the bad old bell...

[Anonymous Coward]

You can configure OpenDNS to not do the same thing, based on your IP address. It will then act like a normal DNS server when you look up a host that doesn't exist (and not that simulated error page junk with a cookie that Rogers and Bell are pulling, ugh). It's what I do at home, with Rogers, and works like a charm, especially since my IP never changes (otherwise you'll need to update your IP through OpenDNS).

Re:Well, that's the bad old bell...

[Anonymous Coward]

Mock up website is vulnerable to XSS. I'm sorry I have to point out the uselessly obvious.

Re:Well, that's the bad old bell...

[Luthair]

Yep, and unfortunately they've been allowed to push around the resellers like Teksavvy.

Re:Well, that's the bad old bell...

[michaelhood]

Nice find..

http://preview.tinyurl.com/lb3fo3

Re:Well, that's the bad old bell...

[commodore64_love]

1) You will wait. A very long time.
2) When the waiting is over, nothing will happen. Rogers has been running this annoying crap for months and nothing's happened

I wonder if hiring the mafia to kill the Bell or Rogers CEO would get their attention? "It's not personal - it's just business and your stupid hijacking is interfering with ours." BANG.

Re:Well, that's the bad old bell...

[Anonymous Coward]

Not happy with Rogers at all. But don't have any alternatives where I live.

If you're on Rogers, use 64.71.255.202 as a DNS server. It's the non-hijacking server they set up after many users complained the re-directing was buggering up remote workers and VPN users.

It won't be pushed out through DHCP, but it works fine as a static setting.

Re:Well, that's the bad old bell...

[KillerBob]

Thank you *SOOOO* much! That fixed it.

Gods. I shouldn't have to write to the regulatory board to get my ISP to follow standards.... >. Somebody moderate that reply up, I don't want to see it get buried in poor moderation-land.

Re:Well, that's the bad old bell...

[chrish]

I'm still wondering how they can offer faster-than-5Mbps connections, but none of the third-party DSL companies can. It's the same last mile that's shared, after all.

Last mile should be owned by the municipalities so anyone can take advantage of it. It's been built out by our tax dollars, and Bell and Rogers clearly aren't willing to spend any money upgrading things or even providing half decent service at a reasonable price.

Happy TekSavvy user here, unhappy Rogers cell owner (contract is up in a couple of weeks, but my "choices" for new service suck just as much).

Re:Well, that's the bad old bell...

[Anonymous Coward]

..Just goes to show you can't judge a company by their cute retro pixel-graphic ad campaign.

Re:Well, that's the bad old bell...

[Luthair]

I believe the CRTC only mandates that Bell resell at a minimum of 5 Mbps; at the time this wasn't a bad speed but of course technology has advanced since. The ideal solution in my mind would be to mandate that Bell provide resellers the speed few years prior, this would encourage them to continue to innovate if they want an advantage yet still provide competition. Otherwise we're stuck in the stagnant duopoly unless a city decides to lay fibre/ethernet.

(A real pipe dream would be to split the physical network and content providing parts of Bell Canada and Rogers into separate companies so we could have true competition, but that is unlikely)

In general I don't think that the last mile has been paid for by taxpayers.

From a typical web surfer's point of view

[BadAnalogyGuy]

These pages are helpful for the typical web surfer. In fact, an automatic URL "fixing" service would be one of those revolutionary Web 2.0 features that exists in the recesses of the web, part of the infrastructure and totally natural to use.

Yes, it breaks some scripts and runs contrary to published standards, but it presents a new (actually pretty old) conception of how the web should work.

Re:From a typical web surfer's point of view

[nicolas.kassis]

This should be handled at the infrastructure level. DNS doctoring is bad for many reason. I'm sure a firefox or IE addon would actually be much more preferable. Something easy to dis-activate when things break.

Re:From a typical web surfer's point of view

[Anonymous Coward]

That's fine, but whether or not it's helpful for the typical Web surfer is completely irrelevant.

It's a clear example of a layering violation. If you want URL fixing, great, but do it in the browser, don't hijack DNS which other services depend on.

As far as I am concerned, it is really is clear cut that this shouldn't be happening!

Re:From a typical web surfer's point of view

[qortra]

These pages are helpful for the typical web surfer

How is that? By encouraging them to use a search engine with which they are unfamiliar, or by leading them away from their intended target with advertising. Look at the Sample Page again, and explain to me the utility in that crap. Domain errors should ideally result in a big red "X" so the user knows to turn around and try again.

In fact, an automatic URL "fixing" service would be one of those revolutionary Web 2.0 features that exists in the recesses of the web, part of the infrastructure and totally natural to use.

Now this is an interesting idea. Let me tell you the best way to handle this - on the client side, after the proper DNS opportunities have been exhausted. This is because the client best knows the users browsing proclivities (most often viewed pages, favorite search engines, etc).

Re:From a typical web surfer's point of view

[superdana]

This isn't about the web, this is about the Internet--there's a difference. The web is just one tiny piece of the Internet, and there are 65,000 other services that require a properly functioning domain name system. Screwing it up in a way that only "works" for the web is totally unacceptable.

Re:From a typical web surfer's point of view

[Anonymous Coward]

These pages are helpful for the typical web surfer. In fact, an automatic URL "fixing" service would be one of those revolutionary Web 2.0 features that exists in the recesses of the web, part of the infrastructure and totally natural to use.

Yes, it breaks some scripts and runs contrary to published standards, but it presents a new (actually pretty old) conception of how the web should work.

BadAnalogyGuy: astroturfing since 2009.

Re:From a typical web surfer's point of view

[Useful Wheat]

I think you're wrong that this is helpful to the typical surfer. Sprint does exactly the same thing to me, and their redirect search page is a clone of google, but with one important "feature" that google missed. Not a single item on the page is returned from a search, its all advertising and sponsored links. I have never seen such worthless search results in my life. They allow you to opt out of the page with a measly 6 clicks, and you end up with a cookie (just like in TFA), but its still an annoying process that I have to go through every time I dump my cache. If ISPs want to sell this as a feature, they need to return useful search results, instead of worthless advertisements. Also (and I know this is fantasy) they need to make it opt-in.

Re:From a typical web surfer's point of view

[dirk]

It also breaks functionality of if basic programs. For example we have a lot of people that use Outlook Anywhere, and it will be broken by this. By default, it checks for the internal server first, and when it can't find it, it then jumps to Outlook Anywhere. Except now it gets a response for the internal server, and then waits forever for a timeout. So now we'll have even more people calling us asking why they can't get their email when they could before. We already have a list of 10 or so ISPs that we tell our users not to use for this very reason.

Re:From a typical web surfer's point of view

[superdana]

cat /etc/services

There ya go. And no, it doesn't just affect HTTP. They're intercepting NX responses from DNS, so any software that relies on DNS--anything that has anything to do with the Internet--won't work properly when a nonexistent domain is entered.

Re:From a typical web surfer's point of view

[jimicus]

The web is an incredibly huge piece of the internet.

Please tell us about these 65,000 other services that need a properly functioning DNS. Since the only protocol affected here is HTTP, and the only applications that use invalid URLs are either human-driven (browsers) or malware, I suggest that the NX response is fundamentally outdated and useless.

Not true. The DNS doesn't know if the thing making a request is a web browser or something else, so it affects literally every protocol. SMTP, POP3, SMB, everything. Only now, when you try to debug something like that it looks like the server does exist, it's just ignoring SMTP connections. You spend ages barking up completely the wrong tree.

Even more fun is if the person affected is trying to work from home over a VPN link. If it's set up for split tunnelling, it'll try to resolve a hostname using the default DNS first and only if that fails will it try the VPN. Hint: Windows uses DNS to resolve hostnames for fileshares. All of a sudden, internalhost.yourcompany.com resolves on the public internet and they're trying to save their files to a server that's run by their ISP (and, naturally, isn't offering any SMB fileshares). Cue a bunch of angry calls to the helpdesk.

Re:From a typical web surfer's point of view

[characterZer0]

the only protocol affected here is HTTP

No, every protocol directed at an address obtained by DNS is affected.

Re:From a typical web surfer's point of view

[blueg3]

How is the only protocol affected HTTP? When a DNS query is made, it doesn't state what it's for -- regardless of the protocol to come, the DNS query is the same. Yet when an NX should be returned, a valid but incorrect response is returned. This is quite a significant difference.

Re:From a typical web surfer's point of view

[mini me]

Some browsers do attempt to "fix" URLs. These services break those features, since the domain is always resolved properly as far as the browser is concerned.

Re:From a typical web surfer's point of view

[Sillygates]

I have written scripts for my job, which would break dns was hijacked by my isp. It's not acceptable.

I added a stub section to an article on wikipedia about this a while ago, it would be great if someone would lengthen it ;-)

http://en.wikipedia.org/wiki/DNS_hijacking#Use_by_ISPs

Re:From a typical web surfer's point of view

[Anonymous Coward]

WTF are you talking about? Quite a few modern browsers already do the same thing that this service does (switch to search on an NX response) - this is about $$ for the telco, nothing else.

Re:From a typical web surfer's point of view

[colk99]

What about when the search page gets infected with antivirus 2009 or links to antivirus 2009

Re:From a typical web surfer's point of view

[digitig]

This is because the client best knows the users browsing proclivities (most often viewed pages, favorite search engines, etc).

Nowadays I have a horrid suspicion that the server knows the user's browsing proclivities better than the client.

Re:From a typical web surfer's point of view

[Shin-LaC]

How about FTP, IRC, all sorts of file sharing protocols? All sorts of messaging/chatting/voice protocols that don't use a single corporate point of failure? VNC, RDP, all sorts of services one might want to run on his home computer and access remotely via dynamic DNS, or run at work and access from home?

Here, let me explain it in terms you should understand. Imagine that you get lost while driving. You should have reached your destination, but you're not sure, so you ask a passerby. "Is this 417 Pine Street?" Now, if you're driving a car, the man tells you "No, this is an abandoned warehouse. You need to go back and make a turn at...", and tells you the directions. BUT, if you're driving anything but a car, he tells you "Yeah, this is the place, but everyone is gone."
And now you're saying: "But I only ever drive cars!"
Maybe, but people also drive bikes, trucks, etc. Even if you only drive cars, you'll probably want delivery trucks to get to the right place when they're delivering stuff to you!

But just as you're pondering that, you get beat up by a gang of bikers.

Re:From a typical web surfer's point of view

[DavidTC]

Only now, when you try to debug something like that it looks like the server does exist, it's just ignoring SMTP connections.

And, those of us running mail servers set up often set them up so we don't accept mail, from our own users, addressed to invalid domains. Which means they get immediate feedback, in their email client, that they made a typo in the domain name and the message wasn't sent and is still up on their screen to be edited, instead of having the mail happily go off and a few hours later noticing it bounced, and having to fish it out of the Sent folder and remail it.

Return an actual result to a computer that isn't running a mail server, and not only does the 'bogus submitted domain' blocker not work, but it also results in the damn email sitting there for 72 hours as the mail server repeatedly tries to connect to a mail server that is not running on that IP.

Granted, ISPs doing this interception aren't going to bother people, people don't normally run mail servers over cable connections, but when Network Solutions decided to do it for .com, it indeed broke everything.

Re:From a typical web surfer's point of view

[Dishevel]

If you have no clues as to what you are posting about....Do not post.

Re:From a typical web surfer's point of view

[shinmai]

A really douchy, I mean helpful, move by Bell would be to have every conceivable service running on the machine these DNS queries are redirected to, that would be configured to somehow convey the fact that the queried server doesn't exist, and possibly to display some ads. Like if a person tries to check for their email from IMAP the server would blindly accept any login credentials and return a mailbox with one mail with the subject "Invalid domain" and some adverts as contents. An SMB share would have folders named "Invalid" and "Domain". The possibilities are endless. Think of how convenient and helpful this would be.

Re:From a typical web surfer's point of view

[NitroWolf]

The web is an incredibly huge piece of the internet.

Please tell us about these 65,000 other services that need a properly functioning DNS. Since the only protocol affected here is HTTP, and the only applications that use invalid URLs are either human-driven (browsers) or malware, I suggest that the NX response is fundamentally outdated and useless.

Wow, you are one clueless user. Please don't put fingers to keyboard and start talking authoritatively when you clearly know absolutely nothing about the subject or the problem at hand. Think before you type, next time.

Maybe you've heard of a little thing called "email?" It pretty much takes a huge chunk bandwidth on the net (mostly spam, granted), and then we have P2P stuff, which takes up the bulk of bandwidth I believe - far, far exceeding the HTTP protocol. These are just two of the services that are affected by it, and both exceed web traffic by significant margins. The web bandwidth is indeed a tiny fraction compared to everything else... just because web surfing dominates your life does not make it the dominate service on the internet.

The NX response is everything. It's the foundation of the entire domain resolution system. Saying it's outdated is absolutely and patently ludicrous. There are two proper responses that drive the entire internet, the return of a valid IP address and an NX response. When you start screwing with either one of those, you break the internet. Outdated indeed.

Re:From a typical web surfer's point of view

[sorak]

C:\>cat /etc/services
'cat' is not recognized as an internal or external command,
operable program or batch file.

Crap! Bell's hijacking has already screwed something up.

Re:From a typical web surfer's point of view

[Anonymous Coward]

These pages are helpful for the typical web surfer. In fact, an automatic URL "fixing" service would be one of those revolutionary Web 2.0 features that exists in the recesses of the web, part of the infrastructure and totally natural to use.

No hacking is not useful for the typical web surfer. Useful for the typical web surfer is for the web browser to handle the NX intelligently.

In my case my browser used to send a not found domain to Google (though I can choose any of several handlers), now my typical web browsing experience is greatly diminished because I am sent to a much less useful page with no real choice on my part.

Re:From a typical web surfer's point of view

[Minwee]

Bell makes a habit of screwing up other services. If you're not requesting data on port 80, preferably from one of their servers, then you are just causing trouble.

Way back when Bell Sympatico was first introducing ADSL I signed up for it and stuck with them for a few years. I put up with things like their spam-friendly mail servers, even going so far as to point out how their broken use of the VRFY command was exposing customer account numbers to the world and demonstrated how their POP3 server allowed brute force login attempts only to be told that such a thing was impossible and I must have just imagined the whole thing, but finally dumped them for a cheaper alternative about five years ago when they started messing around with my traffic.

The beginning of the end was when incoming SMTP connections were blocked. I worked my way up through the sludgy layers of technical support trying to find a way to explain that I really did want people on the Internet to be able to connect to TCP port 25 on my computer at home, only to be told that either a) It wasn't happening because Bell would never do that, b) I should be using their mail servers and did I want the IP address of their POPE server? or c) That if there was a problem with one of my ports then I should take my computer to a shop and have it fixed.

I only wish I was making those up. I finally managed to escalate to someone who knew what TCP was and he was as surprised as I was that there was a problem.

Bell is only interested in selling access to Facebook and Flickr. If you want anything more than that then you're probably not worth it and they will be quite happy to lose your business.

Re:From a typical web surfer's point of view

[Anonymous Coward]

Another day I helped a user troubleshoot the same kind of problem (in their case it was OpenDNS, which has the same kind of misbehavior). Windows was not finding the other machines in the network, because it was configured to look first on DNS (the order is configurable) and then broadcast. Since OpenDNS was falsely returning a found result for names which did not exist, Windows never tried the broadcast which would have found them in the local network. Installing BIND on a spare machine on their network solved that problem instantly.

Re:From a typical web surfer's point of view

[KurtisKiesel]

This just in Canada has found the end of the internet.. and it is a big red "X".

Re:From a typical web surfer's point of view

[Achromatic1978]

Even more fun is if the person affected is trying to work from home over a VPN link. If it's set up for split tunnelling, it'll try to resolve a hostname using the default DNS first and only if that fails will it try the VPN. Hint: Windows uses DNS to resolve hostnames for fileshares.

Funny, the last three VPN setups I've used inserts the VPN allocated DNS servers as the top priority resolver on any clients I've connected with. I can't imagine a scenario where it wouldn't be the case. You don't want your 'secure connection' to be the last resort, that's a big, gaping hole on a number of levels, not just DNS, the equivalent of making the VPN gateway the lowest metric, etc.

Re:From a typical web surfer's point of view

[XanC]

One of the biggest failures of this system is with the HTTPS protocol, which is a huge problem for a number of reasons. It's also one that "regular people" might have a shot at understanding.

Re:From a typical web surfer's point of view

[vintagepc]

Whats more, if your account has a bandwidth cap, their custom page eats your limit... whereas a standard not-found error will eat much less- no images, scripts, and crap to load.

Looks like another story of forced content down your throat...

Re:From a typical web surfer's point of view

[Anonymous Coward]

the only protocol affected here is HTTP

Once upon a time the people of Slashdot knew the elementary details of how the Internet works. Then the Web spread all over the world and all their knowledge was lost into the clouds.

Re:From a typical web surfer's point of view

[Albanach]

While not many folk are running SMTP servers on a cable connection these days, as blacklists will stop lots of their mail, a very large number of users will have client side anti-spam software.

One thing anti-spam software will often do is check the sending domain actually exists. Of course with this change, every domain suddenly exists and you have one less test available in scoring spam.

Re:From a typical web surfer's point of view

[UltraAyla]

Bingo. Add something like this at the user-interface level, and let people choose whether they want it or not - don't do it by exploiting a protocol the world's apps rely on.

Re:From a typical web surfer's point of view

[Fulcrum of Evil]

So make it a web plugin and leave the grownups alone.

Re:From a typical web surfer's point of view

[bennomatic]

Let me tell you the best way to handle this - on the client side, after the proper DNS opportunities have been exhausted. This is because the client best knows the users browsing proclivities (most often viewed pages, favorite search engines, etc).

Agreed!

Re:From a typical web surfer's point of view

[aix tom]

Yep. Many browsers also have a history of pages you have been. Normally anything where you mis-typed the server doesn't end up in the history because the browser knows it couldn't connect. Now that typos might end up in the history.

Re:From a typical web surfer's point of view

[Anonymous Coward]

Hm an excellent idea. Thanks!

Re:From a typical web surfer's point of view

[mister_playboy]

/. users == Linux users

Didn't you get the memo? :)

Re:From a typical web surfer's point of view

[Dragoness Eclectic]

Fortunately my mail host provides service on non-standard ports to spite ISPs that insist on blocking port 25. They also provide SSL access to my e-mail, so I don't have to drag it down in the clear.

Re:From a typical web surfer's point of view

[Tom]

These pages are helpful for the typical web surfer.

Do you work in marketing?

Clue: DNS stands for "Domain Name Service", not "Targeted Advertisement Injection". The "typical web surfer" already has a tool that is responsible for handling unresolvable addresses, it's built into the browser. If you want more help, suggestions for typo fixing, etc. then the browser is the proper location.

There are client programs out there that rely on getting proper DNS responses, including correct "domain not found" replies when the domain does not exist.

Yes, it breaks some scripts and runs contrary to published standards, but it presents a new (actually pretty old) conception of how the web should work.

No, it doesn't. And running contrary to published standards isn't a minor offense. They're called standards for a reason, and client-side programs expect a certain behaviour. Breaking that means breaking customers' software. And no, the web should not work this way. If you want to get a search page on DNS error, a Firefox plugin would be the proper approach, not DNS manipulation.

What this is is the equivalent of your phone company hijacking every call with a mistyped phone number to a toll line with a "helpful" operator that helps you guess the correct number. The only difference is the payment method.

Re:From a typical web surfer's point of view

[jank1887]

don't ping and traceroot do a resolve before giving you your data? does this screw with that?

Re:From a typical web surfer's point of view

[DavidTC]

Yeah, many server antispam filters do that also.

Mine checks before accepting the mail at all, which is also a safety feature...if for some reason the email can't be delivered, we need to be able to bounce it somewhere, otherwise, it will just disappear into a void. We'd attempt to bounce it back to them, which wouldn't work, so we'd attempt to bounce it to postmaster@theirmisspelleddomain, which won't work either. So it will end up in our postmaster box, but don't have time to figure out where the hell things should be from that have invalid domains.

If we SMTP reject it, however, it will probably end up back with them, with an error message about an invalid sending domain they can figure out.

If not, it will at least end up in the sending machine's postmaster box, at which point those guys do, indeed, have a chance to see who's got the wrong address set up in their client. (As they can figure out which of their own domains it should have come from. If they have dsgoaw.com, they can figure out what blah@dsgaow.com is supposed to be a lot better than I, a random other person, can.)

Re:From a typical web surfer's point of view

[Anonymous Coward]

Whoosh!

Re:From a typical web surfer's point of view

[Anonymous Coward]

Yah, some people are totally clueless but think they know everything or it's someone from sbell defending their action. Either way it's another wtf moron post.

Re:From a typical web surfer's point of view

[superdana]

Yup.

Re:From a typical web surfer's point of view

[digitalaudiorock]

Now this is an interesting idea. Let me tell you the best way to handle this - on the client side, after the proper DNS opportunities have been exhausted.

Exactly. Never mind that many browsers have the capability to automatically add '.com' for you so 'yahoo' goes to 'yahoo.com' if the lookup for 'yahoo' fails. This DNS "feature" breaks that as well. Jeez...it's as if a good ISP DNS server is going the way of good ISP usenet servers and the dodo.

Re:From a typical web surfer's point of view

[dave420]

It'd be more useful at the DNS server, as a DNS server, by its very definition, knows more about domain names than a client. I can understand why folks on slashdot have a problem with this, but for grannies mis-typing a domain name and getting a gentle shove in the right direction is better than telling them to download a plugin and train it for use. All the software is there in the DNS-server approach. Personally I don't care about this at all. Most folks get nothing from requesting a domain that doesn't exist. At least this way they might get something useful. I'd take something useful over nothing any day.

Re:From a typical web surfer's point of view

[Tired and Emotional]

No they're not. Although perhaps implementations differ. Qwest redirects you to their own web page and changes the URL so you have to go back and retype the whole thing. Its very annoying.

Re:From a typical web surfer's point of view

[Anonymous Coward]

I think the best explaination (to the layperson, ish) of why this is bad is that it actually PREVENTS browsers from implementing better functionality, as it removes a source of information for a failed DNS lookup.

I.e.Bell is actively preventing browsers from giving a better user experience out of greed and with no good mechanism to disable it. They're blocking innovation using their status as a big supplier.

Re:From a typical web surfer's point of view

[stim]

Are you serious? Also, that's not a bad analogy, try again!

Re:From a typical web surfer's point of view

[Mozk]

Did you notice that (when using Firefox) the mock-up page shown with the opt-out cookie set uses text and images ripped directly from Firefox's error page? Yet I see no mention of the GPL anywhere.

Re:From a typical web surfer's point of view

[Anonymous Coward]

Done, I cited this page. :)

Re:From a typical web surfer's point of view

[prestomation]

Exactly. I work a corporate help desk and experience calls like this every so often.

Annoying..

Re:From a typical web surfer's point of view

[DigiShaman]

All of a sudden, internalhost.yourcompany.com resolves on the public internet

I get what your saying, but using a .com for your private network is generally a *bad* idea for this very reason. All internal domains ought to be ending in .local. You'll save yourself unncessary DNS butt ache by adhering to this rule.

Re:From a typical web surfer's point of view

[Hawke666]

I don't think it matters in this case. They'll claim that nonexistentdomain.local exists just as much as nonexistentdomain.com.

Re:From a typical web surfer's point of view

[marka63]

I challenge any ISP that does this to point their SMTP servers to these name servers then decide that it is a "good thing" that provides a "enhanced service".

Why should the end user put up with crap that the ISP wouldn't put up with itself?

Re:From a typical web surfer's point of view

[PsychoSlashDot]

I figure any ISP who does this is manned by aliens. It's the only way they could have learned so much about shoving unwanted things up people's asses.

But seriously, I liken this to me using their mail server, and if I make a typo in the e-mail address, instead of giving me an NDR they did a search on all the terms in my mail and sent it along to someone "appropriate". An NDR is the PROPER response and anything else isn't.

Speaking of NDRs, I'm predicting they're the next advertising interception. They could throw a buttload of adverts in any and every NDR sent to their customers. "Sorry, your mail couldn't be delivered as requested, but have you considered refinancing your home?"

Re:From a typical web surfer's point of view

[Kalriath]

It could be worse. In Google Chrome, it claims "Safari can't open the page..."

(Also, Firefox is not licensed under the GPL, so why would it be mentioned again?)

Re:From a typical web surfer's point of view

[KillerBob]

It could be even worse... the Rogers version of the same shows a mockup of the Internet Explorer page, complete with broken images (if you're using something other than IE), regardless of the browser you're using. At least Bell is trying to admit that there's people who use something other than IE...

And to add insult to injury, it's the IE6 error page, which is different from the IE7 and IE8 error pages....

Re:From a typical web surfer's point of view

[Anonymous Coward]

I especially like the first link in the sample page, "errornerd.com"... total crapware, same text on all pages, download links everywhere. Yeah, helpful indeed for Joe common.

Re:From a typical web surfer's point of view

[Jaseoldboss]

Ah, that explains why all the images are broken when using User Agent Switcher to view the IE8/Vista page.

Re:From a typical web surfer's point of view

[Anonymous Coward]

If the company has a .com domain (they do), they'll use it for everything. External hosts AND internal hosts. It's called split DNS, the internal names are only visible if you query the dns server from an internal ip.

And from the other side, it seems that someone decided that .local is now reserved for zeroconf "multicast dns", and should NOT be used for internal networks. As another domain has not been allocated for internal networks, that would mean that the right thing to do is to use your the official domain (if you have one. Those of us who don't are officially out of luck).

http://en.wikipedia.org/wiki/.local

Re:From a typical web surfer's point of view

[TheThiefMaster]

The correct way to handle it is to have a "suggestions" query that the client chooses to make, either by http (e.g. googling) or by an extension to DNS.

At least I think so.

Re:From a typical web surfer's point of view

[Anonymous Coward]

Clue: DNS stands for "Domain Name Service", not "Targeted Advertisement Injection".

Duh! Otherwise it would be called TAI! Do you people even think before opening your mouths? Sheesh!

Re:From a typical web surfer's point of view

[Mozk]

Also, Firefox is not licensed under the GPL

Honestly, I don't know how I put that since I know that it's not.

Re:From a typical web surfer's point of view

[WuphonsReach]

One thing anti-spam software will often do is check the sending domain actually exists. Of course with this change, every domain suddenly exists and you have one less test available in scoring spam.

I'm assuming that you're talking about client-side tests. For mail server checks like that, it's a really good idea to have a local DNS server (on the same box, or at least on the same LAN) to handle DNS queries. Mostly for performance reasons (faster lookups, cached lookups), but also because a proper DNS server setup doesn't rely on the usually broken ISP DNS servers.

Thank god I don't work there anymore

[Drakkenmensch]

You wouldn't believe the amount of angry customer calls I had escalated to me by people who think that computers, modems and internet service are all the same things and I was responsible for all of them. If you want me to share them with you, bring lots of hard liquor - you're going to need it.

Re:Thank god I don't work there anymore

[schon]

You wouldn't believe the amount of angry customer calls I had escalated to me

So, were you one of the idiots who thought it would be a good idea to break your own mail servers by enabling PMTU discovery and then dropping the replies when you hit a router with an MTU of less than 1500?

Re:Thank god I don't work there anymore

[Anonymous Coward]

no he meant amount. Now fuck off and die you pedant idiot

Re:Thank god I don't work there anymore

[GnomeChompsky]

Like most big corporations, one side of Bell doesn't know what the other side is doing. The side that made that decision is likely in a different city than the call-centre that handles support calls.....

Re:Thank god I don't work there anymore

[schon]

The side that made that decision is likely in a different city than the call-centre that handles support calls

Considering that he had calls escalated to him, that implies he might not be in the call center, but be an actual technician (which was my question.)

Re:Thank god I don't work there anymore

[sabt-pestnu]

How about popcorn instead? I don't work there, you no longer work there, what's the stress?

Re:Thank god I don't work there anymore

[Anonymous Coward]

Not hard to believe, considering all of Bell's call centers are located in India.... They'll just add a new line to the script after "Did you reboot your computer, and did you unplug all the cables from your modem"

Happens in Germany too..

[ltning]

The Deutsche Telekom / T-Online does exactly the same in Germany.

Re:Happens in Germany too..

[Anonymous Coward]

But compared to Bell you can switch the behaviour permanently off in your User Control Panel of T-Online. No weird cookies are required...

Re:Happens in Germany too..

[Anonymous Coward]

But you can opt-out to get proper DNS back.

Re:Happens in Germany too..

[muyla]

Here in Brazil a dsl provider called telefonica was doing it, I hated that service because when u type just a part of the address in your browser (like google instead of www.google.com.br) u get the Telefonica search. we could opt out by checking a box in the search page, but it still showed their page without the search option. A couple months ago they had a huge problem with hackers in their DNS servers (I don't know if it was related to the search page scam)... took them a long time to solve it and they are still forbidden to sell new subscriptions to the dsl service untill they prove that they can provide a good quality service to the already existent clients.

Re:Happens in Germany too..

[comm2k]

HanseNet / Alice also does this and as T-Online the opt-out process is done via a user control panel and is permanent, until you opt-in again. No cookies are set. While it shouldn't be necessary to do this in the first place it is MUCH better than a cookie based system as used by Bell.

Re:Happens in Germany too..

[Andr T.]

Yeah, I started using openDNS after I saw that stupid Telefonica's page.

Re:Happens in Germany too..

[Anonymous Coward]

They don't. Stop spreading misinformation without even as much as a trace of proof. Oh, and I did test several non-existing domains prior to posting this.

Re:Happens in Germany too..

[Anonymous Coward]

Yes, and it's pissing me off.

Funnily enough, Bell Canada's DNS trap has obviously been translated by a very ancient version of babelfish for us Germans.

Quote: "Wir haben nicht für: www.domainnotfound.ca. Probieren Sie die VorschlÃge aus oder geben Sie eine neue Abfrage über "

Re:Happens in Germany too..

[Tom]

Alice (HanseNet) does it too, and the opt-out process is ridiculous.

Re:Happens in Germany too..

[Hurricane78]

Good to know, because that means I'll rather die than use them and let them wreck my DNS services!

Re:Happens in Germany too..

[ltning]

They SO do .. but it might be for certain T-DSL products only; I have no idea. I've seen it in action at two different homes in southern Germany (Bavaria). My "samplings" are from the latter half of July 2009.

I don't have proof, and I cannot produce proof as I'm not in Germany at the moment.

I guess you'll just have to take my word for it, eh? Or offer alternative suggestions as to what I've seen.

Does the Taco add on work here?

[gurps_npc]

Taco stands for Targetted Advertising Cookie Opt-Out. It is a firefox addon that keeps a generic, non-user specific cookie opting out of the things that need cookies to opt out of.

Re:Does the Taco add on work here?

[characterZer0]

It does not work for every non-browser application that uses DNS.

Re:Does the Taco add on work here?

[Anonymous Coward]

Maybe Stallman can explain it, but sorry, mandating the use of a cookie to opt out of using cookies is just a little too recursive for me.

Instead of TACO maybe they should call this one CINAC (Cookie is not a Cookie).

Re:Does the Taco add on work here?

[Anonymous Coward]

It depends whether the Taco is a commander or Not?

Re:Does the Taco add on work here?

[bennomatic]

Wouldn't that be TACOO?

Re:Does the Taco add on work here?

[Anonymous Coward]

There must be a Taco Bell joke in here somewhere, but I got nothing.

If true, a SERIOUSLY broken opt-out...

[nweaver]

If this is a true description of the opt-out, it is SERIOUSLY broken.

Simply put, any opt-out mechanism MUST enable the user's computer to properly receive an NXDOMAIN response. Because the problem is NOT the advertising web page on a web browser typo for http, but all the other things that do DNS lookups.

For example, NXDOMAIN wildcarding even snagged and confused Dark Tangent into thinking that someone was trying to MitM the Defcon forums!

I can accept an ISP doing this only under the following conditions:

a) The opt-out is a one-click item on the page

b) The opt-out is perminent and for all connected through that IP/customer link

c) The opt-out is a real opt-out which will cause NXDOMAIN responses to be properly returned as NXDOMAIN.

This clearly fails B and C.

Re:If true, a SERIOUSLY broken opt-out...

[Anonymous Coward]

RCN (in MA at least) is doing this too and it's pissing me off. When I ping a non-existant domain, I get an RCN server instead. Furthermore, the opt-out is _cookie based_! (b) and (c) totally fail.

Re:If true, a SERIOUSLY broken opt-out...

[qortra]

b) The opt-out is perminent and for all connected through that IP/customer link

But then, how will the user re-enable the service when they start missing those targeted advertisements?

Re:If true, a SERIOUSLY broken opt-out...

[melikamp]

It sucks that a provider's DNS is broken. Still, you can run your own caching DNS server and forward your requests to servers that work.

Re:If true, a SERIOUSLY broken opt-out...

[Noxn]

But then, how will the user re-enable the service when they start missing those targeted advertisements?

Why should anyone want that? It is useless.

Re:If true, a SERIOUSLY broken opt-out...

[TheRaven64]

I'm not sure how an opt out that uses cookies is supposed to work. My mail client, for example, does a DNS lookup for smtp.domainwithtypoinname.com. The resolver on my machine sends a UDP packet containing the DNS request to the DNS cache. The DNS cache replies with NXDOMAIN. The function called by my mail client returns failure. How does the DNS cache get hold of the cookie to know that it should return the real NXDOMAIN?

Hopefully the root servers will start using DNSSec soon, so the resolver can just flag these and the libc functions can return the same kind of failure as they would for an NXDOMAIN reply.

Re:If true, a SERIOUSLY broken opt-out...

[John Hasler]

The doofuses behind this are unaware of the existence of any software other than a browser that uses DNS. They would tell you that DNS is part of the Web.

Re:If true, a SERIOUSLY broken opt-out...

[QuantumRiff]

This puts itself exactly like the whole "Phorm" debacle... Where in order to have things work the way they should, you have to remember to "opt-out" any time you are using a different computer, or clear your cookies, or whatever.. however, it doesn't actually opt you out of anything, it just changes what you see.. (the Phorm debacle didn't opt you out of tracking everything you do with deep packet inspection, it just opted you out of seeing the ads tailored to you!).

This is the same thing..
Opt out should opt their DNS server from hijacking stuff. The only use I can see for this kind of service, is the ISP can get a list of the most mis-typed domains, and start squatting them.

Re:If true, a SERIOUSLY broken opt-out...

[Anonymous Coward]

Or they don't want you to use anything other than a browser. They throttle P2P afterall.

Re:If true, a SERIOUSLY broken opt-out...

[dzfoo]

Yeah, and good luck making your SMTP server (or any other IP service other than HTTP agents) understand cookies!

      -dZ.

Re:If true, a SERIOUSLY broken opt-out...

[MyLongNickName]

I would say *whoosh*, but the joke went so far over your head as to be inaudible.

Re:If true, a SERIOUSLY broken opt-out...

[e9th]

What I've never understood is why an ISP bent on NXDOMAIN hijacking wouldn't also block DNS queries to other than its own servers. Bellsouth did this with SMTP requests shortly before I gave up on them. You had to relay any outbound SMTP traffic through one of their servers. Ostensibly, this was to prevent zombied machines from spamming. I'm sure an evil ISP could come up with a similar rationale for DNS traffic.

Re:If true, a SERIOUSLY broken opt-out...

[funkatron]

A small question.

Can an NXDOMAIN response include additional info? If so could this be used to send a message such as "No such domain, use this search page"? If not would adding this be a problem?

It seems that a solution that could return a correct NXDOMAIN response and suggest an alternative action would satisfy everyone's requirements.

Re:If true, a SERIOUSLY broken opt-out...

[NormalVisual]

It seems that a solution that could return a correct NXDOMAIN response and suggest an alternative action would satisfy everyone's requirements.

It would, but that solution properly belongs in the browser, not the DNS server. DNS should not be doing anything other than returning NXDOMAIN. The client that received it in turn can handle it however it wants, be it through suggesting alternate pages, etc.

Re:If true, a SERIOUSLY broken opt-out...

[Locklin]

If true, switch to a reseller. Seriously. If you can get Bell DSL, you can likely get DSL from a reseller like Acanac or Teksavvy. They shield you from most of the Bell bullshit, have better tech support, and are cheaper than Bell. No only that, but you are supporting companies currently fighting court battles with Bell on their nasty traffic management practices.

Re:If true, a SERIOUSLY broken opt-out...

[Jared555]

I know it was a joke. But for the computer illiterate that might actually WANT this, it could be a separate page on the user account to choose 'I want this' or 'Disable this piece of **** now'

Re:If true, a SERIOUSLY broken opt-out...

[drinkypoo]

What I've never understood is why an ISP bent on NXDOMAIN hijacking wouldn't also block DNS queries to other than its own servers.

Because fucking around with DNS requests to their servers can be argued to be a service, and there's no law saying that "internet" means DNS is functioning correctly... but dicking around with your obviously legitimate traffic is clearly anticompetitive and a big naughty no-no.

Re:If true, a SERIOUSLY broken opt-out...

[inject_hotmail.com]

I'm the article submitter.

Yes, this is seriously broken.

A) It's about 4 clicks, the first being a button labeled "About this page".

B) The opt-out survives only as long as the cookie. It is only an opt-out for that user, it's not even system-wide (as cookies belong to the user, not the machine)

C) It's not a true opt-out of the broken NX DNS-breaking response system, it's an opt-out of the automatic search page. The "service" provides an approximation (fabricated to appear as though one's browser is providing it...very sneaky) of the "domain not found" page of the web browser of its user. If the cookie is removed, behaviour reverts back to the ISP's original surreptitious functionality.

So what happens if I am a user that refuses all cookies? I am forced to partake in their domain hijacking.

Bell did not notify their customers in any way shape or form that this was going to or did happen.

It's not easy (or even possible in some cases) to change the DNS entry in their provided modem. I was able to do so because I am very technically inclined. As I sit here, I think of a more important side-effect. This hijacks the browser's "search from the address bar" function. If a browser gets a response that the domain exists, it'll negate the user's preference to use Google, Yahoo or whomever else. This, in essence, is Bell being a queue barger, it wants to be first in the search line.

Re:If true, a SERIOUSLY broken opt-out...

[digitalaudiorock]

The opt-out is perminent and for all connected through that IP/customer link

Yup. I have Optimum Online and their opt out disables it for the MAC address of your cable modem which properly allows the NX to come through. I'll give them tiny kudos for this, but not as much as just leaving DNS the fuck alone.

Re:If true, a SERIOUSLY broken opt-out...

[complete loony]

You could build a resolver send a DNS request for say 10 random 10-15 character domain names when it starts up and black list any IP addresses that are returned more than once (just on the off chance that one of those random addresses collided with a real one). But still, this is stupid. If you want to put training wheels on an internet connection and sell it as a feature, force the user to visit a config page once when they sign up via say a transparent proxy, giving one place to go to turn all that crap off.

Re:If true, a SERIOUSLY broken opt-out...

[Anonymous Coward]

That used to be the case, but hasn't been so for quite a while now. Now, the "opt-out" does absolutely nothing whatsoever.

Not really seeing an issue

[Mordaximus]

Most people that are savvy enough to care, don't use their provider's DNS services. Those who aren't probably either don't care, or might even like the "feature."

Re:Not really seeing an issue

[nine-times]

Maybe I'm misunderstanding, but I get the impression from the summary that Bell is hijacking domain queries, meaning that users can't easily choose not to use their provider's DNS services. So the idea is that, even if you choose to use another DNS provider, Bell will intercept your query and give you their own response.

Not that there aren't ways around it, but why should users have to try to figure out ways around something like this? An ISP shouldn't be intercepting your traffic without your permission.

Re:Not really seeing an issue

[jimicus]

Then you've never used Cisco's VPN client.

Hint: Connecting to internal-machine.yourcompany.com over the VPN doesn't work when internal-machine.yourcompany.com can be resolved from outside the company.

Re:Not really seeing an issue

[Timothy Brownawell]

Maybe I'm misunderstanding, but I get the impression from the summary that Bell is hijacking domain queries, meaning that users can't easily choose not to use their provider's DNS services.

Your ISP always provides a couple of caching DNS resolvers, and it tells your computer about them when you get your IP address (ie, provided by the DHCP server). So your computer will by default send all DNS queries through your ISPs DNS resolvers, and they can send you whatever garbage results they want.

This is most likely "only" Bell making their DNS resolvers (that everyone uses, because they're the default) malicious, and not them redirecting traffic mean for other DNS servers to their servers.

Re:Not really seeing an issue

[Nursie]

Really?

I don't know anyone that uses DNS servers that aren't provided by their ISP, unless they have some specific need to do otherwise.

I mean, other than in cases like this, what does it get you?

Re:Not really seeing an issue

[John Hasler]

> I mean, other than in cases like this, what does it get you?

You'd be amazed at how bad the DNS of some ISPs can be.

Re:Not really seeing an issue

[melikamp]

That is unlikely. I think it would require deep packet inspection to work. You do not really need your provider's DNS (although it is useful when it works properly). You should be able to run a minimal DNS server locally and set it to bypass your ISP and go to higher level servers.

Re:Not really seeing an issue

[Anonymous Coward]

Just to clarify as we were...considering that client... (and might still--people don't seem to like the current choice as it doesn't run on Vista 64...*sigh* )

Does this mean the VPN client will fail entirely if there's...one portion of our company/infrastructure that depends upon the presence of a * record on a particular subdomain (that VPN users sometimes go to...) ? Or does it only work on specific named domains published via A record?

Re:Not really seeing an issue

[Wowlapalooza]

NXDOMAIN spoofing/redirection is inexcusable, but "resolver failover on NXDOMAIN" behavior is broken too. Cisco once again proves that it is clueless about the fundamentals of DNS (any of their customers with the GSS product already knows this of course).

Re:Not really seeing an issue

[nine-times]

Yes, I understand how you get DNS servers through DHCP. If it's only Bell choosing how their own DNS servers respond, then it doesn't seem like much of a problem.

However, the summary talks about "hijacking" DNS queries. The summary is pretty light on details, and it doesn't link to other articles, so I'm not sure what it means by "hijacking", but I was guessing from the wording and tone of the article that they were intercepting DNS queries to other DNS servers. If that's not the case, then personally I find the summary misleading. But maybe I'm just wrong.

Re:Not really seeing an issue

[jimicus]

Even without your VPN client doing that it'll break things because many applications don't make any subsequent DNS lookups as soon as they've had one successful one - or if they do it doesn't happen for some time.

So if your end-user connects to the VPN after starting the application rather than before, the application will need to be restarted. And this is before we even think about things like operating systems caching DNS entries.

Re:Not really seeing an issue

[nine-times]

That is unlikely. I think it would require deep packet inspection to work.

You can't just redirect the DNS ports to another server? You may be right. I just wouldn't expect it to be all that complicated.

Re:Not really seeing an issue

[mzs]

You are right, if you are on Bell and you use dig with a different DNS server all is well. But if they really wanted to be jerks they could do what that fellow you responded to was afraid of with out deep packet inspection for 99.9% of those that just hard code some sane DNS server IPs. They already have a firewall, now they just redirect everything to port 53 to another spigot connected to one of their many evil DNS servers. There is no need to rewrite any frames or anything of that sort. That server can even be Windows since everything supports SOCK_RAW which is just one way to not have to worry about correct IPs. It just replies to all ARPs, hey that's me, and returns bogus IPs when NXDOMAIN should have instead.

Re:Not really seeing an issue

[dougisfunny]

Would it be better if it said Bell starts DNS Fraud?

Re:Not really seeing an issue

[inject_hotmail.com]

I'm the article submitter.

I'm quite certain that applies to only those people that use Bell's DNS servers. I switched immediately to a public/free DNS service, and I no longer get my NX responses hijacked.

Re:Not really seeing an issue

[Wolfrider]

--You can do this with the Squid proxy cache as well, pretty easy to set up in the config file.

Re:Not really seeing an issue

[Wolfrider]

--Well, now you know one. ;-)

--I use 4.2.2.x almost exclusively after dealing with horrible ISP DNS servers. Internet access is nice and fast now. Slowdowns, having to bounce the modem, etc are pretty much nonexistent now. And I never have to worry about "ganking" DNS situations like multiple other providers have pulled.

Re:Not really seeing an issue

[nine-times]

Oh, then I did misunderstand. I probably wouldn't have used the word "hijack" to describe Bell's servers giving an improper response to a DNS query, unless that query was actually directed elsewhere. But maybe that's just me.

Re:Not really seeing an issue

[nine-times]

Yeah, maybe. Or maybe "Bell's DNS servers suck"?

Re:Not really seeing an issue

[bertoelcon]

But that isn't news at all. They always sucked.

Re:Not really seeing an issue

[Anonymous Coward]

How would YOU implement "figure out if this is an internal or external host"? Without querying both name servers, and seeing which one returns a valid result.

Oh, and the internal one usually DOES return valid results for external hosts too, as it's the one people use to surf at work.

Re:Not really seeing an issue

[Wowlapalooza]

How would YOU implement "figure out if this is an internal or external host"? Without querying both name servers, and seeing which one returns a valid result.

Oh, and the internal one usually DOES return valid results for external hosts too, as it's the one people use to surf at work.

Well, where I work we disable split-tunnel in our VPN client. As inconvenient as that is, it's the best thing to do from a security standpoint anyway.

If split-tunneling were on, I'd provide a view in our DNS infrastructure to those VPN clients, which can resolve the internal versions of domains which are owned by us and used both internally and externally, and Internet resolution of names in external domains. The internal domains also contain the external entries so that the VPN clients (and anything else, for that matter) can resolve external names in the domain(s), regardless of which version of the domain(s) they use. In our case, we don't use NAT between our internal network and the Internet (everything goes through application-level proxies or gateways); if we had a NAT requirement, I might have to re-think that architecture. NAT is evil, though, with respect to far more than just DNS, and I hope we can avoid it.

teksavvy

[tedrampart]

does anyone know if they're applying this to other ISP who lease bandwidth from bell? Such as Teksavvy and the like? I'm switching from bell anyhow, but I'd be pissed if they force that on other ISPs too (along with throttling).

Re:teksavvy

[Anonymous Coward]

does anyone know if they're applying this to other ISP who lease bandwidth from bell? Such as Teksavvy and the like? I'm switching from bell anyhow, but I'd be pissed if they force that on other ISPs too (along with throttling).

Doubt it. Teksavvy has their own DNS servers.

browser task?

[sugarmotor]

Browsers can take care of this quite well!

I think they mostly do.

Or put otherwise, this is a pretty heavy solution to the problem, if the problem is what it is to solve -- unlikely.

Stephan

Re:browser task?

[thePowerOfGrayskull]

if the problem is what it is to solve -- unlikely.

Unlikely indeed. A simple search on that site for "Test" turns up many results. Several of them have notes like this next to them: "Sponsored by: www.momshomeroom.com/msn ", and "Sponsored by: www.Tests.com "

Looks like helping the customer is a secondary concern after all.

Re:browser task?

[bennomatic]

Mostly, yes, but not entirely. I like the way that Firefox, Safari and Chrome handle these errors, primarily because you can tell the difference between being off-line and getting an NX response. IE, however, seems to show the same error regardless. If I'm using IE and something stops working, I have to switch to Firefox and try again to determine if I need to restart my cable modem.

Additionally, if I get a 301 (moved) redirect to a non-existent domain with IE, the browser's location bar doesn't update; I get a failure that looks like its at the URL I was trying to go to. In the other browsers, the location updates, so I can see that the failed URL is a different one.

This last one might not seem like a big deal, but one of the things I do for work is build SSO integrations, and part of that is redirections to a challenge URL on un-authenticated access attempts. With IE, I try going to www.X.com, and get redirected to challenge.Y.com. If the latter URL is hidden behind a firewall, or if I mistyped it, it appears in IE that www.X.com doesn't exist, when really it does. It's annoying.

And unfortunately, since it's big corps that use these integrations, I have to do the majority of my testing in IE.

Re:browser task?

[kayditty]

If I'm using IE and something stops working, I have to switch to Firefox and try again to determine if I need to restart my cable modem.

uh.. why wouldn't you first try a ping of your local network & ISP, then try looking up a hostname with ping/dig/nslookup/host to determine what's going on? your solution seems pretty absurd.
win+r cmd ping -t www.l.google.com ...... done

openDNS

[Anonymous Coward]

208.67.222.222
208.67.220.220

problem solved

Re:openDNS

[vslashg]

I'm not sure if this is a troll or not, but just in case it isn't: openDNS does the same sort of hijacking.

Re:openDNS

[jabithew]

Er, OpenDNS does exactly this. Only I don't think it has an opt-out.

Re:openDNS

[Bieeanda]

You forgot the most important thing:

127.0.0.1 block.opendns.com

127.0.0.1 guide.opendns.com

Re:openDNS

[Anonymous Coward]

OpenDNS only does this if you use their filtering options. If you use just the standard straight up dns service you can opt out.

Re:openDNS

[jimicus]

It does, but you need an account to opt out. Though I've never tried it so I'm not sure if their "opt-out" is smart enough to register the IP address you're connecting from and add it to a list of "addresses not to break DNS for" or if it's a similar "mock-up a browser page".

Re:openDNS

[diamondsw]

And it is especially difficult to get it to stop. You can, but you have to turn off every feature they offer beyond bare DNS.

Of course, they do provide quite good bare DNS, so that's not a terrible thing, but it would be much better if their "helpful" services were opt-in.

Re:openDNS

[Vectronic]

Like others have said, OpenDNS does this same thing, it shows you a Yahoo search page, and if you are one of those F5ck Mycr0$of7 types, then that will be a Bing search soon.

I just set mine up with OpenDNS to see, and there doesn't seem to be an Opt-Out for it. And none of their options are really that nifty, they can all be done within your Router, and/or within your Browser settings.

Re:openDNS

[HeronBlademaster]

The opt-out is a true opt-out. You enter a list of IP addresses to opt-out on your account screen, and from there it gives you real NXDOMAIN responses (and it even works with filtering).

Re:openDNS

[talcite]

Yes, openDNS does do this. There's a couple of ways to get around the NXDOMAIN hijacking. First, you could use another DNS server. For a list of good, free, DNS servers, I use the vivilProject. They have a bunch of scripts which can determine the fastest DNS servers for your location. http://80.247.230.136/dns.htm The other option is to run your own BIND server and configure it to cache only. For most of you Linux guys out there, major distros will provide a package to do this. This option not only gets around the NXDOMAIN garbage, but it also gives you faster DNS resolution on your local network.

Re:openDNS

[Otto]

Their DNS does indeed return the proper NXDOMAIN responses if you a) sign up for an account, b) register your IP with them, and c) disable all the "advanced" features they offer. Set it to be basic no-frills DNS and that's indeed what you get with them.

So yes, their opt-out for that sort of thing, while a bit of a pain, does work properly. But considering that their entire service is opt-in to begin with, there's not a lot to complain about on that score.

For people with dynamic IPs, they offer software to run that pings them every so often to update your IP and make you stay opted out. Actually, they use that because you can create "templates" of settings to apply to different networks you use and such.

Re:openDNS

[jimicus]

How much good does that do you on a domestic DHCP-allocated address?

Re:openDNS

[HeronBlademaster]

If memory serves they have a notification mechanism you can set up to update your account with your current IP address.

Re:openDNS

[dotgain]

For goodness' sake stop using localhost to blackhole things!

I was getting the same shit from Mediacom today

[Anonymous Coward]

Only they have decided that "google.com" is not a valid domain...ffs

Oh, and why do I have to make firefox pretend to be IE8 to post on slashdot?

Embarq

[Dan East]

Embarq does the same thing with their DSL:

http://search.embarq.com/index.php?origURL=http://lkwkerwer.com/

Re:Embarq

[Anonymous Coward]

But at least when you opt-out it will then make it return NX responses (yes I have Embarq and that was one of the first things I'd do (or end up doing accidentally) when the IP changed)
And it seems to work until you end up changing IP (DSL so I only changed when the link went down.)

Detect and fix DNS hijacks locally?

[caseih]

Is there any way a local caching name server can detect this brokenness and return the right answer? I seem to remember some bind configs a few years back that would do that but I'm not sure if they would still work.

Or maybe a firefox plugin could detect this damage and restore the original, correct behavior somehow.

Re:Detect and fix DNS hijacks locally?

[slazzy]

Should be pretty easy thing to detect. Do a get of several domains you know shouldn't exist: ie: kg84jrtuwerufhg3r4.com and see what response you get from DNS servers. You could even go so far as to do a whois lookup to see if they are in fact registered or not.

Re:Detect and fix DNS hijacks locally?

[jimicus]

You could set up your own caching DNS server and have it bypass your ISP altogether, instead drilling down the DNS from the DNS root servers.

DNS is fairly easy to detect so it wouldn't be too hard to set up an invisible proxy, but most ISPs won't go to these kind of lengths.

Re:Detect and fix DNS hijacks locally?

[pipatron]

I use dnsmasq on my router, you could use it locally as well. It has a --bogus-nxdomain=<ipaddr> option that you can use for this purpose.

Re:Detect and fix DNS hijacks locally?

[characterZer0]

Bingo.

Re:Detect and fix DNS hijacks locally?

[Kickasso]

I don't have mod points, so let me just say this:

Mod Parent Up!

Re:Detect and fix DNS hijacks locally?

[vlm]

You could set up your own caching DNS server and have it bypass your ISP altogether, instead drilling down the DNS from the DNS root servers.

Here is another useful thing you can do with your own server... because you probably have a large home lan, you can also set up the "caching" server to be authoritative for a tld like .home

So, now you can get to all your machines on the lan by pinging sshing httping something.home

You can also experiment with dynamic DNS updating the .home tld.

I would advise staying away from a tld like .local, that messes up the bonjour protocol or multicast DNS or whatever its called.

Re:Detect and fix DNS hijacks locally?

[RKThoadan]

I'm not savvy to the inner workings of bind, but I think it would be easiest to find out what they return instead of NX and correct it that way. You would be unable to intentionally visit their little ad page, which isn't really a problem. Depending on their setup I suppose you might lose access to other parts of their site, which could be a problem.

Re:Detect and fix DNS hijacks locally?

[HeronBlademaster]

Awesome :)

Someone mod this guy +1 Informative!

Re:Detect and fix DNS hijacks locally?

[Anonymous Coward]

This is all kinds of awesome.

Re:Detect and fix DNS hijacks locally?

[enosys]

I contacted them at domainnotfound@bell.ca and I was told about the NoRedirect extension for Firefox. That wasn't what I was asking for, but it is an improvement over their fake opt-out mechanism.

Re:Detect and fix DNS hijacks locally?

[Anonymous Coward]

Tomato uses dnsmasq, and I think DD-WRT may as well. You can also install it to OpenWRT if you so choose.

Re:Detect and fix DNS hijacks locally?

[John Hasler]

> Is there any way a local caching name server can detect this brokenness and
> return the right answer

Just use different servers. You don't have to use theirs.

Waiting for DNSSEC...

[Timothy Brownawell]

Isn't this sort of forgery exactly what DNSSEC is supposed to prevent?

(And no, don't go suggesting DNSCurve. It doesn't protect against your ISPs caching resolver being malicious like this.)

Sponsored Links Appearing In The Middle Of Results

[Anonymous Coward]

This is what I find interesting/scary about this. Search for "Microsoft" from that webpage. Of course the first hit is from www.microsoft.com and if you look carefully you can see that it is sponsored. But the fourth hit down is for a sponsored link.

Microsoft Help & Support 1-888-935-4306
Get Microsoft Technical Help & Support by Expert 24x7, Call now !!
Sponsored by: www.iyogi.net

Very interesting that they mix sponsored and regular hits. I thought normally these were at the top of the results page and separated by bars/colors/lines/fonts.

OpenDNS & IPv6

[Midnight Thunder]

Using other services like OpenDNS is a certainly one way to go, but last time I checked they had issues when it came to IPv6. Does anyone know any IPv6 friendly open DNS servers?

Re:OpenDNS & IPv6

[Xtravar]

I have Charter, and they do the same thing . I just use 4.2.2.1 and 4.2.2.2 as my primary DNS servers. Although, I can't really speak to their IPv6 capability.

Re:OpenDNS & IPv6

[pongo000]

I have Charter, and they do the same thing . I just use 4.2.2.1 and 4.2.2.2 as my primary DNS servers. Although, I can't really speak to their IPv6 capability.

OpenNIC offers IPv6 DNS resolution services on some of their servers.

Re:OpenDNS & IPv6

[ion.simon.c]

A local BIND9 installation would do the trick.

Why is this bad?

[danking]

Don't get me wrong. I don't like this practice. But I do not know what the technical issues are with doing this. Are there security concerns? How does it break stuff? Also, does anyone know if complaints have been filed with the CRTC or if this practice is contrary to CRTC rules?

Re:Why is this bad?

[jimicus]

The technical issue is this: Incorrect functioning of DNS is only a problem if the internet connection is used for nothing but web browsing.

User has misconfigured their email client? Well, normally they'd get a fairly clear warning that the mail server they're trying to connect to doesn't exist. Now, it appears to exist but it doesn't respond.

User is trying to connect to something over a VPN? Depending on configuration the internal DNS servers may only be consulted if the external ones can't resolve a hostname. So if you need a VPN to connect to some system your employer runs, all of a sudden it doesn't work because the host lookup points your PC at completely the wrong IP address. Even if this isn't the case, most operating systems will cache DNS replies for some time and many applications won't bother to re-query DNS once they've got an IP address from a hostname. So if your end-user forgets to fire up the VPN before they fire up anything else, their PC will mysteriously not work properly.

Cue a bunch of calls to the helpdesk and an enduser who can't work properly.

Ignorance is Bell's best friend.

[Garbad Ropedink]

Bell's current business model pretty much relies on people not caring about the shit they pull.

It's sort of interesting (or infuriating depending if I'm trying to use the internet..). My new ISP makes it no secret they hate everything Bell does. I think that largely has to do with them leasing their lines from Bell, and having their service screwed up when Bell does things of this nature. I imagine I'll be getting an email from my ISP soon telling me who to complain to about the service getting buggered yet again. Thanks Bell, I'll be by your office in the morning with a fresh cinderblock. I see you replaced your front window from the last time I put one through it.

Re:Ignorance is Bell's best friend.

[PitaBred]

Fortunately it's not that hard to run a caching nameserver from a more authoritative source. I run one at home because I just don't trust Comcast's.

Shouldn't impact third party ISPs

[Digital_Quartz]

If you're using TekSavvy, then you're using TS's DNS servers, so your query goes to TS's DNS server which should respond with NXDOMAIN. You aren't even contacting the Bell DNS, so there's no opportunity for them to interfere.

It's possible, since Bell controls the last mile, that they could intercept NXDOMAIN results going to your machine and replace them using DPI, but I can't see how they'd get away with that without being in violation of CRTC rules about changing the meaning of communication. And, at least for me on Primus, this doesn't seem to be the case (yet).

Re:Shouldn't impact third party ISPs

[tom17]

Just checked, I get NXDOMAIN so there is no hijacking going on :)

Tom...

Re:Shouldn't impact third party ISPs

[John Hasler]

> It's possible, since Bell controls the last mile...

Possible, but very unlikely. Third-party ISP traffic does not go over their network as TCP. They'd have to install a lot of expensive hardware to mess with it.

Re:Shouldn't impact third party ISPs

[Digital_Quartz]

Well, my third-party ISPs bit-torrent traffic is being throttled by Bell.

Jail time for this.

[Tei]

I have just read a article, about a children getting a possible 10 years sentence to open a hardware to install software on it. And now I am reading this? I am angry, very angry, please _jail time_ for the people that has taken this decission in Bell!, NOW!.

Can we get a fair world, please?

Re:Jail time for this.

[frozentier]

I have just read a article, about a children getting a possible 10 years sentence to open a hardware to install software on it.

It would appear you didn't actually read said article.

Bell

[Anonymous Coward]

I SERIOUSLY URGE YOU ALL TO LOOK AT THE CRTC WEBSITE!
Bell is on a buying spree, They now own (or are buying into, to take over) Aliant (BellAliant), Virgin Mobile CA (Bell Virgin Mobility), Rogers (Bell Rogers), Telus (BellTelus), BarbadosTel (Don't know the new name yet), The Source, Koodo trying to take over MTS, ATT WW, with more on the radar.
And the reason why they can get away with it right now is they are buying up 61% so they can get co-branded Bell[Name]... Oh yeah, they are no longer known as Bell Canada Enterprises...it's now Bell Enterprises, which means they plan on going global... WATCH YOUR WALLETS!

Cookie?

[wiredlogic]

How is this cookie supposed to work for lookups from apps other than a web browser?

Re:Cookie?

[jimicus]

It isn't. Clearly Bell don't consider themselves an ISP any more, they consider themselves a WSP. (Web Service Provider).

Re:Cookie?

[Minwee]

How is this cookie supposed to work for lookups from apps other than a web browser?

I see that you are not a Bell customer. They don't follow the simple "You pay us, we provide a service" model which you have come to expect from other ISPs, but they are half way there.

Re:Cookie?

[Anonymous Coward]

What other apps, the icon on my desktop is clearly labeled "internet"...?

Re:Cookie?

[PitaBred]

Didn't you know? Bell only sells a web browsing "internet" connection. Other services aren't officially supported. Besides... who uses anything other than a web browser? Who cares if other stuff breaks?

Re:Cookie?

[Chris Burke]

It isn't. Clearly Bell don't consider themselves an ISP any more, they consider themselves a WSP. (Web Service Provider).

It's not supposed to work, it's supposed to give them a blanket CYA response to people complaining about this bullshit. "Hey you can opt out."

Direct comments to domainnotfound@bell.ca

[Anonymous Coward]

Contrary to the summary, they do provide a very visible 'Contact Us' link, providing both a feedback form and an actual email address: domainnotfound@bell.ca

OpenNIC does none of this silliness

[pongo000]

OpenNIC offers free, open, and democratic domain name services. No redirects like your favorite ISP or OpenDNS (and to think these used to be the "good" guys back in the days of everydns.net). All ICANN domains, plus a good helping of alternate roots (including OpenNIC) as a bonus. The OpenNIC DNS network is slowly building, with servers around the world

Using your ISP's name servers is so passe. They'd like the masses to think that's the only choice.

Re:OpenNIC does none of this silliness

[Fastolfe]

Isn't this an alternate root, though? With all of the problems that alternate roots have?

OpenDNS has an opt-out at least...

[nweaver]

I'm not a fan of OpenDNS because they also do NXDOMAIN wildcarding.

However, they do have a working opt-out in the OpenDNS dashboard, however you need to use their notification mechanism so they can track where you are to maintain the opt-out.

Legal?

[TheRaven64]

So, what happens if I buy ping a domain that doesn't exist? Presumably this will then cache the DNS NXDOMAIN reply. If I then buy the domain, set up a DNS entry, and then try to connect to it, I will get their sever instead of mine. This sounds like it would fall foul of computer misuse laws; intentionally hijacking a connection. The presence of ads means that they're doing it for commercial purposes, which usually carries a heavier sentence. Other ISPs will not be breaking these laws, because they will just be inadvertently blocking my connection, rather than hijacking it.

Re:Legal?

[Melkhior]

IANAL.

I originally thought this was breaking 18 U.S.C. Chapter 119, 2510 to 2522 (?), but no.

*IF* they only alter the answer of their own DNS servers to their clients, when the client has made a request to said DNS servers, then they're probably in the clear. There is two communications: one from the client (C) to the Bell server (B), then one from B to the authoritative server (S). S then answer NXDOMAIN to B, which then returns a completely different information to C. So they're not intercepting anything.

OTOH, *IF* they hijack all the port 53 requests to the outside world (which I doubt), then it's very likely 2511(1)(a) and (d) applies. They still could argue under 2511(2)(a)(i) that it's "necessary"...

Then again, IANAL.

OTOH, even if it's legal, it's still absolutely wrong.

Re:Legal?

[Melkhior]

> I originally thought this was breaking 18 U.S.C. Chapter 119, 2510 to 2522 (?), but no.

Sorry, completely irrelevant: I didn't notice it's Bell Canada, so U.S. laws don't matter.

I have no doubt there's some US ISP doing the same thing :-(

Re:Legal?

[RedK]

How did this ever get +5 ? Seriously, if you register a non-existant domain, they won't hi-jack you. First, there's this thing called TTL on requests, when a DNS server caches a response from an authoritative source, it is not permanent. It has a Time to Live, defined in the Start of Authority in the zone on the master server or on the entry itself. So after a while, the DNS server will query the authoritative source again to make sure its answer is still correct and up to date. This is also implemented for NXDOMAIN queries, as defined in RFC2308. Section 3 is specific that NXDOMAIN queries should also return the SOA and that the receiving cache is to use the minimum TTL (the last value in the SOA). The default on this is 3600 seconds, or you guessed it, 1 hour. Since your domain will take 24-48 hours to show up on the ccTLDs or gTLDs anyhow, 1 hour isn't going to make or break anything as far as caching a NXDOMAIN answer and anyway, you wouldn't have gotten that traffic to begin with.

Re:Legal?

[kayditty]

you must be living in 1996. for the past 5 years, any time I've registered a gTLD (and this is probably true for many ccTLDs as well), it's been in the root servers mere minutes later.. at least with GoDaddy. I know VeriSign started doing root zone updates every five or ten minutes somewhere around 5-7 years ago.

Re:Legal?

[Anonymous Coward]

and you are naively assuming that they honor the TTL for nxdomain answers when they are already violating the spec

Re:Legal?

[RedK]

Call it naivete, and I'll just call you a conspiracy nut. I discuss facts, not fiction. Until someone comes forward with proof that they cache NXDOMAIN responses longer than they should, then it's not worth starting foaming at the mouth about it.

Also, let's be clear, in no way am I advocating that what they are doing is right. It's a blatent violation of the spec and I am against that, I was just explaining to the OP that NXDOMAIN aren't cached forever and as such, he wouldn't lose traffic that he would have had anyway with his hypothetical scenario.

Re:Legal?

[Spliffster]

Here crappy providers (I mean the big ones which serve 90% of our population) tend to cache DNS records for um to 2 weeks completely disrigarding TTLs ... yes *two fucking weeks*. It is especially annoying when we move customers from one hosting provider to another.

That's where we come in...

[Anonymous Coward]

Well that's kind of the point isn't it?

We as techical people do see the point, so we have to educate those that don't, as well as companies that do stupid things like this.

Excusing yourself for OTHER people not understanding seems a very, very odd standpoint.

Feedback form

[talcite]

For those of you who want to let Bell hear a bit of your mind, the comments form is here:

https://www.bell.ca/support/PrsCSrvInt_CtUs_Eform.page

At least their search page suggest s a solution

[Man Eating Duck]

The first hit for me is the wonderful errornerd.com, which can fix these errors if you download their registry utility.
They can even fix a host of other errors, even 404s and errornerd.com is a fraud errors.

Re:At least their search page suggest s a solution

[Andr T.]

Damn, that seems pretty good! It's even Microsoft certified!

Re:At least their search page suggest s a solution

[Anonymous Coward]

So, um. What does the wonderful .exe on that site do?

Re:At least their search page suggest s a solution

[Anonymous Coward]

It even fixed [url=http://www.errornerd.com/error.php?seed=The-Internet]The Internet[/url]!

Re:At least their search page suggest s a solution

[Man Eating Duck]

So, um. What does the wonderful .exe on that site do?

After googling it seems to be a piece of malware disguising itself as a registry cleaner. It's google-bombed extensively, but the cries for help shines through if you look at forums and reliable sites after googling "regcure malware" or something like it. I have no idea if it's trying to impersonate a real utility, but this one smells bad. Stay away :)

Re:At least their search page suggest s a solution

[Anonymous Coward]

I didn't believe you until I saw it could fix this!.

Re:At least their search page suggest s a solution

[Anonymous Coward]

My favorite: how to fix Microsoft Windows

Re:At least their search page suggest s a solution

[megrims]

Hehe.

From his terms and conditions:

Unless expressly authorized by website, no one may hyperlink this site, or portions thereof, (including, but not limited to, logotypes, trademarks, branding or copyrighted material) to theirs for any reason. Further, you are not allowed to reference the url (website address) of this website in any commercial or non-commercial media without express permission, nor are you allowed to 'frame' the site. You specifically agree to cooperate with the Website to remove or de-activate any such activities and be liable for all damages. You hereby agree to liquidated damages of US$100,000.00 plus costs and actual damages for violating this provision.

Re:At least their search page suggest s a solution

[Nyvhek]

This is amazingly exploitable. It even lets you inject arbitrary html in the query.

Re:At least their search page suggest s a solution

[julesh]

This is amazingly exploitable. It even lets you inject arbitrary html in the query.

So? What can you achieve by doing this?

And yet I don't see it

[Late Adopter]

DNS doctoring is bad for many reason.

Just because a domain exists doesn't mean it's the one you wanted. Think of all those properly registered phishing sites out there, just waiting for a user typo. What's the difference between them and a DNS search redirect? If anything, this highlights the broken behavior of using the (non-)existence of a domain name for anything useful. You really care about whether you got the RIGHT site, not just *a* site.

Re:And yet I don't see it

[gnick]

There's an easy solution for that. When I want to visit slashdot, I type in:

http://216.34.181.48/"

Or google:

http://74.125.95.103

or, if that's too slow:

http://74.125.95.105

Is that too hard to remember?

OK, kidding aside, I agree - The DNS system's a mess. I'd like to see something where typo-trolls could be shut down, but that's not simple. Without writing a thesis on the subject here, it's pretty damned complicated. But, stopping DNS-folks from parking on domains is simple as long as we (regionally) rule on whether or not they're allowed. Right now, they are. That pisses off most slashdot folks, but not most of the general public. So, we tolerate it and come here to bitch and whine. /bitch-and-whine

Re:And yet I don't see it

[Kozz]

DNS doctoring is bad for many reason.

Just because a domain exists doesn't mean it's the one you wanted. Think of all those properly registered phishing sites out there, just waiting for a user typo. What's the difference between them and a DNS search redirect? If anything, this highlights the broken behavior of using the (non-)existence of a domain name for anything useful. You really care about whether you got the RIGHT site, not just *a* site.

Oh, I see... so then Bell can decide for me whether I'm about to see the "right" site? Yeah, that WOULD be helpful. Thankfully it will be easy to agree on what's the "right" and "wrong" sites. No problem there.

[/sarcasm]

Re:And yet I don't see it

[Late Adopter]

Oh, I see... so then Bell can decide for me whether I'm about to see the "right" site?

I'm confused. I don't recall even implying such a thing. I likened Bell to phishers... how can that be an endorsement of their results?

In the event that I was unclear, let me say it more explicitly: when you use user input to do a DNS lookup you can't trust the results. There's typos and typosquatters. So whether or not the DNS server returns the proper error message or resolves to a site is *meaningless* for any piece of software to rely on.

Just like a server that inherently trusts the client is broken, so is any software that makes assumptions about a remote site just because it exists.

Re:And yet I don't see it

[MBGMorden]

And what about when I want to visit the phising site to take sceenshots to show my users the signs that they're on a phishing site? Or what about when I really do want to visit goolgled instead of google?

Nah, I'd much prefer the computer keep what it "thinks" I meant to type to itself. As a group I thought we already realized from Microsoft's Clippy that the computer changing around what you do is annoying. Heck my cell phone still does this and it's one of the most annoying things in existence. I type a makeshift abbreviation for a word and half the time it replaces that with what it thinks I meant. The whole concept is broken.

Re:And yet I don't see it

[Chris Burke]

. So whether or not the DNS server returns the proper error message or resolves to a site is *meaningless* for any piece of software to rely on.

Just like a server that inherently trusts the client is broken, so is any software that makes assumptions about a remote site just because it exists.

Knowing whether a site exists can still provide useful information for a wide variety of uses. Nobody is using the existence of a server as a form of authentication, okay? We have other mechanisms for verifying the identity of a site, when such identification is important. As the simplest example of how this screws things up, having a valid NX response versus a made up lie of a response will make the difference between an app failing immediately because the NX response says the server doesn't exist, versus waiting and eventually timing out trying to connect to a server that doesn't exist, but the app doesn't know it's because the server is slow, or the service is down, or the packet filter rules are eating your packets.

Just because you don't know or understand how this breaks things doesn't mean it isn't broken.

The behavior of identifying typosquatters and directing the user to the site they intended is properly implemented in the web browser. Not by fucking up one of the fundamental protocols of the internet. The web isn't the internet. And this behavior is broken even for the web.

Re:And yet I don't see it

[KillerBob]

Just to add an example that might make more sense to people, checking whether the originating domain has a DNS entry is one of the easiest and simplest ways to filter spam, and will probably catch 75-80% of it. By having a DNS server that hijacks the response and sends a false answer, they are breaking that method of spam filtering, which causes an awful lot of unneeded processor time on mail that wouldn't have gotten onto the server in the first place, which in turn slows things down for the legitimate mail getting through.

While it's not quite so important to somebody who's on a home connection, it is an example that might be more tangible to the casual reader, and which might make it easier for them to understand why DNS hijacking is a bad thing.

Re:And yet I don't see it

[stine2469]

Perhaps they should be required to pay an appropriate registrar for each domain they simulate....call it a rental fee, the same as the purchase price, good for 1 response, non-refundable.

Re:And yet I don't see it

[stine2469]

No, not exactly. If i own domain thisismydomain.net and i have two hosts, www and ftp, and that's ALL that i have defined, anyone who enters wwww.thisismydomain.net or sftp.thisismydomain.net will get redirected, even though the domain (thisismydomain.net) does exist. The solution is a wildcard dns record so i end up with
www 135.84.0.1
ftp 135.84.10.30
* www.thisismydomain.net

All names other than www and ftp will resolve to my www server, but without it, they get hijacked and an internet user might just think that my site had gone offline.

It's not...

[argent]

This...

When you "opt-out", your browser receives a cookie (isn't that nice) that tells them that you don't want the search page. It will still use their broken DNS server's non-NX response, but it will show a 'Domain Not Found' mock-up page that they (I surmise) tailor to your browser-agent string. ...is just ****ing unacceptable. That's not ****ing opting out.

Windows shares

[Anonymous Coward]

If you have a share "woody://shared/data" then your machine will look up "woody" on DNS. Before this, your work laptop would get NXDOMAIN and wouldn't try to map a drive.

With this, it will hear that there is such a domain from your ISP and try to mount a share from it.

Same bull**** with Bresnan Communications

[Anonymous Coward]

Bresnan Communications pulls this same crap. The only way to opt-out is accept thier cookie.

So f**king annoying

[Malc]

I spent June in Toronto and Ottawa with friends and my family, all of whom have internet service provided by Rogers. Now I have a bunch of type-o URLs in FF's history when I'm typing the in the address bar. Anybody in the province who can get DSL should go to Teksavvy where you'll get good service and none of this crap.

Re:So f**king annoying

[knorthern knight]

> I spent June in Toronto and Ottawa with friends and my family, all of
> whom have internet service provided by Rogers. Now I have a bunch of
> type-o URLs in FF's history when I'm typing the in the address bar.

When this happens in Firefox
1) down-arrow to the line in the list with the item you don't want
2) hit {DELETE}

and it's gone.

no news here.

[Anonymous Coward]

windstream, verizon, and insight engage in this routinely...only way around it is to run your own caching nameserver. problem solved.

Net Neutrality

[sugarmotor]

Viewed in the context of net neutrality -- how can there be net neutrality if they don't even provide net access
according to the semantics of the protocols?

Stephan

Re:Net Neutrality

[John Hasler]

You don't have to use your ISP's DNS. To violate net neutrality they'd have to be blocking access to any servers other than their own.

numerous other ISPs are also guilty of this...

[Mystic Pixel]

...Cavtel (for some reason, the only DSL available in my office building, even though I can see the Verizon CO 1000 yards away from my window) does this same BS and it drives me nuts, I just changed the DNS servers returned by our DHCP box and voila.

Broken, and boneheaded, but solved with a small amount of work. Still, it's something I shouldn't have had to bother with, and the whole "breaking the Internet" thing is a problem -- they should no longer be able to classify themselves as an "Internet Service Provider" since they're not doing a reasonable job at it.

Free fast Public DNS Servers List

[condition-label-red]

Free fast Public DNS Servers List

Personally I use 4.2.2.1 and 4.2.2.2 due to them being easy to remember

This isn't news.

[spicyed]

Optimum online, and Verizon internet services in my area have been doing this for awhile. You're telling me this isn't business as usual? I get that the opt out method is pretty stupid, but at least they have an opt out option.

Not the only one.

[LaminatorX]

Paytec/McCloud telco does this here in the states.

Yay for faked browser pages!

[TechnoFrood]

I'm sure those faked browser error pages won't be at all confusing, visiting the page in Chrome displays a fake Safari error page (unsurprising as the user agent is for some odd reason Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.196.2 Safari/532.0).

Only affects www subdomains

[Anonymous Coward]

This seems to only affect lookups for queries prefixed with www. For example, a lookup of blerght.com returns nx, while www.blerght.com returns 67.63.55.2. There may well be other subdomain queries that it also hijacks.

Visit the CRTC Website

[Anonymous Coward]

I urge all of you to visit the CRTC website to see what Bell has been upto.
So far, they are on a buying spree to take over, or own controling shares in Aliant (Now Bell Aliant), Virgin Mobile Canada (Now Bell Virgin Mobility), Telus (Now Bell Telus), rogers, koodo, fido, BarbadosTel, the Source, and are trying to take over MTS and AT&T WorldWide, aka AT&T USA.
They are also no longer BCE (Bell Canada Enterprises) but Bell Enterprises, cementing their plan to go global (As if AT&T and BarbadosTel aren't enuf proof...)..And trust me, more is in the works, but it will take time for you to see it.

4.0.0.1

[Anonymous Coward]

Actually, OpenDNS has been known to doctor with the requests too, so suggesting it in this case is treating a problem by introducing a new one. Much better to simply use 4.0.0.n with n in the range [1-6] if memory serves me correctly.

Re:4.0.0.1

[Volante3192]

Or install your own DNS server.

This ought to be illegal

[Baron_Yam]

DNS is recursive, right? Starting with the TLD servers, then downwards. Someone upstream of Bell is returning a 'domain not found' and Bell is intercepting that and modifying it.

I understand that you're using Bell's local DNS servers to start the search, but the effect is the same as them intercepting and modifying your communications.

ISPs doing this kind of crap should get sued under whatever law most closely applies.

Re:This ought to be illegal

[Anonymous Coward]

IIRC I remember getting pages from my ISP in my browser saying they were the website "www.google.com"
and that they (the ISP) were asking me for money or to register in some way. So yeah, man in the middle does exist.

Re:This ought to be illegal

[Wowlapalooza]

DNS is recursive, right? Starting with the TLD servers, then downwards. Someone upstream of Bell is returning a 'domain not found' and Bell is intercepting that and modifying it.

I understand that you're using Bell's local DNS servers to start the search, but the effect is the same as them intercepting and modifying your communications.

ISPs doing this kind of crap should get sued under whatever law most closely applies.

IANAL, and I'm even less familiar with Canadian laws on the subject, but if a U.S. ISP were doing this, it's not clear that any U.S. law applies to this behavior. Although modifying DNS responses for profit seems intuitively "fraudulent", the Computer Fraud and Abuse Act (18 USC 1030 et seq) speaks in terms of "access", "authorization" and "damage". It's pretty hard to force this behavior into that framework (are the ISPs nameservers "damaging" the client? "accessing" the client? what's their "authorization") in a way that actually passes the Laugh Test.

Re:This ought to be illegal

[JesseMcDonald]

They're not intercepting your communications with any outside server. You asked them for the IP address linked to a given domain name, they asked a higher-level DNS server that returned NXDOMAIN to them, and instead of just returning the same NXDOMAIN to you like everyone else would they returned a pointer to the server hosting their search page. Underhanded? Sure. But intercepting and modifying your communications? Not really. Your communications were with the ISP to being with, not the upstream DNS servers, and nothing really obligates the ISP to return the standard response.

You could configure your system to query one of those upstream DNS servers directly. If they messed with that, then they would be interfering in your communications.

vigilante

[fulldecent]

where's that perl script that queries random domains to break the ISP's DNS cache?

The simple solution.

[sudog]

And everyone wins: a version of BIND that allows an overlay of master records based on secondary queries. You look something up, the authoritative query goes out to the replacements, the fallback position is the root nameservers.

Then, you can participate in OpenDNS or OpenNIC or whatever you want, *and* participate in the base DNS network as well. Plus, if you ever decide someone is being naughty, you can just overlay them with a whiteout (and you get rid of every domain-squatter-searcher you want to get rid of,) or you can simply override domain squatters with the original rightful owner.

Plus, the extortion money you currently pay? You can get rid of it basically for free. Set up a domain in the overlay instead.

InfoSpace is behind this.

[Animats]

They're reselling InfoSpace. Click on this link to demonstrate.

InfoSpace claims to be passing search queries to Google, Yahoo, Bing, Ask, and Twitter, then combining the results. I'm surprised they can do that. Google, Yahoo, and Bing all prohibit that in their terms of service. (With Google, you're only allowed to use Google's display format, expressed in their AJAX API, but you can add additional info. Google doesn't allow reordering or combining their results. Yahoo is more flexible; you can reorder, reformat, and, subject to some restrictions, add ads. Bing allows reordering and combining for Web searches, but not other types of searches.)

Re:InfoSpace is behind this.

[Anonymous Coward]

And you can see that they manipulate the InfoSpace results returned. Search for "Microsoft" on InfoSpace. All of the sponsored links are at the top of the page. Do the same here and the sponsored links are scattered throughout the page. Very deceiving.

Ma Bell got the Ill Communication

[AP31R0N]

Better Headlines:

"Bell Is Hijacking NX Domain Queries"

Does Bell "startS" hijacking on a daily basis or all the time? Tony Hawk skateS every day.

"Bell Hijacking NX Domain Queries"

Brevity is wit.

Hit the reply button to make excuses and apologies.

How my ISP does opt-out

[Anonymous Coward]

My ISP (Qwest) tried to do this, but they had an option (albeit slightly hidden) to truly disable it. It worked by giving the router a different DNS server next time it DHCP'd, and this server actually sends NXDOMAIN when it can't find a site. So it is possible to do opt-out correctly, not that it makes it OK for them to do this in the first place.

Reverted Policy?

[cripeon]

I use Bell, and I noticed the hijacking maybe a week back. Even thought of submitting a story to /.

But then it magically disappeared later on (next day?). Hasn't come back since, and before posting, i made sure that I was receiving NXDOMAIN's and not Bell's specially crafted "Domain not found" for opera: [eon@enthalpy:~]$ host fadfad.ca Host fadfad.ca not found: 3(NXDOMAIN) [eon@enthalpy:~]$

So, did they change their policy, or am I the only one mysteriously not affected by this?

Infringing use of Apple's Safari logo?

[PrimeWaveZ]

I would imagine that their use of the Apple-designed Safari logo (it is stored on their server at http://assist.infospace.com.edgesuite.net/bellassist/pics/compass.png) is an infringing use of Apple's intellectual property, especially if it is designed to appear as though Safari itself generated the message and cause confusion as to the source of the message.

Get Apple legal's hounds on Bell and see what happens.

so what would be a workable solution?

[dalbaeb]

Sorry, I'm new here and relatively inexperienced in the whole area of DNS-network-domain malarkey..

Déjà vu

[apankrat]

It seems like a good time to re-pimp my dnsfix utility that undoes the effects of their NS response mangling. I wrote six years ago when VeriSign tried to pull the exact same NX proxying bullshit with its SiteFinder "service".

patch

[asdfndsagse]

dnsmasq supports specifying bogus NX domains, and rewriting/fixing them.

Cookie? What's a cookie?

[Todd Knarr]

I don't see any definition of this "cookie" in the DNS RFCs. I don't see it in the SMTP RFCs, or Telnet, or FTP, or SNMP, or SSH, or in fact any Internet protocol except for HTTP. And I hate to have to tell Bell Canada this, but the majority of the Internet does not use HTTP for name resolution. It uses DNS, and interprets DNS responses including NXDOMAIN. So if they're going to implement an opt-out solution for DNS, it needs to work with DNS clients and not just with HTTP clients. Otherwise, they need to abandon DNS redirection and begin doing transparent proxying of HTTP instead.

Oh, and before you say "But everything uses the Web now!", riddle me this: what transport protocol does World of Warcraft use to communicate between the game and Blizzard? What protocol does Everquest use? Hint: it's not HTTP. Do you want to claim that World of Warcraft and Everquest have a negligible number of players?

You can take action against Bell

[Ant P.]

Yes, you!

Report their fake error page: Help -> Report Web Forgery in Firefox, probably in the same place in other browsers.

Bell and Rogers are dirty dirty bastards

[billcopc]

Bell fucks with DNS, Rogers hijacks web traffic to insert little messages about your bandwidth usage. Those two are just bad netizens all around.

The simplest solution to Bell's DNS mongling is to not use their DNS. If you can't set up your own recursive DNS server (bind), well try to find an open DNS you can mooch off of. Maybe Bell's corporate side doesn't do this kind of bullshit, just a guess...

DJB dnscache

[Anonymous Coward]

Seems Bell isn't hijacking all DNS queries, just messing with queries to their own DNS servers.
I just installed DJB's dnscache as a local "authoritative" cache, and firefox now hits up google for the first result if the domain doesn't exist (as per usual).
Don't know what you'd do if you're on windoze, but then I guess you'd be used to things being broken...

Unable to reproduce

[Leolo]

I'm on a Bell DSL connection.  I am unable to reproduce this problem.

;; QUESTION SECTION:
;bing.honk-honk.qc.ca.          IN      A

;; AUTHORITY SECTION:
ca.                     3600    IN      SOA     jbq01.tor.cira.ca. admin-dns.cira.ca. 2009080414 1800 900 604800 3600

;; Query time: 56 msec
;; SERVER: 206.47.244.78#53(206.47.244.78)
;; WHEN: Tue Aug  4 14:16:41 2009
;; MSG SIZE  rcvd: 99

Re:Sponsored Links Appearing In The Middle Of Resu

[Ant P.]

On reputable sites, they are.

Bell is clearly anything but.

It doesn't even work correctly...

[flibuste]

Type "http://www.domainnotfound.ca/" in IE 8 - you get "Internet Explorer cannot display this page."
Type "http://www.domainnotfound.ca/" in FF - you get directed to http://www.domainnotfound.cawww.domainnotfound.ca/ (yes, doubled name, it's not a typo from me)
Go to "http://www.domainnotfound.ca/clickserver/". The "back" link is broken and doesn't work (without looking, I assume it's a javascript:back()).
One word: pathetic.

www.non-existent-domain.com

[FrozenFrog]

I just registered it. :) Frog

Add to hosts file

[Anonymous Coward]

0.0.0.0 www.domainnotfound.ca

I already submitted this before.

[Tolkien]

This is old news.

Verizon did this

[Anonymous Coward]

Verizon did this a while ago. FUN!

Great Idea!

[SCHecklerX]

Because, you know, the only thing that relies on DNS is users browsing web pages.

Another reason I just cancelled my Bell service.

[imccuaig]

It's not like you can use their DNS anyways. That's the first thing their techs tell you when you get them on the phone, to switch. Also, when you finally get sick of their lousy service and switch, they hold your line hostage for 30 days and inflict an extra month of embarrassingly bad DSL service on you as punishment. Bell has become a sad joke.

Massive Typosquatting

[typosquatting]

I've made the point before, but it's worth pointing out again that this is just typosquatting on a massive scale.

Many people don't realize that there's TONS of traffic going to typo domains (whether registered or not). For instance, youtuve.com (notice the v instead of the b) got 347,852 visitors over the last 31 days. It redirects to another domain for cloaking purposes, but here is the traffic report. This level of traffic provides the financial incentive to implement these DNS schemes.

By the way, there's a new, free typosquatting scan tool at aliasencore.com. It shows you all the registered .COM domain names that are one character misspellings of any Alexa top 100,000 site you enter. It also displays screenshots of those typosquatting sites. It's a nifty way to get a quick idea of the rampant growth of typosquatting. Here's an example that shows the 425 registered .COM domain names that are one character away from google.com.

Full disclosure: I am Graham MacRobie, the CEO of Alias Encore, Inc. We help companies recover cybersquatting domain names, but we focus solely on "slam-dunk" typosquatting cases (obviously only registered domain names). I can speak from personal experience in this field that the very last thing we need is wholesale typosquatting at the DNS level. Bell Canada should turn this "feature" off immediately.

I'd also intervene if you were about to jump off a

[Anonymous Coward]

cliff.

I was actually planning on switching soon, as they were advertising 16Mbps service for way cheaper than Rogers. Of course if they're pulling crap like this, I'd rather stay with the evil I know and have learned to tolerate.

I'm going to do you a huge favour ever and tell you that you must go to the dslreports.com Bhell forums and find out the truth about Bhell and what their victi^h^h^h^h^hcustomers think of their serivce, india-based tech support, speed claims, pricing scam^h^hemes, throttling of torrents, tiny download caps, etc.

Your're welcome.

Cox too: goes to find-assist.com

[Anonymous Coward]

I have the same problem... our office uses Cox and lately we have been redirected to "find-assist.com" where they give a search page based on my erroneous URL. Our Trend Micro anti-malware catches this and warns of a phishing attack. Lovely.

This broke Safari's domain completion feature

[mikeloader]

This change breaks the URL completion feature in Safari where if you type "cnn", Safari automatically displays "cnn.com". If you type a URL that is in your browser history, then of course Safari will auto complete it before submitting the http request, but if it's a domain you haven't visited before, you now get the useless Bell page instead of the page you really wanted. Does Bell just use Internet Explorer? If they were Mac users, they wouldn't have done this.

Misconfiguration, not forgery.

[John Hasler]

There's no forgery. You are connecting to their server just as you intended to and it is giving exactly the response they configured it go give. However, that response is not the one specified by the RFC.

Typical websurfer here, w/ own protective methods

[Anonymous Coward]

"DNS doctoring is bad for many reason. I'm sure a firefox or IE addon would actually be much more preferable. Something easy to dis-activate when things break." - by nicolas.kassis (875270) on Tuesday August 04, @11:40AM (#28941989)

Is it? I use a CUSTOM HOSTS file, it "proofs me", as far as many lunacies & madnesses going on, online, today.

I also never see an adbanner & these have been found to bear malicious content, such as this from this website ->

----

IT: The Next Ad You Click May Be a Virus:

http://it.slashdot.org/story/09/06/15/2056219/The-Next-Ad-You-Click-May-Be-a-Virus

----

(& many more upon request are available here, even with the "big guns", like Microsoft even, being victim to it... I can produce that also, just ask, upon request)

Anyhow/anyways, "back on track":

Nor do I slow myself down, in downloading + processing/parsing banner material or their javascripts (the harbinger of doom, unfortunately, by the misguided jack asses that misuse it thus for "evil ends", & this is another one I generally "turn off" on MOST sites, unless they demand it being in place operating, so I can gain full function from said website)

HOWEVER?

That's JUST the tip of the "benefits iceberg"... E.G.-> I also go F A S T E R, via another means (that also allows me to avoid DNS port 53 udp queries period, & their 30-60ns or more roundtrip resolutions of URL's to IP Addresses), by adding my favorite 200++ or so websites I like... so, if a DNS server gets "poisoned" (lot of THAT going on lately too, see Dan Kaminsky & more recently, he & Moxie Marlinspike's findings here, such as this article alludes to)?

I get to the RIGHT spot, regardless of a DNS server being poisoned, or just flat on its back, by being "knocked over"... I get to where I want to, in either instance... &, not to a misdirected malicious code laden one instead.

(AND, again? I get there, FASTER... many orders of magnitude so, even during the init. HOSTS file reads (since today's disks are so fast, especially the ones I use in Velociraptors, & WD Raptors + two TRUE SSD's (where I house my HOSTS file, by altering the DataBasePath location in the registry here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) & there I get literally 0ms access/seek (which COMPLETELY "blows away" the 45ms avg. of remote DNS server querying) especially once my local custom HOSTS file is fully cached (either by the local DNS client service, or, by the local discache subsystem))

This technique would/SHOULD also be useful to folks in GERMANY lately, what with their gov't. "choking off" parts of the internet to they, &/or tracking them for violating their edicts/laws... how so?

For those of you that may have heard of "A Black Day for Internet Freedom in Germany" from this /. article here recently of -> http://yro.slashdot.org/story/09/06/16/1657255/A-Black-Day-For-Internet-Freedom-In-Germany ?

I have a way around your "woes", & one that will not get you DNS port 53 udp logged either, in case your ISP/BSP (or gov't./police even) blocks out your fav. sites online, & it's VERY SIMPLE to do, using a custom HOSTS file & a text editor (like notepad.exe, but pay attention below to notepad.exe .txt extension warning I note below though)!

----

1.) Find the IP addresses (ping'ing them will get you this usually) of your favorite websites (even IF they are "banned/restricted" by your ISP/BSP & their DNS servers)

2.) Enter their "IP Address-to-URL" equation/resolution into your local HOSTS file (typically located under %WinDi5%\system32\drivers\etc ), using notepad.exe (be sure to sa

Just use Verizon's servers

[Anonymous Coward]

After battling Bell phone support for a good half hour hoping for (thought not really expecting) a decent opt-out method, I was told to use 4.2.2.2 as my primary dns and 4.2.2.1 as my secondary. They didn't sound like Bell owned IP's... A quick reverse lookup revealed 4.2.2.2 as vnsc-bak.sys.gtei.net, then a whois reported ownership by Verizon!

Well, its not being hijacked at least.

I hate them both so much

[sayfawa]

Man, do I ever hate Rogers. But I especially hate Bell. But *especially* Rogers.

Packet Mangling or Server-Side Spoofing?

[Wowlapalooza]

OK, after reading the article summary, everything linked from there, and all of the comments, it's still not clear to me whether Bell Canada is: a) replacing NXDOMAIN within their own DNS resolvers with address records pointing to the "helpful" web page or b) mangling packets so that any NXDOMAIN response from any nameserver to any client on its network gets its contents replaced with the "helpful" crap.

(a) is relatively easy to deal with, by setting your resolvers to "trusted" ones (perhaps a local caching server running on your own network), instead of the spoofy ones provided by Bell Canada

(b) is much harder to deal with, you'd probably have to either have multiple Internet connections, or to set up an encrypted tunnel through Bell Canada's network to the "trusted" resolvers.

Can anyone confirm/clarify exactly which form of "DNS hijacking" Bell Canada is allegedly perpetrating? "DNS hijacking" by itself is such an imprecise term...

Heh...

[Anonymous Coward]

Type in my.rogers.com (main competitor to Bell) and it goes to Bell's domainnotfound website...

Also, the page is formatted to look like a Safari 404... for Google Chrome!

I would give you the address but I blocked the URL with my router.

draft-livingood-dns-redirect-00

[marka63]

Bell Canada's engineers should read draft-livingood-dns-redirect-00 which if nothing else explains how bad their implementation is.

While there isn't consensus on where to go with this draft. The is consensus that cookies don't work and that NXDOMAIN rewrites are different in nature to the other forms of redirect in draft-livingood-dns-redirect-00 and should be treated as a separate issue to the other forms of redirect.

This is being discussed in the dnsop working group.

Bell tech support is useless.

[gnasby]

btw, if you are a current Bell customer don't even try calling their tech support to complain or ask how to opt out. I just did and the tech support had no idea what a NX Domain Query was, nor did the Supervisor I was transferred to. I even used small words to explain what Bell was doing and they claimed they had no idea what I was talking about. Go figure.

You aren't alone

[Draeconix]

Just got an e-mail from Comcast that it is currently implementing the exact same thing. Here is the email: "Dear Comcast High-Speed Internet Customer , At Comcast, we're constantly looking to deliver the best online and search experience. That's why we're introducing a new feature called 'Domain Helper' to help you find the sites you want when you mistype a Web site address in your Web browser. You'll notice this service if you mistype a Web site address, for example "http://www.comtcas.com" instead of "http://www.comcast.com." Instead of receiving an error page that the Web site does not exist, this new service will provide you with a Web page of suggestions and links to get you back on track quickly and help you find what you need faster. We also understand that sometimes customers want to surf their own way, without the assistance of Domain Helper, so we also offer an easy way to opt-out when you receive the suggestion Web page. You can also opt out by visiting the opt-out page now. We hope you find this to be a valuable tool to help you surf the web even faster. Sincerely, Comcast"

It is a fact

[Anonymous Coward]

Not the same poster as the one you responded to but where I work I have experienced first hand local and national ISPs IGNORING the TTL in our DNS records. By the way, Bell Canada is one of the national ISPs I was refering to. Rogers was the other.

How do they do this?

[Anonymous Coward]

See: http://en.wikipedia.org/wiki/Paxfire for one such enabler.

Add some muscle to this fight

[sootman]

One way to attack this: copyright infringement. This image that they serve up to Safari users is, according to Photoshop, identical to file:///Applications/Safari.app/Contents/Resources/compass.icns which is surely copyrighted by Apple. This won't necessarily shut them down but it would draw some attention and maybe hurt them financially a bit.

Cookies only help http:80, not other protocols

[billstewart]

Their cookie-based fix is offensively lame - not only does the typical implementation of DNS hijacking only "help" queries to http port 80 and maybe https port 443, while breaking other protocols, their opt-out "fix" only fixes connections to those ports from cookie-supporting browsers, not from the applications for other protocols. Comcast's opt-out uses MAC addresses, so at least you can opt out for everything, not just only opt out from the least broken services.

ion.simon.c is a child molester

[Anonymous Coward]

ion.simon.c is a known convicted child molester who was caught raping little boys.