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."
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).
A little planning goes a long way...
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?
I assume the patch will filter requests, which resolve to the site-finder IP, so what's to stop VeriSign simply changing IPs every so often?
Of course, hopefully this and public opinion will actually cause VeriSign to rethink the whole operation. (We can at least dream)
As soon as a patch comes out, bug your ISP to sort out their DNS servers. Try and nip this thing in the bud
Interesting that BIND only runs 80% of DNS servers, what is the other 20% made up of?
The .nu domain registry has been doing this for years.
Money for nothing, pix for free
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 @
"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
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, as referenced by this Internet Web site they have registered. Let's not forget they're also a bunch of Clueless DNS whores. Oh yes, and I heard Verisign supports terrorists at this page: here...
Verisign needs to be shut down for these un-American and clearly criminal web sites. Someone notify John Ashcroft, quickly!
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
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.
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.
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.
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 available.
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
Maybe if a misspelled URL went to a random other URL, it might be OK, but using that page to advertise for a particular company's profit, regardless of the URL, seems really bad. I would much prefer to have a "not found" message, since that's really what's happened. Can you imagine if this happened while driving? Anytime you turn down the wrong street, the same ad came on the radio or something like that? It seems positively Orwellian.
stuff |
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.
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
Exactly. The correct term for this is Sldahost efcfet
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!
Good point, they *do* already have your money. Stay with Verisign (until your registration expires), but make a lot of support calls. (After all, you've paid for their sterling support.) Especially about this wildcard thing. I'm already forgetting exactly what it is, maybe you are, too. I'm sure they'd be happy to explain it to you, and why it's not bad. And if you forget again after a month or two, they'll be happy to discuss it with you again. And any other questions you might have, like how to set up a mail server alias thingy.
John.
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".
UNIX? They're not even circumcised! Savages!
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/
Is Stratton D. Sclavos doing a good job as CEO of Verisign? Vote yes or no in this Forbes.com poll.
Also, here's a petition that may also be of interest.
<sig>Guvf vf abg n frperg zrffntr
They don't state if it's simply blocking the well-known IP of SiteFinder or doing something cleverer.
How long till they change the IP/round-robin it?
I noticed the wildcard domain does not generate an SOA record so that may be a better detection mechanism, but maybe it will break existing misconfigured sites?
In any case, Verisign can always come up with new scams to make the record look more authentic.
The only long-term solution is to move to a different host, which would be really hard to arrange collectively.
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
"I just did. I don't see what the fuss is."
.net and .com and there's a world of other TLDs out there.
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.
Oddly Draconis
Too cynical to live, too stubborn to die.
And not to be outdone by Verisign, Google has added a default route to the global BGP table which brings any formerly unroutable web traffic to their search engine.
NOT!
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Read the discussion: 80% runs BIND, what runs on the remaining 20%?
Clever signature text goes here.
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?
"2.4 Monitoring and Communication .com and .net and associated responses, and all traffic sent to the response server. This traffic is correlated and monitored in real time, 24 hours a day, seven days a week, by VeriSign's Network Operations Centre... complete traffic stream to the .com and .net name servers and the response server, as well as rolled up statistics, are stored for analysis."
VeriSign actively monitors all traffic associated with Site Finder, including DNS queries matching the wildcard entries in
Ehm, well I don't agree to your Terms and Conditions, thank you very much. Please stop storing my typo data Please.
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.
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)
this effectively lets VeriSign get away with it.
h tml
As a BIND architect/deployer/admin I see that ISC is always getting bashed. Kudos to them for this creative patch, presented almost instantly compared to their usual release schedules. But, precisely, it let's Verisign get away with this action, which is horrible. Especially because this: http://www.iab.org/Documents/icann-vgrs-response.
(which was posted in the first slashdot thread abot this topic), went unnoticed, and unheeded by Verisign.
Big business in this country is getting WAY out of hand with greed.
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
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.
When all you have is an axe, everything looks like a grindstone.
"Linux is a serious competitor"
- Steve Ballmer, Chief Executive Microsoft Corp.
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
You'll forgive me if I don't exactly hang my head in shame.
Cheers,
Ian
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...
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.
If a job's not worth doing, it's not worth doing right.
* 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.
UNIX? They're not even circumcised! Savages!
Who should I write in the government to complain about Verisign's abuse of power? If I recall correctly, the US government had granted Network Solutions the power to directly control the DNS servers, but NetSol was later bought out by Verisign who has done nothing but abuse its monopoly. Is there some government agency in charge of watching over Verisign; a government computer agency? I feel the need to write someone in power about this. We can patch the problem all we want - the only true solution is to end Verisign's power over the DNS outright.
http://www.petitiononline.com/verisign/
That would be bad. We use wildcards to ease our DNS duties. For example, we have a customer who likes to create daily new domains such as somenewcompany.theircompany.com somenewcompany2.theircompany.com blahblah.theircompany.com Instead of letting them change the DNS constantly we just setup *.theircompany.com to go to their server. Then all they have to do is manage their apache/IIS/whatever web server. So having BIND remove wildcard support would break us as well as I suspect MANY sites.
Good questions.
As for splitting, there are already several alternate roots. In addition to Alternic, there's OpenNIC and Pacific Root. People are using these only voluntarily, and the different roots cooperate to some extent. For example, most will only establish a new TLD if no other root is using that TLD, and most will peer TLDs for the other roots so you can see the entire composite alternate namespace. This is strictly voluntary, however.
It might be that some day the alternate roots cooperate less. We can get a glimpse of how this works through the issue of the .biz TLD. Pacific Root had a .biz TLD years before the official Internet .biz TLD. People had paid Pacific Root for this privilege. Pacific Root decided to maintain their own .biz TLD, such that if you are connected to them you will see their .biz, and if you are connected to the real Internet root servers, you'll see the official .biz. Meanwhile, they peer all the other official TLDs so that you see them. Other alternate roots made independent decisions. OpenNIC, for example, chose to continue peering the Pacific Root .biz and ignore the official one. Verisign et al can be viewed as a non-cooperative alternate root server, and this shows how a group of independent voluntary alternatives can coexist.
As for cost, at the moment OpenNIC is free to use (I don't know about the others). I think most alternate TLDs have free registration, though I know that Pacific Root charges (and apparently makes money) for registering in the TLDs they created. If more people started using these alternate roots and costs went up, the alternate roots could start charging more registration fees, or charge users; people could choose among alternatives based on price, quality, and access to the TLDs they want to see. Competition would be good, though some alternates might have to shut down. Think about who finances the yellow pages: the users, or the people who are registered. Also, it's possible this could be entirely financed through voluntary donations.
It's conceivable we could completely escape from Verisign just through exercising our free will to choose alternate roots.
Secession is the right of all sentient beings.
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.
This is NOT a solution!
.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.
I repeat, this will not fix anything. Verisign controls the
Moderators, please mod this up.
Matthew Walker
http://www.tweeterdiet.com/ - My Diet Tracking Tool
"2.4 Monitoring and Communication VeriSign actively monitors all traffic associated with Site Finder, including DNS queries matching the wildcard entries in .com and .net and associated responses, and all traffic sent to the response server. This traffic is correlated and monitored in real time, 24 hours a day, seven days a week, by VeriSign's Network Operations Centre... complete traffic stream to the .com and .net name servers and the response server, as well as rolled up statistics, are stored for analysis."
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?
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.
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...
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 toI 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?
I signed up for a