OpenDNS Phases Out Redirection To Guide
First time accepted submitter Jim Efaw (3484) writes "Tired of the OpenDNS Guide surprise from website-unavailable.com when you go to an old link or a typo from some ISPs? Relief is at hand: On June 6, 2014, OpenDNS will stop redirecting dead hostnames to Guide and its ads; the OpenDNS Guide itself will shut down sometime afterwards. OpenDNS nameservers will start returning normal NXDOMAIN and SERVFAIL messages instead. Phishing protection and optional parental controls will still stay in place."
"We can make enough money from selling your IP and the domains you look up."
It is not "your" data, it is data about you. Data that you are freely giving them.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Careful, you'll summon ...him
(1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
Using my ISPs, or VPNs, Google's, or having to roll my own all suck even more.
So what sucks about using google? Don't trust them? I guess that's a valid concern, but I wouldn't say it causes suckage.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
My company used to use OpenDNS, but then they'd resolve websites that went MIA and our automated scripts wouldn't know that and vomited on what OpenDNS fed them. We're using Google DNS now and it works perfectly. Gets around all the problems introduced by BT mangling the DNSSEC chain.
Being a prepper of sorts, and seeing the Gub'mint positioning itself to hijack DNS in order to exert control (or potentially just shut everything down by attacking this low hanging fruit) I've been looking around for a very specific type of resolver, which can be placed manually into one of several modes:
NORMAL: all lookups are resolved with network queries (as a standalone resolver OR as a 'thin' resolver which just forwards to some upstream DNS server). The results are returned as a real-time resolver does, but are also cached permanently to disk in a database that will inevitably grow over time.
FALLBACK 1, fill in the blanks: when a real result is received yet it is a fail (NOERROR,SRVFAIL,NXDOMAIN), as might be the case in a hypothetical shutdown attack, a stored query that had a positive result is returned.
FALLBACK 2, DNS network down/disabled: all queries are returned from the database and network lookups are not attempted.
So while we are resolving normally a database is being created for emergency use, yet if some disruption to DNS occurs it would be possible to switch to one of the fallback modes to surf -- if not completely, at least with some reasonable level of success...
A desirable feature would be to store a maintainable list of 'poison' ip/net masks of known DHS/ICE webservers, so any A records matching this list are NOT treated as real results, and trigger fallback action. Another desirable feature would be explicit (and implicit via matching of results) recognition of wildcard DNS schemes such as gobblegook.realdomain.com so repeated resolves of these do not overwhelm the database. But there might be some gruesome heuristics behind this.
I realize OpenDNS is in itself a step in this direction, but the local fallback resolver would also give you options for cases when OpenDNS itself is not reachable, such as a hostile/draconian ISP that rewrites DNS packets to point to its own servers.
<blink>down the rabbit hole</blink>
Use OpenNIC instead - less schennigans
I'm going to go with "he thinks he looks k00l if he can use words like 'telnet' and 'GET' on a Slashdot post".
The _behavior_ of redirecting failed DNS lookups to an advertising server is unsurprising. Roughly 10 years ago, Verisign did much the same thing to to the master servers for *.com', and broke the concept of getting a "no such record" result for everyone in the world using ".com" addresses.
http://slashdot.org/story/03/0...
Many, many people were _extremely_ upset when this unannounced change occurred. It broke tools worldwide that were used to verify DNS configuraitons, and it routed email that was misspelled or had faild DNS to Verizon's advertising DNS IP addresses. I was never sure if Verisign bothered to do anything with all the DNS connection requests, FTP requests, SSH requests, or everyehing else redirected to their sites, but it left Verisign in charge of a tremendous amount of data and potential network manipulation.
People, and software, have become more accustomed to such DNS abuse. But it's still problematic if you don't realize it's going on.
Nope. Never.
We wouldn't make such a case for turning off ads if this was our business model going forward. You could visit our site and see how we make money. We sell security services. We never could have done it without first being a consumer service, but we're not selling your data. Come on.
-David
# Hack the planet, it's important.
MaraDNS caches to memory, not disk, but will return expired DNS records to the client when there is no answer from authoritative sources.
PowerDNS can connect to a database backend, which can then permanently store a huge collection of DNS records.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
We have been building a data privacy and data usage policy document that we plan to release soon.
One of the many, many reasons to turn off ads is that we had to share some potentially personally identifiable information with ad partners (indirectly when making ad requests, they would just see it in the ad request), so by turning off ads, our privacy / data policy will be a lot more clear and will not need to have weird "certain third parties for certain services" kind of language to address the advertising business.
We're waiting to turn off ads, we'll get the document cleaned up, and we'll publish it.
-David
# Hack the planet, it's important.