Re: Idea: Rogue DNS resolvers
Hi Thomas, Pretty old news. There are quite a few folks who have been doing this sort of stuff for quite a while. Besides SSZ there is also the .god domain. If you get around to setting something up give me a holler. On Mon, 7 Apr 2003, Thomas Shaddack wrote:
Watching the senseless court fights for domains, DNS hijackings, all kinds of technical and lawyernical attacks, getting into the way of the people who just want their informations and want their bookmarks and links from search engines just-working. Pondering...
The situation could be alleviated by a few (or a wider network of) volunteers, running public DNS resolvers (dnscache could be a good candidate) paired with DNS servers (tinydns is a choice here), with the "problematic" domains resolvings being set up manually, outside of the DNS infrastructure. (I don't talk about the alternative root servers now.) Let's name them RogueDNS (contrary to fully specs-conformant OfficialDNS). Standard setup, used commonly on LANs when some domains have to resolve to internal IPs instead of external ones (eg, servers behind the firewall, accessible from both the LAN and the outside over external IP).
Example of function: A company (or a country) unleashes their lawyers (or goons) on somedomain.com, which then gets shut down or repointed to the companydomain.com. A news about it gets out, together with the patch for the RogueDNS server definitions. From then, the RogueDNS resolvers answer queries for the hijacked domain with their original values, though the OfficialDNS hierarchy now show the officially enforced values (eg, pointing to the DEA servers with the we-don't-sell-bongs agenda, like in the recent case of government-hijacked domains of head shops).
Could be paired together with a webserver specialized to issue HTTP-REDIRECT responses, for the cases when the server is entirely taken down but a mirror exists - RogueDNS returns the IP of the redirecting server, the redirecting server gets the entire URL in the request, looks up the database of redirects, issues one.
Can be both centralized, decentralized, or running on end users' machines. The key problem here are the updates; they can be realized by mailing lists, or periodic or on-demand queries on a server (or server networks) using a protocol of choice; this is open for the developers.
A prototype version, without the HTTP redirector, already worked for my LAN (standard dnscache/tinydns combination). The HTTP redirector can be easily implemented using eg. Apache/PHP/MySQL. Or it can be partially emulated locally, by using hosts file.
Could it be useful in some scenarios? Does it have the proper ingredients for eventual wider deployment? Or is it completely unusable? Ideas welcomed. :)
-- ____________________________________________________________________ We are all interested in the future for that is where you and I are going to spend the rest of our lives. Criswell, "Plan 9 from Outer Space" ravage@ssz.com jchoate@open-forge.org www.ssz.com www.open-forge.org --------------------------------------------------------------------
participants (1)
-
Jim Choate