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."
Isn't it this one ? ;)
I'm asking because the wording is quite hard to understand as my main language isn't english
blah
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:
Well, windows dns, maradns, powerdns... etc etc.
;)
Or they are like me and use djbdns, and won't go back..
There is a patch for djbdns, but they're not official so I wouldn't reccomend blindly using them.
The way to corrupt a youth is to teach him to hold in higher value them who think alike than those who think differently
Or if you get bored you could try dnsmasq and block the sitefinder yourself. As of yesterday dnsmasq has had the option to return NXDOMAIN when it recieved the 64.94.110.11 address (or any others you choose)
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.
Bind should just return NXDOMAIN and the application (Mozilla, IE, BitchX, whatever) can then sort it out in this fashion. Hell, we can even make handy BSD-licensed shared libraries that do this for easy integration.
The matter is that the application must be informed when a domain does not exist, not spammed with guesses that may be right.
Pathman, Free (as in GPL) 3D Pac Man
BIND should be enhanced in several ways:
The most important one, IMHO, is to compute a list of close matches and present these choices to the user. They may use the Soundex algorithm or some other tricks to see if characters are transposed, if one characters is wrong, if one is missing, etc. If well implemented, this would solve 60% of the problem.
BIND (and other Domain Name Servers) are given the simple task of turning a string into set of 4 octets (aka an IP address), using a massively distributed lookup table that maps strings to IP address.
The reason people are pissed off about Verisign's wildcard entry is that they have depended on their DNS saying "I can't find an IP address" when it can't find an IP address.
In general BIND is a program that talks to other programs via a very stable and well understood interface. Now, how would enhance BIND to do a soundex and return multiple possible results to programs that have been written to expect either a response in the form of a single IP address, or a "domain not found" error?
Sounds to me like this is something that should be handled in the application, if at all.
-josh
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.
Were I coding this patch, for example, the IPs for which to return NXDOMAIN would be specified in a config.
And what good would that do? If VeriSlime changes the ip hourly, you'd have to edit the config file hourly: bwilliant patching Holmes.
I prefer the patch as it will be supplied by the ISC: Patch bind and add the following snippet to named.conf:
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
Tada. Let VeriSlime work around *that*.
DNS is a directory service for god's sake, not a god damn search engine.
Right
DNS maps domain names to IP addresses and vice versa, nothing more
Wrong
Special Relativity: The person in the other queue thinks yours is moving faster.
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.
But glue records are very specific, and can be easily checked for. Only if an A record matches one of the names in the NS records need it be kept.
but couldn't this be the thin end of the wedge towards technologically mediated censorship?
Nope, no chance of that. You hace to actively define the zones for delegation-only.
From a post by Paul Vixie:
> And make it default configuration for new bind releases...
never. not for your example, nor for any set of tld's. the default for
bind will be what it's always been -- to respect the autonomy of the
zone administrator/publisher. overriding that autonomy has to be a
local act by a local name server administrator who is fully conscious of
the impact of their configuration change. once, with "check-names", isc
was accused of "legislating from the bench". never again.
Read the discussion: 80% runs BIND, what runs on the remaining 20%?
Clever signature text goes here.
No, they don't dare do this.
It's a federal offence to redirect a misspelling to a porn site as it's "illegal to deceive children into viewing harmful material". This is a provision of the "Amber Alert" legislation and will land you in jail for 4 years.
Relevant Link
The root servers do not serve
Moreover, alternative root servers would have to delegate .com & .net to some other trusted(?) party...
I have to make a small complaint here. I don't seem to be able to get the sitefinder page when I enter in an unregistered domain name. Not the links above nor just random garbage. I merely get a "Could Not Connect to Remote Server" message.
*Sigh*. I never get to have any fun...
Ryosen
One man's "Troll, +1" is another man's "Insightful, +1".
Here is the documentation for the patch. They don't hardcode an IP, they just have a way to say that wildcards records don't necessarily have to work everywhere. eg. you can say that "*.foobar.com => 1.2.3.4" but you can't say that "*.com => 64.94.110.11".
It's the other way around. Hormel has a trademark on 'SPAM' and would prefer UBE to be called 'spam'. See the SPAM website for more info.
Scroll down, there are multiple polls on the same page.
<sig>Guvf vf abg n frperg zrffntr
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.
What your not aware of is that about the same time Microsoft inserted it's own "helpful" page instead of what the remote server sent web admin realised the value of using the servers own internal feature of sending a more helpful page.
The internal 404 usually is some sort of program to track down and redirect you to where you should be so instead of saying "This page no longer exists" it's saying "Hay maybe you want THIS page instead."
Also read the 404 page more carefully. If something has gone wrong with the website your given contact information (presumming the web admin did his job and put the admin contact e-mail into the server) in the 404 message so that you can contact the person or persons responsable for maintanence and tell them what went wrong.
But again you won't get that contact information under Microsoft Windows IE "helpful" page.
That page is IEs best guess as to what happend and being familure with the Internet I'm usually aware of what is wrong and what is really going on and quite frankly IE has yet to guess the real cause of the 404 message.
However the big diffrence between Microsoft IEs replacement "Hay quit complaining I'm only trying to help" and Verisons search website is that IE is on YOUR computer and if you don't like how IE works download Netscape, Opra, Mozilla or one of the many other web browsers that are out there and you get the REAL 404 message but Verison is basicly changing the Internet inferstructure to do this so we all get screwed reguardless of the programs and os we use.
I don't actually exist.
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)
Even better is the version I wrote last night, which lets you ignore a list of names.
-russ
names.tinydns.org/djbdns-1.05-ignoreip2.patch.
Don't piss off The Angry Economist
I'm sure it's been mentioned before, but for those of you who run their own DNS servers, there is an extremely easy way to set yourself up to use OpenNIC as an alternative root.
/usr/bin/dig @ns0.opennic.glue > /var/named/root.servers
Simply locate your "root.servers" file (/var/named for RedHat installations) and run:
dig @131.161.247.226 > root.servers
and restart named. To verify that things are then working correctly:
> host ns0.opennic.glue
ns0.opennic.glue. has address 131.161.247.226
From that point onwards, you can update your root server file by adding something like this to your weekly cron:
while true; /dev/null
do
echo VerisignSucks${RANDOM}Times.com \
| nslookup >
done
Read this amendment to H.R. 1104:
Yes, but BIND already lets you mark nameservers as bogus. If that happens, it's just a simple matter of editing and reloading configuration files.
--
Can you sum it up in a word? *No.* In a noise? *Whuuuurghhhhh!*
http://www.petitiononline.com/verisign/
Yeah, how exactly IS this going to help??? Who modded this person informative?
It will only work if you manually try and goto sitefinder.verigisn.com (www, ping, trace, whatever).
Do you really understand how DNS works? If I make a query to iudsbfkjdf.com, verisign redirects me to their IP using the wildcard 'A' record, in which the webpage at that IP CLAIMS to be www.iudsbfkjdf.com.
Adding that to hosts will only redirect you to (in your stated case - google) if you attempt to connect to sitefinder.verisign.com.
Party?!? What kind of party is this? Where's the damn keg?
Virtus Junxit Mors Non Separabit
No kidding! Now if you ping fartsnuggle.com it just sits and waits for the timeout, but if you ping fartsnuggle.org you get an immediate proper response of "ping: unknown host fartsnuggle.org"
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.
they did. Just patch and add the following to named.conf:
zone "cc" { type delegation-only; };
The fix provided by isc even allows for denying wildcard records for subdomains only. This has been thought out.
And since Whitehouse is a company, and the White House isn't (although there has been some discussion of that recently), whitehouse.com is much better pointing to the magazine
Actually there are plenty of legitimate uses of the wildcard feature. One you might use everyday:
*.sourceforge.com
How do you think they keep on top of that many DNS entries that constantly come and go? You see it at ISPs that do third level (and higher) DNS virtual hosting and and group systems where the URL might be in the form of username.domain.com instead of domain.com/~username/
DNS supports it because it is a legitimate
feature. And less you think removing wildcard support would fix the issue, as it has already been mentioned in this discussion, all Verisign has to do is modify their DNS server to supply responses that appear to make the domain legitimate. They already use non-standard DNS software, why not make a few more changes to enhance their bottom line?
Even after the ISC makes the patch to disable wildcards at the TLD level, Verisign can as mentioned above work around it if they really want to by modifying how their servers respond.
Never meddle in the affairs of dragons,
for you are crunchy and good with catsup.
Let's see...
gamefaq.com leads to a page for gamefaqs.com... no pr0n there.
whitehouse.com is the site for a pr0n magazine which predated the internet. The act wouldn't cover that case.
As for resonatorsoft.com, it's not pr0n either.
So you're 0-3 thus far...
See http://www.verisign.com/corporate/about/contact/in dex.html
for plenty of toll-free (in US) contact numbers.
The bruteforce method:
include "named.delegation-only";
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.
It doesn't care WHAT you type, you get the same garbage no matter what.
Give a man a fish, he'll eat for a day, but teach a man to phish...
Here is a much better petition entitled: "Stop Verisign DNS Abuse"
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.
replace
while( bogus_addrs[i].addr.addr4.s_addr != (in_addr_t)-1 )
with
while( bogus_addrs[n].addr.addr4.s_addr != (in_addr_t)-1 )
or you'll be sorry.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I think the chain of command is that
VeriSign ICANN DoC (Department of Commerce)
If a train station is a place where a train stops, what's a workstation?
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