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 an INVALID_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.