About Archive Tags RSS Feed


bind9 considered harmful

11 July 2017 21:50

Recently there was another bind9 security update released by the Debian Security Team. I thought that was odd, so I've scanned my mailbox:

  • 11 January 2017
    • DSA-3758 - bind9
  • 26 February 2017
    • DSA-3795-1 - bind9
  • 14 May 2017
    • DSA-3854-1 - bind9
  • 8 July 2017
    • DSA-3904-1 - bind9

So in the year to date there have been 7 months, in 3 of them nothing happened, but in 4 of them we had bind9 updates. If these trends continue we'll have another 2.5 updates before the end of the year.

I don't run a nameserver. The only reason I have bind-packages on my system is for the dig utility.

Rewriting a compatible version of dig in Perl should be trivial, thanks to the Net::DNS::Resolver module:

These are about the only commands I ever run:

dig -t a    steve.fi +short
dig -t aaaa steve.fi +short
dig -t a    steve.fi @

I should do that then. Yes.



Comments on this entry

icon Robert Edmonds at 18:46 on 11 July 2017

Or just install the knot-dnsutils package.

icon Steve Kemp at 18:58 on 11 July 2017

That works!

Thanks for the suggestion, it was a package I'd not heard of before :)

icon Jonathan Carter at 10:48 on 12 July 2017

Could it just be that bind is good at releasing security fixes? While other servers take longer to release and clump security updates together? I don't think looking at frequency of security fixes alone is at all a good enough indication on its own of whether something should be considered harmful or not.

icon Steve Kemp at 10:57 on 12 July 2017

Obviously fixing known issues as promptly as possible is a good thing, but I'm a little surprised to see just how many issues are being found with bind.

Historically bind had an appalling record for security problems, to the extent that bind9 was rewritten from scratch as I recall? That seems to have not lead to a significant improvement.

I'm pleased when auditors find problems, I'm pleased when security issues are fixed, but there comes a point where you step back and realize that some projects have more issues discovered/reported and fixed than they should have. I try not to run issue-prone software, and I think now bind9 is in that category.

icon Anthony DeRobertis at 12:29 on 12 July 2017

Did you actually look at the advisories?

DSA-3758-1 is a bunch of things that could trigger assertion failures (so, cause the DNS server to stop—a DoS attack, if you're running the server).

DSA-3795-1 is another server crash, in a very unusual config.

DSA-3854-1 is another three assertion failures which make the server stop. One sounds like its even only exploitable via the local admin interface, maybe even only after authentication (didn't investigate).

DSA-3904-1 is one that may allow an attacker to perform a zone transfer (obtain a copy of a zone) when they shouldn't be able to. Or maybe to make a dynamic update, if those are enabled.

So none of those advisories are relevant to your use of dig. At worse you'd get an assertion failure instead of a proper error message. Even if you were running the server, they're relatively minor attacks (except for that update one, in some less-common configs).

[I actually run name servers.]

icon Steve Kemp at 12:56 on 12 July 2017

I did look at them, yes. While I see that they don't apply to me, a mere user of dig, as per the previous comment they add up to the idea that bind is not secure software - and as such I don't want to be using it.

icon Andy Smith at 14:02 on 12 July 2017

There is also drill from the ldnsutils package.


icon Corsac at 19:21 on 13 July 2017

Also, the last bind9 vulnerability was actually found after a similar vulnerability was found in knot (which has not yet been fixed in Debian).

(not that I advise to use bind9, after preparing the DSA I really don't want to touch it anymore)