Home / server / Questions / 1040409
Accepted
chilladx
Asked: 2020-10-29 10:48:48 +0800 CST

Incomplete axfrdns response

  • 772

I'm trying to setup djbdns (tinydns, dnscache and axfrdns) in a private network. There is a secondary server running BIND that should be able to transfer the zone managed by tinydns (through axfrdns).

I get this error message in the axfrdns logs when I request a zone transfer:

axfrdns: fatal: unable to read data.cdb: format error

But in fact, the data.cdb file is the one used by tinydns, and it has been generated by tinydns-data: no visible problem with it.

If I do the transfer request manually with dig -t AXFR my_zone.com @172.16.2.200, I get a response, but only with the first ~20 entries from the data file (in the same order: SOA, NS, MX, A, ...), ended with the following message:

;; communications error to 172.16.2.200#53: end of file

Obviously, this is not the end of the file.

The full response (names have been slightly changed, for privacy purpose):

$ dig -t AXFR my_zone.com @172.16.2.200

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> -t AXFR my_zone.com @172.16.2.200
;; global options: +cmd
my_zone.com.           2560    IN      SOA     srv-10.my_zone.com. hostmaster.my_zone.com. 1603886087 16384 2048 1048576 2560
my_zone.com.           259200  IN      NS      srv-10.my_zone.com.
srv-10.my_zone.com.    259200  IN      A       172.16.2.199
my_zone.com.           259200  IN      NS      vm01.my_zone.com.
vm01.my_zone.com.      259200  IN      A       172.16.2.201
my_zone.com.           259200  IN      NS      vm02.my_zone.com.
vm02.my_zone.com.      259200  IN      A       172.16.2.202
my_zone.com.           86400   IN      MX      0 my_zone.mail.protection.outlook.com.
aaa.my_zone.com.       86400   IN      A       78.40.125.202
bbb.my_zone.com.       86400   IN      A       193.186.8.180
ccc.my_zone.com.       86400   IN      A       78.40.125.106
ddd.my_zone.com.       86400   IN      A       78.40.125.202
eee.my_zone.com.       86400   IN      A       193.186.8.34
fff.my_zone.com.       86400   IN      A       35.204.32.245
ggg.my_zone.com.       86400   IN      A       192.168.10.81
hhh.my_zone.com.       86400   IN      A       13.69.156.71
iii.my_zone.com.       86400   IN      A       13.69.156.71
jjj.my_zone.com.       86400   IN      A       13.69.156.71
my_zone.com.           86400   IN      A       172.16.2.172
lll.my_zone.com.       86400   IN      A       172.16.2.186
mmm.my_zone.com.       86400   IN      A       172.16.2.187
nnn.my_zone.com.       86400   IN      A       172.16.2.170
ooo.my_zone.com.       86400   IN      A       172.16.2.171
;; communications error to 172.16.2.200#53: end of file

I tcpdumped the communication between the axfrdns client (172.16.2.170) and the server (172.16.2.200): I can't see a clear problem in it, except at some point, the server closes the connection (packet #22).

tcpdump

I thought it could be something in the data file, but switching the entries where it stops responding (in the above example, ooo.my_zone.com) and the one after (say ppp.my_zone.com) doesn't help. It now stops at ppp.my_zone.com (i.e. at the same position, not the same entry).

Each query response packet in the tcpdump contains multiple DNS response.

How can I transfer my whole zone (~340 entries) with axfrdns? Or how to debug further?

djbdns

2 Answers

  1. Best Answer

    I had this mysterious problem too following an OS upgrade and recompile. Turns out I just had to increase the softlimit (from 300000 to 3000000) in /etc/axfrdns/run.

    • 3

  2. I've been using djbdns for years, & OMFG it's great except when it's just stuff like this. For context, my VPS is transitioning away from a subnet that contains an IP I've been using for years, and that's fine, but trying to get tinydns to deal with it was confusing at best and infuriating at worst. The server was fulfilling exactly one request and then hanging prior to the above fix.. But at least it's not BIND.

    • 0