The state of MaraDNS in Debian

Taking over

Erre con erre cigarro
Erre con erre barril
Rápido ruedan los carros
En el ferrocarril

With the release of MaraDNS 1.4.06-1 in Debian, I took over the packaging of this DNS server in Februaury 2011. The previous maintainer quite reasonably had not wanted to manage the migration to the new 2.0 version, with its enhanced recursive resolver and better support for IPv6. On the other hand I wanted to become more familiar with a DNS server, that was lightweight and secure. Looking at the bugs, I could put them into three groups:

• those that required work on the init scripts;
• those that would be fixed by upgrading to the 2.0 code base;
• those that required intimacy with resolvconf.

I do not intend to use resolvconf for now, so I am waiting for someone who cares about both MaraDNS and resolvconf before looking into that one. In any case I have taken what free actions I can by making sure that whatever was available was installed at least as an example. Moving onto the 2.0 code base will require a new process, deadwood, so I felt it was important to fix all init script issues first.

Multiple server processes

The first curious feature I found in the init scripts is that by exposing the SERVERS environment variable in /etc/default/maradns, it supports multiple servers on a single machine bound to different IP addresses. Obviously this does not enable load balancing or high availability, as that would require multiple machines. Nor is it Debian's way of starting the zoneserver — that is a different issue. I had to look back to 2003 over the changelog to find the bug report that asked for the functionality so that you could have outward facing service and an inward facing service supporting private addresses. I suppose pre-deadwood it would be useful in implementing the fix for the dangling CNAME issue. On the other hand I cannot help feeling that this was a hack, which must surely complicate the security of a firewall. I am fairly sure I would have refused to implement it. However it is not so easy to turn off a feature once it is out there.

On becoming a Daemon

I have previously attempted a light-hearted exposition of the nature of daemons in Linux. One motivation in writing that was to get very clear in my head what was going on in these MaraDNS init scripts. The core of the init script is the invocation via start-stop-daemon:

 start-stop-daemon --start -m --pidfile /var/run/$SERVERNAME.pid \
             --exec $DAEMON -- -f $rcfile </dev/null 2>&1 \
             | logger -p daemon.notice -t $SERVERNAME 2>/dev/null &
 

I can trace at least two issues to that line:

• Failure to restart after an upgrade During an upgrade the above line gets called inside the postinst script and it is not actually detached from the terminal so it dies when the script finishes. We would need the --background argument.
• The logger process does not guarantee it is starting in an unmountable file system.

The whole line feels as if too much is being squashed into one small box. Now Sam has pointed out that duende would solve all those problems — but I will come back to that. So the solution I came up with is to rewrite the init script so it daemonizes both the maradns process and the logger script. For each file listed in the SERVERS environment variable it:

1. creates a named pipe;
2. daemonizes a logger process taking the input of the logger process from the named pipe;
3. daemonizes a maradns process redirecting its standard output and error to the named pipe.

The first problem with this is that is not actually possible to redirect the input-output since with the --background argument, one ends up redirecting or the start-stop-daemon command. To get round this I found it necessary to use wrapper scripts. The wrapper scripts do some sanity checking and then exec to the corresponding command with the required redirection.

Are we nearly there yet?

In test this is working well. However I still have some issues:

• The logger process runs as root.
• The logger process is not running in any sort of restricted environment or jail.
• It is complicated.

It was at this point, I realized we really do need duende. It does all the stuff my rewrite of the init scripts does, fixes the logger over-privilege issues and is more straightforward and elegant. I had missed this partly because I was approaching it from the current state of MaraDNS in Debian, and partly because discussions with Sam via the bug reports had revolved around the reload issue. I was ready throw away this rewrite, when I hit a problem. Duende does not create a pid file, and the pid file created by start-stop-daemon will not do because the pid is that of the parent process which dies immediately.

Where next?

The required changes to duende look fairly trivial to me. I'll work on a patch and forward it to the MaraDNS mailing list. However the time that I can spend on this release is used up and it will be pushed out of the door. The release after that will, if everything goes according to plan, move the Debian package onto the 2.0 codebase.