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."
Good... Verisign's actions here are a particularly heinous form of "embrace-and-extend". Here, they're "embracing" an entire technology freely provided to them, and "extending" it in a blatantly proprietary manner, with no significant work at all on their part. Taking the whole DNS stack and turning it into a profit center by redirecting it at your whim across the entire internet, is outrageous.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
The .nu domain registry has been doing this for years.
Money for nothing, pix for free
http://www.isc.org/products/BIND/delegation-onl
To E-mail me, replace the first period in my domain with an @
"VeriSign did not respond requests for comment."
Isn't that what caused the problem in the first place?
Thanks, I'll be here all week!
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:
OK, I'm in favour of working-around the problem in classic
But I'm really concerned that this effectively lets VeriSign get away with it. They've bust everyone's trust folks, doesn't anyone care? This sort of activity in a social context (umm... let's see if we can construct a tortured metaphor: ...uhhh..: Your friend asks for your cousins's phone number and you instead give them the phone number of your shop. Reasonable?) would result in the perpetrator being ostracised fairly quickly, if not actually slapped about by a clue-by-four. It's flat out antisocial behaviour, never mind any legalities.
Here, since these buggers appear to hold us all over a barrel with the root domains, we can't just ignore them, and invoking legal recourses is at best slow and expensive. But what about appeal to the authorities that granted them those rights?
Um, the more I rant about this the closer I get to thinking a better solution is switching to an alternate root... Best head off to google again then, I know there's a way around this...
--
I'd rather have a bottle in front of me than a frontal lobotomy
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 @
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
So you have 2 mail servers with mx priorities as follows:
mail.someplace.com 10
mail.otherplace.com 20
if your someplace.com domain expires (hey, it happens) all your mail bounces thanks to verisigns ace "Snubby Mail Rejector Daemon v1.3". The backup mx record, which is there to cover failures like domains expiring, is never tried. In the 'real' world.. where lookups on dead domains fail... the backup server would be used.
Thats a bigger problem than all this spam checking people are getting worked up about. If they both had priority 10 (a simple load balancing arrangement) then half your mail would bounce and half would be ok.
Some improvement! Patches to BIND aren't the answer. Verisign need to be made to stop breaking the internet.
0daymeme.com: Great stuff.
ISPs running DNS will certainly disallow this redirection to VeriSuck.
/we/ want you to go."
But soon thereafter, if not immediately, they'll start directing their customers to their own search site, or whatever search site they're paid to send them to. Or maybe some ISPs already do this?!
We need an RFC stating that this is not permissable.
Heh, maybe as a byproduct we'll see public DNS servers pop up. "Use us for free, but occasionally we will send you where
NO NO NO NO NO NO NO! DNS is a directory service for god's sake, not a god damn search engine. If you want a search engine then go to Google like everyone else does. If people are too stupid to assume typing in "www.whitehouse.com" will take them to the White House's homepage then they deserve to get tits in the face. Type in White House in Google, hit feeling lucky and you'll get the right page right off. DNS maps domain names to IP addresses and vice versa, nothing more. Don't pervert it into some god damn spell checking search engine.
Exactly. The correct term for this is Sldahost efcfet
this is just a trick. They just want to get rid of all those obsolete BIND-versions out in the internet.
So they did this to goat all admins into patching their bind.
Tricky they are...
Regards, Martin
ICANN might be able to force VeriSign to get this off the net
http://www.petitiononline.com/icanndns/
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.
as suggested by Abby Patel at http://www.theregister.co.uk/content/6/32872.html
/. them and see how many netblocks they end up excluding.
However, it seems that the T&C's might help us to stop this abuse. If you do not agree to the T&C's the only option they have is to not redirect your netblock to their site. So, give them a call on 0800-032-2101, select 2 to speak to their support department and once you get a human, tell them that you don't agree to their T&C's and can they remove your netblocks!
So lets
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 dial a wrong number on your phone and a local telephone carrier answers and begins to try and sell you long distance and local services.
UNIX/Linux Consulting
Interesting that it rejects the first recipient, but accepts the second, then bomb on the DATA stage.
You are thinking too complex for verisign standards
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.