BIND9 on Alpine; with K8s in mind. Bring your own named.conf and get up and running.
CI/CD will automatically build and push new images to container registries. Currently, the following registries are supported:
All workflows are using the tagging convention listed below. It is subsequently applied to all images.
| Event | Image Tags |
|---|---|
push on main |
edge |
push a tag (e.g. v2.4.3) |
2.4.3, 2.4, 2, latest |
Your base configuration can be mounted to ${NAMED_MAIN_CONFIGURATION_FILE} (see environment variable section). The entrypoint script will execute the named service and provide the aforementioned file as the configuration file. As a consequence, you can configure everything yourself. A default configuration can be found under configuration/named.conf - this file is mounted to ${NAMED_MAIN_CONFIGURATION_FILE} as a default.
If you want to run a custom script before the DNS server is started, you can mount a script to ${USER_PATCHES_FILE} (see environment variable section). This script will be sourced before the DNS server is started, if it is present. If you provide a function called user_patches_-_main, the function is called. This way, you can even adjust environment variables configured in the entrypoint script. Have a look at the entrypoint script to see which variables are declared and what you can adjust.
The following list of environment variables can be used to adjust the container's behavior.
This sets the main configuration file that the named service is provided with during startup. The default is /etc/bind/named.conf.
If you want to provide a custom script that is run right before the named service is started, you can change the location of this script with this variable. The default is /user-patches.sh.
named listens on port 8053 by default, for both UDP and TCP. You can run this container with a read-only root filesystem and as a non-root user.
| Metric | Value |
|---|---|
| open port(s) | 53 & 8053 (TCP & UDP) |
| default user | named (UID 100 & GID 101) |
In K8s, CoreDNS is a de-facto standard for cluster-wide DNS. CoreDNS is easy to configure for most use cases. However, if you need a more complex recursive resolver that may be able to use DNSSEC, you would need to compile CoreDNS with the unbound plugin yourself. With this container though, you can resolve queries recursively and with DNSSEC. Here is a small example of a Corefile that forwards queries, that may need recursive resolving, to this container:
dnswl.org spamhaus.org {
forward . dns://<K8S-DNS-SERVICE-CLUSTER-IP-ADDRESS>:8053 {
prefer_udp
}
}
.:53 {
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods verified
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
forward . tls://1.1.1.1 tls://1.0.0.1 {
tls_servername cloudflare-dns.com
health_check 30s
}
}
This is especially useful because CoreDNS can handle cluster-specific traffic very well. You would not want to handle cluster-specific DNS traffic with this container alone.