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?
but couldn't this be the thin end of the wedge towards technologically mediated censorship?
' m a programmer with a soldering iron, and I'm not afraid to use it.
after all, almost anything is possible with the a patch... it just takes the will to do it.
____________________________________________
I
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
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?
Advice?
Signatures are a waste of bandwi (buffering...)
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.
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.
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!
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!
That approach is fucking dangerous.
.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.
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 (3.214.8.19) and cats.movezig.com (3.217.21.40), then delegate it to those nameservers. Obviously, if the
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 64.94.110.11 as expected, with the Authority section claiming com. IN NS (a-m).gtld-servers.net.
This would be the tricky way of doing it.
You're doing it wrong.
"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.
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?
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.
Of course, they would need to customize their DNS software to do that, as opposed to just adding a line to a config file.
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.
-russ
-russ
Don't piss off The Angry Economist
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.
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...
Why should all our existing software have to be rewritten because Verisign screwed over the internet?
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!
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 with ignoreip-update posted on dns@list.cr.py.to seem to be the Right Way for now.
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.
BD Phone Home!
Shameless plug. Like you weren't expecting it.
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
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.
You're welcome.
==========
Together, we will drive the rats from the tundra.
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?
I signed up for a