<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hello List,</p>
<p>I recently upgraded from Deb12 to Deb 13 and thereby from bind 9.18.33-1deb to 9.20.11-4deb. <br />While in former version everything was running as expected I observed a (to me) strange behavior between bind9.20.11-4-deb and Windows Server 2016, Version 1607 Build: 14393.8148 running as Domain Controler.</p>
<p>In short, DC as primary, bind9 as secondary. Transfer fails with:</p>
<p><br />25-Aug-2025 07:06:46.519 xfer-in: debug 10: 0x7fbd93256000: transfer of '245.10.in-addr.arpa/IN/dmz.stp' from 10.245.33.20#53: dns_message_parse: unexpected end of input<br />25-Aug-2025 07:06:46.519 xfer-in: error: 0x7fbd93256000: transfer of '245.10.in-addr.arpa/IN/dmz.stp' from 10.245.33.20#53: failed while receiving responses: unexpected end of input<br />25-Aug-2025 07:06:46.519 xfer-in: debug 1: zone 245.10.in-addr.arpa/IN/dmz.stp: zone transfer finished: unexpected end of input<br />25-Aug-2025 07:06:46.519 general: debug 1: queue_soa_query: zone 245.10.in-addr.arpa/IN/dmz.stp: enter<br />25-Aug-2025 07:06:46.519 xfer-in: info: 0x7fbd93256000: transfer of '245.10.in-addr.arpa/IN/dmz.stp' from 10.245.33.20#53: Transfer status: unexpected end of input<br />25-Aug-2025 07:06:46.519 xfer-in: info: 0x7fbd93256000: transfer of '245.10.in-addr.arpa/IN/dmz.stp' from 10.245.33.20#53: Transfer completed: 1 messages, 338 records, 16330 bytes, 0.007 secs (2332857 bytes/sec) (serial 58483)<br />25-Aug-2025 07:06:46.519 database: debug 1: called qpzone_destroy(245.10.in-addr.arpa)</p>
<p>the 245.10.in-addr.arpa zone has over 1300 entries, no secondary file is created.</p>
<p>After some digging I suspected EDNS, so I added server 10.245.33.20 { edns no; }; to my bind config. AXFR are now working again. Another observation hinting toward EDNS Problems is:</p>
<p>#> dig @10.245.33.20 axfr 245.10.in-addr.arpa</p>
<p>[....]<br />58.20.245.10.in-addr.arpa. 3600 IN PTR portal-proxy01.example.com.<br />59.20.245.10.in-addr.arpa. 3600 IN PTR portal-proxy02.example.com.<br />61.20.245.10.in-addr.arpa. 3600 IN PTR nextcloud01.example.com.<br />62.20.245.10.in-addr.arpa. 3600 IN PTR nextcloud02.example.com.<br />72.20.245.10.in-addr.arpa. 3600 IN PTR stage-mupro.example.com.<br />;; Got bad packet: extra input data<br />16347 bytes<br />d7 7c 80 80 00 01 01 38 00 00 00 00 03 32 34 35 .|.....8.....245<br />02 31 30 07 69 6e 2d 61 64 64 72 04 61 72 70 61 .10.in-addr.arpa<br />00 00 fc 00 01 02 37 32 02 32 30 c0 0c 00 0c 00 ......72.20.....<br />01 00 00 0e 10 00 23 11 74 65 73 74 2d 70 6f 72 ......#.test-por<br />74 61 6c 2d 69 61 6d 30 31 0b 73 74 xx xx xx xx tal-iam01.exampl<br />75 6e 6b 74 65 03 61 72 64 00 02 37 33 02 32 30 e.com.xxx..73.20<br />[....]</p>
<p>dig @10.245.33.20 axfr 245.10.in-addr.arpa +noedns delivers the expected output.</p>
<p>Not sure which other impacts might occur without EDNS. We’re not running DNSSEC therefore I hope I'm ok for now, so basically just to let you know and curious if anyone else see the same behavior and maybe has a better solution (i know, get rid of Win...;-) )</p>
<p>Oh, this is not only between bind and our own DC, also between our bind and a customer DNS running on Windows (Win dns).</p>
<p>Greets,<br />Daniel</p>
<div id="signature">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><span class="sig">-- <br />Anything that is unrelated to elephants is irrelephant.</span></div>
</div>
</body></html>