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?"

Comments

Overblown

[Rafke]

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.

I'll play the part of ICANN...

[pergamon]

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

[ncc74656]

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

It's nowhere near as difficult to set up as BIND, it's more secure than BIND, and there's a patch 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.

There are two features

[Florian Weimer]

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.

ISC at fault? Not likely.

[samj]

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!

Re:Not ISC's fault

[rufey]

I don't necessarily think that it is a bug in the BIND patches, nor with VeriSign. Its more a configuration issue with BIND.

The problem is that some TLDs do more than just delegation. The article mentioned the .name domain specifically.

The problem with the BIND patch arose when people implemeting the patch decided to not allow wildcarding on all TLDs. If you used the patch to only set .com/.net to delegate-only, there wasn't a problem. If you also set .name to delegate-only, then you would have a problem with stuff in the .name domain.

For those who didn't install the patch and start using the delegate-only options, BIND doesn't automatically start enforcing a delegate-only on all TLDs. The TLDs which you want to be delegate-only have to be specified in the config file. To undo VeriSign's wildcard behavior, one would only want to set the delegate-only option on the .com and .net domains. Other TLDs had been doing wildcards prior to VeriSign's actions, and, indeed, some TLDs relied on wildcarding for some things to work. Unilaterally stopping all TLDs from doing more than delegating would break things.

BIND considered harmful

[Angst Badger]

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

[Nevyn]

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.

Re:Not ISC's fault

[Zocalo]

*What* bugs are there in BIND due to the anti-wildcarding of DNS patches? ISC's patch provides two ways of approaching the problem; either prevent wildcarding of specific TLDs or globally ban wildcarding of TLDs and provide an exception list. Both approaches work fine, provided that the DNS admins that implement them take the time to understand the implications and approach the patch with caution instead of a jerking knee. It also clearly stated in the release notes with the patches what the issues were and that there were exceptions such as .de, .museum and several others.

If anything, the rest of the blame for this part of the fiasco lies with the DNS admins at the TLDs concerned that took so long to realise that they were doing wildcarding and raise this issue with ISC. Or any of the other DNS vendors that provided a similar workaround for that matter. Still, at least I know some more TLD operators to avoid registering domains with now...

Not safe to install patches?

[dirk]

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.

[zapp]

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.

Re:Isn't it unnecessary now?

[karl.auerbach]

Verisign is playing a cat and mouse game with the US Dept of Commerce (NTIA) and ICANN.

As I see it, Verisign is building a portfolio of legal positions that it will be using in what I belive is almost certain litigation between Verisign and ICANN and possibly involving the US Department of Commerce?

- Verisign is trying to engender a sufficient number of statements by technical experts that it can convince a judge that there is really a technical debate and that thus the judge ought to stay out of the matter.

- It is trying to come up with enough anecdotal evidence that the internet isn't broken by sitefinder. Of course, those anecdotes are from a point of view, such as that of the typical mom and pop user, that is unlikely to perceive the real damage that has been caused. But we have to remember that most people who use the net, including most judges and lawyers, see the net in that same, technially naive, way.

- It is trying to expose the fact that the US Department of Commerce never articulated, and may not have, any authority to have done what it has done in these areas and that thus it has no authority over Verisign.

- It is trying to use the previous item to undermine ICANN's authority. And ICANN's authority is far from clear: a) the contracts ICANN uses are very, very complicated (and like many complicated things, may be full of holes) b) ICANN's claims of "consensus" are far from broadly established, particularly given ICANN's explusion of the broad community of internet users from its decision making forums.

- It is trying to establish that if there is any harm to the net, it is not of such an immediate and overwhelming nature that it has to be restrained during any legal proceedings. (Verisign would, of course, reap the financial proceeds of sitefinder during those proceedings - thus giving it a cash flow to finance the litigation. ICANN's pockets are not so deep and it is not in a position to outspend Verisign.)

So, the DNS wildcarding part of sitefinder may be turned off for the moment, but I think that is merely a tactical move on Verisign's part.

Agreed - The patch works fine

[billstewart]

The problem is that .com and .net aren't the only TLDs with evil wildcarding brokenness, just the latest and the only one to do so unilaterally without the responsible people discussing and setting policy first, and the patch didn't list quite all the TLDs that have official policies of wildcarding, just most of them. You can update it to add the others to the list, if you want, though that'll only help web browsing on port 80, and will cause you trouble if spammers try to forge mail from the other domains.