Debugging failed AXFR zone transfers

Recently we upgraded our server at Host Europe to get better hardware and more RAM for less money/month. Moving from one server version to the next (v4 to v6 with us) means you get the new server for 7 days (and some more if you need the time and ask nicely) in parallel to the old. In this time you can setup the new system and move all data. After that time, the old server is shut down and away.

Since we were forced to re-setup the new system, I chose to switch the DNS server software: Goodbye bind, hello djbdns (more precisely: dbndns, Debian's djbdns fork with IPv6 support).

Denic, the registrar for .de domains, requires everyone to have at least two DNS servers. Hosteurope offers AutoDNS for that: Register your domain for AutoDNS, and you'll get one of their name servers assigned as secondary NS (I regularly have, and They will update themselves automatically with AXFR zone transfers.

Failed zone transfers

This automatism was source of my problem: It did not work. The serial number on the secondary name server did not match the primary's even after a day:

$ dig +short SOA 1359617938 16384 2048 1048576 2560
$ dig +short SOA 1359488555 16384 2048 1048576 2560

I am using axfrdns now, and its log file /etc/axfrdns/axfrdns4/log/main/current only told me that the remote server aborted the connection:

tcpserver: status: 1/40
tcpserver: pid 22112 from
tcpserver: ok 22112 0: :
50ed8003001c00000000000000000000:b1e4:1583 0006
50ed8003001c00000000000000000000:b1e4:1584 00fc
axfrdns: fatal: unable to read from network: connection reset
tcpserver: end 22112 status 28416

I had no idea what was going on and contacted the Host Europe support.

Finding the problem

The support answered some days later; they did investigate the issue and could not find a problem on their part. They provided an excerpt from their DNS server log file:

transfer of '' from
 failed while receiving responses: bad label type
 end of transfer
 failed while receiving responses: bad label type
 end of transfer

Because of this they suspected a problem on my side, which they underpinned with the output of a AXFR transfer test via dig:

$ dig -t AXFR @
; <<>> DiG 9.7.3 <<>> -t AXFR @
;; global options: +cmd 1359631614 16384 2048 1048576 2560
... 86400 INSRV0 0 5222
;; Got bad packet: bad label type
75 bytes
89 f5 84 00 00 00 00 01 00 00 00 00 0c 5f 78 6d          ............._xm
70 70 2d 73 65 72 76 65 72 04 5f 74 63 70 07 63          pp-server._tcp.c
77 65 69 73 6b 65 02 64 65 00 00 21 00 01 00 01!....
51 80 00 17 00 05 00 00 14 95 05 78 6d 70 70 07          Q..........xmpp.
63 77 65 69 73 6b 65 02 64 65 00               

So the problem was the SRV record. Thanks to Florian Riehe for finding the issue.

Fixing the SRV record

The SRV line in my DNS data file looked like this:\000\005\000\000\024\225\005xmpp\007cweiske\002de\000

Nice and readable, isn't it? In case you did not spot the totally obvious problem: The second \005 is wrong, it has to be a \004.

The reason for this cryptic line is that djbdns does not have built-in "nice" support for SRV records; you have to use its generic record syntax ("uncommon data lines") to express them. This is error prone as I had to experience.

Since I don't want to write those lines myself, I use a djbdns SRV record generator . Having to use it sucks, but what else can I do? D. J. Bernstein rejects the SRV patch because he thinks the generic record syntax suffices.

Nevertheless, AXFR zone transfers work now:

$ dig +short SOA 1360100327 16384 2048 1048576 2560
$ dig +short SOA 1360100327 16384 2048 1048576 2560

Written by Christian Weiske.

Comments? Please send an e-mail.