Re: BIND 9.20.4 exiting

Ondřej Surý Wed, 18 Dec 2024 05:51:40 -0800

Hi Guillaume,

thanks for reading the instructions. I’m afraid you’ve hit a bug and filling an issue would be appropriate in this case.

I also think that Klaus (in Cc) seen similar crash.

We would appreciate if you can provide coredump and binaries with debug symbols.

Ondrej

Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

On 18. 12. 2024, at 14:00, Guillaume Bibaut <guillaume.bib...@gmail.com> wrote:

Hello,

I'm posting here because it is recommended there
https://gitlab.isc.org/isc-projects/bind9/-/issues/new
to post on this list before posting issues on gitlab.

I'm using bind 9.20 for a professional DNS service in my company (redacted).
Our DNS services are working fine with version 9.20.2 of BIND.
Last week-end, we updated the FreeBSD package from 9.20.2 to 9.20.4.
Today, as we were using our services just as usual, both our primary and secondary DNS services exited after some of our CI executed an update on removing some CNAME used while developing. We are using nsupdate with some key to update the DNS securely.
We are using FreeBSD 14.1-RELEASE-p3, and the "latest" packages repository so that our BIND services are always up to date.
I had to rollback to the previous packages, so from 9.20.4 to 9.20.2.
Everything was working well before and since we updated to 9.20.2.

FreeBSD latest port and package for bind920:
https://www.freshports.org/dns/bind920/

https://dnssec-analyzer.verisignlabs.com/ and https://dnsviz.net/ both tell that our sub domain dev.example.com is well configured for DNSSEC (no errors).

Our log looks like this when it exited, I had to redact the log because I do not want company informations to get disclosed.

>>>SNIP<<
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub1.subsub.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub2.subsub.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub3.subsub.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub1.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub3.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub4.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.fichier.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub2.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub5.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub6.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub7.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: client @0x17a2c0e9c00 62.4.5.16#55188/key dev3.cname: updating zone 'dev.example.com/IN': deleting rrset at 'branch.sub8.dev.example.com' CNAME
Dec 18 10:45:13 mail named[3615]: zone dev.example.com/IN (signed): sending notifies (serial 2024095766)
Dec 18 10:45:13 mail named[3615]: zone dev.example.com/IN (signed): sending notify to SECONDARY_1_IP#53
Dec 18 10:45:13 mail named[3615]: zone dev.example.com/IN (signed): sending notify to REGISTRAR_SECONDARY_IP#53
Dec 18 10:45:13 mail named[3615]: client @0x17a2bd41400 SECONDARY_1_IP#16894 (dev.example.com): transfer of 'dev.example.com/IN': IXFR started (serial 2024095765 -> 2024095766)
Dec 18 10:45:13 mail named[3615]: client @0x17a2bd41400 SECONDARY_1_IP#16894 (dev.example.com): transfer of 'dev.example.com/IN': IXFR ended: 2 messages, 102 records, 18757 bytes, 0.034 secs (551676 bytes/sec) (serial 2024095766)
Dec 18 10:45:13 mail named[3615]: client @0x17a28824c00 SECONDARY_1_IP#64952: received notify for zone 'dev.example.com'
Dec 18 10:45:31 mail named[3615]: client @0x17a2cf7c400 172.217.41.209#33339 (BRanCH.sUB1.DeV.ExAmpLE.CoM): expected a exact match NSEC3, got a covering record
Dec 18 10:45:31 mail named[3615]: ../../lib/dns/include/dns/name.h:1013: REQUIRE(suffixlabels <= name->labels) failed
Dec 18 10:45:31 mail named[3615]: 0x23f15b <main+0x191b> at /usr/local/sbin/named
Dec 18 10:45:31 mail named[3615]: 0x82182c66a <isc_assertion_failed+0xa> at /usr/local/lib/libisc-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234d7922 <ns_query_start+0x7ee2> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234de122 <ns_query_start+0xe6e2> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234d3c37 <ns_query_start+0x41f7> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234d1c01 <ns_query_start+0x21c1> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234cd952 <ns_query_done+0x18f2> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234cbe13 <ns__query_start+0x453> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234d04f3 <ns_query_start+0xab3> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234d01f3 <ns_query_start+0x7b3> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234c445c <ns__client_setup+0x1c4c> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x8234c2650 <ns_client_request+0x630> at /usr/local/lib/libns-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x821816c4f <isc__nm_readcb+0xcf> at /usr/local/lib/libisc-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x82182b30b <isc__nm_udp_read_cb+0x21b> at /usr/local/lib/libisc-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x826b56947 <uv_tty_get_vterm_state+0x1547> at /usr/local/lib/libuv.so.1
Dec 18 10:45:31 mail named[3615]: 0x826b58c53 <uv_cpu_info+0xd83> at /usr/local/lib/libuv.so.1
Dec 18 10:45:31 mail named[3615]: 0x826b46dc0 <uv_run+0x1b0> at /usr/local/lib/libuv.so.1
Dec 18 10:45:31 mail named[3615]: 0x8218404d2 <isc_loopmgr_run+0x2f2> at /usr/local/lib/libisc-9.20.4.so
Dec 18 10:45:31 mail named[3615]: 0x821851053 <isc_thread_create+0x223> at /usr/local/lib/libisc-9.20.4.so
Dec 18 10:45:31 mail named[3615]: exiting (due to assertion failure)
>>>SNIP<<<

Our dns configuration is, redacted as well:
>>>SNIP<<<
options {
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";

listen-on { PRIMARY_IP; 127.0.0.1; };

disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

forwarders {
HOSTING_DNS1_IP;
HOSTING_DNS2_IP;
};

forward only;

query-source address *;

notify explicit;
auth-nxdomain no;
allow-recursion {
127.0.0.1;
SECONDARY_IP;
REGISTAR_SECONDARY_QUERY_IP;
REGISTRAR_SECONDARY_UPDATE_IP;
};
allow-recursion-on {
127.0.0.1;

SECONDARY_IP;
REGISTAR_SECONDARY_QUERY_IP;
REGISTRAR_SECONDARY_UPDATE_IP;
};

allow-query-cache { none; };

rate-limit {
responses-per-second 7;
exempt-clients {
127.0.0.1;

          SECONDARY_IP;
          REGISTAR_SECONDARY_QUERY_IP;

          HOSTING_DNS1_IP;
          HOSTING_DNS2_IP;
};
};

dnssec-validation yes;
rrset-order { order cyclic; };
version "unknown";
};
[...SNIP...]
dnssec-policy "company" {
keys {
ksk lifetime unlimited algorithm RSASHA256 2048;
zsk lifetime unlimited algorithm RSASHA256 2048;
};
nsec3param;
};
[...SNIP...]
zone "dev.example.com" {
type primary;
key-directory "/usr/local/etc/namedb/keys";
update-policy {
grant local-ddns zonesub any;
grant certbot.dev. wildcard *.dev.example.com. txt;
grant dev.cname. wildcard *.dev.example.com. cname;
};
dnssec-policy "company";
inline-signing yes;
file "/usr/local/etc/namedb/primary/dev.example.com";
allow-query {
any;
};
allow-transfer {

SECONDARY_IP;
REGISTRAR_SECONDARY_UPDATE_IP;
};
also-notify {

SECONDARY_IP;
REGISTRAR_SECONDARY_UPDATE_IP;
};
};
>>>SNIP<<

I can't find what could be wrong in our configuration since it's been working for more than 2 years.
Is there anything to do?
Should I post this problem as an issue in gitlab?

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

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

Re: BIND 9.20.4 exiting

Reply via email to