Questions[djbdns](server)

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).

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?

Does djbdns/tinydns support large TXT records, for example when serving long DKIM keys?

I'm aware of RFC 4408 section 3.1.3 and RFC 1035 section 3.3.14:

https://www.rfc-editor.org/rfc/rfc4408#section-3.1.3

https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14

Which both suggest that a TXT record can be split into multiple character strings to permit long (>255 characters) records to be served.

I also bumped into this question during my research:

https://serverfault.com/questions/255580/how-do-i-enter-a-strong-long-dkim-key-into-dns

I've attempted both approaches mentioned in the accepted answer, with and without surrounding parenthesis.

But djbdns refuses to to serve these records correctly. For example, when querying my domainkey record using nslookup I get:

mail03._domainkey.zygonia.net   text =

    ""v=DKIM1; k=rsa; p=" "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7UNgSlnndT9JY0soSjxLhFFnvAeVN8b6Y3oKctAunNltMjvXfTD37doER8a9xwEOIXkGPgxJ5UPb/KndvHiIo+j8AScoIZCW"
    "glFWp4AUoKlQkKP7o7vwFnWypU+DmcJAtyuhZ9X5yzag37cVR"
    "YD4icd02yAETLbIpv1mnMUFkTnkdmtSa5gL2cLUueUOValoENwkWTcZR" "+kraTEU/VDPI"
    "RgNBu6OJmQdk0sv4qdkwVVvxvquT4C/SimQDoDaQwlFCp2sBryXyaNSRCaAhRxPaKUpKsPmubW0SJF2nQZ3DprJQcaRQLd9Qgxz+V+XaseaXXWPy+6"
    "tB6BlPFk5FwIDAQAB""

*** Error: record size incorrect (515 != 419)

*** ns0.example.net can't find mail03._domainkey.zygonia.net: Unspecified error

This is with a DKIM TXT record that looks like:

"v=DKIM1; k=rsa; p=" "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7UNgSlnndT9JY0soSjxLhFFnvAeVN8b6Y3oKctAunNltMjvXfTD37doER8a9xwEOIXkGPgxJ5UPb/KndvHiIo+j8AScoIZCW1glFWp4AUoKlQkKP7o7vwFnWypU+DmcJAtyuhZ9X5yzag37cVRGYD4icd02yAETLbIpv1mnMUFkTnkdmtSa5gL2cLUueUOValoENwkWTcZR" "+kraTEU/VDPIrRgNBu6OJmQdk0sv4qdkwVVvxvquT4C/SimQDoDaQwlFCp2sBryXyaNSRCaAhRxPaKUpKsPmubW0SJF2nQZ3DprJQcaRQLd9Qgxz+V+XaseaXXWPy+6rtB6BlPFk5FwIDAQAB"

The raw djbdns data record looks like:

:mail03._domainkey.zygonia.net:16:\642"v=DKIM1;\040k=rsa;\040p="\040"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7UNgSlnndT9JY0soSjxLhFFnvAeVN8b6Y3oKctAunNltMjvXfTD37doER8a9xwEOIXkGPgxJ5UPb\057KndvHiIo+j8AScoIZCW1glFWp4AUoKlQkKP7o7vwFnWypU+DmcJAtyuhZ9X5yzag37cVRGYD4icd02yAETLbIpv1mnMUFkTnkdmtSa5gL2cLUueUOValoENwkWTcZR"\040"+kraTEU\057VDPIrRgNBu6OJmQdk0sv4qdkwVVvxvquT4C\057SimQDoDaQwlFCp2sBryXyaNSRCaAhRxPaKUpKsPmubW0SJF2nQZ3DprJQcaRQLd9Qgxz+V+XaseaXXWPy+6rtB6BlPFk5FwIDAQAB":600

Is djbdns a lost cause when it comes to long TXT records?

Spent a wonderful 6 hours setting up djbdns (tinydns + dnscache) as a secondary name server. I managed to hack together a working solution, but am confused as to why it did not work out of the box.

Both primary & secondary name servers live behind a Cisco ASA, external IPs get NAT'd to appropriate internal subnets, in this case DMZ for the name servers.

Primary NS is run by a Plesk-type CP, so djbdns configuration is all GUI, and runs fine. Now, until I discovered the extortion that is secondary name server hosting, I was considering offloading this task to a 3rd party. No thanks, trop cher for this frere. Anyway, roll-your- own-time: have a file server sitting in colo rack not doing much of anything, let's put it to work.

Following this tutorial:

http://www.howtoforge.com/clean-djbdns-dns-server-on-centos-dnscache-and-tinydns-a-to-z

I got everything installed just fine; however, nothing worked, or at least only digs against localhost worked. I needed dig@dmz-ip foo.com to resolve.

Not knowing any better, I hacked the dnscache & tindns env/IP files, reversing them, so tinydns listens on dmz and dnscache on localhost. Restarted both services and voila, was able to dig from remote laptop to secondary name server IP and resolve the domains that we host, wonderful.

So, I thought, well I should do this properly, and blew away everything, reinstalled, and set tinydns to listen on dmz and dnscache on localhost (as I had done in manually hacking env/IP files). Tried to dig @localhost foo.com, nada; same deal with dig@dmz-ip foo.com. WTF? Yes, wtf. In Noob mode, I tried tindyns on localhost, both on dmz, etc., nothing worked.

In the end I installed dnscache on the dmz, tinydns on localhost, and then env/IP reversed them (dnscache on localhost & tinydns on dmz). It's the only way I've found to get them working, and am completely at a loss as to why I could not just install without having to hack env/IP files.

djbdns users, feel free to chime in, am glad I finally have a working setup, but that was a hellacious evening, would like a clean setup if at all possible...

I have a djbdns dnscache running; is there a way to have it return a specific IP instead of NXDOMAIN?

I am working on an application that will be used to verify new domains are configured correctly as they're set up for hosting. Part of this checks the validity of SPF, DomainKey, DKIM records, etc.

I currently use a default TTL of one hour for most of these records. Occasionally a mistake is found in one of the records so it needs to be updated. Currently, if I've just tested the domain I have to wait for the system's resolver's cached record to expire before I can verify it is correct with my application. (Yes, I can check manually but I wrote the application so I don't have to).

I would like to set up a DNS server on the system to act as a normal caching resolver except that it will expire records in a maximum of a set time such as five minutes or just not cache at all. Not all of the domains have DNS hosted on my normal name servers so this system would have to query the authoritative name servers for a domain rather that use upstream resolvers (which would just use their cached records).

This machine is not currently running DNS of any kind so I can install BIND or djbdns (or something else if there's a good suggestion.