BIND Patches Make Bad Situation Worse

An anonymous reader writes "After .COM and .NET started using a wildcard, the internet community busily started creating patches to various pieces of software to circumvent this. It was said that this was a grave problem to the internet. Several official BIND patches were announced over the next few days. However, it turns out they weren't necessarily too well thought through. Usage of the patch unexpectedly broke at least 7 Top Level Domains, ISC announced 3 weeks later, after users started having problems. The .NAME registry has sent a formal letter to ICANN's Security and Stability Advisory Comittee to warn against using the BIND patch, which they will look into in their next meeting. The intention may have been good, but... Stability? Anyone?"

Isn't it unnecessary now?

I thought sitefinder was dead

Do I know anymore?

Yes. .io and .sz.

Doh!

I see we call these "patches" and not security updates.

Software Development Cycle

Write, Compile, Deploy, Test, Pass the Blame.

Bind

Ahhh! BIND

Not ISC's fault

It should be noted that the bugs in the BIND patch are really Verisign's fault, not ISC's. Verisign (Network Solutions) is the company that unilaterally decided to break the .com and .net TLD servers by making them return false data, with almost no advance warning. ISC basically came up with an emergency response to support their customers, and it's unsurprising that it wasn't perfect.

It seems appropriate for the Commerce Dept. to revoke the Verisign contract and award it to another entity that will be more concerned about operating the registry, root, and TLD servers in compliance with relevant standards and for stability and the public benefit, rather than an entity that sees their custodianship as a way of subverting the system to increase their profits without regards to the effects on the internet at large.

So now VeriSign can say ...

... we told you about the ill effects of blocking the wildcard!

Will this be the beginning of a rematch between VeriSign and the world?

bad patches

Indeed the patches were bad. I tried the first one and it caused strange problems.
My ISP installed another one and it is even worse: it does not return an error but it simply returns no answer for the wildcarded records.

Overblown

This report sounds a bit overblown. A conservative named.conf would only contain:

zone "com" { type delegation-only; };
zone "net" { type delegation-only; };

And that would not have the problems described.

This is wrong

"unexpectedly broke at least 7 Top Level Domains"
They were /.'d

Well

A BIND patch wasn't the right way to address the problem anyway.

The legality of the wildcard scheme is what needs to be addressed. If it's illegal then the bind patch isn't needed, and if it's legal then then BIND people would probably find themselves sued.

hmm..

BIND patches? Well I'm in a bind as to whether or not I should ask someone what in the heck this means, since I have no idea.

oy vey

it made picking up new domains take half of forever in my experience. i have bellsouth access, still, through sheer interia. they seem to be always the last on the net to refresh dns.

The Problem with Decentralized Control...

...is easily seen here. Its a perfect example.

We really need to link ICANN more effectively to the
world, maybe each state or province in each country can elect 1 ICANN rep.

Or maybe they should be elected from the owners of each CLASS A worth of network space, or each network, regardless of size, that has a large impact on the internet as a whole (AT&T owns all of 12.0.0.0/255.0.0.0 as far a i know)

Whatever the method, we need a more top-down system for ICANN.

Just my 216 Yen.

The procrastinator wins again...

Don't I feel all smug for letting the free world try out all that expimentanl @#$!&!!#$A$#@$!!^!!#$%!#Q [No Carrier]

I'll play the part of ICANN...

...in an appropriate response to .name's letter:

Dear (dot)name,

Since (dot)name provides such a useful and valuable service to the Internet community, we will immediately take action to address your--

DELETED!

Sounds like a good reason to use djbdns instead

http://cr.yp.to/djbdns.html [cr.yp.to]

It's nowhere near as difficult to set up as BIND, it's more secure than BIND, and there's a patch [tinydns.org] available to block Verisign's wildcard lookups. I've been running the patched version at home and at work since shortly after Verisign added the wildcard records and haven't had issues with any DNS queries.

This is exactly the reason why I did not used them

I don't want to sound like "told you so", but this is exactly the reason why I did not used them in the first place. An authoritive answer from a nameserver is authoritive, even if you do not agree with it. IMHO, Verisign should hang for their completely stupid actions which messed up the entire DNS system but on the other hand, I think that DNS operators should think twice before applying code that tampers with authoritive answers from root nameservers.

The path to follow was via ICANN, or if you still wanted to disable the sitefinder, just insert a route for the /32 in your favourite IGP and reroute the traffic to /dev/null or your ISP's site.

I do appreciate the efforts from the ISC in this matter. A lot. It certainly helped convincing ICANN of the seriousness of this problem.

blame verisign

the blame for this lies squarely at verisign's feet.

Thats the argument isn't it

When verisign went ahead and changed the TLD the argument by icann was that the ensueing enviroment in the internet community would cause chaos as organizations attempted to accomidate a once static internet infastructure.

YOU DAMN DIRTY VERISIGN.

Yep

I had a feeling this would happen.

And now that SiteFinder is gone, it may take forever for 100% of these patches to be fixed/remedied/removed/ etc.

In the meantime, i'm sure that someone, somewhere (or most likely hundreds or thousands of someones) are considering what mischevious deeds they might be able to do with these patches, a situation like SiteFinder or similar.

Ever notice that whenever someone does something a little bold and arrogant, they get shut down almost right away. But within 6 months of that, the gate opens and a pile of people pop up doing things significantly worse or ugly with little effective resistance?

Oh well. Maybe i should just obey the voices in the back of my head and go kill myself.

This wouldn't be a problem...

This wouldn't be a problem with closed course software.

I'm just sayin. With closed source software domain name hijacking and pop-up windows are an unavoidable part of your day.

There are two features

The first feature (which is the one that was implemented initially) supports marking selected zones as delegation-only. This is safe, as long as VeriSign doesn't rush ahead and offers a special DNS service (with alleged super-high reliability) which involves A records directly in the COM and NET zones.

The second feature is much more dangerous because you have to explicitly mark the TLD zones which contain records which aren't delegations--all other zones are assumed to be delegation-only. Some zones have lots of in-zone A and/or MX records (DE, for example), so you have to do some research before you can enable this feature.

If the second feature is incorrectly configured, there will be some local disruption of service. While it might contribute slightly to the instability of the Internet, it's just a localized configuration error (mind that BIND doesn't even have a default for the configuration option), and it's not comparable to what VeriSign did on a global scale.

That tears it!

I'm going back to Windows!

I used the patch...

BIND Patches Make Bad Situation Worse

I hear those Nicotine Patches can do the same thing to people trying to quit smoking.

Wildcarded TLD

I'd almost say that if a TLD can be handled with a single wildcard, then the domain is not large enough to exist and should be a second level under something else. Even if it is just starting out, it should be run as if it were a significant participant in the net, which means delegation of specific second level entries under that tld.

Invader ZIM

ZIM: I helped with the DNS problem.
Tallest: You made the DNS problem worse!
ZIM: Worse..? or better?

Uh...

DJBDNS, [cr.yp.to] anyone?

The Bind authors are known idiots. Much like users of their software. It's buggier, more resource intensive and slower, but at least it costs more!

But...

But I thought, regression testing, hell testing at all, was a bad thing. Isn't it *good* that in the open source world, a patch gets slapped together and applied the world over, within an hour?

ISC at fault? Not likely.

I find it strange that I be coming to the aid of the authors of BIND as a loyal djbdns user, but in this case I strongly believe it is Verisign who are to be hung, drawn and quartered over this one. The ISC were merely attempting to meet the needs of their customers. I haven't looked at why this caused breakage yet, but I wonder how much of it is related to poor configuration of the other domains? I wonder also how difficult it would be to modify the patch to sanitise only .com and .net domains? Not quite as clean, but better than, say, filtering IP numbers!

What's this world coming to, anyway?

I'm on Bellsouth.Net dial-up, and it's been a couple of weeks now since I've been able to correctly get to google.com. I ultimately had to ask a friend of mine to give me the correct IP address, and have had to bookmark that. I noticed that in the first few days the browser was unable to locate any page on that address, but the space has since been "colonized", I guess by some opportunist.

I presume this hassle is because of the various problems caused by these idiotic modifications to the foundations of the Internet, and I wish hellfire and brimstone upon the PHB's responsible for them.

There is no stability problem

The non-delegation records in those zones are crap records to various registrars's websites, just like the ones Verisign was publishing. Why would anyone care? Filter them all, I say.

What problem?

.name suits complain that their wildcard doesn't work anymore with those who installed patched Bind?
How is it a problem for anyone except them?

When Verisign turned the wildcard for .com/.net and ISC came up with Bind patches, many admins decided to also block wildcards in about a dozen small TLDs some of which supported wildcards from day one - they were simply below the radar until Sep 15. Now those TLDs are unhappy because customers have tools to block their idiotic tricks - who cares? - how are they any better than Verislime except they can't quite screw up as many people?

I am perfectly happy running the patched bind and have no intention of rolling it back - even if sitefinder is out for good, it's a matter or principle, - no wildcards on TLDs!

Vlad

Sounds to me...

... like the companies want to keep people away from future "patches" that may override such annoying services in the future.

Ditto.

I prefer instability...

I prefer instability to inaction in circumstances such as arose with Verisign.

BIND considered harmful

You know, every time this buggy, insecure, over-complicated sack of crap is the source of a security hole, I make a post here to the effect that BIND is a buggy, insecure, over-complicated sack of crap and that its maintainers evidently lack either the will or the ability to fix it, and that there is more than one good alternative, including, but not limited to, djbdns.

And every time, someone comes back and says no, it's really fixed this time, it's really finally stable, the developers really are both concerned and competent.

I no longer bother replying anymore. Usually CERT does it for me.

BIND must go. The only thing it does reliably is diminish the credibility of open source. (And make sendmail look good by comparison, which is no mean feat, either.)

Re:BIND considered harmful

there is more than one good alternative, including, but not limited to, djbdns.

Ok, so I want a authorative and recursive DNS server. It needs to be able to be distributed via. rpms, and patchable etc. I really want it to be my vendor of choice who packages and distributes it, but I that's more of a social thing.

So ... what do I use?

• nsd is written with just as little regard for security as bind ... and isn't a recursive server
• djbdns has all the legal djb problems and can't be a recursive and authoritive server
• maradns has already had security problems and fairly major DNS bugs, uses a threaded design and has piles of needed things in the "unimplemented" section of the man page. The string ADT looks suspicious to say the least.
• dnrd is recursive only
• dents unmaintained, and never worked well AIUI
• dnsmasq just does recursive queries
• dnsproxy is just recursive
• ens (yaku-ns) is said to be "experimental" by the author
• pdnsd proxy only, has lots of bugs and uses a threaded design.

So I'll use bind 9 ... and when there's a security problem I hope it's the last. However this issue doesn't count, this is a minor configuration problem that is All verisigns fault.

Jeez you make it sound like

Microsoft is in charge of BIND development now!

Not ISC's fault, but a lot of misinformation.

The DJB wanabees are pushing their idol's software, and ISC gets the flak for having designed a very good patch. The problem is not with the patch itself, it's how it is used.

The first patch

ISC initially designed Verisign wilcard blocking patch so that one can mark a zone as delegation only. Explanation: the TLD servers (the one that serve .com, .net, .us, etc) should not contain any domain information: their purpose is just to point to the actual name server for a given domain:

• When a .com TLD server is asked for existingdomain.com, it replies: for any address below existingdomain.com, ask this and this servers. That's a delegation answer.
• When asked for non-existingdomain.com, the gtld server used to reply: there is no such domain.
• When Verisign introduced their sitefinder service, they basically configured their server to say: non-existingdomain.com is at this address. Compare that with the ask this other server. That's not a delegation. It's a straight answer.

So, the first ISC patch allowed people to mark a zone (eg. .com) as delegating-only. All straight (i.e. non-delegating) answers from a delegating-only zone are interpreted as no such domain.

Note to the DJB groupies: that's much cleaner than passing an IP address to be ignored in an environment variable. For once, with the bind approach, you can still access www.sitefinder.com. It's only the unwanted wildcard referrals that are blocked, not a given IP address.

Second (and current) patch

Then people noticed that all TLD ought to be delegation-only (they were wrong) and objected to have to write a stanza in the configuration file for every TLD. That's why the second patch was introduced.

This time, in addition to the configuration directive saying "this zone is delegation only", a new configuration directive was introduced: "all TLDs are delegation-only". You may also provide a a TLD exclusion list for the few domains that were known to have non-delegation records (like .de).

Some misinformed admins started using this new directive with just the few known non-delegating domains excluded, but more TLDs than previously thought had non-delegating records in their TLD zone. Like .name. And that's what they're complaining about.

Summary

If you use the .com and .net are delegation-only zones configuration directive, you're doing good.

If you use the all TLDs but a select few are delegation-only, then you must make sure you have the exhaustive list of non-delegating TLDs. Since no-one has the exhaustive list yet, so I suggest you just mark .com and .net for the moment.

If you use DJBDNS, stop showing such misplaced zealotry.

Verisign is the problem

We should all be using OpenNIC [unrated.net]. I know that I've converted all DNS servers that I run. (including one at a large University)

Not safe to install patches?

People are always saying it isn't safe to install MS patches because they break things, but this case surely shows that it can happen in any OS or any environment (closed and open). Where are all the people screaming about how people shouldn't install patches until they have been out at least 6 months like they do with MS patches? And doesn't this make OSS patches as dangerous, since they obviously aren't being tested?

Hypocrits.

Wow, so the open source community released a patch that wasn't well tested, that caused problems, and probably cost some people a bit of money.

How many times has slashdot bitched and moaned about a certain unnamed corporation doing something similar.

Some people say "this could have been avoided if your named.conf was written properly." Yes, and most viruses and worms could be prevented if people would patch their desktops.

So what we have:
A patch that caused a lot of problems.
Users that could have prevented the problem if they had known better.

Sounds a lot like the kind of users all you eleet unix junkies diss on so often.

Caught between the pan and the fire

Hi,

some may have faced the same decision i did: Either you spend hours and hours in investigations if the sitefinder shit breaks some script of yours or your ancestors, or you take the risk applying a patch that can't be tested very throughly. Neither choice really seemed inviting.

As it turned out, the patch wasn't working very well (increased memory usage, was an unofficial patch for 8.4.somewhat) and we had a malfunctioning debug script.

Regards, Martin

BIND needs an overhaul

BIND 9 still doesn't have all the functionality of BIND 8 (which is one reason a lot of people haven't switched). The IPv6 reverse-lookup records are painful to the eyes. I'm not convinced DNSSEC is fully working.

Since BIND doesn't support dynamic updates, it doesn't work well with DHCP, Mobile IP, Ad-Hoc IP or any other environment in which dynamic updates are, well, essential. (Incidently, as IPv6 mandates Mobile IP support, BIND cannot be considered IPv6-compliant.)

The API changes with BIND 9 meant that anything using the resolver library was likely to do nasty things.

So why does anyone use BIND? Why do I use BIND? Because, as was the case with Sendmail, until Postfix came along, the "alternatives" just aren't even up to the level of these dying, legless dinosaurs.

(Even now, Postfix won't do everything Sendmail can. It's usable for most things, and development is impressive, but until it passes Sendmail by, it won't be a real alternative, merely a usable standby.)

So what do I want, that the other DNS' either can't do as well as BIND, or can't do at all?

• BIND -does- have some DNSSEC. That's important.
  
• It's RFC-compliant (for the most part).
  
• It handles IPv6 (with the limitation given above).
  
• It'll run on most platforms and porting it is not too hard.
  
• I can identify buggy/mis-configured nameservers elsewhere in the heirarchy, because BIND does some checking.
  
• It doesn't need a gui and although it's not lightweight, it's not too bad on memory, disk or processor power. It'll run on an embedded system without problems.
  
• There's limited built-in support for distributed name-serving. (I'd like this to be better, but it's better than nothing.)
  
• It's reasonably well documented. Again, this could always be improved.
  

For those of you criticizing ISC --

Consider that ISC stepped up to the plate and delivered a sensible solution in the midst of many unknowns at the time - Verisign did the breaking, not ISC.

Sorry, but ISC BIND is the most standards compliant implementation widely available, and djbdns is still incomplete. Switching name server software is not the answer to the problem of Verisign commandeering the COM and NET zones for their own profit.

I have been running 8 ISP 9.2.1 BIND servers for nearly a year without a single hiccup, security breach or question of performance.

Please review the history of ISC BIND development vs. security issues. You'll see that they've done an admirable job of clearing up loads of problems.

You should not be using BIND 8, although it is still supported. I've had a very good experience with BIND 9.2.x, and I did not roll out the patch at the time because I suspected that Verisign would remove the problem shortly and they did. It was my lucky guess, it could have worked out otherwise.

Say it ain't so!

Paul Vixie releasing untested, buggy software?

You're kidding!

- A.P.

Data Problem, Not a Code Problem.

The problem isn't the code, it's just data. The BIND patch had a list of top-level domains, like .museum, for which wildcarding is ok, and otherwise it blocks them. The problem is that Vixie missed some of the domains that do wildcarding - so just add the extra domains to the list. The patch works just fine, and seems to be stable. Furthermore, Vixie (who discussed this at a talk at Stanford as week or so ago) says that the patch *does* violate strict interpretation of DNS standards, whereas Verisign's Sitefinder doesn't violate the technical standards (just the policies), so the patch only provides a mechanism for implementing the feature but doesn't turn it on unless you explicitly tell it to.

As a secondary issue, there's the question of whether you *want* DNS wildcarding for those domains. If you don't, then even if the patch mistakenly blocks them, that's ok. One of the most serious problems with Verisign's DNS hack was that it's OK behaviour for web browsing on port 80, broken for browsing on other ports, but is almost never helpful for typoed email messages, is seriously broken wrong behaviour for spammer-forged email addresses, and for other protocols, is usually broken, sometimes very annoyingly broken. If you're using a web browser to check out http://nonexistent.museum, you get a friendly menu, but if you were trying to send email to [e-mail], instead of your email client telling you that the domain doesn't exist (which you'd then correct), it'll accept the email and then eventually give you a bouncegram, which is especially annoying if you were sending mail to more than one person. Do you get any better treatment from [e-mail] ?

What's worse is spammers forging From: or SMTP envelope addresses from these TLDs, which was a problem that wasn't particularly obvious before Verisign's .com hack reminded everybody. Instead your email system detecting that MAIL FROM: is bogus and rejecting it, or accepting the message, or detecting that From: [e-mail] is bogus and discarding it instead of delivering it to you, now you'll have to notice that yourself, if your email server and client are friendly enough to let you see the envelope headers.

Let the trolls begin

Every time there's a patch to BIND, somebody spouts off about DJB's "great stuff"...

As much of the value of software is the LICENSE under which it is release as the source code itself.

If M$ didn't sell binary copies of their Windows O/S, it would have no value at all.

DJB's tools might be great for some people, and it might even become a standard for the Internet, but as long as DJB's license is so restrictive as to prevent Red Hat from releasing a QMail RPM, its value is greatly diminished. Despite the aviailability of the source code, it's not truly "open source".

So we stick with BIND. Written for a different era of the Internet, it nonetheless works quite well, and security issues aren't much of a problem (at least for me, periodically running up2date works quite well)

Another example is qmail. Since only patches can be released, I have to go through the scavenger hunt of patches and crossed fingers hoping to get a qmail installed with support for LDAP and qmail-scanner.

And it's not as though qmail is perfect, either. I mean, auto-responder messages with hard coded reply headers? WTF? How magnificently retarded is that?

The restrictive license of DJB's tools prevent things that really should have happened long ago - a forking of the codebase, and binary distribution.

Broken "feature" isn't quite a "patch"

The "breaking" that this "patch" supposedly caused is a feature (root-delegation-only), apparently used more by the (understandbly) uninformed than the informed, that is available only in BIND 9.2.3 Release Candidate 3 and 4.

Informed or uninformed about the feature, a release candidate in production may as well be beta software, good reasons to deploy notwithstanding. When you use beta software in production and it does something unintended, that's not a callous failure of the provider/programmer, that's called "testing" and impact should have been considered first. Last I heard, those who place their feet in a fire can expect to get burned, even if they don't like the idea of it.

BIND 9.2.2P3-- which is neither designated formally as a release candidate nor informally as a beta-- does not implement the root-delegation-only feature. So unless you're playing with the fires associated with beta testing... there should be no wildcard-related issues for the uninformed (innocent or otherwise).

Conspiracy theory

This sounds suspiciouly like the comments that Verisign have previously made public. Just who is this "Anonymous Coward", anyway?

Re:Must be a Unix thing

You can't ping Slashdot because Slashdot doesn't respond to pings. Notice that the web server seems to be working fine? :-P

Don't worry...

The slashzealots will figure out a way to blame Microsoft somehow.

Re:Must be a Unix thing

I'm using Windows 2K and I haven't noticed any problems. I have been experiencing 500 Internal Server Errors with Slasdhtot lately, but I'm pretty sure that isn't a BIND thing. I checked task manager and BIND isn't running. Also, I can't ping Slashdot either. Something is wrong.

you hit that on the head... yes something is wrong and you can fix it easily...

first search your /winnt or /windows directory for a teddy bear icon. this is the verisign virus that causes sitefinder to run. you need to delete that.

now every time something act's wierd you need to simply press ALT-F4 and it will correct the problem.