1

Recently I took up maintenance of another company network where BIND has been installed in a dedicated VM (ostensibly for security). The company uses Debian as a system for servers.

I have to say the concept intrigued me. Unless you have a dedicated box for BIND (I don't), installing it on a VM hosts (two, because they're in active/passive cluster) is kind of security risk knowing BIND's vulnerability history. I know it's chrooted in Debian (?), but still.

Do you think it's a good idea? Pros, cons? Is it really needed or is it basically pointless given current BIND versions?

LetMeSOThat4U
  • 1,371
  • 2
  • 17
  • 35
  • 3
    You really need *security* reasons to stash independent services into independent containers? I find the peace of knowing that *even non-malicious malfunctions cannot affect unrelated services* entirely sufficient justification to always err on the side of compartmentalization. – anx Dec 24 '20 at 16:08
  • It's one thing to pack related services into independent containers for obvious reasons and another thing to exaggerate and pack services that do not really need that into containers. I do not see how BIND in particular can cause such nasty side effects apart from failure of DNS service itself of course. Typically BIND does not cause high system load or consume excessive amounts of memory. Somehow BIND served for decades on servers without such unspecified side effects apart from security problems, so I find BIND's troublesome history of security to be the only serious reason here. – LetMeSOThat4U Dec 25 '20 at 21:51

2 Answers2

1

I think that the rewrite that was BIND 9 (initial 9.x version released some 20 years ago) made massive strides to address the security history of the versions before it.
Not that it has been completely spotless since or anything of the sort, but I don't find the track record for 9.x to really stand out compared to other popular software projects.
(In my book, it just needs the same level of maintenance as anything else; there will be bug and security fixes to install, and that work has to be done on a regular basis.)

Ie, I don't think that BIND in itself necessarily makes you want to isolate it more than anything else.
That said, I don't think it's a bad idea to isolate services, BIND or otherwise.

Pros:

  • No "tangling" from unrelated services on the same host that somehow interact in some less formalized way
  • No dependency conflicts from unrelated software on the same host
  • Resource usage is more isolated which reduces interactions as well as potentially making the attribution more clear
  • Possible to migrate/scale without also changing other systems
  • More isolated environment in case of a security incident

Cons:

  • Less resource efficient
  • Maybe there is some form of direct interaction that is desired for whatever reason
  • More things to maintain (something something automation)
Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
0

This is actually not half bad. Not only can you secure it heavily compared to say a LAMP stack or similar but scaling it is simplified. As well as making sure you can stagger the downed services.

Say you got the following setup... BIND1 BIND2 Webserver and backend codebases (PHP/NodeJS/etc) frontend DB backend

Now when any of these needs to be serviced/scaled you can just account for very limited variables. As compared to a "traditional" LAMP stack.

Rickuku
  • 344
  • 1
  • 5