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.

Flattr this
DNS and DNSSEC :: 10 Jul 2012 :: e-mail

Comments

blog comments powered by Disqus