Add example configs and sample/stub zones.

[ventz]

Add example configs and sample/sub zones so that users can deploy faster if they have not used bind.

[jnovack]

I would definitely note the importance of the /etc/bind/bind.keys in the documentation somewhere. It IS there by default, but the volume you mount to /etc/bind/ overwrites it, which means it needs to be replaced.

It's probably better to only volume in the file /etc/bind/named.conf rather than the directory /etc/bind/ especially since you want to force everyone to use the working directory of /var/named/bind/. But that does force /etc/bind/named.conf to have:

options {
    directory "/var/cache/bind";
}

OR, at that start of your entrypoint.sh you can save the user a step and copy in a backup copy of the bind.keys file (hidden in another directory)

This will simplify the container by only using TWO mounts, /etc/bind (and keep the working directory /etc/bind/) and /var/named/log.

[ventz]

That's a great point. I think i'll add both just overriding the named.conf file, and provide examples that can be copies and pushed "as is". Thanks.

[ventz]

@jnovack I haven't forgotten about this - I am trying to figure out a good compromise because I've gotten hundreds of emails for people asking to mount over the entire /etc/bind so that they can override all of the configs with modular .conf files. I could add something that generates the keys, or I could add a README note about it. My assumption is that people who use this already understand BIND, but maybe that's not the case. Open to suggestions here.

[jnovack]

Generically, I would expect any program to write files to the "working directory" if they didn't exist. For example, mysql needs to write the database files, and I can choose to mount it in (for persistent storage) or leave it in the container. But I wouldn't expect ME to have to generate them.

This analogy could work for /etc/bind/bind.keys. It's a file that needs to be there for proper function. Thus, if it's not there, the environment (in this case, your entrypoint.sh) should ensure it is there, because the application (bind) does not.

My assumption is that people who use this already understand BIND

Bad Developer! :)

But seriously, if someone was using this container, they might not be FULLY immersed in bind's little details (bind.keys is a required file) combined with docker's little details (when mounting a directory, previous files go missing), and thus just want to "play" with it. In that instance, they shouldn't have to worry about the hidden little gotchas.

I'm one of those people who used modular configs but I just copied out bind.keys from the container into my host's directory so I can have 1 mount (/etc/bind/), which I feel is a "work-around". Thus my suggestion of having entrypoint.sh ensure it is exists by any means necessary.

Thanks for not abandoning this!

[ventz]

@jnovack Thanks. I went through a few options this weekend and I think I have a good idea how to "better things" for the next release. I am going to move to the "standard" /etc/bind/zones dir, which will enable just /etc/bind to be mounted over. I'll include example zones for each scenario (resolver , master, slave, etc, with stub info) and include a fully working config from the start (probably for a resolver). This should solve a lot of issues.

[ventz]

@jnovack Alright, here's what you have been waiting for: https://github.com/ventz/docker-bind/commit/108554317ee821cc926109de9179fed4a1aed2ea

By the way - added key generation, and fully functional defaults for an authoritative server and a recursive resolver/forwarder. Also added examples.

All feedback/suggestions/improvements welcome!

[jnovack]

@ventz Heavily impressed. Just doing a cursory read while I ingest my morning caffeine and this looks solid ("great/sturdy/secure" if English is not your first language). I see you are in the MA area, so maybe I should say "wicked". :)

[ventz]

Closing this thread. I am going to open a new issue for improvements on the new push @tcely - if you can, could you please comment there.