# DJBDNS vs bind 1:9.XX - AXFR = FORMERR **URL:** \ **Category:** General Interworx Control Panel Info\ **Created:** [March 25, 2026, 6:29pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023 "2026-03-25T18:29:06Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![quash](https://forums.interworx.com/letter_avatar_proxy/v4/letter/q/3ab097/32.png) [@quash](https://forums.interworx.com/u/quash)\ **Post date:** [March 25, 2026, 6:29pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/1 "2026-03-25T18:29:06Z")
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 ```auto 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 ```auto 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:** 1. 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? 2. 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 ---
**Author:** ![d2d4j](https://forums.interworx.com/user_avatar/forums.interworx.com/d2d4j/32/16_2.png) [@d2d4j](https://forums.interworx.com/u/d2d4j)\ **Post date:** [March 25, 2026, 7:31pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/2 "2026-03-25T19:31:01Z")
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 ---
**Author:** ![iworx-brandon](https://forums.interworx.com/user_avatar/forums.interworx.com/iworx-brandon/32/1432_2.png) [@iworx-brandon](https://forums.interworx.com/u/iworx-brandon)\ **Post date:** [March 25, 2026, 8:01pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/3 "2026-03-25T20:01:01Z")
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! ---
**Author:** ![quash](https://forums.interworx.com/letter_avatar_proxy/v4/letter/q/3ab097/32.png) [@quash](https://forums.interworx.com/u/quash)\ **Post date:** [March 25, 2026, 8:08pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/4 "2026-03-25T20:08:46Z")
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:** > 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? ---
**Author:** ![iworx-brandon](https://forums.interworx.com/user_avatar/forums.interworx.com/iworx-brandon/32/1432_2.png) [@iworx-brandon](https://forums.interworx.com/u/iworx-brandon)\ **Post date:** [March 25, 2026, 8:23pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/5 "2026-03-25T20:23:42Z")
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. ---
**Author:** ![quash](https://forums.interworx.com/letter_avatar_proxy/v4/letter/q/3ab097/32.png) [@quash](https://forums.interworx.com/u/quash)\ **Post date:** [March 25, 2026, 8:32pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/6 "2026-03-25T20:32:55Z")
Isn’t that enough? (Sorry, I’m not a lawyer!) > ## LICENSE (C) 2012 Peter Conrad [conrad@quisquis.de](mailto:conrad@quisquis.de) 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/](http://www.gnu.org/licenses/). ---
**Author:** ![iworx-brandon](https://forums.interworx.com/user_avatar/forums.interworx.com/iworx-brandon/32/1432_2.png) [@iworx-brandon](https://forums.interworx.com/u/iworx-brandon)\ **Post date:** [March 25, 2026, 9:00pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/7 "2026-03-25T21:00:53Z")
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. ---
**Author:** ![quash](https://forums.interworx.com/letter_avatar_proxy/v4/letter/q/3ab097/32.png) [@quash](https://forums.interworx.com/u/quash)\ **Post date:** [March 25, 2026, 9:45pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/8 "2026-03-25T21:45:28Z")
I think if I only want to fix Bind AXFR FORMERR, then this many patches are enough! ```c --- 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. ---
**Author:** ![iworx-brandon](https://forums.interworx.com/user_avatar/forums.interworx.com/iworx-brandon/32/1432_2.png) [@iworx-brandon](https://forums.interworx.com/u/iworx-brandon)\ **Post date:** [March 26, 2026, 7:51pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/9 "2026-03-26T19:51:42Z")
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, ---
**Author:** ![quash](https://forums.interworx.com/letter_avatar_proxy/v4/letter/q/3ab097/32.png) [@quash](https://forums.interworx.com/u/quash)\ **Post date:** [March 26, 2026, 8:06pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/10 "2026-03-26T20:06:05Z")
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 ---
**Author:** ![IWorx-Jenna](https://forums.interworx.com/user_avatar/forums.interworx.com/iworx-jenna/32/41_2.png) [@IWorx-Jenna](https://forums.interworx.com/u/IWorx-Jenna)\ **Post date:** [March 27, 2026, 2:15pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/11 "2026-03-27T14:15:01Z")
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 ---
**Author:** ![IWorx-Jenna](https://forums.interworx.com/user_avatar/forums.interworx.com/iworx-jenna/32/41_2.png) [@IWorx-Jenna](https://forums.interworx.com/u/IWorx-Jenna)\ **Post date:** [May 12, 2026, 5:28pm UTC](https://forums.interworx.com/t/djbdns-vs-bind-1-9-xx-axfr-formerr/24023/12 "2026-05-12T17:28:37Z")
Hello– We pushed changes, today, that should resolve the issue that you are experiencing. They are currently in the Beta channel for InterWorx 8, which is available on EL8 and EL9: [Changelog — InterWorx documentation](https://appendix.interworx.com/current/changelog/index.html#version-8-2-14-build-3237-beta) Barring any bugs logged against them, these changes should reach the Release channel in two weeks–around May 25th. Unfortunately, since CentOS 7 is no longer supported, and InterWorx 7 has reached Maintenance Only status (which means that it will no longer receive feature updates, just security ones), these changes cannot be applied to your current, server. You will need to migrate to a supported environment. If you would like a demo key to help facilitate the migration, just let us know at [support.interworx.com](http://support.interworx.com). Thanks, -Jenna