Slashdot Log In
BIND Strikes Back Against VeriSign's Site Finder
Posted by
timothy
on Wed Sep 17, 2003 07:00 AM
from the checks-and-balances dept.
from the checks-and-balances dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Excellent! (Score:5, Insightful)
Good for BIND (Score:5, Insightful)
Re:Good for BIND (Score:5, Funny)
Parent
Re:Good for BIND (Score:5, Interesting)
I hope BIND makes it configurable enough to kill off the .cc and .ws wildcards as well.
Parent
Re:Good for BIND (Score:5, Insightful)
I can't help but think of the contraversy over deep linking and how all those stupid suits could have been avoided if server operators would have just detected the referer header and bounced deep links back to the home page...
Parent
Re:Good for BIND (Score:5, Interesting)
Explain how they are in violation of the Anti-Cybersquatting laws, and have broken their contract with the Department of Commerce regarding the whois database. Mention how it's abuse of a monopoly power.
Make the states get involved, not the private attorneys.
Parent
Re:Good for BIND (Score:5, Insightful)
If someone is so gung ho about privacy that they disable the referer header and refuse cookies, then they must accept that sites with policies that require them to come through the front door and accept a token will be unavailable to them. Publishers are under no obligation to provide their material without at least a nominal quid pro quo from the user.
Parent
Bug your ISP (Score:5, Interesting)
Interesting that BIND only runs 80% of DNS servers, what is the other 20% made up of?
Re:Bug your ISP (Score:5, Informative)
-
TinyDNS [cr.yp.to]
-
Power DNS [powerdns.com]
-
NSD [nlnetlabs.nl]
Really depends on if you need a Recursive Caching server or just an Authoritive Server.Parent
Here is ISC's web page for delegation Only zones (Score:5, Informative)
http://www.isc.org/products/BIND/delegation-onl
Internet standards humor alert (Score:5, Funny)
Isn't that what caused the problem in the first place?
Thanks, I'll be here all week!
Re:Internet standards humor alert (Score:5, Funny)
Parent
Is a Technology solution ALWAYS better than law? (Score:5, Interesting)
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...
TRUST (Score:5, Insightful)
Had trust. Who can take them seriously now?
Parent
Re:Is a Technology solution ALWAYS better than law (Score:5, Interesting)
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.
Parent
link to patch and example (Score:5, Informative)
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
For TinyDNS / dnscache users (Score:5, Informative)
Russell Nelson has a patch [tinydns.org] for tinydns [tinydns.org] which does the same thing.
He also notes that several other TLD operators for the same thing and has another patch [tinydns.org] that allows you to do the same thing to several naughtly tld operators at once.
The new versions of BIND are already available (Score:5, Informative)
Although the news are not on the BIND page [isc.org] 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!
Re:The new versions of BIND are already available (Score:5, Informative)
DaC
Parent
MX Problems (Score:5, Insightful)
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.
Re:MX Problems (Score:5, Interesting)
Parent
Re:MX Problems (Score:5, Insightful)
Some improvement! Patches to BIND aren't the answer. Verisign need to be made to stop breaking the internet.
There's been this silly thread in this conversation that stakes out two sides. Either a) fix anti-social, monopolistic behavior with technology, or b) fix it with laws and legal action. This is a moronic dichotomy. A technological solution mitigates the immediate problem while the lawyers have time to file their briefs and sort out the damage done. A combination of technical solutions and legal action is a possibility and even a sometimes a Good Thing, not some binary choice.
Parent
Who will agree? (Score:5, Interesting)
The interesting question is, will enough people pick up the patch, so that Verisign will see their efforts wasted? This will only happen if the distros redistribute the patch.
Will the Linux distros provide updates to BIND that include the patch? (I bet yes.) Will Sun, the dot in .com, update Solaris? (This is harder to guess.) As for Microsoft, I think they will sneak in a patch, to Internet Explorer only, the next time they issue an "urgent" security patch -- though their motive is purely to protect their MSN Search revenue.
DJBDNS already has a patch [djbdns.org] available.
ISPs Will Soon Send You To Their Own Site (Score:5, Interesting)
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
It's a trick... (Score:5, Funny)
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
Sign the online petition to get ICANN into action (Score:5, Interesting)
http://www.petitiononline.com/icanndns/ [petitiononline.com]
Have your say (Score:5, Interesting)
Is Stratton D. Sclavos doing a good job as CEO of Verisign? Vote yes or no in this Forbes.com poll [forbes.com].
Also, here's a petition [petitiononline.com] that may also be of interest.
use their T&C against them... (Score:5, Interesting)
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
Google (Score:5, Funny)
NOT!
Not Trustworthy (Score:5, Interesting)
With it's digital certificate business, Verisign started as a company that dealt in trust. That was the heart of their business. Now it's hard to think of a company I trust less than Verisign.
For this stunt, they should lose their authority to register domain names. This company should never be allowed to touch internet infrastructure.
Re:Sqatting (Score:5, Interesting)
The .nu [whatevercrap.nu] domain registry has been doing this for years.
Parent
Re:Yeah, only SPAM, sure. (Score:5, Informative)
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:
Parent
Re:Yeah, only SPAM, sure. (Score:5, Funny)
Not if they make it in a configurable way to let you choose what IP Verisign is redirecting to. Then again, Verisign is a bunch of Dope Smoking Pedophiles [dopesmokin...philes.com], as referenced by this Internet Web site they have registered. Let's not forget they're also a bunch of Clueless DNS whores [cluelessdnswhores.com]. Oh yes, and I heard Verisign supports terrorists at this page: here.. [weloveinte...rorism.com].
Verisign needs to be shut down for these un-American and clearly criminal web sites. Someone notify John Ashcroft, quickly!
Parent
Re:Yeah, only SPAM, sure. (Score:5, Insightful)
Parent
Re:Yeah, only SPAM, sure. (Score:5, Funny)
Exactly. The correct term for this is Sldahost efcfet [slashdot.org]
Parent
Re:How will this work? (Score:5, Insightful)
I'd say that's quite an assumption. Were I coding this patch, for example, the IPs for which to return NXDOMAIN would be specified in a config. That config would be able to take single IPs and also ranges.
I wouldn't write this off as ineffective yet. We need to see what methodolgy is being chosen before we can comment on its technical effectiveness.
Cheers,
Ian
Parent
Re:How will this work? (Score:5, Informative)
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.)
Parent
Re:How will this work? (Score:5, Informative)
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
Parent
Re:very cool.. dnscache? (Score:5, Informative)
tinydns.org/djbdns-1.05-ignoreip.patch [tinydns.org]
Parent
Patches (Score:5, Informative)
Patches for DJBDNS and lots of other daemons here [imperialviolet.org].
Parent
Re:very cool.. dnscache? (Score:5, Informative)
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.
Parent
Re:ISC ROCKS (Score:5, Interesting)
I said it a long time ago, but there's a very simple way to fix this problem. Alternic was offering a solution 7 or 8 years ago for the Network Solutions monopoly. If BIND decided to distribute a seperate set of root servers in a cache file and enough ISPs used it the Internet DNS system as we know it today could change overnight. ;-) There is NOTHING giving ICANN or Verisign any power except our own complacency to not change a single file in our DNS server. It's laziness.
Parent
Re:Soundex into BIND! (Score:5, Insightful)
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.
Parent
Re:didn't they already do that? (Score:5, Insightful)
Having an application do that is completely different than having what is essentially one of the only Internet "utilities" do it without your consent. Redirecting queries is the job of an application, not the DNS root servers. There's a reason looking up non-registered domains returns an NXDOMAIN, because the RFC says it is should!
Parent
Re:Advice on switching to another registrar (Score:5, Funny)
John.
Parent
Re:Lot of fuss about nothing (Score:5, Informative)
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.
Parent
Re:Lot of fuss about nothing (Score:5, Informative)
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).
Parent
Re:the patch (Score:5, Interesting)
Clever solution. They rigged it so that you can declare the
So, if BIND makes a non-recursive query for www.verisign-is-really-bad.com from a server authorative for
Verisign could work around this by replacing the A record with a wildcard NS record pointing to ns.sitefinder.verisign.com or some such, and then having that new name server return an IP address for any query made of it.
The question is: is Verisign willing to escalate the matter or will they back off?
Parent
Re:Has anyone.. (Score:5, Insightful)
Ah. Bless. Cuddle up nice and warm.
Verisign is the root domain authority. This is them overstepping bounds and trying to get into the search engine game, something which is 'forbidden' by ICANN. They're farming information that comes in, and if you'd read the handy terms and conditions, you'd notice some real oddity.
So, you type in a mispelled URL...what if your competitor is in their database but you aren't? Furthermore, what if they get the domain wrong? Verisign only has
Then there's the email angle. They're running an MTA that barfs after the 550 for 'From: '. So they're grabbing 'legitimate' email addresses. Trust verisign? As a 'trusted' third party for certificate signing, they're supposed to remain impartial to a certain degree, except they're pushing webservices.
Parent
Re:What about the other 20%? (Score:5, Informative)
Parent