Slashdot Mirror
BIND Strikes Back Against VeriSign's Site Finder
BrunoC writes "Following the story about VeriSign's new Site Finder, the Internet Software Consortium promises to release a patch to its (in)famous BIND that will block the controversial Site Finder. Wired News has full coverage of the ISC initiative against this name resolving atrocity."
http://www.isc.org/products/BIND/delegation-onl
To E-mail me, replace the first period in my domain with an @
I hope some large ISP's bring action against Verisign for breaking their email systems like that.
In the meantime, if you want to help keep Verisigns SiteFinder off the internet, try this simple script in a while loop:
Yep, the patch for dnscache by veteran Russ Nelson is here:
tinydns.org/djbdns-1.05-ignoreip.patch
-
TinyDNS
-
Power DNS
-
NSD
Really depends on if you need a Recursive Caching server or just an Authoritive Server.To E-mail me, replace the first period in my domain with an @
Patches for DJBDNS and lots of other daemons here.
upgrade can be found here:n -only.h tml
s &m=1063 79587928771&w=2
http://www.isc.org/products/BIND/delegatio
There is no need to create a com or net data file. Just the
entries to the named.conf file is enough
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
Ofcourse, if you use views, this needs to be provided within the relevant
view (the one performing recursive lookups).
quote from:
http://marc.theaimsgroup.com/?l=bind9-user
No, the patch doesn't do filtering in that sense. It just allows you to mark some zones in your BIND config file (such as .com and .net), that should only contain delegation information. So basically if your BIND server recieves back A record(s) rather than NS delegation records from a server authoritative for .com , BIND simply ignores it.
Simple and elegant, and nothing Verislime can do about it. (I hope.)
Russell Nelson has a patch for tinydns which does the same thing.
He also notes that several other TLD operators for the same thing and has another patch that allows you to do the same thing to several naughtly tld operators at once.
Although the news are not on the BIND page yet, patches for the current versions 9.2.2 and 9.1.3 are already available. Only 9.2.3rc2 is currently listed on the page (as of this writing).
You can get the details from the bind-announce list archives:
All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:
Have fun downloading and installing!
-Raphaël
Unfortunately the djbdns patch at that URL is not as elegant as the official patch from ISC for BIND. Unlike the ISC BIND patch, the djbdns patch does not support the declaration of "delegation-only" zones. Instead, it adds support for the rather crude technique of converting an A record response containing an operator specified IP address (which you would currently set to 64.94.110.11) into a NXDOMAIN response.
We're not talking about you and your little web browser, we're talking about a major network provider breaking an important network infastructure component in a way which has already started to cause havoc across the internet. At the moment, the server they are using as a catch all is not responding to connections, which means that there "clever" solution to handle mis-directed email doesn't work. As a consequence, mis-directed mail has already started to pill up in mail queues while mail servers waste their time trying to contact the Verisign server.
Other services are also shit out of luck; Verisign only allowed for HTTP and SMTP. Anything else trying to connect to a non-existent domain is out of luck and will sit around until the connection timesout. Of course, if the server had just returned NXDOMAIN in the first place, as it should, you wouldn't have that problem.
Read the discussion: 80% runs BIND, what runs on the remaining 20%?
Clever signature text goes here.
That approach is fucking dangerous.
/authoritative/ non-apex data from zones configured as delegate only. however, it can still make use of additional data (ie glue). Glue records are never queried directly AFAIK when a DNS server is sending queries to determine the set of authoratitive servers for a zone, so the patch does not cause any problems.
Why? Glue records. You are _meant_ to receive certain As from the parent servers of a domain delegated to nameservers which live within its own namespace.
However, you're missing a crucial part: when you ask the delegating server for the NS records, the glue A records are given out in the additional section, not in the answer section.
The ISC patch disregards
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
You don't get to see a "404 No Found" response if the server doesn't even exist. You'd usually get an error message (generated by IE) that says something like "www.invaliddomain.com doesn't exist." (that's what Mozilla displays, I don't know IE's message).
The 404 response is what you get when your browser could send a HTTP request to the web server, but the server couldn't find the page you were requesting. The response page is generated by the web server, so how helpful it is depends on what the web server admins have configured. Some pages will not simply return an error message but also include a search box, for example.
Well, yes, I expect a somewhat helpful error message. But that's not actually the point. The main problem with Verisign's move is that they are assuming (like you seem to do) that the purpose of the Domain Name System is to find the web server that a user is trying to contact when he types an URL into his browser. But DNS isn't used for the web only, it is used to associate names with IP addresses. You can then use the returned IP address for whatever protocol you want, DNS doesn't tell you whether or not the server with the returned IP supports that protocol.
For all protocols that run non-interactively (i.e. without a human sitting in front of the computer and interactively deciding what server should be contacted next, and interpreting the responses), Verisign's action means that if contacting a remote system fails, the computer can now no longer find out if it's due to a misconfiguration and will likely never work (if the other computer doesn't exist), or if it's just a temporary problem (if the other computer does exist but does not respond).
Sig (appended to the end of comments I post, 54 chars)
http://www.petitiononline.com/verisign/
I got a rep on the line and he seems oblivious of what was going on, after a bit I got a superviser and she gave me this email telling me that this is where the complaints are going to:
sitefinder@verisign-grs.com
Someone asked me the difference between ignorance and apathy, I told them I don't know and I don't care.
It's amazing how many super cool random people are running around suggesting using OpenNIC, which, of course, won't do a DAMN FUCKING THING. Anyone who suggests an alternate root has demonstrated they have no knowledge of how DNS works at the topmost level.
Please, someone go around and find all the posts that mention this and moderate them up! I've posted at least three posts pointing this out, and other people have also.
I'm starting to think everyone should have a few emergency -1: Wrong mod points to get rid of information that is just flatout incorrect.
If corporations are people, aren't stockholders guilty of slavery?
Doesn't work for me...then again, I've already fixed djbdns here to return NXDOMAIN when a lookup resolves to Verisign's squatter page. (A copy of the patch is here (the patch isn't mine, but the only place I've seen it is buried in bugs.gentoo.org) and an ebuild for your local Portage tree is here. To use the ebuild, you'll also need to copy Manifest and files/1.05-errno.patch from /usr/portage/net-dns/djbdns.)
20 January 2017: the End of an Error.
i didn't write this the post above, but it is definitely not offtopic. here's a brief rundown of what it does:
/dev/null. obviously, this string (with appended .com) resolves to verisign's search page.
generates a random string of characters.
performs a "wget" to look up that string as a domain name, and fetch the url returned and dump contents to
this accomplishes two things. first, or course, is wasting verisign bandwidth. more interestingly, however, it causes dns servers upstream from you to cache the address of all these garbage domains. when their dns cache fills up, they start discarding older entries they have had in there. basically, this is forcing dns servers to constantly flush their caches of any useful data. this, in turn, makes every valid dns query have to cascade all the way down to the root servers. that is, "slashdot.org" is no longer cached in your isp's dns cache, so every user on you isp trying to get to slashdot is contributing to a DDOS of verisign's root servers.
well done.
The new feature just needed this bit added to named.conf to get it working:
When its running, it will put message like this to