Home / server / Questions / 1047461
Accepted
LetMeSOThat4U
Asked: 2020-12-25 06:13:51 +0800 CST

BIND in a dedicated VM?

  • 772

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?

domain-name-system debian bind debian-buster

2 Answers

  1. Best Answer

    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)
    • 1

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

    • 0