DJBDNS vs bind 1:9.XX - AXFR = FORMERR

quash · March 25, 2026, 6:29pm

Hi everyone,

After upgrading from Debian 11 to 12 (moving from BIND 9.16 to 9.18), my public DNS servers is no longer able to pull zones from a remote djbdns (1.05) master. This setup worked flawlessly prior to the upgrade.

Error logs:

Plaintext

transfer of 'xxxx.xx/IN' from 92.xx.xx.xx#53: missing question section
transfer of 'xxxx.xx/IN' from 92.xx.xx.xx#53: failed while receiving responses: FORMERR
transfer of 'xxxx.xx/IN' from 92.xx.xx.xx#53: Transfer status: FORMERR

Technical Context: It appears the axfrdns module in djbdns omits the Question Section from the AXFR response packet. While BIND 9.16 was lenient enough to accept this, the stricter parser in BIND 9.18 treats this as a protocol violation and immediately drops the connection with a FORMERR.

Troubleshooting attempted (unsuccessful): I tried the following server block configurations to bypass the issue, but the error persists:

DNS Zone file

server 92.xx.xx.xx {
    edns no;
    request-ixfr no;
    transfer-format one-answer;
};

It seems the BIND 9.18 parser rejects the packet’s structure before these compatibility flags can take effect.

Questions for the developers:

Is there any BIND-side configuration (perhaps a hidden or legacy option) to relax the parser’s strictness regarding the “Question Section” in AXFR responses?
For those still dealing with legacy infrastructure: When are you planning to phase out the unsupported djbdns in favor of modern alternatives (e.g., BIND )? Since modern software is clearly dropping support for djbdns-style behavior, I’d be interested to hear about your migration roadmaps or experiences.

We use several interworx CPs, and we also extract DNS records from other systems, which we serve with a common DNS cluster. Due to the above error, the cluster is now unable to update zones from interworx DJBDNS. In this form, Interworx/djbdns is unusable!

Regards,
Gábor Szél

d2d4j · March 25, 2026, 7:31pm

Hi

I would open a support ticket and let IW have a look

Do you receive a correct answer if you run dig from bind on 1 zone

Have you tried just using axfr and not infrared as a test

many thanks

john

iworx-brandon · March 25, 2026, 8:01pm

Hello–

I dug into the BIND docs, and it looks like the newer versions (namely 9.18) are intentionally stricter. Unfortunately, there doesn’t seem to be a way around it. It’s a deliberate design choice on their end.

We’re currently in the middle of moving away from DJB. Qmail is the focus right now and BIND is the second phase of that. We have begun some work on BIND. That said, since many of our largest partners and, thus, a majority of our install base handle DNS outside of InterWorx, BIND support has ended up on the back burner while we rush the Qmail side of things.

I can’t give you a specific timeline just yet, but the plan is to have a completely DJB-free environment by EL10 (with similar improvements for previous OSs too).

It is coming!

quash · March 25, 2026, 8:08pm

Dear John!

Yes, dig AXFR is working!

root@ns2:/etc/bind# dig AXFR xxxx.xxx @92.xx.xx.xx

; <<>> DiG 9.18.44-1~deb12u1-Debian <<>> AXFR xxxx.xx @92.xx.xx.xx
;; global options: +cmd
xxxx.xx. 2560 IN SOA ns.xxxx.xx. zzzz.xxxx.xx. 2023011100 7200 300 604800 10800
xxxx.xx. 3600 IN NS ns2.xxxx.xx.
xxxx.xx. 2560 IN SOA ns.xxxx.xx. zzzz.xxxx.xx. 2023011100 7200 300 604800 10800
;; Query time: 28 msec
;; SERVER: 92.61.113.217#53(92.61.113.217) (TCP)
;; WHEN: Wed Mar 25 20:48:07 CET 2026
;; XFR size: 32 records (messages 32, bytes 1694)

Problem is:
axfrdns program in djbdns-1.05 does not include the question section in its AXFR (zone transfer) response packets, which can cause compatibility issues with some strict DNS clients.

But, I found patch from this problem:
Patch Information: A patch designed for RFC-1034 section 4.3.3 compatibility (which requires including the question section) is available as part of the tinydnssec project. It is applied to axfrdns.c.
Google: “djbdns axfrdns-question-section patch”

Patch source:

github.com/henryk/tinydnssec

djbdns-1.05-dnssec.patch

master

(C) 2012 Peter Conrad <conrad@quisquis.de>

This patch is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License version 3 as
published by the Free Software Foundation.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

diff -rNU3 djbdns-1.05.tds-base/axfrdns.c djbdns-1.05.tinydnssec/axfrdns.c
--- djbdns-1.05.tds-base/axfrdns.c	2012-12-06 22:45:38.000000000 +0100
+++ djbdns-1.05.tinydnssec/axfrdns.c	2012-12-06 22:39:13.000000000 +0100
@@ -23,6 +23,7 @@
 #include "response.h"
 #include "ip6.h"

This file has been truncated. show original

if you add this to interworx djbdns package, it will probably solve the problem.
I don’t want to create a CentOS build environment for this.
can you make a patched package?

iworx-brandon · March 25, 2026, 8:23pm

Unfortunately, we cannot use the dnssec patch. One of the patches it requires is from an author that refuses to name a license for their patch, meaning we are unable to distribute it without opening up potential legal issues for us. Even the author of this patch warns that they cannot even distribute the upstream patch due to the lack of a license.

quash · March 25, 2026, 8:32pm

Isn’t that enough? (Sorry, I’m not a lawyer!)

github.com/henryk/tinydnssec

README.tinydnssec

master

DNSSEC for tinydns
==================

This project adds DNSSEC support to D. J. Bernstein's tinydns (see
http://cr.yp.to/djbdns.html ).

It consists of two parts (mostly):

- tinydns-sign, a perl script for augmenting a tinydns-data file with
  DNSSEC-related RRs, and

- a patch to tinydns / axfrdns to make them produce DNSSEC-authenticated
  answers.

The patch tries to preserve the behaviour of tinydns/axfrdns wrt non-DNSSEC
queries, with these noteworthy exceptions:

- The interpretation of wildcard records now matches the description in
  RFC-1034 section 4.3.3. Specifically, if there's a wildcard *.x and a
  record for a.x, then a query for y.a.x will *not* be answered using the

This file has been truncated. show original

LICENSE

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License version 3 as
published by the Free Software Foundation.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.

iworx-brandon · March 25, 2026, 9:00pm

Sorry for the confusion: this patch is licensed permissively, no issue there. However, this patch relies on other patches being installed first. One of those patches does not have a license. Since these patches are cumulative, trying to just install this patch without the other patch would fail. So there is no way to use this patch without the downstream patch, which we cannot use.

I am not a lawyer either, so you’re in good company.

quash · March 25, 2026, 9:45pm

I think if I only want to fix Bind AXFR FORMERR, then this many patches are enough!

--- axfrdns.c
+++ axfrdns.c
@@ -146,7 +146,15 @@ int build(stralloc *sa,char *q,int flagsoa,char id[2])

if (!stralloc_copyb(sa,id,2)) nomem();
- if (!stralloc_catb(sa,“\204\000\0\0\0\1\0\0\0\0”,10)) nomem();
+/* HEADER: QDCOUNT=1, ANCOUNT=1 */
+if (!stralloc_catb(sa,“\204\000\0\1\0\1\0\0\0\0”,10)) nomem();
+/* QUESTION SECTION (RFC-compliant AXFR) */
+if (!stralloc_catb(sa,q,dns_domain_length(q))) nomem();
+if (!stralloc_catb(sa,type,2)) nomem();
+if (!stralloc_catb(sa,DNS_C_IN,2)) nomem();
+
copy(misc,1);
if ((misc[0] == ‘=’ + 1) || (misc[0] == ‘*’ + 1)) {
–misc[0];

This “patch” inserts the QUESTION section into the first AXFR response packet.
One modified line and 4 new lines and the comments!
I don’t think this requires any license and has no previous dependencies!

unfortunately I can’t compile it because I don’t have the “djbdns.x86_64 1.05-166.rhe7x.iworx” package you modified.
and compiling the original djbdns-1.05.tar.gz is very cumbersome under modern CentOS!
I tried, there are a lot of things that need to be fixed.

iworx-brandon · March 26, 2026, 7:51pm

Hello–

I’ve made a ticket to look into this option more. Having said that, CentOS 7 support for external customers ended at the beginning of the year. This issue will still exist for EL8 and EL9 and I would expect any work done on it to be directed toward those platforms.

Thank you,

quash · March 26, 2026, 8:06pm

Dear Brandon!

If we upgrade to EL8 or EL9, will the problem be solved?
I understand that DJBDNS is used in all interworx versions?
So the upgrade will leave DJBDNS, so the problem will remain!

Regards,
Gábor Szél

IWorx-Jenna · March 27, 2026, 2:15pm

Hello–

As Brandon stated, the issue will still remain on an EL8 or EL9 server.

However, we no longer support CentOS 7 servers for external customers.

So, any progress that may be made on the issue will only be for EL8+.

While there is no ETA on a resolution, once it is resolved, whenever that may be, you will never receive that fix on your current server. Migrating to a supported environment will be required, no matter what.

Thanks,

-Jenna