# Running djbdns in a podman container

Posted on Sat 08 January 2022 in misc

I have been using djbdns for several years now and I still love it. Tiny, secure, maybe not as beginner friendly but I don't mind that. I previously used an RPM file that I first build on Enterprise Linux 6 which cleanly build on EL7 as well, but EL8 is another issue. Now the end of life for EL7 is still two years out when writing this blog, I was still interested in a more long term solution. Enter containers. As a user of EL for servers, both professionally and privately, I switched to podman i.o. Docker, just because the daemonless nature of podman yield a more secure system and it's even possible to run the containers rootless, but in this case that comes at a price.

### Rootfull vs rootless containers

Wherever I use containers I try to use them rootless, but in certain scenarios it is an issue with running a DNS. Most importantly, running a djbdns container rootlessly means that it is not possible to distinguish the source of DNS queries. That means that you cannot use a split horizon or limit AXFR access to specific IP addresses. The logging will also show a source query address in the network namespace of the container (usually 10.0.2.0/24). If neither are required, running a container with tinydns and axfrdns rootlessly is a good idea.

Another issue with a rootless container is the fact that dnscache cannot forward queries to another rootless container with tinydns on the same host since they both listen on port 53 and there is no way to distinguish between the networks.

If tinydns and axfrdns are run in a rootless container, both TCP and UDP port 53 must be published on some high host port. Via a NAT firewall rule a query to port 53 of the host can be redirected to the published port.

When using a rootfull container, the container can be defined with its own IP address within a podman network and in this case port 53 does not need to be published on a host port, port 53 on the container IP is reachable and a DNAT firewall rule can be used to send the DNS query to the container. If you use a second rootfull container with dnscache the DNS queries that should be handled by tinydns or axfrdns can be forwarded to the IP addres of the tinydns container.

### Creating the container.

If I run a container, I want it small. I started with the Dockerfile that was published by Yasuo Ohgaki to install djbdns, ucspi-tcp and daemontools on Alpine Linux. For this, gcc etc had to be installed to compile the code, but I want it two changes on that: first I wanted to apply some patches and second, I wanted only the compiled result, not the source nor gcc, perl and the like. To achieve that I modified the Dockerfile to a multi stage version where first a container is used to compile the data and then a second container is created where the compiled result is copied to.

For daemontools 0.76 I applied a single patch to replace "extern int errno;" by "#include <errno.h>". This is needed to be able to compile the software with gcc (this goes for ucspi-tcp and djbdns as well). After compiling and installing, the various binaries stay in the source tree and there were symlinks from the "/command" directory to the compiled binaries in the source tree and there were symlinks from /usr/local/bin to the symlinks in the /command directory. I deleted the symlinks from /usr/local/bin and did a "cp -L" from /command directory to /usr/local/bin.

On ucspi-tcp 0.88 I applied "Fefe's" diff20 patch to enable IPv6 support on tcpserver and tcpclient.

On djbdns 1.05 I applied quite a few more patches. First, I applied Fefe's (test28) patch to enable IPv6 for tinydns. Second, I installed Peter Conrad's DNSSEC patch for tinydns (version 1.8) which requires Fefe's patch. I have yet to enable DNSSEC. A third patch that I applied is Guilherme Balena Versiani's NAPTR extension to Michael Handler's SRV patch which allows easy creation of both resource records. Since Guilherme published a patched version of djbdns-1.05, I re-calculated the patch and applied it to my patched source. This yielded a few rejected hunks that were easily fixable. I also added a second parameter to his "rr_finish()" statements because lacking those generated compile errors. The final patch against my Fefe + DNSSEC version is a collection of various patches that I collected. I applied them all manually to what I had until then and used git diff to generate a big patch with all of them. The patches are named in the top of this collective patch file, but for most of them I can no longer find the original online.

The modified version of Guilherme's patch and the patch collective, along with two scripts and the containerfile are available via this Gitlab snippet.

After compiling all these I copied the content of /usr/local/bin to the destination image. I added two scripts to this directory: a script to start the required djbdns daemon (startdjb.sh) and a second one to build the djbdns databases from within the container (makeall.sh).

Recreating the image yourself is trivial. Clone the snippet repository and build the image from within the cloned directory like so:

git clone https://gitlab.com/snippets/2232485.git
cd 2232485


and then either

docker build -f Containerfile -t yourtagname .


or

buildah bud -f Containerfile -t yourtagname


This should yield an 8MB container. If you want to try a ready-made image, a saved image is available via this link. The image can be recreated via podman load < tarfile or docker load < tarfile.

### Using the containers

The containers expose TCP and UDP ports 53 and /usr/local/etc should be mapped to a directory on the host. If you use podman on a system with SELinux enabled (I hope you do), make sure the directory that is mapped to the container's /usr/local/etc has a writable content type (I use container_file_t).

Via the DJBMODE environment variable, you can define which djbdns daemon should run in the container. If no value is provided, the value tinydns is assumed which starts both tinydns and axfrdns. For the dnscache, walldns or rbldns daemons, you should use the values dnscache, walldns or rbldns respectively.

To run the container rootlessly, use a command line like:

podman create --rm --name djbdns -p 5553:53/tcp -p 5553:53/udp \
-v /var/podman:/usr/local/etc -e DJBMODE=tinydns alpine-djbdns

On the first run, the /var/podman will be populated with a tinydns and axfrdns tree. Make sure that the administrator redirects TCP and UDP queries to the port(s) as specified.

If you run a rootfull container, you can assign an IP address to the container. By default, podman installs a network named "podman" with an IP network of 10.88.0.0/16. To find out, you can use

podman network ls

and

podman network inspect networkname

to see which IP space is available. To create an own network, you use something like

podman network create --subnet 172.25.1.0/24 --gateway 172.25.1.1 djbnet

Creating the container with an IP address goes something like this:

podman create --rm --ip 172.25.1.10 --network djbnet --name djbdns \
-v /var/podman:/usr/local/etc -e DJBMODE=tinydns alpine-djbdns

If you also need dnscache you can create the container similarly but with a different IP address in the same network. The exposed ports do not need to be published on a host port, port 53 is available on the container's IP address. To reach the container, the routing tables need to know how to reach the container, or the host running the container needs DNAT rules when the server is queried on the DNS port (don't forget to set the DJBMODE variable to dnscache for that to work).

It is advisable to generate systemd files with

podman generate systemd --files --new --name containername

With this systemd can be used to start, stop and monitor the containers.

With rootfull containers, it is possible to create forward files for dnscache to be handled by tinydns or axfrdns. If, e.g., the tinydns container listens on IP address 172.25.1.10 and serves DNS records for example.com, you can create the file *volumemount*/dnscache/root/servers/example.com with 172.25.1.10 as content.

After first running the tinydns container, the tinydns and axfrdns databases are still missing. They can be created externally and copied to *volumemount*/tinydns/root/data.cdb and *volumemount*/axfrdns/tcp.dns respectively, or the source files data and tcp can be edited after which you run "makeall.sh" in the running container with

podman exec -it containername /usr/local/bin/makeall.sh