Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
The Internet Businesses Software Your Rights Online

BIND Strikes Back Against VeriSign's Site Finder 582

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.

BIND Strikes Back Against VeriSign's Site Finder

Comments Filter:
  • Excellent! (Score:5, Insightful)

    by Ratface ( 21117 ) on Wednesday September 17, 2003 @08:04AM (#6984453) Homepage Journal
    Tereby helping to prove the old adage that the Internet will just route around regulation! (OK, it's not strictly regulation, but with any luck Verisgn will find that "controlling" the underlying technology of the Internet is not as easy as they first though).
  • Good for BIND (Score:5, Insightful)

    by Empiric ( 675968 ) * on Wednesday September 17, 2003 @08:05AM (#6984461)
    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.
  • by nounderscores ( 246517 ) on Wednesday September 17, 2003 @08:06AM (#6984466)
    but couldn't this be the thin end of the wedge towards technologically mediated censorship?

    after all, almost anything is possible with the a patch... it just takes the will to do it.

    I' m a programmer with a soldering iron, and I'm not afraid to use it.
  • by mccalli ( 323026 ) on Wednesday September 17, 2003 @08:09AM (#6984488) Homepage
    I assume the patch will filter requests, which resolve to the site-finder IP...

    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.

    ...so what's to stop VeriSign simply changing IPs every so often?

    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.


  • by MCRocker ( 461060 ) on Wednesday September 17, 2003 @08:14AM (#6984526) Homepage
    I was dumb enough to sign up with, what was called Network Solutions at the time. Then during a moment of shear stupidity, I renewed... till 2007!

    I really want to get away from these jerks. There seem to be lots of registrars out there, but I've heard horror stories about totally unresponsive registrars that are glad to take your money, but ignore you if there's any problem at all. Also, if I switch, doesn't that just improve Verisign's profit margin? I've paid till 2007, now they don't have to do anything at all for that money. If I transfer to another registrar does Verisign get to keep my money?

  • MX Problems (Score:5, Insightful)

    by tinla ( 120858 ) on Wednesday September 17, 2003 @08:20AM (#6984561) Homepage Journal

    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.

  • by AKnightCowboy ( 608632 ) on Wednesday September 17, 2003 @08:25AM (#6984586)
    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.

    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.

  • by AKnightCowboy ( 608632 ) on Wednesday September 17, 2003 @08:27AM (#6984604)
    I seem to remember certain 'default' browser settings, that would automaticly re-direct unknown queries to a related MSN search page.

    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!

  • by Zocalo ( 252965 ) on Wednesday September 17, 2003 @08:29AM (#6984616) Homepage
    Actually, ISC as been smarter than that. What they have done is allow certain domains to be designated "delegation only". That means, in a nutshell, you can specify for instance ".net" and ISC will automatically return NXDOMAIN for anything other than an NS pointer at that level. This in effect will wipe out wildcarding at the TLD/GLD levels for which it is configured, and if you wished you could even extend it to block wildcarding of things like "*.uk.com".
  • Re:Good for BIND (Score:5, Insightful)

    by aborchers ( 471342 ) on Wednesday September 17, 2003 @08:33AM (#6984643) Homepage Journal
    And the BIND solution is an excellent response in the spirit of the network's self-healing nature. I'd rather see it solved this way than through a bunch of law suits that benefit none but the attorneys.

    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...

  • by Michael Hunt ( 585391 ) on Wednesday September 17, 2003 @08:39AM (#6984680) Homepage
    That approach is fucking dangerous.

    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.

    For example, let's say I have the domain movezig.com. I fill in a host template to for the two nameservers, base.movezig.com ( and cats.movezig.com (, then delegate it to those nameservers. Obviously, if the .com NSs only returned movezig.com IN NS base.movezig.com and movezig.com IN NS cats.movezig.com, we'd have a problem of infinite recursion.

    So, nameservers are designed to respond with A records for authoritative nameservers when a domain is delegated to NSs within its own zone.

    Since these records are sent by the servers authoritative for the parent zone (they live in the same zonefile as the NS records do), filtering them would break resolution of roughly 20% of the internet.

    Bad idea.

    A much better idea is to merely filter out any responses under a configurable set of parent TLDs where the authority section returned matches a preconfigured list of NSs.

    For example, doing a lookup for f00bw1tz.com (which i presume doesn't exist) returns an A of as expected, with the Authority section claiming com. IN NS (a-m).gtld-servers.net.

    This would be the tricky way of doing it.
  • Re:Has anyone.. (Score:5, Insightful)

    by Oddly_Drac ( 625066 ) on Wednesday September 17, 2003 @08:51AM (#6984735)
    "I just did. I don't see what the fuss is."

    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 .net and .com and there's a world of other TLDs out there.

    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.

  • TRUST (Score:5, Insightful)

    by Craig Ringer ( 302899 ) on Wednesday September 17, 2003 @09:04AM (#6984815) Homepage Journal
    This is especially critical given that Verisign's business is supposedly trust. They sell SSL certificates, and the only way they can claim they're better to use for them than (say) I am, is that they have an established record of security procedures and trust.

    Had trust. Who can take them seriously now?
  • Re:MX Problems (Score:5, Insightful)

    by TheViewFromTheGround ( 607422 ) on Wednesday September 17, 2003 @09:13AM (#6984882) Homepage

    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.

  • by bluGill ( 862 ) on Wednesday September 17, 2003 @09:14AM (#6984891)

    Anyone have a lawyer and a small site to try this on. I suspect that you have a case of some sort. "Your honor, we had planned for this type of mistake by having some.other.domain.com as a backup, but verisign illegally stole the expired domain and started bouncing our messages." Or some such. Of course that backup wouldn't work in the case of the domain expiring and someone else registering it instead, but you tried.

  • Re:Good for BIND (Score:5, Insightful)

    by aborchers ( 471342 ) on Wednesday September 17, 2003 @09:26AM (#6984976) Homepage Journal
    As UU7 just pointed out, the idea is to redirect requests with foreign headers to the front door. The vast majority of modern clients will send the header, and if it is blank, you can either elect to let them have the page, or force them to the front door and set a cookie.

    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.

  • by ananiasanom ( 704770 ) <ananias@st[ ]mail.com ['rib' in gap]> on Wednesday September 17, 2003 @09:36AM (#6985044) Journal
    I'm not a DNS expert, but couldn't Verisign work round this, by delegating x.com (where x is any unregistered domain) to a different nameserver (of their own), which would then return A records pointing to their advert server?

    Of course, they would need to customize their DNS software to do that, as opposed to just adding a line to a config file.

  • by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Wednesday September 17, 2003 @09:44AM (#6985109) Homepage
    Yup. It's crude. On the other hand, it's simple. Simple is good because you can read the patch and understand it. Consider that ISC has published three or four remote root exploits, and djbdns has had no exploits, remote, root, or otherwise. I'll take crude over insecure any day. J.P. Larocque has a script which lets you update root/ignoreip. You can update that file in a few seconds. An ISC-enabled root exploit means a complete reinstall unless you seriously trust your ability to remove a rootkit. Let's say it takes five seconds to update the file. Let's say it takes a whole day to reinstall your server (optimistic). Let's say there's a 1 out of ten thousand chance of this code causing a remote root exploit. There's 86K seconds in a day, so their code costs you 9 seconds a day. Given those assumptions, the "automatic" ISC procedure for updating the ignorable IP addresses costs you more time, on average, than updating by hand every day.

  • by vidarh ( 309115 ) <vidar@hokstad.com> on Wednesday September 17, 2003 @09:58AM (#6985232) Homepage Journal
    Ah, after reading your documentation, I realised that the explanation you give is wrong.

    What the patch does is saying that if I query server Foo, running this version of Bind, and Foo has to go and ask Bar about it, Foo will only consider delegation data from Bar, not other resources.

    So if Bar sends NS and SOA records back, all is well, and Foo happily tries to ask the delegated servers to resolve the name. If Bar sends an A record back, Foo will ignore it, and report a failure to the client.

    Problem with this is that if it gets widespread, Verisign might decide to serve these A records from other nameservers and add SOA and NS records for all the unregistered names as well, essentially fully delegating the names.

    The end result of that would be even more bandwidth wasted.

  • by Rich0 ( 548339 ) on Wednesday September 17, 2003 @10:40AM (#6985565) Homepage
    but that is why we have what we call, in the jargon, "soft-ware main-ten-ance"

    And the reason that we have standards bodies is so that we don't have to do "soft-ware main-ten-ance" three times a week every time somebody on a hunch decides to break the standard. Suppose AOL decided BGP isn't a good protocol and starts broadcasting AOLBGP instead - which looks like BGP to a BGP-speaking router but isn't, and is misinterpreted to cause all their routes to get scrambled. Suppose somebody has a backup MX record which doesn't get consulted because the primary is down and Verisign unhelpfully reports that it still exists and accepts but does not deliver the email. Ditto for 100 other protocols other that http.

    What if the company contracted to do road-work decided that roads are an inefficient technology and decided to go ahead and replace them with rails instead. No problem, you just need to do a little car main-ten-ance...
  • by Anonymous Coward on Wednesday September 17, 2003 @10:41AM (#6985573)
    Why should all our existing software have to be rewritten because Verisign screwed over the internet?
  • by Dun Malg ( 230075 ) on Wednesday September 17, 2003 @10:41AM (#6985578) Homepage
    ICANN might be able to force VeriSign to get this off the net http://www.petitiononline.com/icanndns/

    Petitions only work if a) the petitioners represent a threat to the petitionee's livelyhood, or b) the petition is to force a state government to put something to a vote (e.g. referendum process). ICANN viewa us, the lowly internet users, as riff-raff. They are the lord, we are their serfs. What threat does a petition hold for them? They have absolute power and don't care what we think.

  • by Zocalo ( 252965 ) on Wednesday September 17, 2003 @10:55AM (#6985691) Homepage
    Actually the could quite easily setup their already non-standard DNS servers to simply respond with the effective equivalent of:

    * IN NS screw-isc.verisign.com. and use that to deliver their stupid A records. Of course, if they do that, then things are going to degenerate rapidly. Verisign will not back down because there is money involved, the DNS admins will not back down because of the principle of the thing.

    Should this happen, then ICANN is going to have to step up to the plate, since they are the body to which Verisign is responsible, and make a decision. So, on one side we will have the Internet DNS community, the IAB and IETF, while on the other we have Verisign exceeding their mandate for a chunk of cash. It should be a no-brainer, but given ICANN's track record I certainly wouldn't put any money on which way they would make the call.

  • Re:Good for BIND (Score:3, Insightful)

    by amcguinn ( 549297 ) on Wednesday September 17, 2003 @11:13AM (#6985858) Journal

    The technical workaround is good, but I think this is one rare case where legal action might be reasonable.

    If you don't want deep linking, you're objecting to how various random individuals on the internet interact with your computers. You should restrict that interaction on your own computer and not whine about the rest of the world.

    Verisign are not some random external party - they exclusively control chunks of the internet infrastructure. They should be held to a higher standard of behaviour.

    Of course, the real technical solution is for everyone to use an alternative root server. Given the economic network effects in the internet, that's very difficult to arrange. (If Verisign's abuse got much worse, it would be just conceivable).

  • Re:Bug your ISP (Score:2, Insightful)

    by japhie ( 704786 ) <slashdot@japhy.fnord.org> on Wednesday September 17, 2003 @11:30AM (#6986016) Homepage

    There is a patch for djbdns, but they're not official so I wouldn't reccomend blindly using them.

    What would you call `official patch for djbdns', one released by DJB? Forget it. ;) There are no `official' patches for any djbware.

    The ignoreip2-patch [tinydns.org] with ignoreip-update [ely.ath.cx] posted on dns@list.cr.py.to seem to be the Right Way for now.

  • by Blkdeath ( 530393 ) on Wednesday September 17, 2003 @11:42AM (#6986104) Homepage
    Verisign will not back down because there is money involved, the DNS admins will not back down because of the principle of the thing.

    I'm not sure if you intended it that way or not, but you make it sound like this has become a corporate versus long-haired hippy DNS admins battle. I dare say it's much more severe than that. Even my small (by comparison) mail servers are churning like sum'bitches now that they've got all sorts of "hjkvashjklfasdhl.com"-esque domains to send bounce messages to. Imagine the hapless provider with millions of e-mail accounts and, correspondingly, millions of SPAM messages per day. Formerly, forged domains could be easily chucked to the virtual circular file. Now, however, they quite happily resolve to a server that answers to SMTP queries. (Also a black hole, I imagine, but it still has to traverse half the Internet to get there)

    DNS/Sys Admins have to spend time troubleshooting this problem and attempting to work around it in several different arenas. This is definately a money versus money issue. It just so happens that we also have principals on our side.

  • by Utoxin ( 26011 ) <utoxin@gmail.com> on Wednesday September 17, 2003 @12:08PM (#6986339) Homepage Journal
    This is NOT a solution!

    I repeat, this will not fix anything. Verisign controls the .com and .net TLDs, and as such, OpenNIC has to delegate all queries to their servers. Result? All unregistered .com and .net domains will still resolve to the evil SiteFinder.

    Moderators, please mod this up.
  • by DDumitru ( 692803 ) <doug@@@easyco...com> on Wednesday September 17, 2003 @01:13PM (#6986956) Homepage
    This is more than a little troubling.

    The BIND patch is very simple and elegant. It relies on the particular technical method that Verisign used to implement their wildcard responses. But we can make some assumptions here.

    If Verisign truely believe they have the "right" to do whatever they want to do with the root zone files, they can easily circumvent the patch.

    One design that they might try is to take the inbound domain name, hash it, take a modulo of the hash and create a "fake" SOA and NS for that domain name on a unique IP address. With a pool of only several thousand real IP addresses they could create what looks like 100% real zones for everything. They could even send the traffic to one of many different IP addresses. This could be an arms race that never ends.

    The only "real" solution is that the root zone files must be "trusted".

    If Verisign refuses to change their behaviour then one of several things must happen.

    o ICANN / IANA must force them to
    o DOC must force them to
    o Private lawsuits must force them to
    o State AGs must force them to
    o Everying must blackhole "ALL" Verisign owned IP addresses and effectively take them off of the net.
  • Strong language (Score:3, Insightful)

    by lysium ( 644252 ) on Wednesday September 17, 2003 @03:50PM (#6988435)
    'Atrocity' is a heavy word for ruining the DNS system as we know it, when compared to the senseless killing of thousands. I hearby coin the term 'etrocity' (possible alternate: e-trocity) to fill this hole in our vocabulary.
    You're welcome.


  • by efti ( 568624 ) on Wednesday September 17, 2003 @07:24PM (#6990084)
    I don't see how DDoS-ing the root servers is going to solve this problem. A successful DoS attack against the root servers will just cause total mayhem as even legitimate domain names won't resolve any more.

    Well, actually I do see the point in doing just that, but are we prepared to destroy DNS in order to save it?

Nothing succeeds like the appearance of success. -- Christopher Lascl