OpenDNS taunts Google with real-time directory In mid-October, Sweden's net authorities managed to boot the entire country from the interwebs when a routine maintenance script accidentally removed a rather important dot from its top level domain. The period was reinstated in less than an hour, but address problems persisted for who knows how long, thanks to cached DNS …
Home for the kids & for many networks I support to lock out spyware/adware/myfacebebospacebook/pr0n at dns level, and I dont care that they are making money out of typo's - means I dont have to pay real money out.
Cant see me ever handing over more data to Google than I have too.
So long as OpenDNS continues to redirect 404 to ad pages by default (thus not actually returning a 404), their service remains a completely unacceptable standards breaker. Google is doing the "right" thing with their service. I should not need to register with a DNS service to make it work correctly.
In this case, Google wins. For now.
I would suggest that your knowledge is returning a 404.
If a page you request gives a 404 error then you get the 404 page that the domain has specified, exactly as you should.
Now if the domain you request does not have a valid record, then OpenDNS will by default return the IP address of their redirection service when it should return a NX Domain response.
NX Domain != 404
That said the OpenDNS service does a lot more than just the basic DNS service, so if you want those features you would register anyway, and then disable redirection and get the NX Domain response.
If you don't want to use the other features then fair enough, don't use the basics either.
OpenDNS does not redirect 404s. In order to do that, they would have to serve as a proxy, and DPI all your packets, my ISP does this (the bastards, I don't mind the DPI so much if they didnt flaunt it). What OpenDNS does do is redirect NXDOMAINs (which is a nonexsistant domain name).
NXDOMAIN errors are not nonexistant domains, no matter what the name may suggest. NXDOMAIN is returned for every requested host name with no resolution.
So if you were to enter splodge.theregister.co.uk you'll get an NXDOMAIN from your DNS server. So if you were to try to visit, say, ww.theregister.co.uk OpenDNS would redirect you to an advertising page.
NXDOMAIN errors are given if the domain does not have a DNS record at the level requested. If the domain exists at that level, but the file asked for at that domain does not you get the 404 error.
The point I was making is that OpenDNS only redirect NXDOMAIN errors not 404 errors. The page NXDOMAIN redirects to does not have any obvious ads to me, but then I block a lot using Opera, though it does give search results that are tracked.
Switching off NXDomain redirects can be done, though needs you to register an account. As I said if you want DNS resolution only then using OpenDNS probably not best, If you want to use the other features, and so be able to disable NXDomain redirects, you would register anyway.
"NXDOMAIN errors are given if the domain does not have a DNS record at the level requested. If the domain exists at that level, but the file asked for at that domain does not you get the 404 error."
You seem to be confusing http with DNS. A 404 error is indeed returned if the file does not exist, but it is not returned by the DNS server it's the web server that returns the 404.
For example is you enter http://www.theregister.co.uk/popular.html in your browser your browser would ask the DNS client for a resolution for www.theregister.co.uk. If the client doesn't already have the ip address it will ask the server. Having got the ip address your browser can ask the server for the page popular.html. The server will hand back the page.
If you were to enter http://www.theregister.co.uk/popular.htlm. You would still get a successful DNS resolution, but when asked for the page popular.htlm the server will instead serve up its 404 error page.
If you were to enter http://www.tehrgeister.co.uk/popular.html your DNS server will return an NXDOMAIN.
When looking at the matter of DNS redirects it's important that you distinguish between the FQDN, say www.theregister.co.uk and the URL say http://www.theregister.co.uk/popular.html. The former is something that can be resolved by a DNS server. The latter tells the browser the protocol, the host and the path to the file, it's no use to a DNS server.
In redirecting NSDOMAIN errors OpenDNS are effectively typo squatting.
If I want my domains to update fast I set a TTL low myself, let that propogate then begin updating. I don't want opendns increasing the load on my server by ignoring it thank you very much. If I start to see significant traffic from opendns I *will* block it, as will many others.
This from a company that redirects failed lookups to a web page, breaking the standards and betraing an assumption that the internet = port 80. Wouldn't touch them with a bargepole.
Free public DNS has existed for years in the guise of the unicast nameservers
4.2.2.1 -> 4.2.2.6
Those are 4ms from my UK gateway and 0.6ms from my US one.. I expect they're similar distance from most places. They don't screw around with DNS standards, don't bombard you with adverts, and aren't silently recording all your lookups to sell to google 'partners' either... they just work.
Totally agree with you Tony, this should not be in the hands of the resolvers. TTLs are there for a reason. If bad data has got into the DNS, it's because the provider put it there and didn't take enough steps to ensure it didn't get there in the first place.
It's like driving a car into a lake, and expecting the lake to dry up and make room for it, when in reality it was the driver's fault and the lake wasn't designed to cope with that situation.
Having the "directory" push updates out to resolvers will be nearly impossible - not everyone will use OpenDNS or Google.
The "parental control" aspect of OpenDNS should also not be handled by the DNS - it's the biggest case of using a system for something completely opposite to what it was designed that I've seen.
You've spectacularly missed the point.
Here's an example: Your site is stable and good, so you've set the TTL to something really long - say a month.
The various DNS places grab the record and store it nicely, requesting an update every month.
A while later, you need to change the DNS records. You set the TTL short, make the change, then set it high again.
However, you changed that TTL value shortly *after* one block of DNS updated using the old value. They don't know about the new TTL value or the new DNS records, so they will now wait one month to request an update.
Oh dear - now everyone using those nameservers can't find you for a month!
This scheme is proposing that when you make a change requiring new DNS records, instead of passively waiting for everyone to find out, instead you send out a cry of "Hey everyone - I have a new set of DNS records - come get it!"
And so they do - on your request.
If you haven't made a change, then the call is not sent.
Consider this "Push" DNS on top of the existing "Poll" DNS.
As to the behaviour of OpenDNS - well, that's another matter altogether. They have to make money somehow, so they use the NXDOMAINs to do so. If you don't like that, then pay someone else who does it the way you like.
My DNS are set to 24 hours, no need for any more generally speaking, much less creates unnecessary traffic.
When I need to make a change I drop TTL to 15 minutes.
Wait 24 hours.
Make my changes and put TTL on the new records to 24 hours.
Setting TTL to a month is just plain ridiculous and will create problems unless you know you will always have at least a month's notice of any changes.
Another big issue with DNS comes with some clients which effectively cache an NXDOMAIN.
We find this to be quite a common problem. You can guarantee that some numpty will try to visit a new host before it goes live. Usually some web developer who puts a new site live without bothering to ask us to do the DNS. They then try to access the "live" page and receive an error. They then realize they've forgotten the DNS (this happens so often it's depressing). We create the A record and test it. It works. We tell the developer who tries to access the page and it fails again. We remind them that, just like the last 12 times they've made this error, they need to flush their DNS cache so the stupid DNS client will actually try to lookup the A record again rather than just assuming it's not there.
The trouble with this is that they've usually already emailed hundreds of people with the new URL who've all clicked the link and got the error. They all ring the helpdesk who try to access the site and because we've just created the A record it works for them So the helpdesk pass all the faults through to the network team or the server team (never the developers for some reason) because it must be a network problem or a server problem.
It doesn't matter how often it happens the developers never learn, the helpdesk never learn. And all because some fucktard wrote a crappy DNS client.
This story is here so that I find out about the new service that openDNS provides and, as a fringe benefit, learn a little more about how t'interweb works.
On the other hand, your comment provides no useful information at all, although it could be inferred that you are a bored and somewhat angry person.
OpenDNS do not just provide a DNS service, they are also censors. What is worse, they are almost completely unaccountable. If anybody can find a practicable way to appeal against their misclassification of a domain then I would be delighted to hear of it. On second thoughts, why should we even need to appeal against a self appointed censor?
I love the fact I can put in a custom logo for the error pages, yes fine they are making money from typos and servers being down, though it still looks good to a client and its miles better than any DNS out there.
I wont be using Google DNS purely for the fact that I dont want to put all my eggs in one basket, Googles basket more the point.
Sometimes a centralised/all in one solution isnt always best.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
