ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-25T05:26:23Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4653Are Application-layer Loop DoS Attacks relevant for bind9?2024-03-25T05:26:23ZPetr MenšíkAre Application-layer Loop DoS Attacks relevant for bind9?A new document were shared to me from our security team:
<<redacted>>
They are mentioning DNS, but it seems to be not a problem for any well behaving DNS server. Have you seen this paper already? Do you have already some stance for desc...A new document were shared to me from our security team:
<<redacted>>
They are mentioning DNS, but it seems to be not a problem for any well behaving DNS server. Have you seen this paper already? Do you have already some stance for described attacks? To me it seems this should not affect any well behaving resolver or its client.
Have you already assessed this kind of attack, whether it is relevant on bind9 in any well configured instance?
Can you confirm whether this strange thing is known to be relevant or irelevant to bind9 versions?https://gitlab.isc.org/isc-projects/kea/-/issues/3303db-delay with reservations database "imagines" database connection2024-03-22T21:44:42ZMarcin Godzinadb-delay with reservations database "imagines" database connectionAfter kea#3300 fix, there is still a problem left:
When using the reservations database, Kea detects that there is no database and states that it is the first of 5 retries.
Then reports `database connection lost` and immediately reports ...After kea#3300 fix, there is still a problem left:
When using the reservations database, Kea detects that there is no database and states that it is the first of 5 retries.
Then reports `database connection lost` and immediately reports `database connection recovered.` (line 35 in log) (but the database is shut down) and proceeds like it has a database (so it serves traffic, etc.)
reproducable on v4, v6, MySQL and postgr
[kea-dhcp4.conf](/uploads/8ab1eb9ca661f49dba54190969c1d532/kea-dhcp4.conf)
[kea.log](/uploads/1016f040cd96d876517feb57fe8e342b/kea.log)kea2.5.7Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/3307Changes for Kea 2.5.7 release2024-03-22T15:55:28ZMarcin GodzinaChanges for Kea 2.5.7 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.5.7Marcin GodzinaMarcin Godzina2024-03-27https://gitlab.isc.org/isc-projects/kea/-/issues/3306Changes for Kea 2.5.7 release2024-03-22T15:26:13ZMarcin GodzinaChanges for Kea 2.5.7 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.5.72024-03-27https://gitlab.isc.org/isc-projects/kea/-/issues/3304bump up lib versions for 2.5.72024-03-22T14:53:31ZRazvan Becheriubump up lib versions for 2.5.7kea2.5.7Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2692Hook service must start before the first packet.2024-03-22T14:46:14ZFrancis DupontHook service must start before the first packet.We have a general issue with hooks starting services by a post to the server IO service as this is IO service is polled so the services started after the first packet processing.
I suggest to add a poll at the end of loadConfigFile in c...We have a general issue with hooks starting services by a post to the server IO service as this is IO service is polled so the services started after the first packet processing.
I suggest to add a poll at the end of loadConfigFile in ctrl_dhcp[46]_srv.cc to catch late issues e.g. bad configuration detected when the service is launched.
Hooks using deferred start: HA, LQ and soon RADIUS.kea2.5.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3300Database connection retry/delay causes infinite loop2024-03-22T14:22:46ZMarcin GodzinaDatabase connection retry/delay causes infinite loopThis MR that started it: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2238
db_retry_legallog and db_retry_reservation system tests are failing - Kea goes into an indefinite loop trying to reconnect to the database without de...This MR that started it: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2238
db_retry_legallog and db_retry_reservation system tests are failing - Kea goes into an indefinite loop trying to reconnect to the database without delay
(Failing Tests on Jenkins https://jenkins.aws.isc.org/job/kea-dev/job/tarball-system-tests/1168/)
A problem appears when retrying the connection to reservation or legallog db. At first glance, the lease db connection is unaffected.
Config to reproduce (of course, change paths. You do not have to change the DB setting - there should be no DB running to connect to)
[kea-dhcp4.conf](/uploads/72df474f98af62208baeeb6b618a4c54/kea-dhcp4.conf)
Part of the Log from the test
[kea__1_.log](/uploads/f4297c0cf1520f4cee7f6b9f6da0a0d3/kea__1_.log)kea2.5.7Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3079Process: Fix issues reported by dependabot2024-03-22T13:55:21ZTomek MrugalskiProcess: Fix issues reported by dependabot[Dependabot on github](https://github.com/isc-projects/kea/security/dependabot) reports 4 issues and complains that updates are disabled, because previous reports were not addressed.
![Screenshot_from_2023-09-21_11-34-35](/uploads/d6025...[Dependabot on github](https://github.com/isc-projects/kea/security/dependabot) reports 4 issues and complains that updates are disabled, because previous reports were not addressed.
![Screenshot_from_2023-09-21_11-34-35](/uploads/d602529e436a9edff8387c2c120a0e2c/Screenshot_from_2023-09-21_11-34-35.png)
The goal is to:
- [ ] update the dependencies
- [ ] make sure the PRs on github are resolved
- [ ] make sure the dependabot updates are no longer pausedkea2.5.7Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3266status-get command must return an HA relationship identifier2024-03-22T13:17:40ZMarcin Siodelskistatus-get command must return an HA relationship identifierWe now support the hub-and-spoke setup with multiple relationships in one server. The HA state can be retrieved using the `status-get` command. The problem is, though, that the `status-get` result lacks an association between returned lo...We now support the hub-and-spoke setup with multiple relationships in one server. The HA state can be retrieved using the `status-get` command. The problem is, though, that the `status-get` result lacks an association between returned local/remote entries and the configured relationships. It makes it nearly impossible to match the returned statuses with the relationships we maintain in the Stork database. The status-get response must return identifiers of the HA relationships to enable this matching.kea2.5.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4436nsupdate segfaults in tsiggss on FreeBSD 142024-03-22T12:19:44ZMichal Nowaknsupdate segfaults in tsiggss on FreeBSD 14`nsupdate` segfaults in the `tsiggss` system test on FreeBSD 14.0 on ~"v9.18" and ~"v9.16".
Here's a first crash in the system test. There are several more crashes afterward.
```
2023-11-15 12:20:53,799 INFO:tsiggss I:tsiggss_tm...`nsupdate` segfaults in the `tsiggss` system test on FreeBSD 14.0 on ~"v9.18" and ~"v9.16".
Here's a first crash in the system test. There are several more crashes afterward.
```
2023-11-15 12:20:53,799 INFO:tsiggss I:tsiggss_tmp_dk09tbmf:testing updates to testdc1 as administrator (1)
2023-11-15 12:20:53,800 INFO:tsiggss I:tsiggss_tmp_dk09tbmf:testing update for testdc1.example.nil. A 86400 A 10.53.0.10
2023-11-15 12:20:53,840 INFO:tsiggss Segmentation fault (core dumped)
2023-11-15 12:20:53,841 INFO:tsiggss I:tsiggss_tmp_dk09tbmf:update failed for testdc1.example.nil. A 86400 A 10.53.0.10
2023-11-15 12:20:53,841 INFO:tsiggss I:Reply from SOA query:
2023-11-15 12:20:53,841 INFO:tsiggss I:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47069
2023-11-15 12:20:53,842 INFO:tsiggss I:;; flags: qr aa; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
2023-11-15 12:20:53,842 INFO:tsiggss I:;; QUESTION SECTION:
2023-11-15 12:20:53,842 INFO:tsiggss I:;testdc1.example.nil. IN SOA
2023-11-15 12:20:53,842 INFO:tsiggss I:
2023-11-15 12:20:53,842 INFO:tsiggss I:;; AUTHORITY SECTION:
2023-11-15 12:20:53,842 INFO:tsiggss I:example.nil. 0 IN SOA blu.example.nil. hostmaster.example.nil. 2010113027 172800 14400 3628800 604800
2023-11-15 12:20:53,842 INFO:tsiggss I:
2023-11-15 12:20:53,842 INFO:tsiggss I:Found zone name: example.nil
2023-11-15 12:20:53,842 INFO:tsiggss I:The primary is: blu.example.nil
2023-11-15 12:20:53,843 INFO:tsiggss I:start_gssrequest
2023-11-15 12:20:53,843 INFO:tsiggss I:Found realm from ticket: EXAMPLE.NIL
2023-11-15 12:20:53,843 INFO:tsiggss I:tsiggss_tmp_dk09tbmf:failed
```
Sample `nsupdate` backtrace:
```
Core was generated by `/root/bind9/bin/nsupdate/.libs/nsupdate -g -d ns1/update.txt'.
Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
#0 0x00000008316a1a0f in EVP_Cipher () from /lib/libcrypto.so.30
[Current thread is 1 (LWP 188477)]
#0 0x00000008316a1a0f in EVP_Cipher () from /lib/libcrypto.so.30
#1 0x000000082e96f4b6 in ?? () from /usr/lib/libkrb5.so.11
#2 0x000000082e973ac8 in krb5_encrypt_ivec () from /usr/lib/libkrb5.so.11
#3 0x000000082e973de5 in krb5_encrypt () from /usr/lib/libkrb5.so.11
#4 0x000000082e9675bf in _krb5_build_authenticator () from /usr/lib/libkrb5.so.11
#5 0x000000082dcff3f6 in ?? () from /usr/lib/libgssapi_krb5.so.10
#6 0x000000082dcfed0b in _gsskrb5_init_sec_context () from /usr/lib/libgssapi_krb5.so.10
#7 0x000000082d95bd4f in gss_init_sec_context () from /usr/lib/libgssapi.so.10
#8 0x000000083ed613b6 in ?? () from /usr/lib/libgssapi_spnego.so.10
#9 0x000000083ed5f5c0 in _gss_spnego_indicate_mechtypelist () from /usr/lib/libgssapi_spnego.so.10
#10 0x000000083ed607ee in _gss_spnego_init_sec_context () from /usr/lib/libgssapi_spnego.so.10
#11 0x000000082d95bd4f in gss_init_sec_context () from /usr/lib/libgssapi.so.10
#12 0x0000000822a308e5 in dst_gssapi_initctx (name=<optimized out>, intoken=intoken@entry=0x0, outtoken=outtoken@entry=0x83d56d700, gssctx=0x83d56e218, mctx=0x1aef866b3000, err_message=0x83d56e200) at gssapictx.c
#13 0x0000000822b0c9af in dns_tkey_buildgssquery (msg=0x1aef87203a80, name=0x2130e0 <fkname>, gname=0x1aef87234300, gname@entry=0x83d56d7a0, intoken=0x1aef872700f0, intoken@entry=0x0, lifetime=lifetime@entry=0, context=0xcf, context@entry=0x83d56e218, win2k=<optimized out>, mctx=0x1aef866b3000, err_message=0x83d56e200) at tkey.c
#14 0x000000000020e790 in start_gssrequest (primary=primary@entry=0x83d56e730) at nsupdate.c
#15 0x000000000020e33c in recvsoa (task=<optimized out>, event=0x0) at nsupdate.c
#16 0x0000000821c68370 in task_run (task=0x1aef8665c140) at task.c
#17 isc_task_run (task=0x1aef8665c140) at task.c
#18 0x0000000821c38689 in isc__nm_async_task (worker=worker@entry=0x1aef866d0000, ev0=0x1aef872700f0, ev0@entry=0x1aef8721c480) at netmgr/netmgr.c
#19 0x0000000821c32ec6 in process_netievent (worker=worker@entry=0x1aef866d0000, ievent=ievent@entry=0x1aef8721c480) at netmgr/netmgr.c
#20 0x0000000821c384f2 in process_queue (worker=worker@entry=0x1aef866d0000, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c
#21 0x0000000821c2e6bd in process_all_queues (worker=0x1aef866d0000) at netmgr/netmgr.c
#22 async_cb (handle=0x1aef866d02d8) at netmgr/netmgr.c
#23 0x0000000829b3c871 in ?? () from /usr/local/lib/libuv.so.1
#24 0x0000000829b4e0fd in ?? () from /usr/local/lib/libuv.so.1
#25 0x0000000829b3ce60 in uv_run () from /usr/local/lib/libuv.so.1
#26 0x0000000821c2e7ab in nm_thread (worker0=0x1aef866d0000) at netmgr/netmgr.c
#27 0x0000000821c70e46 in isc__trampoline_run (arg=0x1aef8662bb90) at trampoline.c
#28 0x00000008376e0a75 in ?? () from /lib/libthr.so.3
#29 0x0000000000000000 in ?? ()
```
```
BIND 9.18.21-dev (Extended Support Version) <id:ed78bc4>
running on FreeBSD amd64 14.0-RC2 FreeBSD 14.0-RC2 #0 releng/14.0-n265317-1d2ff5639925: Fri Oct 20 06:17:03 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
built by make with '--disable-maintainer-mode' '--enable-developer' '--enable-option-checking=fatal' '--enable-dnstap' '--with-cmocka' '--with-libxml2' '--with-json-c' '--with-readline=libedit'
compiled by CLANG FreeBSD Clang 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152)
compiled with OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.46.0
linked to libuv version: 1.46.0
compiled with libnghttp2 version: 1.57.0
linked to libnghttp2 version: 1.57.0
compiled with libxml2 version: 2.10.4
linked to libxml2 version: 21004
compiled with json-c version: 0.17
linked to json-c version: 0.17
compiled with zlib version: 1.3
linked to zlib version: 1.3
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
geoip-directory: /usr/local/share/GeoIP
```
```
checking for krb5-config... /usr/bin/krb5-config
checking for gssapi libraries... -I/usr/include -L/usr/lib -lgssapi -lgssapi_krb5 -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lwind -lheimbase -lroken -lcrypt -pthread
checking for gssapi/gssapi.h... yes
checking for gssapi/gssapi_krb5.h... yes
checking for gssapi_krb5.h... no
checking for gss_acquire_cred... yes
checking for krb5 libraries... -I/usr/include -L/usr/lib -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lwind -lheimbase -lroken -lcrypt -pthread
checking for krb5/krb5.h... no
checking for krb5.h... yes
checking for krb5_init_context... yes
```
[pytest.log.txt](/uploads/ca1a092b91023024d1c3215295837dd2/pytest.log.txt)
[core.43134-backtrace.txt](/uploads/dab5cd198e0e09345030257576a91602/core.43134-backtrace.txt)
[core.43041-backtrace.txt](/uploads/f40e49e3120623d207cd0ed5b8e93d0b/core.43041-backtrace.txt)
[core.44009-backtrace.txt](/uploads/c7c66927be73250c875443cdb6c70802/core.44009-backtrace.txt)
[core.43922-backtrace.txt](/uploads/e82cfe048701645b83c74af46773e7e1/core.43922-backtrace.txt)
[core.43252-backtrace.txt](/uploads/fdfe3109fd5b13b2f9b06f22ce0da585/core.43252-backtrace.txt)
[core.43094-backtrace.txt](/uploads/9c4a6c1e2e03753c9e71cbb5b7465ff8/core.43094-backtrace.txt)
[core.42986-backtrace.txt](/uploads/c964412aa69ad3fede8fb6cf8c9c1b5d/core.42986-backtrace.txt)
[core.42931-backtrace.txt](/uploads/6402826262a2210df3fc0bb39857813e/core.42931-backtrace.txt)
[nsupdate.out6](/uploads/bdda0082ecfb34190cec4e83a9c3f1d1/nsupdate.out6)
[nsupdate.out5](/uploads/df1a9bbff55030ce6093fea3750f08f0/nsupdate.out5)
[nsupdate.out8](/uploads/58f94412f56d2136472a3305f1b0f573/nsupdate.out8)
[nsupdate.out7](/uploads/28aa35d4d517296581d05630cae16b7d/nsupdate.out7)
[nsupdate.out4](/uploads/9ec2300228db0bf43e29609b88bfef9a/nsupdate.out4)
[nsupdate.out3](/uploads/4fcbf78e8cb9e5a356618123d0e97941/nsupdate.out3)
[nsupdate.out2](/uploads/46b5c9ce602f9bb99cb1673e72ab879d/nsupdate.out2)
[nsupdate.out11](/uploads/cb41ad3685b8d0f31315a5da05308044/nsupdate.out11)
[nsupdate.out10](/uploads/c1f8cbe2f93700b395ee9547658c66cd/nsupdate.out10)
[nsupdate.out1](/uploads/f77767f9b3e2d067f15bc1b121bd56cf/nsupdate.out1)December 2023 (9.18.21, 9.18.21-S1, 9.19.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2188Bug in message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) fa...2024-03-22T08:14:06ZFstarkBug in message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed, back trace
```
test@test:~/bind9/collect$ ./dns_message_parse_fuzzer id\:000000\,sig\:06\,src\:002736+001626\,time\:192782276\,op\:splice\,rep\:128
INFO: Seed: 1666455395
INFO: Loaded 1 modules (61310 inline 8-bit counters): 61310 [0x100d2b0, 0x101c22e),
INFO: Loaded 1 PC tables (61310 PCs): 61310 [0x101c230,0x110ba10),
./dns_message_parse_fuzzer: Running 1 inputs 1 time(s) each.
Running: id:000000,sig:06,src:002736+001626,time:192782276,op:splice,rep:128
message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed, back trace
./dns_message_parse_fuzzer() [0xab474a]
./dns_message_parse_fuzzer() [0xab43d0]
./dns_message_parse_fuzzer() [0xab422a]
./dns_message_parse_fuzzer() [0x566c5f]
./dns_message_parse_fuzzer() [0x566da7]
./dns_message_parse_fuzzer() [0x551bc4]
./dns_message_parse_fuzzer() [0x550f98]
./dns_message_parse_fuzzer() [0x45a0c2]
./dns_message_parse_fuzzer() [0x445843]
./dns_message_parse_fuzzer() [0x44b89f]
./dns_message_parse_fuzzer() [0x473213]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f0090f5eb97]
./dns_message_parse_fuzzer() [0x41fed9]
==23768== ERROR: libFuzzer: deadly signal
#0 0x527611 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
#1 0x472a38 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
#2 0x458b63 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:232:3
#3 0x7f009196489f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1289f)
#4 0x7f0090f7bf46 in __libc_signal_restore_set /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:80
#5 0x7f0090f7bf46 in gsignal /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:48
#6 0x7f0090f7d8b0 in abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:79
#7 0xab4233 in isc_assertion_failed /src/bind9/lib/isc/assertions.c:47:2
#8 0x566c5e in msgreset /src/bind9/lib/dns/message.c:673:2
#9 0x566da6 in dns_message_destroy /src/bind9/lib/dns/message.c:801:2
#10 0x551bc3 in render_message /src/bind9/fuzz/dns_message_parse.c:131:2
#11 0x550f97 in LLVMFuzzerTestOneInput /src/bind9/fuzz/dns_message_parse.c:162:11
#12 0x45a0c1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:558:15
#13 0x445842 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:296:6
#14 0x44b89e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:796:9
#15 0x473212 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
#16 0x7f0090f5eb96 in __libc_start_main /build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:310
#17 0x41fed8 in _start (/home/test/bind9/collect/dns_message_parse_fuzzer+0x41fed8)
NOTE: libFuzzer has rudimentary signal handlers.
Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
```
### BIND version used
master-git
### Steps to reproduce
./fuzzer POC
[bind9.zip](/uploads/58bf9e655b37622954937535b1e69bd6/bind9.zip)
### What is the current *bug* behavior?
crash
### Relevant logs and/or screenshots
File in zip
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/3267some option headers are missing in libkea dhcp include HEADERS2024-03-21T16:16:53ZPiotrek Zadrogasome option headers are missing in libkea dhcp include HEADERSSome options' headers are missing in `libkea_dhcp___include_HEADERS` in `src/lib/dhcp/Makefile.am`.
This results in those header missing in `isc-kea-dev` packages or under `include/kea/dhcp` path when kea built and installed from tarbal...Some options' headers are missing in `libkea_dhcp___include_HEADERS` in `src/lib/dhcp/Makefile.am`.
This results in those header missing in `isc-kea-dev` packages or under `include/kea/dhcp` path when kea built and installed from tarballs/sources.
Maybe this could be checked as part of release process?kea2.5.7Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/bind9/-/issues/1565"autosign" system test still fails occasionally due to apparent randomness is...2024-03-21T15:29:42ZMichał Kępień"autosign" system test still fails occasionally due to apparent randomness issuesThe `autosign` system test still [fails occasionally][1] due to the number of daily categories into which signature expiration times are divided is not high enough (4, which is less than the required minimum of 5):
```
I:autosign:checki...The `autosign` system test still [fails occasionally][1] due to the number of daily categories into which signature expiration times are divided is not high enough (4, which is less than the required minimum of 5):
```
I:autosign:checking expired signatures were jittered correctly (13)
I:autosign:404 20200121
I:autosign:202 20200123
I:autosign:599 20200124
I:autosign:405 20200125
I:autosign:error: not enough categories
I:autosign:failed
```
We should investigate our options here to prevent this test from failing as it is happening too often to just gloss over it. Assuming nothing is wrong with the implementation itself (or the test code checking the number of categories), we should either further lower the minimum required number of categories or ignore this issue completely - otherwise we are going to develop a bad reflex of ignoring all failures of this test.
[1]: https://gitlab.isc.org/isc-private/bind9/-/jobs/572751April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4247Autosign resigning too fast after dnssec-settime calls2024-03-21T15:29:09ZMark AndrewsAutosign resigning too fast after dnssec-settime callsJob [#3570991](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3570991) failed for ce1db0017ee498c3c9e0d632b83113a344d25dda:
I've seen autosign fail in the ZSK roll test several times and it appears to be because dnssec-signzone is bei...Job [#3570991](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3570991) failed for ce1db0017ee498c3c9e0d632b83113a344d25dda:
I've seen autosign fail in the ZSK roll test several times and it appears to be because dnssec-signzone is being called in the same second as dnssec-settime. dnssec-signzone uses the phase `is set and is in the past` as the determinant of when things change. Should this be made `is set and is now or in the past`? Which behaviour is consistent with named's behaviour? Which behaviour is less error prone? If we don't change the behaviour we need to add sleeps to ensure the tests succeed.
```
-S This option enables smart signing, which instructs dnssec-signzone to search the key repository for keys that match the zone
being signed, and to include them in the zone if appropriate.
When a key is found, its timing metadata is examined to determine how it should be used, according to the following rules.
Each successive rule takes priority over the prior ones:
If no timing metadata has been set for the key, the key is published in the zone and used to sign the zone.
If the key's publication date is set and is in the past, the key is published in the zone.
If the key's activation date is set and is in the past, the key is published (regardless of publication date) and used to
sign the zone.
If the key's revocation date is set and is in the past, and the key is published, then the key is revoked, and the revoked
key is used to sign the zone.
If either the key's unpublication or deletion date is set and in the past, the key is NOT published or used to sign the
zone, regardless of any other metadata.
If the key's sync publication date is set and is in the past, synchronization records (type CDS and/or CDNSKEY) are
created.
If the key's sync deletion date is set and is in the past, synchronization records (type CDS and/or CDNSKEY) are removed.
```
```
2023-08-08 00:59:52 INFO:autosign I:autosign_tmp_x_6wkr8z:preparing ZSK roll
2023-08-08 00:59:52 INFO:autosign I:autosign_tmp_x_6wkr8z:ns1 A zone reload and thaw was started.
2023-08-08 00:59:52 INFO:autosign I:autosign_tmp_x_6wkr8z:ns1 Check the logs to see the result.
2023-08-08 00:59:56 INFO:autosign I:autosign_tmp_x_6wkr8z:revoking key to duplicated key ID
2023-08-08 00:59:56 INFO:autosign dnssec-settime: warning: Permissions on the file ns2/Kbar.+013+59973.private have changed from 0644 to 0600 as a result of this operation.
2023-08-08 00:59:56 INFO:autosign I:autosign_tmp_x_6wkr8z:ns2 A zone reload and thaw was started.
2023-08-08 00:59:56 INFO:autosign I:autosign_tmp_x_6wkr8z:ns2 Check the logs to see the result.
2023-08-08 00:59:56 INFO:autosign I:autosign_tmp_x_6wkr8z:waiting for changes to take effect
2023-08-08 01:00:01 INFO:autosign I:autosign_tmp_x_6wkr8z:checking former standby key 5259 is now active (53)
2023-08-08 01:00:01 INFO:autosign I:autosign_tmp_x_6wkr8z:failed
```
```
echo_i "preparing ZSK roll"
starttime=$($PERL -e 'print time(), "\n";')
oldfile=$(cat active.key)
oldid=$(keyfile_to_key_id "$(cat active.key)")
newfile=$(cat standby.key)
newid=$(keyfile_to_key_id "$(cat standby.key)")
$SETTIME -K ns1 -I now -D now+25 $oldfile > settime.out.test$n.1 || ret=1
$SETTIME -K ns1 -i 0 -S $oldfile $newfile > settime.out.test$n.2 || ret=1
# note previous zone serial number
oldserial=$($DIG $DIGOPTS +short soa . @10.53.0.1 | awk '{print $3}')
($RNDCCMD 10.53.0.1 freeze . 2>&1 | sed 's/^/ns1 /' | cat_i) || ret=1
cp ns1/root.db.signed ns1/root.db.1
$SIGNER -S -o . -O full -K ns1 -f ns1/root.db.signed ns1/root.db.1 > signing.root.out$n 2>&1 || ret=1
($RNDCCMD 10.53.0.1 thaw . 2>&1 | sed 's/^/ns1 /' | cat_i) || ret=1
sleep 4
echo_i "revoking key to duplicated key ID"
$SETTIME -R now -K ns2 Kbar.+013+59973.key > settime.out.test$n.3 || ret=1
($RNDCCMD 10.53.0.2 freeze bar. 2>&1 | sed 's/^/ns2 /' | cat_i) || ret=1
cp ns2/bar.db.signed ns2/bar.db
$SIGNER -S -o bar. -O full -K ns2 ns2/bar.db > signing.bar.out$n 2>&1 || ret=1
($RNDCCMD 10.53.0.2 thaw bar. 2>&1 | sed 's/^/ns2 /' | cat_i) || ret=1
echo_i "waiting for changes to take effect"
sleep 5
echo_i "checking former standby key $newid is now active ($n)"
ret=0
$DIG $DIGOPTS dnskey . @10.53.0.1 > dig.out.ns1.test$n || ret=1
grep 'RRSIG.*'" $newid "'\. ' dig.out.ns1.test$n > /dev/null || ret=1
n=$((n + 1))
if [ $ret != 0 ]; then echo_i "failed"; fi
status=$((status + ret))
```
```
08-Aug-2023 00:59:52.469 allocate new control connection
08-Aug-2023 00:59:52.469 received control channel command 'freeze .'
08-Aug-2023 00:59:52.469 loop exclusive mode: starting
08-Aug-2023 00:59:52.469 loop exclusive mode: started
08-Aug-2023 00:59:52.469 zone_dump: zone ./IN: enter
08-Aug-2023 00:59:52.469 loop exclusive mode: ending
08-Aug-2023 00:59:52.469 loop exclusive mode: ended
08-Aug-2023 00:59:52.469 freezing zone './IN': success
08-Aug-2023 00:59:52.469 freeing control connection
08-Aug-2023 00:59:52.497 dump_done: zone ./IN: enter
08-Aug-2023 00:59:52.497 zone_journal_compact: zone ./IN: target journal size 7662
08-Aug-2023 00:59:52.497 zone ./IN: dns_journal_compact: success
08-Aug-2023 00:59:52.509 allocate new control connection
08-Aug-2023 00:59:52.509 received control channel command 'thaw .'
08-Aug-2023 00:59:52.509 loop exclusive mode: starting
08-Aug-2023 00:59:52.509 loop exclusive mode: started
08-Aug-2023 00:59:52.509 zone ./IN: starting load
08-Aug-2023 00:59:52.509 zone_startload: zone ./IN: enter
08-Aug-2023 00:59:52.509 loop exclusive mode: ending
08-Aug-2023 00:59:52.509 loop exclusive mode: ended
08-Aug-2023 00:59:52.509 thawing zone './IN': success
08-Aug-2023 00:59:52.509 freeing control connection
08-Aug-2023 00:59:52.509 zone_loaddone: zone ./IN: enter
08-Aug-2023 00:59:52.509 zone ./IN: number of nodes in database: 5
08-Aug-2023 00:59:52.509 zone ./IN: loaded; checking validity
08-Aug-2023 00:59:52.509 dns_zone_verifydb: zone ./IN: enter
08-Aug-2023 00:59:52.509 zone ./IN: zone serial (2000042101) unchanged. zone may fail to transfer to secondaries.
08-Aug-2023 00:59:52.509 zone ./IN: replacing zone database
08-Aug-2023 00:59:52.509 calling free_rbtdb(.)
08-Aug-2023 00:59:52.509 done free_rbtdb(.)
08-Aug-2023 00:59:52.509 zone ./IN: loaded serial 2000042101 (DNSSEC signed)
08-Aug-2023 00:59:52.509 zone_postload: zone ./IN: done
08-Aug-2023 00:59:52.509 zone__settimer: zone ./IN: enter
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/kea/-/issues/3292kea 2.4.x: make install fails with python 3.122024-03-21T14:57:02ZNatanael Copakea 2.4.x: make install fails with python 3.12kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bi...kea 2.4.1 fails to `make install` with python 3.12:
```
...
make[4]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[5]: Entering directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/bin/mkdir -p '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
/usr/bin/install -c kea-shell '/home/ncopa/aports/main/kea/pkg/kea/usr/sbin'
/usr/bin/install -c -m 644 kea_conn.py kea_connector3.py '/home/ncopa/aports/main/kea/pkg/kea/usr/lib/python3.12/site-packages/kea'
Traceback (most recent call last):
File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'imp'
make[5]: *** [Makefile:528: install-pkgpythonPYTHON] Error 1
make[5]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[4]: *** [Makefile:740: install-am] Error 2
make[4]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[3]: *** [Makefile:577: install-recursive] Error 1
make[3]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin/shell'
make[2]: *** [Makefile:464: install-recursive] Error 1
make[2]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src/bin'
make[1]: *** [Makefile:462: install-recursive] Error 1
make[1]: Leaving directory '/home/ncopa/aports/main/kea/src/kea-2.4.1/src'
make: *** [Makefile:649: install-recursive] Error 1
```
From https://docs.python.org/3/whatsnew/3.12.html
> The asynchat, asyncore, and imp modules have been removed, along with several unittest.TestCase method aliases.https://gitlab.isc.org/isc-projects/kea/-/issues/2478Documentation - how to migrate from ISC dhcp to Kea2024-03-21T14:43:40ZPeter DaviesDocumentation - how to migrate from ISC dhcp to KeaDocumentation - how to migrate from ISC dhcp to Kea.
Add a section to the ARM describing migration strategiesfrom ISC dhcp to Kea.
This could contain:
a) A short description of the differences between ISC dhcp and Kea.
b) kea...Documentation - how to migrate from ISC dhcp to Kea.
Add a section to the ARM describing migration strategiesfrom ISC dhcp to Kea.
This could contain:
a) A short description of the differences between ISC dhcp and Kea.
b) keama introduction
c) Where can I find keama?
d) https://kb.isc.org/docs/migrating-from-isc-dhcp-to-kea-dhcp-using-the-migration-assistant
d) link to https://kb.isc.org/docs/kea-migration-assistant
e) What cannot be migrated with keama
(this need to be fleshed out)next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4648pytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.py2024-03-21T12:09:20ZMark Andrewspytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.pyJob [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in...Job [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in _call_runtest_hook
INTERNALERROR> reraise = (runner.Exit,)
INTERNALERROR> AttributeError: module '_pytest.runner' has no attribute 'Exit'
INTERNALERROR> Traceback (most recent call last):
```https://gitlab.isc.org/isc-projects/kea/-/issues/3262add RADIUS thread pool and make the RADIUS library MT-compatible2024-03-21T11:52:04ZAndrei Pavelandrei@isc.orgadd RADIUS thread pool and make the RADIUS library MT-compatibleRADIUS access is now asynchronous, but it is still single-threaded. To truly benefit from multi-threading, it needs its own thread pool.
There might also be some MT-specific races and bugs that need to be fixed. TBDRADIUS access is now asynchronous, but it is still single-threaded. To truly benefit from multi-threading, it needs its own thread pool.
There might also be some MT-specific races and bugs that need to be fixed. TBDkea2.5.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4591TTL-based cache cleaning in rbtdb ineffective (M/N problem)2024-03-20T13:50:45ZOndřej SurýTTL-based cache cleaning in rbtdb ineffective (M/N problem)Copying stuff from MatterMost for permanent record:
How it started?
> @ondrej: But I don't know actually - if there's something blocking the top of the heap to be cleaned up (dunno why yet), it could block cleaning everything else behin...Copying stuff from MatterMost for permanent record:
How it started?
> @ondrej: But I don't know actually - if there's something blocking the top of the heap to be cleaned up (dunno why yet), it could block cleaning everything else behind it
So, here's a summary of our finding
The TTL based cleaning is opportunistic. When we are inserting a new node, we look at the top of the heap ("list sorted by TTL-value") and if TTL of the top of the heap is expired, we try to eradicate the data it stores from the cache. The code that decides whether we will do the TTL-based cleaning looks like this:
```c
header = isc_heap_element(rbtdb->heaps[rbtnode->locknum], 1);
if (header != NULL) {
dns_ttl_t rdh_ttl = header->rdh_ttl;
/* Only account for stale TTL if cache is not overmem */
if (!cache_is_overmem) {
rdh_ttl += STALE_TTL(header, rbtdb);
}
if (rdh_ttl < now - RBTDB_VIRTUAL) {
expire_header(rbtdb, header, tree_locked,
expire_ttl);
}
}
```
Now, the RBTDB_VIRTUAL is this:
```
/*
* Allow clients with a virtual time of up to 5 minutes in the past to see
* records that would have otherwise have expired.
*/
#define RBTDB_VIRTUAL 300
```
Which means that even with 0 TTL records, the TTL-based cleaning will not kick-in until 5 minutes has passed.
Now what happens if you insert N records (where N could be large) within the first 5 minutes (cold bootstrap)?
After 5 minutes the TTL based cleaning should kick-in, but that's only if everything in the cache has expired, but even with that.
If we insert M records in the next minute, only M records will gets cleaned at maximum.
But anything that has longer TTL will just add to N, so the backlog of the records that are not subject to the TTL-based cleaning will build up over time until we are overmem and LRU based cleaning kicks in.
Additionally, @ondrej found out that there are records with `rdh_ttl` set to `0` if you just run `dnsperf` on a cold cache resolver, which made us puzzled - shouldn't we be cleaning records only after 5 minutes?
@michal did some excellent work and found out following:
so, i looked at those "zero TTL" frees that happen very shortly into the start of regular resolver operation
turns out that these are "superseded" headers
now, i don't understand why RBTDB does that. but it's this branch in add32() that expires these headers: https://gitlab.isc.org/isc-projects/bind9/-/blob/8fb49c5a8acdb37d4f4be0c5f5b19645d0103f48/lib/dns/rbtdb.c#L6677-6714
basically, AFAICT, what happens here is:
resolver: hey, RBTDB, add this shiny new SOA rdataset header to the cache
RBTDB: oh okay, let me see if i have a SOA header on that node already...
RBTDB: yup, got one. i'll just expire the one i had in there before (topheader) and insert the new one you gave me (newheader).
what i don't understand is why it just doesn't leave that old (identical, AFAICT) rdataset intact. but i'll move on with the reasoning for now.
so, the "previously-topmost" SOA header has its TTL set to zero, so it lands on the top of one of the TTL heaps
once we add a new rdataset, it should be cleaned up. but, as we already established yesterday, that only happens if the reference count of its node is zero.
meanwhile, in my very basic test (literally seconds into firing up dnsperf with the query set we use for respdiff tests, at some 1 kQPS), those rdatasets at the top of the heap are for nodes like net. or com. whose reference counts are around 60, or maybe 80 references. and until that count goes to zero, the first rdataset on the TTL heap will not disappear from there, blocking any rdataset headers on the same TTL heap from being cleaned up as well (backlog)
so, i thought "how bad is it and can we measure it?" and oh, boy, he could:
```
20-Feb-2024 10:46:29.561 connection refused resolving 'geo.fortinet.net/NS/IN': 104.198.248.186#53
20-Feb-2024 10:46:29.564 DNS format error from 203.205.195.75#53 resolving ns3.qq.com/AAAA for <unknown>: Name qq.com (SOA) not subdomain of zone ns3.qq.com -- invalid response
20-Feb-2024 10:46:29.564 FORMERR resolving 'ns3.qq.com/AAAA/IN': 203.205.195.75#53
20-Feb-2024 10:46:29.564 DNS format error from 108.136.87.44#53 resolving api.cloud.huawei.com/AAAA for 127.0.0.1#34840: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
20-Feb-2024 10:46:29.564 FORMERR resolving 'api.cloud.huawei.com/AAAA/IN': 108.136.87.44#53
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 106 msecs since expiry
-- 106 msecs since expiry
-- 29 msecs since expiry
-- 29 msecs since expiry
20-Feb-2024 10:46:29.574 success resolving 'a.karma.sc2.fsapi.com/A' after disabling qname minimization due to 'ncache nxdomain'
-- 243 msecs since expiry
-- 246 msecs since expiry
-- 249 msecs since expiry
-- 433 msecs since expiry
-- 806 msecs since expiry
-- 813 msecs since expiry
-- 243 msecs since expiry
-- 246 msecs since expiry
-- 249 msecs since expiry
-- 433 msecs since expiry
-- 806 msecs since expiry
-- 0 msecs since expiry
-- 816 msecs since expiry
-- 816 msecs since expiry
-- 123 msecs since expiry
-- 323 msecs since expiry
-- 123 msecs since expiry
-- 323 msecs since expiry
20-Feb-2024 10:46:29.601 success resolving 'F00DCFRIBM41.zf.if.atcsg.net/A' after disabling qname minimization due to 'ncache nxdomain'
20-Feb-2024 10:46:29.624 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 47.118.199.194#53
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:29.677 DNS format error from 3.97.163.50#53 resolving api.cloud.huawei.com/AAAA for 127.0.0.1#34840: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
20-Feb-2024 10:46:29.677 FORMERR resolving 'api.cloud.huawei.com/AAAA/IN': 3.97.163.50#53
-- 6 msecs since expiry
-- 3 msecs since expiry
-- 9 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:29.801 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.33#53
-- 3 msecs since expiry
-- 3 msecs since expiry
-- 46 msecs since expiry
-- 19 msecs since expiry
-- 0 msecs since expiry
-- 39 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 3 msecs since expiry
-- 3 msecs since expiry
-- 126 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:30.104 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 139.224.142.104#53
-- 286 msecs since expiry
-- 0 msecs since expiry
-- 69 msecs since expiry
-- 13 msecs since expiry
20-Feb-2024 10:46:30.307 success resolving 'hcdnd.csfw.c.cdnhwc6.com/AAAA' after disabling qname minimization due to 'ncache nxdomain'
-- 0 msecs since expiry
-- 199 msecs since expiry
-- 269 msecs since expiry
-- 656 msecs since expiry
-- 689 msecs since expiry
-- 746 msecs since expiry
-- 789 msecs since expiry
-- 816 msecs since expiry
-- 819 msecs since expiry
-- 819 msecs since expiry
-- 839 msecs since expiry
-- 853 msecs since expiry
-- 873 msecs since expiry
-- 876 msecs since expiry
-- 889 msecs since expiry
-- 896 msecs since expiry
-- 896 msecs since expiry
-- 916 msecs since expiry
-- 936 msecs since expiry
-- 956 msecs since expiry
-- 969 msecs since expiry
-- 979 msecs since expiry
-- 983 msecs since expiry
-- 999 msecs since expiry
-- 999 msecs since expiry
-- 1006 msecs since expiry
-- 1006 msecs since expiry
-- 1053 msecs since expiry
-- 1053 msecs since expiry
-- 1063 msecs since expiry
-- 1066 msecs since expiry
-- 1073 msecs since expiry
-- 1079 msecs since expiry
-- 1083 msecs since expiry
-- 1089 msecs since expiry
-- 1096 msecs since expiry
-- 1133 msecs since expiry
-- 1139 msecs since expiry
-- 1156 msecs since expiry
-- 1163 msecs since expiry
-- 1166 msecs since expiry
-- 1179 msecs since expiry
-- 1183 msecs since expiry
-- 1189 msecs since expiry
-- 1193 msecs since expiry
-- 1196 msecs since expiry
-- 1199 msecs since expiry
-- 1223 msecs since expiry
-- 1223 msecs since expiry
-- 1249 msecs since expiry
-- 1259 msecs since expiry
-- 1276 msecs since expiry
-- 1293 msecs since expiry
-- 1336 msecs since expiry
-- 1363 msecs since expiry
-- 1369 msecs since expiry
-- 1379 msecs since expiry
-- 1393 msecs since expiry
-- 1396 msecs since expiry
-- 1399 msecs since expiry
-- 1403 msecs since expiry
-- 1423 msecs since expiry
-- 1429 msecs since expiry
-- 1436 msecs since expiry
-- 1436 msecs since expiry
-- 1439 msecs since expiry
-- 1446 msecs since expiry
-- 1446 msecs since expiry
-- 1466 msecs since expiry
-- 1466 msecs since expiry
-- 1469 msecs since expiry
-- 1473 msecs since expiry
-- 1486 msecs since expiry
-- 1503 msecs since expiry
-- 1506 msecs since expiry
-- 1516 msecs since expiry
-- 1539 msecs since expiry
-- 1539 msecs since expiry
-- 1556 msecs since expiry
-- 1566 msecs since expiry
-- 1569 msecs since expiry
-- 1589 msecs since expiry
-- 1623 msecs since expiry
-- 1623 msecs since expiry
-- 1629 msecs since expiry
-- 1636 msecs since expiry
-- 1636 msecs since expiry
-- 1649 msecs since expiry
-- 1679 msecs since expiry
-- 1686 msecs since expiry
-- 1703 msecs since expiry
-- 1703 msecs since expiry
-- 1716 msecs since expiry
-- 1726 msecs since expiry
-- 1736 msecs since expiry
-- 1773 msecs since expiry
-- 1796 msecs since expiry
-- 1796 msecs since expiry
-- 1799 msecs since expiry
-- 1803 msecs since expiry
-- 1829 msecs since expiry
-- 1839 msecs since expiry
-- 1876 msecs since expiry
-- 1879 msecs since expiry
-- 1883 msecs since expiry
-- 1889 msecs since expiry
-- 1889 msecs since expiry
-- 1889 msecs since expiry
-- 1899 msecs since expiry
-- 1946 msecs since expiry
-- 1956 msecs since expiry
-- 1983 msecs since expiry
-- 2013 msecs since expiry
-- 2013 msecs since expiry
-- 2023 msecs since expiry
-- 2049 msecs since expiry
-- 2059 msecs since expiry
-- 2063 msecs since expiry
-- 2079 msecs since expiry
-- 2106 msecs since expiry
-- 2109 msecs since expiry
-- 2119 msecs since expiry
-- 2136 msecs since expiry
-- 2156 msecs since expiry
-- 2183 msecs since expiry
-- 2199 msecs since expiry
-- 2203 msecs since expiry
-- 2219 msecs since expiry
-- 2223 msecs since expiry
-- 2229 msecs since expiry
-- 2243 msecs since expiry
-- 2253 msecs since expiry
-- 2263 msecs since expiry
-- 2286 msecs since expiry
-- 2303 msecs since expiry
-- 2343 msecs since expiry
-- 2356 msecs since expiry
-- 2376 msecs since expiry
-- 2376 msecs since expiry
-- 2379 msecs since expiry
-- 2386 msecs since expiry
-- 2416 msecs since expiry
-- 2426 msecs since expiry
-- 2433 msecs since expiry
-- 2449 msecs since expiry
-- 2466 msecs since expiry
-- 2479 msecs since expiry
-- 2509 msecs since expiry
-- 2516 msecs since expiry
-- 2523 msecs since expiry
-- 2529 msecs since expiry
-- 2536 msecs since expiry
-- 2539 msecs since expiry
-- 2539 msecs since expiry
-- 2543 msecs since expiry
-- 2553 msecs since expiry
-- 2559 msecs since expiry
-- 2569 msecs since expiry
-- 2593 msecs since expiry
-- 2609 msecs since expiry
-- 2616 msecs since expiry
-- 2623 msecs since expiry
-- 2629 msecs since expiry
-- 2656 msecs since expiry
-- 2659 msecs since expiry
-- 2673 msecs since expiry
-- 2716 msecs since expiry
-- 2766 msecs since expiry
-- 2773 msecs since expiry
-- 2773 msecs since expiry
-- 2776 msecs since expiry
-- 2783 msecs since expiry
-- 2789 msecs since expiry
-- 2823 msecs since expiry
-- 2843 msecs since expiry
-- 2879 msecs since expiry
-- 2879 msecs since expiry
-- 2886 msecs since expiry
-- 2899 msecs since expiry
-- 2919 msecs since expiry
-- 2926 msecs since expiry
-- 2949 msecs since expiry
-- 2956 msecs since expiry
-- 2956 msecs since expiry
-- 2956 msecs since expiry
-- 2979 msecs since expiry
-- 2983 msecs since expiry
-- 2983 msecs since expiry
-- 2986 msecs since expiry
-- 3033 msecs since expiry
-- 3039 msecs since expiry
-- 3049 msecs since expiry
-- 3066 msecs since expiry
-- 3086 msecs since expiry
-- 3126 msecs since expiry
-- 3129 msecs since expiry
-- 3156 msecs since expiry
-- 3169 msecs since expiry
-- 3173 msecs since expiry
-- 3176 msecs since expiry
-- 3226 msecs since expiry
-- 3253 msecs since expiry
-- 3266 msecs since expiry
-- 3269 msecs since expiry
-- 3279 msecs since expiry
-- 3279 msecs since expiry
-- 3299 msecs since expiry
-- 3323 msecs since expiry
-- 3323 msecs since expiry
-- 3336 msecs since expiry
-- 3336 msecs since expiry
-- 3363 msecs since expiry
-- 3366 msecs since expiry
-- 3396 msecs since expiry
-- 3399 msecs since expiry
-- 3409 msecs since expiry
-- 3449 msecs since expiry
-- 3463 msecs since expiry
-- 3466 msecs since expiry
-- 3499 msecs since expiry
-- 0 msecs since expiry
-- 199 msecs since expiry
-- 269 msecs since expiry
-- 656 msecs since expiry
-- 689 msecs since expiry
-- 746 msecs since expiry
-- 789 msecs since expiry
-- 816 msecs since expiry
-- 819 msecs since expiry
-- 819 msecs since expiry
-- 839 msecs since expiry
-- 853 msecs since expiry
-- 873 msecs since expiry
-- 876 msecs since expiry
-- 889 msecs since expiry
-- 896 msecs since expiry
-- 896 msecs since expiry
-- 916 msecs since expiry
-- 936 msecs since expiry
-- 956 msecs since expiry
-- 969 msecs since expiry
-- 979 msecs since expiry
-- 983 msecs since expiry
-- 999 msecs since expiry
-- 999 msecs since expiry
-- 1006 msecs since expiry
-- 1006 msecs since expiry
-- 1053 msecs since expiry
-- 1053 msecs since expiry
-- 1063 msecs since expiry
-- 1066 msecs since expiry
-- 1073 msecs since expiry
-- 1079 msecs since expiry
-- 1083 msecs since expiry
-- 1089 msecs since expiry
-- 1096 msecs since expiry
-- 1133 msecs since expiry
-- 1139 msecs since expiry
-- 1156 msecs since expiry
-- 1163 msecs since expiry
-- 1166 msecs since expiry
-- 1179 msecs since expiry
-- 1183 msecs since expiry
-- 1189 msecs since expiry
-- 1196 msecs since expiry
-- 1199 msecs since expiry
-- 1203 msecs since expiry
-- 1226 msecs since expiry
-- 1226 msecs since expiry
-- 1253 msecs since expiry
-- 1263 msecs since expiry
-- 1279 msecs since expiry
-- 1296 msecs since expiry
-- 1339 msecs since expiry
-- 1366 msecs since expiry
-- 1373 msecs since expiry
-- 1383 msecs since expiry
-- 1396 msecs since expiry
-- 1399 msecs since expiry
-- 1403 msecs since expiry
-- 1406 msecs since expiry
-- 1426 msecs since expiry
-- 1433 msecs since expiry
-- 1439 msecs since expiry
-- 1439 msecs since expiry
-- 1443 msecs since expiry
-- 1449 msecs since expiry
-- 1449 msecs since expiry
-- 1469 msecs since expiry
-- 1469 msecs since expiry
-- 1473 msecs since expiry
-- 1476 msecs since expiry
-- 1489 msecs since expiry
-- 1506 msecs since expiry
-- 1509 msecs since expiry
-- 1519 msecs since expiry
-- 1543 msecs since expiry
-- 1543 msecs since expiry
-- 1559 msecs since expiry
-- 1569 msecs since expiry
-- 1573 msecs since expiry
-- 1593 msecs since expiry
-- 1626 msecs since expiry
-- 1626 msecs since expiry
-- 1633 msecs since expiry
-- 1639 msecs since expiry
-- 1639 msecs since expiry
-- 1653 msecs since expiry
-- 1683 msecs since expiry
-- 1689 msecs since expiry
-- 1706 msecs since expiry
-- 1706 msecs since expiry
-- 1719 msecs since expiry
-- 1729 msecs since expiry
-- 1739 msecs since expiry
-- 1776 msecs since expiry
-- 1799 msecs since expiry
-- 1799 msecs since expiry
-- 1803 msecs since expiry
-- 1806 msecs since expiry
-- 1833 msecs since expiry
-- 1843 msecs since expiry
-- 1879 msecs since expiry
-- 1883 msecs since expiry
-- 1886 msecs since expiry
-- 1893 msecs since expiry
-- 1893 msecs since expiry
-- 1893 msecs since expiry
-- 1903 msecs since expiry
-- 1949 msecs since expiry
-- 1959 msecs since expiry
-- 1986 msecs since expiry
-- 2016 msecs since expiry
-- 2016 msecs since expiry
-- 2026 msecs since expiry
-- 2053 msecs since expiry
-- 2063 msecs since expiry
-- 2066 msecs since expiry
-- 2083 msecs since expiry
-- 2109 msecs since expiry
-- 2113 msecs since expiry
-- 2123 msecs since expiry
-- 2139 msecs since expiry
-- 2159 msecs since expiry
-- 2186 msecs since expiry
-- 2203 msecs since expiry
-- 2206 msecs since expiry
-- 2223 msecs since expiry
-- 2226 msecs since expiry
-- 2233 msecs since expiry
-- 2246 msecs since expiry
-- 2256 msecs since expiry
-- 2266 msecs since expiry
-- 2289 msecs since expiry
-- 2306 msecs since expiry
-- 2346 msecs since expiry
-- 2359 msecs since expiry
-- 2379 msecs since expiry
-- 2379 msecs since expiry
-- 2383 msecs since expiry
-- 2389 msecs since expiry
-- 2419 msecs since expiry
-- 2429 msecs since expiry
-- 2436 msecs since expiry
-- 2453 msecs since expiry
-- 2469 msecs since expiry
-- 2483 msecs since expiry
-- 2513 msecs since expiry
-- 2519 msecs since expiry
-- 2526 msecs since expiry
-- 2533 msecs since expiry
-- 2539 msecs since expiry
-- 2543 msecs since expiry
-- 2543 msecs since expiry
-- 2546 msecs since expiry
-- 2556 msecs since expiry
-- 2563 msecs since expiry
-- 2573 msecs since expiry
-- 2596 msecs since expiry
-- 2613 msecs since expiry
-- 2619 msecs since expiry
-- 2626 msecs since expiry
-- 2633 msecs since expiry
-- 2659 msecs since expiry
-- 2663 msecs since expiry
-- 2676 msecs since expiry
-- 2719 msecs since expiry
-- 2769 msecs since expiry
-- 2776 msecs since expiry
-- 2776 msecs since expiry
-- 2779 msecs since expiry
-- 2786 msecs since expiry
-- 2793 msecs since expiry
-- 2826 msecs since expiry
-- 2846 msecs since expiry
-- 2883 msecs since expiry
-- 2883 msecs since expiry
-- 2889 msecs since expiry
-- 2903 msecs since expiry
-- 2923 msecs since expiry
-- 2929 msecs since expiry
-- 2956 msecs since expiry
-- 2959 msecs since expiry
-- 2959 msecs since expiry
-- 2959 msecs since expiry
-- 2983 msecs since expiry
-- 2986 msecs since expiry
-- 2986 msecs since expiry
-- 2989 msecs since expiry
-- 3036 msecs since expiry
-- 3043 msecs since expiry
-- 3053 msecs since expiry
-- 3069 msecs since expiry
-- 3089 msecs since expiry
-- 3129 msecs since expiry
-- 3133 msecs since expiry
-- 3159 msecs since expiry
-- 3173 msecs since expiry
-- 3176 msecs since expiry
-- 3179 msecs since expiry
-- 3229 msecs since expiry
-- 3256 msecs since expiry
-- 3269 msecs since expiry
-- 3273 msecs since expiry
-- 3283 msecs since expiry
-- 3283 msecs since expiry
-- 3303 msecs since expiry
-- 3326 msecs since expiry
-- 3326 msecs since expiry
-- 3339 msecs since expiry
-- 3339 msecs since expiry
-- 3366 msecs since expiry
-- 3369 msecs since expiry
-- 3399 msecs since expiry
-- 3403 msecs since expiry
-- 3413 msecs since expiry
-- 3453 msecs since expiry
-- 3466 msecs since expiry
-- 3469 msecs since expiry
-- 3 msecs since expiry
20-Feb-2024 10:46:30.324 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.53#53
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:30.524 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.32#53
-- 0 msecs since expiry
```
So, there are multiple issues circling around the TTL-based cleaning.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4413Add RESINFO (261) type to named2024-03-20T13:50:45ZMark AndrewsAdd RESINFO (261) type to namedIt's a singleton, TXT clone. https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/It's a singleton, TXT clone. https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Mark AndrewsMark Andrews