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.

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.

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.