YADIFA (sometimes spelled Y:A:D::I::F:A) is a name server developed by EURid, the registry for the .eu top-level domain. EURid implemented (yet another) name server to increase the robustness of the .eu name server infrastructure. YADIFA is currently an authoritative-only name server which:
- supports master/slave configurations with full (AXFR) and incremental (IXFR) zone transfer handling
- is written from scratch in C and purported to be portable and fast
- supports DNSSEC (EDNS0, NSEC and NSEC3)
- supports dynamic DNS updates
This post is but a very cursory glance at YADIFA.
I built a server from YADIFA’s source code and used bits of the reference manual to construct an initial configuration file:
<main>
server-port 5353
listen 192.168.1.10, 127.0.0.1 port 5353
uid 501
daemonize false
allow-query any
</main>
# dnssec-keygen -a HMAC-MD5 -b 64 -n HOST ytestkey
<key>
name ytestkey
algorithm hmac-md5
secret OKSjaL1x5sE=
</key>
<acl>
updaters key ytestkey
myhosts 192.168.1.0/24;127.0.0.1/32;::1
</acl>
<zone>
domain example.net
file masters/example.net
type master
allow-transfer myhosts
allow-update updaters
</zone>
<zone>
domain 1.168.192.in-addr.arpa
type slave
file slaves/1.168.192.in-addr.arpa
master 192.168.1.20 port 53
</zone>
The server started with copious debugging on stdout (which can be directed to logfiles or syslog).
As far as I can judge, the program works as advertised, even though a few things surprised me a little:
- Loading of the miniature
example.net
master zone produced anINVALID_CHARSET
error because the zone master file file contained an@
; I had to replace that by an origin name. - Slaving of the
in-addr.arpa
zone showed a “connection refused” to the master. It turns out YADIFA uses the default “server-port” to connect to master servers, unless I explicitly specify a port number in the master statement, as shown above. - Slaving of an internal zone of mine failed with
INVALID_CHARSET
on “record #6”; this is possibly due to an embedded space in the rdata of a PTR record (JPmens\032DNS\032page._http._tcp.ww.mens.de.
) - Dynamic DNS updates with TSIG keys appear to fail but don’t really. (Issue fixed.)
- Stopping yadifad takes quite a long time (15 seconds with above configuration).
- Updated or slaved zones are written to master zone files on disk only when yadifad is signalled with a SIGUSR1 signal. Until then, they are stored in temporary databases (on disk).
YADIFA’s roadmap shows where it is heading to, so you may want to follow its progress.