Hello List,
I recently upgraded from Deb12 to Deb 13 and thereby from bind
9.18.33-1deb to 9.20.11-4deb.
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.
In short, DC as primary, bind9 as secondary. Transfer fails with:
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
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
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
25-Aug-2025 07:06:46.519 general: debug 1: queue_soa_query: zone
245.10.in-addr.arpa/IN/dmz.stp: enter
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
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)
25-Aug-2025 07:06:46.519 database: debug 1: called
qpzone_destroy(245.10.in-addr.arpa)
the 245.10.in-addr.arpa zone has over 1300 entries, no secondary file is
created.
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:
#> dig @10.245.33.20 axfr 245.10.in-addr.arpa
[....]
58.20.245.10.in-addr.arpa. 3600 IN PTR
portal-proxy01.example.com.
59.20.245.10.in-addr.arpa. 3600 IN PTR
portal-proxy02.example.com.
61.20.245.10.in-addr.arpa. 3600 IN PTR nextcloud01.example.com.
62.20.245.10.in-addr.arpa. 3600 IN PTR nextcloud02.example.com.
72.20.245.10.in-addr.arpa. 3600 IN PTR stage-mupro.example.com.
;; Got bad packet: extra input data
16347 bytes
d7 7c 80 80 00 01 01 38 00 00 00 00 03 32 34 35
.|.....8.....245
02 31 30 07 69 6e 2d 61 64 64 72 04 61 72 70 61
.10.in-addr.arpa
00 00 fc 00 01 02 37 32 02 32 30 c0 0c 00 0c 00
......72.20.....
01 00 00 0e 10 00 23 11 74 65 73 74 2d 70 6f 72
......#.test-por
74 61 6c 2d 69 61 6d 30 31 0b 73 74 xx xx xx xx
tal-iam01.exampl
75 6e 6b 74 65 03 61 72 64 00 02 37 33 02 32 30
e.com.xxx..73.20
[....]
dig @10.245.33.20 axfr 245.10.in-addr.arpa +noedns delivers the expected
output.
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...;-) )
Oh, this is not only between bind and our own DC, also between our bind
and a customer DNS running on Windows (Win dns).
Greets,
Daniel
--
Anything that is unrelated to elephants is irrelephant.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
