BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-28T10:46:36Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4606"dry-run" mode to help with dnssec-policy migration2024-02-28T10:46:36ZCarsten Strotmann"dry-run" mode to help with dnssec-policy migration### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC...### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC is good, there is currently no way to "verify" the new "dnssec-policy" configuration before enabling it. Experience has shown (in DNS training classes, but also in real world deployments) that there are many things that can go wrong:
- differences in the DNSSEC key configuration (old vs. new)
- file system permissions on the old key material
- file system location of the old key material
- issues with the time-events stored in the old key material
Going online with a slightly wrong configuration can cause an immediate key rollover, which might break the zone. Recovering from this situation is possible, but requires good knowledge of BIND 9 DNSSEC workings
### Request
Provide a "dnssec-policy dry-run" mode, where BIND 9 will log the next steps in the automatic DNSSEC management to the log files (e.g. category "DNSSEC"), but will not execute any changes to the DNSSEC signed zone or the key material. This will enable the user to test drive the new "dnssec-policy" to see if it will act as expected.
Admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active.
### Links / referencesMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4598statschannel test may fail due to a missing response2024-02-22T09:53:52ZTom Krizekstatschannel test may fail due to a missing response`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-project...`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999177) may fail with:
```
_______________________________ test_traffic_xml _______________________________
[gw2] linux -- Python 3.12.1 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_xml.py:134: in test_traffic_xml
generic.test_traffic(fetch_traffic_xml, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:211: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 6 diff: ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]) != ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4', [('16-31', 1)]),
E ('dns-tcp-requests-sizes-received-ipv6', []),
E ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6', []),
E ('dns-udp-requests-sizes-received-ipv4', [('32-47', 2)]),
E ('dns-udp-requests-sizes-received-ipv6', []),
E - ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)]),
E ? ----------------
E + ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]),
E ('dns-udp-responses-sizes-sent-ipv6', []),
E ]
```
```
______________________________ test_traffic_json _______________________________
[gw3] linux -- Python 3.11.2 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_json.py:104: in test_traffic_json
generic.test_traffic(fetch_traffic_json, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:229: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 2 diff: ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('96-111', 1)]) != ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4',
E [('16-31',
E 1),
E ('32-47',
E 2)]),
E ('dns-tcp-requests-sizes-received-ipv6',
E []),
E ('dns-tcp-responses-sizes-sent-ipv4',
E [('64-79',
E - 1),
E - ('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6',
E []),
E ('dns-udp-requests-sizes-received-ipv4',
E [('32-47',
E 2)]),
E ('dns-udp-requests-sizes-received-ipv6',
E []),
E ('dns-udp-responses-sizes-sent-ipv4',
E [('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-udp-responses-sizes-sent-ipv6',
E []),
E ]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4586Don't count expired / future RRSIGs in verification failure quota2024-02-24T08:17:15ZMark AndrewsDon't count expired / future RRSIGs in verification failure quotaExpired / future RRSIGs don't trigger a public key verification.Expired / future RRSIGs don't trigger a public key verification.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4554Signature expiration calculation backwards compatibility bug2024-02-24T07:53:48ZMatthijs Mekkingmatthijs@isc.orgSignature expiration calculation backwards compatibility bugThe `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `sig...The `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `signatures-validity - signatures-refresh`) which is wrong: it should be using a range of 0 to `signatures-refresh`.
The `sig-validity-interval` that was used for `auto-dnssec` defined two parameters, the first being the signatures validity (same as `dnssec-policy`'s `signatures-validity`), the optional second one being the minimum bound of the signatures validity. It also serves as a signatures refresh. Basically the refresh value is the difference between the first and second parameter.
So the second parameter actually has two meanings: It serves as a jitter and a refresh value.
With `dnssec-policy` there is not yet a way to define `jitter`. The `signatures-refresh` is actually defined as the.
Two things need to be done:
- [x] Add a configuration option to `dnssec-policy` to set desired jitter.
- [x] Ensure resign interval is used correctly.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4550Resolve license aggregation for "reuse lint"2024-02-07T16:19:55ZMichal NowakResolve license aggregation for "reuse lint"`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: Pen...`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: PendingDeprecationWarning: Copyright and licensing
information for 'COPYRIGHT' has been found in both 'COPYRIGHT' and in the DEP5 file located at '.reuse/dep5'.
The information for these two sources has been aggregated. In the future this behaviour will change, and you will
need to explicitly enable aggregation. See <https://github.com/fsfe/reuse-tool/issues/779>. You need do nothing
yet. Run with `--suppress-deprecation` to hide this warning.
...
```Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4517dnssec-verify reports errors in NSEC3 chain2024-02-24T07:53:57ZLibor Peltandnssec-verify reports errors in NSEC3 chain### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the f...### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Bad NSEC3 record for fadb1aa3f.6DA7ffbF, bit map mismatch
Expected and found NSEC3 chains not equal
Break in NSEC3 chain at: VKGD3TE5QRGB6S0KJH6UV3FKS9FUMRIV
Expected: 01EAMK8ES71TN6TKHOK512LQMCORC5O9
Found: 0R6S95GSLHH7HT7MFN2N1NJGNFS7Q2CQ
DNSSEC completeness test failed (failure).
```
I'd say that the NSEC3 chain is however correct.
Some notes:
- opt-out is not used
- `fadb1aa3f.6da7ffbf.` -> `01eamk8es71tn6tkhok512lqmcorc5o9.6da7ffbf.` (first NSEC3 lexicographically, but this probably doesnt care)
- `427e09.owa.6da7ffbf.` -> `vkgd3te5qrgb6s0kjh6uv3fks9fumriv.6da7ffbf.` (last NSEC3 lexicographically)
- node `fadb1aa3f.6da7ffbf.` is "weird" in the way that it's a delegation with non-authoritative data: MX and even DNSKEY(!), but this shouldn't influence the chaining of NSEC3, moreover, it relates to the bitmap at 01EAMK... and not VKGD3T...
### BIND version affected
```
$ dnssec-verify -V
dnssec-verify 9.18.18-0ubuntu0.22.04.1-Ubuntu
```
### Steps to reproduce
Use faketime as the RRSIGs are expired already. It doesn't matter since the errors are related to NSEC3s and not signatures.
The zone file in question is attached.
Just call `$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone`
### What is the current *bug* behavior?
Verify reports errors in the attached zone's NSEC3 chain.
### What is the expected *correct* behavior?
No errors reported.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4485Update httppicoparser2023-12-13T16:43:09ZOndřej SurýUpdate httppicoparserThis sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78This sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4475Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove2024-02-24T07:54:00ZMichal NowakData races in isc_buffer_peekuint8, rdataset_settrust, and memmoveJob [#3848477](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848477) failed for c4fcdbefc5ac65e62f8d16ba78737aa6174c9592.
There are three new types of TSAN errors in the failed `respdiff-long:tsan` CI job.
I did not happen [yesterd...Job [#3848477](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848477) failed for c4fcdbefc5ac65e62f8d16ba78737aa6174c9592.
There are three new types of TSAN errors in the failed `respdiff-long:tsan` CI job.
I did not happen [yesterday](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3843810) on 64ef6968f379fa220c2a2d76311705b4e248e286, so should this be caused by a new code, the only theoretically relevant MR is !8515.
```
WARNING: ThreadSanitizer: data race
Read of size 1 at 0x000000000001 by main thread:
#0 isc_buffer_peekuint8 ../../lib/isc/include/isc/buffer.h:847
#1 isc_buffer_getuint8 ../../lib/isc/include/isc/buffer.h:854
#2 dns_ncache_getsigrdataset lib/dns/ncache.c:630
#3 validate_ncache lib/dns/validator.c:2388
#4 validate_nx lib/dns/validator.c:2431
#5 validator_start lib/dns/validator.c:2994
#6 isc__async_cb lib/isc/async.c:111
#7 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#8 thread_body lib/isc/thread.c:85
#9 isc_thread_main lib/isc/thread.c:116
#10 isc_loopmgr_run lib/isc/loop.c:454
#11 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000001 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1015 at 0x000000000020 allocated by main thread:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 isc_thread_main lib/isc/thread.c:116
#16 isc_loopmgr_run lib/isc/loop.c:454
#17 main bin/named/main.c:1574
Thread T0001 'isc-loop-0002' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race ../../lib/isc/include/isc/buffer.h:847 in isc_buffer_peekuint8
```
```
WARNING: ThreadSanitizer: data race
Write of size 1 at 0x000000000001 by main thread:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 isc_thread_main lib/isc/thread.c:116
#9 isc_loopmgr_run lib/isc/loop.c:454
#10 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000001 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:202
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1015 at 0x000000000014 allocated by thread T0002:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 thread_run lib/isc/thread.c:100
Thread T0001 'isc-loop-0001' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
Thread T0002 'isc-loop-0002' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race lib/dns/ncache.c:499 in rdataset_settrust
```
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by main thread:
#0 memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810
#1 memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:808
#2 memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:36
#3 dns_name_fromregion lib/dns/name.c:739
#4 dns_ncache_current lib/dns/ncache.c:701
#5 validate_ncache lib/dns/validator.c:2382
#6 validate_nx lib/dns/validator.c:2431
#7 validator_start lib/dns/validator.c:2994
#8 isc__async_cb lib/isc/async.c:111
#9 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#10 thread_body lib/isc/thread.c:85
#11 isc_thread_main lib/isc/thread.c:116
#12 isc_loopmgr_run lib/isc/loop.c:454
#13 main bin/named/main.c:1574
Previous write of size 1 at 0x000000000014 by thread T0001:
#0 rdataset_settrust lib/dns/ncache.c:499
#1 dns_rdataset_settrust lib/dns/rdataset.c:597
#2 marksecure lib/dns/validator.c:200
#3 validate_answer lib/dns/validator.c:1528
#4 validator_start lib/dns/validator.c:2935
#5 isc__async_cb lib/isc/async.c:111
#6 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#7 thread_body lib/isc/thread.c:85
#8 thread_run lib/isc/thread.c:100
Location is heap block of size 1047 at 0x000000000021 allocated by thread T0001:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647
#1 mallocx lib/isc/jemalloc_shim.h:67
#2 mem_get lib/isc/mem.c:303
#3 isc__mem_get lib/isc/mem.c:675
#4 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:332
#5 dns__rbtdb_addrdataset lib/dns/rbtdb.c:3153
#6 dns__db_addrdataset lib/dns/db.c:681
#7 addoptout lib/dns/ncache.c:283
#8 dns_ncache_add lib/dns/ncache.c:103
#9 ncache_adderesult lib/dns/resolver.c:6358
#10 validated lib/dns/resolver.c:5385
#11 validator_done_cb lib/dns/validator.c:210
#12 isc__async_cb lib/isc/async.c:111
#13 uv__async_io /usr/src/libuv-v1.47.0/src/unix/async.c:176
#14 thread_body lib/isc/thread.c:85
#15 thread_run lib/isc/thread.c:100
Thread T0001 'isc-loop-0001' (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
#1 isc_thread_create lib/isc/thread.c:139
#2 isc_loopmgr_run lib/isc/loop.c:448
#3 main bin/named/main.c:1574
SUMMARY: ThreadSanitizer: data race /usr/include/x86_64-linux-gnu/bits/string_fortified.h:36 in memmove
```
I restarted the job, and this is a [reproducible issue](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3849392).May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4458dnssec auto fails across multiple views + unable to add/remove DS records fro...2023-12-04T05:39:28ZTom Shawdnssec auto fails across multiple views + unable to add/remove DS records from second view + invalid DS records### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view ...### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view fails to manage and purge old key/state/private files and these start to build up over time
- Unable to get DS records, publish CDS log entries stop appearing for the view
### BIND version used
BIND 9.18.20-1+ubuntu22.04.1+deb.sury.org+1-Ubuntu
### Steps to reproduce
Create a config which has two views, with the same domain in each view. One of the views must only be available to an internal ip range (internal), the other must be available from all (external). Enable dnssec on both domains in both views using separate policies.
### What is the current *bug* behavior?
- keys in the internal view will not be managed correctly and will build up over time
- nsupdate will appear to add/delete the DS records correctly but these are not added or deleted in bind.
### What is the expected *correct* behavior?
- keys in both views should be managed correctly
- nsupdate should be able to manipulate the DS records in the internal view
### Relevant configuration files
I will share my configs privately if possible
Use this yearly internal policy for TDL level domains
```
dnssec-policy "yearly-internal" {
keys {
ksk lifetime P365D algorithm ECDSAP384SHA384;
zsk lifetime P1D algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT5M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
Use this aggressive standard internal policy for sub domains
dnssec-policy "standard" {
keys {
ksk lifetime PT40M algorithm ECDSAP384SHA384;
zsk lifetime PT20M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl 60;
publish-safety PT2M;
retire-safety PT2M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl 300;
parent-ds-ttl 60;
parent-propagation-delay 60;
nsec3param iterations 10 optout no salt-length 16;
};
options {
check-names master ignore;
check-names slave ignore;
check-names response ignore;
masterfile-format text;
listen-on-v6 { none; };
listen-on port 53 { 127.0.0.1; 165.227.238.11; 10.0.254.1; 10.0.254.2; };
directory "/var/cache/bind";
auth-nxdomain no; # conform to RFC1035
querylog yes;
pid-file "/var/run/named/named.pid";
include "/etc/bind/named.options.transfer.conf";
# if running a natted server, set the public ip address here
# this will not work in a multihomed box (specifically linode fails)
# notify the NS servers - only on master
notify yes;
# some dnssec stuff
include "/etc/bind/named.options.dnssec.conf";
max-cache-size 10485760;
};
```
Zone file
```
#ns1.node.flipkick.media
zone "entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
#ns1.node.flipkick.media
zone "node.entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
```
### Relevant logs and/or screenshots
```
28-Nov-2023 12:58:02.305 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25339 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/53449 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/43625 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26195 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/33520 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26171 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/37281 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/7041 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/63692 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/9156 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/29571 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44364 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44662 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/40817 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/22890 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/64449 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/39830 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/30931 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/57355 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/23733 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25059 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/20634 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/2754 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/19617 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/61960 (KSK) is now inactive
```
### Possible fixes
Run two bind servers and attach to differing ipshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4453Switching to a different dnssec-policy broke my zone.2024-02-24T07:54:16ZBjörn PerssonSwitching to a different dnssec-policy broke my zone.### Summary
My zone was previously signed with a KSK and a ZSK with unlimited lifetime. I switched the zone over to a dnssec-policy using CSKs and automatic key rotation. After the DS record was updated, most of the RRSIG records were r...### Summary
My zone was previously signed with a KSK and a ZSK with unlimited lifetime. I switched the zone over to a dnssec-policy using CSKs and automatic key rotation. After the DS record was updated, most of the RRSIG records were removed, leaving the zone broken to validating resolvers.
### BIND version used
```
# named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
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: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
I have two zones that both exist in an external and an internal view. Each zone was previously signed with a KSK and a ZSK with unlimited lifetime. To proceed cautiously with the change to `dnssec-policy` I defined one policy that matched the existing keys and another that would use CSKs and automatic key rotation:
```
dnssec-policy "as_it_was" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
dnssec-policy "automation" {
keys {
csk lifetime P1M algorithm rsasha256 2048;
};
dnskey-ttl P1D;
max-zone-ttl P1D;
signatures-validity P1W;
signatures-refresh P2D;
};
```
First I switched the zones from "`auto-dnssec maintain;`" to "`dnssec-policy as_it_was;`". Bind continued using the existing keys. Once I had the exchange of CDS and DS records working between my zones and the parent zone, I switched one zone over to "`dnssec-policy automation;`" in both views.
The rollover from the old keys to a CSK seemed to go smoothly, but after a while I discovered that the zone was only partially signed in the external view. Several records lacked RRSIG records. Dynamic updates of the unsigned records caused corresponding RRSIG records to appear.
After that initial problem, the following rollover from one CSK to another worked fine, so I proceeded to switch the second zone over to "`dnssec-policy automation;`". This time I took notes and watched for missing signatures.
2023-11-18 16:05:49 a CSK was generated. DNSKEY, CDS and CDNSKEY were signed with both the old KSK and the CSK. SOA got a new signature by the old ZSK. All other records kept their existing signatures.
2023-11-19 17:10:49 CDS and CDNSKEY records for the CSK were published. DNSKEY, CDS and CDNSKEY got new signatures by the KSK and the CSK. SOA was signed with the ZSK and the CSK.
2023-11-20 17:10:49 Bind noticed that DS had been updated in the parent zone.
2023-11-20 18:15:49 the ZSK and all its signatures were removed. DNSKEY, CDS and CDNSKEY got new signatures by the CSK and the KSK. SOA got a new signature by the CSK. All other records were left without RRSIG records.
This time I fixed the external view with "`rndc sign xn--rombobjrn-67a.se IN external`". All the unsigned records were then signed with the CSK. DNSKEY, CDS, CDNSKEY and SOA had their signatures renewed. I left the internal view alone.
2023-11-21 19:10:50 the KSK was removed. DNSKEY, CDS, CDNSKEY and SOA got new signatures by the CSK. At the same time, many but not all other records in the internal view were finally signed with the CSK, having lacked signatures for 24 hours and 55 minutes. Some more records were signed a few minutes later.
As I'm posting this, one NS and one MX record in the internal view are still unsigned after more than four days.
### What is the current *bug* behavior?
The zone becomes only partially signed. Validating resolvers reject the unsigned records.
### What is the expected *correct* behavior?
All records should be signed with the new key before the old keys and signatures are removed.
### Relevant configuration files
See the policies above. After the changes, all the zone declarations look essentially like this:
```
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.external";
dnssec-policy automation;
parental-agents { ::1; };
inline-signing no;
update-policy { [omitted] };
};
```
### Relevant logs and/or screenshots
Excerpts from the system log:
```
2023-11-19T17:10:49.436468+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-19T17:10:49.437286+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-19T17:10:49.488666+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-19T17:10:49.489192+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-19T17:10:49.501444+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-19T17:10:49.502076+01:00 cutie named[443161]: CDS (SHA-256) for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.502515+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.502904+01:00 cutie named[443161]: CDS for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.503279+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.530343+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-19T17:10:49.530897+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-19T17:10:49.534298+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-19T17:10:49.534962+01:00 cutie named[443161]: CDS (SHA-256) for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.535337+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.535684+01:00 cutie named[443161]: CDS for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.536038+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.637732+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 19-Nov-2023 18:10:49.432
2023-11-19T17:10:49.638433+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092737)
2023-11-19T17:10:49.651717+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 19-Nov-2023 18:10:49.432
2023-11-19T17:10:49.673263+01:00 cutie named[443161]: client @0x7efdf9b21368 10.1.0.5#54619 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092736 -> 2023092737)
2023-11-19T17:10:49.674244+01:00 cutie named[443161]: client @0x7efdf9b21368 10.1.0.5#54619 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 23 records, 5465 bytes, 0.004 secs (1366250 bytes/sec) (serial 2023092737)
2023-11-19T17:10:50.192637+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.2.1#57043 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092736 -> 2023092737)
2023-11-19T17:10:50.193661+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.2.1#57043 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 23 records, 5465 bytes, 0.001 secs (5465000 bytes/sec) (serial 2023092737)
```
```
2023-11-20T17:10:49.472806+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T17:10:49.473891+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T17:10:49.525113+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.525655+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.529210+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.530341+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:10:49.466
2023-11-20T17:10:49.557565+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.558183+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.561418+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.562620+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:10:49.466
2023-11-20T17:10:49.617384+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/17339 seen published at Mon Nov 20 17:10:49 2023
2023-11-20T17:10:49.621343+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/53584 seen withdrawn at Mon Nov 20 17:10:49 2023
2023-11-20T17:10:49.624985+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T17:10:49.667546+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.668097+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.671602+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.672714+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:15:49.618
2023-11-20T17:10:50.027333+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/17339 seen published at Mon Nov 20 17:10:50 2023
2023-11-20T17:10:50.031352+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/53584 seen withdrawn at Mon Nov 20 17:10:50 2023
2023-11-20T17:10:50.035151+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T17:10:50.077904+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:50.078540+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:50.081828+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:50.083015+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:15:49.030
```
```
2023-11-20T18:15:49.036472+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T18:15:49.076389+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T18:15:49.077010+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T18:15:49.088905+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/13398/RSASHA256 from DNSKEY RRset.
2023-11-20T18:15:49.089406+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK) is now deleted
2023-11-20T18:15:49.089784+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T18:15:49.192756+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:20:49.033
2023-11-20T18:15:49.193416+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092738)
2023-11-20T18:15:49.275467+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#41397 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092737 -> 2023092739)
2023-11-20T18:15:49.278365+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#41397 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 3 messages, 128 records, 38648 bytes, 0.004 secs (9662000 bytes/sec) (serial 2023092739)
2023-11-20T18:15:49.622949+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T18:15:49.664238+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T18:15:49.664712+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T18:15:49.667624+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/13398/RSASHA256 from DNSKEY RRset.
2023-11-20T18:15:49.668019+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK) is now deleted
2023-11-20T18:15:49.668373+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T18:15:49.764336+01:00 cutie named[443161]: client @0x7efdebdc5168 10.1.2.1#58091 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092737 -> 2023092739)
2023-11-20T18:15:49.767341+01:00 cutie named[443161]: client @0x7efdebdc5168 10.1.2.1#58091 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 3 messages, 128 records, 38648 bytes, 0.004 secs (9662000 bytes/sec) (serial 2023092739)
2023-11-20T18:15:49.779256+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:20:49.621
2023-11-20T18:15:54.192437+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092739)
```
```
2023-11-21T13:15:40.402451+01:00 cutie named[443161]: received control channel command 'sign xn--rombobjrn-67a.se IN external'
2023-11-21T13:15:40.405362+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T13:15:40.431241+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T13:15:40.431697+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T13:15:40.433742+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-21T13:15:40.528574+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:10:50.395
2023-11-21T13:15:40.529172+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092740)
2023-11-21T13:15:40.773096+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#33623 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092739 -> 2023092742)
2023-11-21T13:15:40.774513+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#33623 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 46 records, 12419 bytes, 0.004 secs (3104750 bytes/sec) (serial 2023092742)
2023-11-21T13:15:41.172719+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#33203 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092739 -> 2023092745)
2023-11-21T13:15:41.174657+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#33203 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 89 records, 24907 bytes, 0.004 secs (6226750 bytes/sec) (serial 2023092745)
2023-11-21T13:15:45.528370+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092750)
2023-11-21T13:15:45.561710+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#52787 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092742 -> 2023092750)
2023-11-21T13:15:45.564494+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#52787 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 114 records, 31108 bytes, 0.004 secs (7777000 bytes/sec) (serial 2023092750)
2023-11-21T13:15:46.078928+01:00 cutie named[443161]: client @0x7efdfa51bd68 10.1.2.1#60701 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092745 -> 2023092750)
2023-11-21T13:15:46.080874+01:00 cutie named[443161]: client @0x7efdfa51bd68 10.1.2.1#60701 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 71 records, 18769 bytes, 0.001 secs (18769000 bytes/sec) (serial 2023092750)
```
```
2023-11-21T19:10:50.400377+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:10:50.432532+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:10:50.433038+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:10:50.443664+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/53584/RSASHA256 from DNSKEY RRset.
2023-11-21T19:10:50.444123+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now deleted
2023-11-21T19:10:50.511795+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:15:50.396
2023-11-21T19:10:50.512265+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092751)
2023-11-21T19:10:50.576696+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#54307 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092750 -> 2023092752)
2023-11-21T19:10:50.577645+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#54307 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 27 records, 5832 bytes, 0.001 secs (5832000 bytes/sec) (serial 2023092752)
2023-11-21T19:10:50.626991+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:10:50.660686+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:10:50.661150+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:10:50.663077+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/53584/RSASHA256 from DNSKEY RRset.
2023-11-21T19:10:50.663489+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now deleted
2023-11-21T19:10:50.738310+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:15:50.624
2023-11-21T19:10:51.191122+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#43631 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092750 -> 2023092752)
2023-11-21T19:10:51.191859+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#43631 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 27 records, 5832 bytes, 0.001 secs (5832000 bytes/sec) (serial 2023092752)
2023-11-21T19:10:55.511787+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092752)
2023-11-21T19:15:50.404325+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:15:50.427941+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:15:50.428397+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:15:50.440377+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:20:49.398
2023-11-21T19:15:50.630905+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:15:50.656580+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:15:50.657098+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:15:50.659929+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:20:49.626
2023-11-21T19:20:49.405293+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:20:49.429191+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:49.429646+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:49.438021+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:20:50.399
2023-11-21T19:20:49.630959+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:20:49.656677+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:49.657172+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:49.659897+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:20:50.627
2023-11-21T19:20:50.401138+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:20:50.427552+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:50.428010+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:50.434902+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 20:20:50.399
2023-11-21T19:20:50.629148+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:20:50.654607+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:50.655054+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:50.657686+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 20:20:50.627
```
Some possibly useful status data from when the zone lacked signatures:
```
# rndc dnssec -status xn--rombobjrn-67a.se IN external
dnssec-policy: automatik
current time: Tue Nov 21 12:57:26 2023
key: 17339 (RSASHA256), CSK
published: yes - since Sat Nov 18 16:05:49 2023
key signing: yes - since Sat Nov 18 16:05:49 2023
zone signing: yes - since Sat Nov 18 16:05:49 2023
Next rollover scheduled on Mon Dec 18 15:00:49 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- zone rrsig: omnipresent
- key rrsig: omnipresent
key: 13398 (RSASHA256), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- zone rrsig: unretentive
key: 53584 (RSASHA256), KSK
published: yes - since Sun Nov 3 04:26:07 2019
key signing: yes - since Sun Nov 3 04:26:07 2019
Rollover is due since Sun Nov 19 18:05:49 2023
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- key rrsig: omnipresent
# rndc zonestatus xn--rombobjrn-67a.se IN external
name: xn--rombobjrn-67a.se
type: primary
files: /var/lib/bind/db.xn--rombobjrn-67a.se.external
serial: 2023092739
nodes: 42
last loaded: Tue, 24 Oct 2023 12:43:57 GMT
secure: no
key maintenance: automatic
next key event: Tue, 21 Nov 2023 18:10:50 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```
The output of `rndc zonestatus` changed when I ran `rndc sign`:
```
# rndc zonestatus xn--rombobjrn-67a.se IN external
name: xn--rombobjrn-67a.se
type: primary
files: /var/lib/bind/db.xn--rombobjrn-67a.se.external
serial: 2023092750
nodes: 42
last loaded: Tue, 24 Oct 2023 12:43:57 GMT
secure: yes
inline signing: no
key maintenance: automatic
next key event: Tue, 21 Nov 2023 18:10:50 GMT
next resign node: 7c2ecd07f155648431e0f94b89247d713c5786e1e73e953f2fe7eca3._openpgpkey.xn--rombobjrn-67a.se/NSEC
next resign time: Wed, 22 Nov 2023 22:55:09 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4449too long CNAME chains do not elicit SERVFAIL or even log message2023-11-23T15:08:44ZPetr Špačekpspacek@isc.orgtoo long CNAME chains do not elicit SERVFAIL or even log message### Summary
CNAME chain length is currently limited to ~ 16 steps. Chains longer than this limit are cut short, but the RDCODE is still NOERROR. This creates impression that the final hop might be NODATA answer.
Also I can't see any lo...### Summary
CNAME chain length is currently limited to ~ 16 steps. Chains longer than this limit are cut short, but the RDCODE is still NOERROR. This creates impression that the final hop might be NODATA answer.
Also I can't see any log message in logs that resolution was terminated prematurely.
### BIND version used
* ~"Affects v9.19": a819d3644634997a78b162988156e90f409e1ce8
* ~"Affects v9.18": 6817bf1284fe8aea303365d2dd17bc5523e7a41b
* ~"Affects v9.16": 161d69aba357fa830bb6ef2b097b0447929041f0
* ~"Affects v9.11 (EoL)" : v9.11.37-S1
* Other versions were not tested
### Steps to reproduce
* Setup an auth zone with too long CNAME chain:
- [local.zone](/uploads/af4b4f699adb8b3bf87d5cac31b5d33f/local.zone)
- [named.conf](/uploads/2a0c44310bfbe99a2ffe6bbc1b36bacc/named.conf)
Query for it in default resolver config.
### What is the current *bug* behavior?
RCODE=NOERROR despite the incomplete CNAME chain.
```
$ dig c0000.local.testiscorg.ch. A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20544
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 102100bdc30994f717d0d76d655f5b7d3a1f039d04cd3a86 (good)
;; QUESTION SECTION:
;c0000.local.testiscorg.ch. IN A
;; ANSWER SECTION:
c0000.local.testiscorg.ch. 0 IN CNAME c0001.local.testiscorg.ch.
c0001.local.testiscorg.ch. 0 IN CNAME c0002.local.testiscorg.ch.
c0002.local.testiscorg.ch. 0 IN CNAME c0003.local.testiscorg.ch.
c0003.local.testiscorg.ch. 0 IN CNAME c0004.local.testiscorg.ch.
c0004.local.testiscorg.ch. 0 IN CNAME c0005.local.testiscorg.ch.
c0005.local.testiscorg.ch. 0 IN CNAME c0006.local.testiscorg.ch.
c0006.local.testiscorg.ch. 0 IN CNAME c0007.local.testiscorg.ch.
c0007.local.testiscorg.ch. 0 IN CNAME c0008.local.testiscorg.ch.
c0008.local.testiscorg.ch. 0 IN CNAME c0009.local.testiscorg.ch.
c0009.local.testiscorg.ch. 0 IN CNAME c0010.local.testiscorg.ch.
c0010.local.testiscorg.ch. 0 IN CNAME c0011.local.testiscorg.ch.
c0011.local.testiscorg.ch. 0 IN CNAME c0012.local.testiscorg.ch.
c0012.local.testiscorg.ch. 0 IN CNAME c0013.local.testiscorg.ch.
c0013.local.testiscorg.ch. 0 IN CNAME c0014.local.testiscorg.ch.
c0014.local.testiscorg.ch. 0 IN CNAME c0015.local.testiscorg.ch.
c0015.local.testiscorg.ch. 0 IN CNAME c0016.local.testiscorg.ch.
c0016.local.testiscorg.ch. 0 IN CNAME c0017.local.testiscorg.ch.
```
### What is the expected *correct* behavior?
Same output but SERVFAIL.
### Relevant logs and/or screenshots
There is no log message indicating that the chain was cut prematurely. Here's named log running at `-d 99` from the main branch: [named.log](/uploads/4e9e9f8c70bf4fbc187082914a4b06ac/named.log)
### Other implementations
- PowerDNS Recursor 4.9.1 SERVFAILs and cuts the chain on c0011
- Knot Resolver 5.7.0 SERVFAILs and cuts the chain on c0013
- Unbound 1.19.0 commit 197bf154 SERVFAILs and does not return anything in the ANSWER section. [PCAP](/uploads/abb00b0409388e4a5cedf867a934e9f7/dns.pcap) suggests it stops chasing after encountering c0011.https://gitlab.isc.org/isc-projects/bind9/-/issues/4423named starts up slow when many zones reference the same dnssec-policy2024-02-24T07:54:22ZMatthijs Mekkingmatthijs@isc.orgnamed starts up slow when many zones reference the same dnssec-policyWhile rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones af...While rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones after reload/reconfig and CPU usage of the named process remains at 100% and it takes quite a few minutes for named to start responding to queries after such a reload/reconfig request.
When spreading my zones to 10 identical policies, cpu usage goes well above 100% (using more threads I assume) and this is speeding
things up really nice.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4318Check the size of the structure passed to dns_rdata_*struct methods2024-01-03T13:35:03ZMark AndrewsCheck the size of the structure passed to dns_rdata_*struct methods#4314 made me think we should check the size of the structure being passed to dns_rdata_tostruct, dns_rdata_fromstruct, and dns_rdata_freestruct as we don't have the compiler doing type checks for us. It there is a mismatch badness coul...#4314 made me think we should check the size of the structure being passed to dns_rdata_tostruct, dns_rdata_fromstruct, and dns_rdata_freestruct as we don't have the compiler doing type checks for us. It there is a mismatch badness could happen.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4298ns1 shutdown hang in "tcp:checking that BIND 9 doesn't crash on long TCP mess...2024-02-24T07:51:48ZMichal Nowakns1 shutdown hang in "tcp:checking that BIND 9 doesn't crash on long TCP messages"Job [#3639436](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3639436) failed for 028154d416c2a29bea41c4d9658066845539b82a.
jemalloc arenas were merged to `main` and 9.18, but they did not help with the "tcp:checking that BIND 9 doesn...Job [#3639436](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3639436) failed for 028154d416c2a29bea41c4d9658066845539b82a.
jemalloc arenas were merged to `main` and 9.18, but they did not help with the "tcp:checking that BIND 9 doesn't crash on long TCP messages" check (isc-projects/bind9#4038) entirely (nor with the `isc_mem_benchmark` check of the `mem_test` unit test, see isc-projects/bind9#4286). Arguably, I've never seen the `tcp` check fail four times in a day:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3639436
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3639704
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3639696
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3639687
However, the nature of the failure is different: `ns1` is not OOM-killed but it didn't terminate in time, that is 5 minutes wasn't enough to terminate and the process was aborted.
```
2023-09-06 00:20:22 INFO:tcp I:tcp_tmp_n9au2yez:checking that BIND 9 doesn't crash on long TCP messages (10)
2023-09-06 00:20:22 INFO:tcp I:tcp_tmp_n9au2yez:sending 300000 time(s): 00010000000100000000000003697363036f72670000fc0001
2023-09-06 00:20:22 INFO:tcp I:tcp_tmp_n9au2yez:............................................................................................................................................................................................................................................................................................................
2023-09-06 00:20:22 INFO:tcp I:tcp_tmp_n9au2yez:sent 4023683 bytes to 10.53.0.1:20597
2023-09-06 00:20:22 INFO:tcp I:tcp_tmp_n9au2yez:exit status: 0
---------------------------- Captured log teardown -----------------------------
2023-09-06 00:25:23 INFO:tcp I:tcp_tmp_n9au2yez:ns1 didn't die when sent a SIGTERM
2023-09-06 00:25:23 ERROR:tcp Failed to stop servers
2023-09-06 00:25:24 INFO:tcp I:tcp_tmp_n9au2yez:Core dump(s) found: /builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez/ns1/core.387947
2023-09-06 00:25:24 INFO:tcp D:tcp_tmp_n9au2yez:backtrace from /builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez/ns1/core.387947:
2023-09-06 00:25:24 INFO:tcp D:tcp_tmp_n9au2yez:--------------------------------------------------------------------------------
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D tcp_tmp_n9au2yez-ns1 -X nam'.
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:Program terminated with signal SIGABRT, Aborted.
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#0 0x00007f8a0a4c3129 in pthread_barrier_wait@GLIBC_2.2.5 () from /lib64/libc.so.6
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:[Current thread is 1 (Thread 0x7f8a09eaa580 (LWP 387947))]
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#0 0x00007f8a0a4c3129 in pthread_barrier_wait@GLIBC_2.2.5 () from /lib64/libc.so.6
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#1 0x00007f8a0b2432a2 in stop_tcp_child_job (arg=0x7f8a09ab6800) at netmgr/tcp.c:589
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#2 0x00007f8a0b243372 in stop_tcp_child (sock=<optimized out>) at netmgr/tcp.c:597
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#3 0x00007f8a0b243b21 in isc__nm_tcp_stoplistening (sock=0x7f8a09a77800) at netmgr/tcp.c:622
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#4 0x00007f8a0b23b359 in isc_nm_stoplistening (sock=<optimized out>) at netmgr/netmgr.c:1699
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#5 0x00007f8a0b23dc62 in isc__nmsocket_stop (listener=0x7f8a09a76e00) at netmgr/netmgr.c:1730
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#6 0x00007f8a0b24183e in isc__nm_streamdns_stoplistening (sock=<optimized out>) at netmgr/streamdns.c:962
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#7 0x00007f8a0b23b360 in isc_nm_stoplistening (sock=<optimized out>) at netmgr/netmgr.c:1702
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#8 0x00007f8a0afcab27 in ns_interface_shutdown (ifp=ifp@entry=0x7f8a09ad7980) at interfacemgr.c:729
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#9 0x00007f8a0afcaf9a in purge_old_interfaces (mgr=mgr@entry=0x7f8a09a70500) at interfacemgr.c:815
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#10 0x00007f8a0afcb13e in ns_interfacemgr_shutdown (mgr=0x7f8a09a70500) at interfacemgr.c:435
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#11 0x0000000000445bf1 in shutdown_server (arg=0x7f8a09a9f700) at server.c:9983
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#12 0x00007f8a0b24b383 in isc__async_cb (handle=<optimized out>) at async.c:111
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#13 0x00007f8a0a977bd3 in ?? () from /lib64/libuv.so.1
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#14 0x00007f8a0a99457b in ?? () from /lib64/libuv.so.1
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#15 0x00007f8a0a97d097 in uv_run () from /lib64/libuv.so.1
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#16 0x00007f8a0b25d1ba in loop_thread (arg=arg@entry=0x7f8a09aac800) at loop.c:282
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#17 0x00007f8a0b26ca20 in thread_body (wrap=0xb788b0) at thread.c:85
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#18 0x00007f8a0b26ca99 in isc_thread_main (func=func@entry=0x7f8a0b25d12f <loop_thread>, arg=0x7f8a09aac800) at thread.c:116
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#19 0x00007f8a0b25e109 in isc_loopmgr_run (loopmgr=0x7f8a09a6f6c0) at loop.c:454
2023-09-06 00:27:07 INFO:tcp D:/builds/isc-projects/bind9/bin/tests/system/tcp_tmp_n9au2yez:#20 0x0000000000426faa in main (argc=16, argv=0x7fff1308dae8) at main.c:1592
2023-09-06 00:27:07 INFO:tcp D:tcp_tmp_n9au2yez:--------------------------------------------------------------------------------
```
```
06-Sep-2023 00:20:58.284 client @0x7f895a786800 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 client @0x7f895a787400 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 client @0x7f895a788000 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 client @0x7f895a788c00 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 client @0x7f895a789800 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 client @0x7f895a78a400 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 client @0x7f895a7a5000 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 client @0x7f895a7a5c00 10.53.0.1#53464 (isc.org): bad zone transfer request: 'isc.org/IN': non-authoritative zone (NOTAUTH)
06-Sep-2023 00:20:58.284 netmgr 0x7f8a09a6f900: Shutting down network manager worker on loop 0x7f8a09aae180(3)
06-Sep-2023 00:20:58.284 netmgr 0x7f8a09a6f900: Shutting down network manager worker on loop 0x7f8a09aad900(2)
```
[core.387947-backtrace.txt](/uploads/dab4601f64759ee9475d504cac179df2/core.387947-backtrace.txt)
[named.run](/uploads/d5b292cffcbd202101133e28d131551b/named.run)
Locally, I can't reproduce it; `ns1` terminates at worst in 210 seconds.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4261Detect unexpected files created during system test run with pytest runner2023-12-06T15:51:28ZTom KrizekDetect unexpected files created during system test run with pytest runner> we should have a check whether the named haven't produced any unexpected files. But that's only tangential to cleaning up the cruft. Perhaps this can take a form of .gitignore(?) with expected files for each test.
https://gitlab.isc.o...> we should have a check whether the named haven't produced any unexpected files. But that's only tangential to cleaning up the cruft. Perhaps this can take a form of .gitignore(?) with expected files for each test.
https://gitlab.isc.org/isc-projects/bind9/-/issues/4246#note_395492
Related #3810Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4254zonechecks died mid test2023-08-10T13:14:02ZMark Andrewszonechecks died mid testJob [#3577320](https://gitlab.isc.org/isc-private/bind9/-/jobs/3577320) failed for isc-private/bind9@51f47c4d045f50dd0e72573cd573a5031261fed4:
zonechecks died mid test possibly fallout from setting `-e`.
```
2023-08-10 07:15:03 INFO:zo...Job [#3577320](https://gitlab.isc.org/isc-private/bind9/-/jobs/3577320) failed for isc-private/bind9@51f47c4d045f50dd0e72573cd573a5031261fed4:
zonechecks died mid test possibly fallout from setting `-e`.
```
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking that we detect a NS which looks like a AAAA record (fail)
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking that we detect a NS which looks like a AAAA record (warn=default)
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking that we detect a NS which looks like a AAAA record (ignore)
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking 'rdnc zonestatus' output
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:ns1 zone reload queued
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4230checkds test may fail due to a timing issue2024-01-02T13:40:29ZMark Andrewscheckds test may fail due to a timing issueJob [#3552282](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3552282) failed for 423c9d6716c4b96f0cf939653da47abca267bd23:
```
___________________________ test_checkds_dspublished ___________________________
[gw0] linux -- Python 3.1...Job [#3552282](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3552282) failed for 423c9d6716c4b96f0cf939653da47abca267bd23:
```
___________________________ test_checkds_dspublished ___________________________
[gw0] linux -- Python 3.11.4 /usr/bin/python3.11
/builds/isc-projects/bind9/bin/tests/system/checkds/tests_checkds.py:640: in test_checkds_dspublished
checkds_dspublished(named_port, "explicit", "10.53.0.8")
/builds/isc-projects/bind9/bin/tests/system/checkds/tests_checkds.py:308: in checkds_dspublished
keystate_check(parent, zone, "DSPublish")
/builds/isc-projects/bind9/bin/tests/system/checkds/tests_checkds.py:228: in keystate_check
assert val != 0
E assert 0 != 0
```Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4153Run system tests in network namespaces2023-12-14T15:27:50ZTom KrizekRun system tests in network namespacesExecuting system tests under pytest should support isolation using network namespaces on platforms where it's possible. It would simplify running the tests (no root setup required), prevent any network interference, remove weird quirks w...Executing system tests under pytest should support isolation using network namespaces on platforms where it's possible. It would simplify running the tests (no root setup required), prevent any network interference, remove weird quirks with port assignment and make it easier to capture relevant traffic into PCAP.Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4127dangerfile can't traverse GitLab project boundary2023-06-06T13:13:58ZMichal Nowakdangerfile can't traverse GitLab project boundaryJob [#3445138](https://gitlab.isc.org/isc-private/bind9/-/jobs/3445138) failed for [c713737cdc6ca2997f75c18ad35715ffb48688e8](https://gitlab.isc.org/isc-private/bind9/-/commit/c713737cdc6ca2997f75c18ad35715ffb48688e8).
`danger-python` c...Job [#3445138](https://gitlab.isc.org/isc-private/bind9/-/jobs/3445138) failed for [c713737cdc6ca2997f75c18ad35715ffb48688e8](https://gitlab.isc.org/isc-private/bind9/-/commit/c713737cdc6ca2997f75c18ad35715ffb48688e8).
`danger-python` crashed when `Backport of MR isc-projects/bind9!7457` was present in the MR description field:
```
$ Backport of MR isc-projects/bind9!7457 ci -f
There was an error when executing dangerfile.py:
GitlabGetError at line 207: 404 Not found
Stacktrace:
File "dangerfile.py", line 207, in <module>
original_mr = proj.mergerequests.get(original_mr_id)
File "/usr/local/lib/python3.9/dist-packages/gitlab/v4/objects/merge_requests.py", line 486, in get
return cast(ProjectMergeRequest, super().get(id=id, lazy=lazy, **kwargs))
File "/usr/local/lib/python3.9/dist-packages/gitlab/exceptions.py", line 338, in wrapped_f
raise error(e.error_message, e.response_code, e.response_body) from e
Failing the build, there is 1 fail.
Feedback: https://gitlab.isc.org/isc-private/bind9/merge_requests/531#note_378750
```
It seems that `danger-python` with the current `dangerfile.py` can't traverse the GitLab project boundary from isc-private to isc-projects (and vice versa) and couldn't look for missing isc-private/bind9!531 MR commits that are in the "upstream" isc-projects/bind9!7457 MR.https://gitlab.isc.org/isc-projects/bind9/-/issues/4119delv occasionally hangs in tsan tests2023-08-03T08:53:22ZMichal Nowakdelv occasionally hangs in tsan testsJob [#3442535](https://gitlab.isc.org/isc-private/bind9/-/jobs/3442535) failed for [97f8f0991e3879b047073a7e812e453f620d5c85](https://gitlab.isc.org/isc-private/bind9/-/commit/97f8f0991e3879b047073a7e812e453f620d5c85). Also https://gitla...Job [#3442535](https://gitlab.isc.org/isc-private/bind9/-/jobs/3442535) failed for [97f8f0991e3879b047073a7e812e453f620d5c85](https://gitlab.isc.org/isc-private/bind9/-/commit/97f8f0991e3879b047073a7e812e453f620d5c85). Also https://gitlab.isc.org/isc-private/bind9/-/jobs/3435673. Locally, I could not reproduce it, and in CI, pytest does not present verbose enough output to identify a stuck check.
The `digdelv` system test is sometimes stuck in TSAN system tests https://gitlab.isc.org/isc-private/bind9/-/jobs/3442535, and the CI times out after an hour as a result.
So far, I only saw this on BIND 9.18-S.Not planned