High performance bind with default operating modes
What can I do with this? This image will run BIND9 DNS server precompiled for large installations and maximum performance. It also offers three operating modes: Master, Slave and Resolver set via command: ["mode"].
Why should I run this image and not the other image(s) that already exist? Good question! All the other images on the market that do exactly the same don’t do or offer these options:
Important
- This image runs as 1000:1000 by default, most other images run everything as root
- This image is created via a secure, pinned CI/CD process and immune to upstream attacks, most other images have upstream dependencies that can be exploited
- This image contains a proper health check that verifies the app is actually working, most other images have either no health check or only check if a port is open or ping works
- This repository has an auto update feature that will automatically build the latest version if released, most other providers don't do this
- This image is a lot smaller than most other images
If you value security, simplicity and the ability to interact with the maintainer and developer of an image. Using my images is a great start in that direction.
Below you find a comparison between this image and the most used or original one.
| image | 11notes/bind:9.18.37 | internetsystemsconsortium/bind9:9.18 |
|---|---|---|
| image size on disk | 30.5MB | 39.4MB |
| process UID/GID | 1000/1000 | 0/0 |
| distroless? | ❌ | ❌ |
| rootless? | ✅ | ❌ |
If run as master, set the IPs of the slaves via BIND_SLAVES. Bind will operate with catalog zones for all slaves. You can add new zones via the addzone script that requires the zone name and the IP of at least one NS (slave). You can then use nsupdate to update the master with new records and all changes are populates to all slaves automatically. Add a new zone like this:
docker exec master addzone contoso.com 10.255.53.52It will automatically create a default zone and populate it as well as add a random key for managing the zone via nsupdate or via the dynamically created root key at startup (check /bind/etc/keys.conf for generated keys). Checkout compose.authoritative.yaml for an example.
If run as slave, make sure you set the BIND_MASTERS IPs so they will pickup all changes automatically. The slave enables recursion, so make sure you have a resolver present to resolve queries not handles by the slave. The slave will respond to all IPs on RFC1918 by default. You can setup your own config as well. You can run as many slaves as you like.
If run as a resolver, it will cache all results and use the root zone NS to create its own cache database for all records requested. Make sure the resolver has internet access. The resolver will accept all connections from any RFC1918 address. Checkout compose.resolver.yaml for an example.
- /bind/etc - Directory of named.conf
- /bind/var - Directory of Directory of zone data
name: "bind"
services:
bind:
image: "11notes/bind:9.18.37"
command: ["master"]
environment:
TZ: "Europe/Zurich"
volumes:
- "etc:/bind/etc"
- "var:/bind/var"
ports:
- "53:53/udp"
- "53:53/tcp"
- "8053:8053/tcp"
networks:
frontend:
sysctls:
net.ipv4.ip_unprivileged_port_start: 53
restart: "always"
volumes:
etc:
var:
networks:
frontend:| Parameter | Value | Description |
|---|---|---|
user |
docker | user name |
uid |
1000 | user identifier |
gid |
1000 | group identifier |
home |
/bind | home directory of user docker |
| Parameter | Value | Default |
|---|---|---|
TZ |
Time Zone | |
DEBUG |
Will activate debug option for container image and app (if available) | |
BIND_SLAVES |
IPs of bind slaves if using authoritative master (add ;) | |
BIND_MASTERS |
IPs of bind master if using authoritative slave (add ;) |
These are the main tags for the image. There is also a tag for each commit and its shorthand sha256 value.
It is of my opinion that the :latest tag is super dangerous. Many times, I’ve introduced breaking changes to my images. This would have messed up everything for some people. If you don’t want to change the tag to the latest semver, simply use the short versions of semver. Instead of using :9.18.37 you can use :9 or :9.18. Since on each new version these tags are updated to the latest version of the software, using them is identical to using :latest but at least fixed to a major or minor version.
If you still insist on having the bleeding edge release of this app, simply use the :rolling tag, but be warned! You will get the latest version of the app instantly, regardless of breaking changes or security issues or what so ever. You do this at your own risk!
docker pull 11notes/bind:9.18.37
docker pull ghcr.io/11notes/bind:9.18.37
docker pull quay.io/11notes/bind:9.18.37
Tip
- Use a reverse proxy like Traefik, Nginx, HAproxy to terminate TLS and to protect your endpoints
- Use Let’s Encrypt DNS-01 challenge to obtain valid SSL certificates for your services
This image is provided to you at your own risk. Always make backups before updating an image to a different version. Check the releases for breaking changes. If you have any problems with using this image simply raise an issue, thanks. If you have a question or inputs please create a new discussion instead of an issue. You can find all my other repositories on github.
created 22.05.2025, 07:44:23 (CET)