ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-04-08T14:43:39Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/507agent-server TLS part 6: system tests2021-04-08T14:43:39ZMichal Nowikowskiagent-server TLS part 6: system tests0.17Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2562XoT crash2022-01-26T11:33:40ZMatthijs Mekkingmatthijs@isc.orgXoT crashThis happens on `main`:
```
BIND 9.17.10 (Development Release) <id:13d23b0>
```
[core](/uploads/6c66b48715ab6c82375b6aa41930126e/core)
[named.conf](/uploads/139f28cf64fc73987622671cb68a8278/named.conf)
Tail of log:
```
08-Mar-2021 13:5...This happens on `main`:
```
BIND 9.17.10 (Development Release) <id:13d23b0>
```
[core](/uploads/6c66b48715ab6c82375b6aa41930126e/core)
[named.conf](/uploads/139f28cf64fc73987622671cb68a8278/named.conf)
Tail of log:
```
08-Mar-2021 13:58:29.080 zone_timer: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.080 zone_maintenance: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.080 queue_soa_query: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.080 zone_settimer: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.080 soa_query: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.080 queue_xfrin: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.080 zone xot.rocks/IN: Transfer started.
08-Mar-2021 13:58:29.080 zone xot.rocks/IN: requesting IXFR from 3.126.83.50#853
08-Mar-2021 13:58:29.080 zone xot.rocks/IN: got TLS configuration for zone transfer: success
08-Mar-2021 13:58:29.092 transfer of 'xot.rocks/IN' from 3.126.83.50#853: connected using 3.126.83.50#853
08-Mar-2021 13:58:29.092 transfer of 'xot.rocks/IN' from 3.126.83.50#853: resetting
08-Mar-2021 13:58:29.104 transfer of 'xot.rocks/IN' from 3.126.83.50#853: connected using 3.126.83.50#853
08-Mar-2021 13:58:29.104 transfer of 'xot.rocks/IN' from 3.126.83.50#853: failed while receiving responses: REFUSED
08-Mar-2021 13:58:29.104 zone xot.rocks/IN: zone transfer finished: REFUSED
08-Mar-2021 13:58:29.104 zone_settimer: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.104 queue_soa_query: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.104 transfer of 'xot.rocks/IN' from 3.126.83.50#853: Transfer status: REFUSED
08-Mar-2021 13:58:29.104 transfer of 'xot.rocks/IN' from 3.126.83.50#853: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec) (serial 0)
08-Mar-2021 13:58:29.580 soa_query: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.580 queue_xfrin: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.580 zone xot.rocks/IN: Transfer started.
08-Mar-2021 13:58:29.580 zone xot.rocks/IN: requesting IXFR from 2a05:d014:d33:2020::1111#853
08-Mar-2021 13:58:29.580 zone xot.rocks/IN: got TLS configuration for zone transfer: success
08-Mar-2021 13:58:29.588 transfer of 'xot.rocks/IN' from 2a05:d014:d33:2020::1111#853: connected using 2a05:d014:d33:2020::1111#853
08-Mar-2021 13:58:29.588 transfer of 'xot.rocks/IN' from 2a05:d014:d33:2020::1111#853: resetting
08-Mar-2021 13:58:29.600 transfer of 'xot.rocks/IN' from 2a05:d014:d33:2020::1111#853: connected using 2a05:d014:d33:2020::1111#853
08-Mar-2021 13:58:29.600 transfer of 'xot.rocks/IN' from 2a05:d014:d33:2020::1111#853: failed while receiving responses: REFUSED
08-Mar-2021 13:58:29.600 zone xot.rocks/IN: zone transfer finished: REFUSED
08-Mar-2021 13:58:29.600 zone_settimer: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.600 queue_soa_query: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.600 soa_query: zone xot.rocks/IN: enter
08-Mar-2021 13:58:29.600 view.c:1612: REQUIRE(transportp != ((void *)0) && *transportp == ((void *)0)) failed, back trace
08-Mar-2021 13:58:29.600 named(+0x2261f) [0x55cfb417161f]
08-Mar-2021 13:58:29.600 /usr/local/lib/libisc-9.17.10.so(isc_assertion_failed+0x10) [0x7f149821d790]
08-Mar-2021 13:58:29.600 /usr/local/lib/libdns-9.17.10.so(dns_view_gettransport+0x82) [0x7f1498107452]
08-Mar-2021 13:58:29.600 /usr/local/lib/libdns-9.17.10.so(+0x17f00b) [0x7f149812200b]
08-Mar-2021 13:58:29.600 /usr/local/lib/libisc-9.17.10.so(+0x6cc01) [0x7f1498238c01]
08-Mar-2021 13:58:29.600 /usr/local/lib/libisc-9.17.10.so(isc__trampoline_run+0x56) [0x7f1498240486]
08-Mar-2021 13:58:29.600 /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7f1497bd1609]
08-Mar-2021 13:58:29.600 /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f1497acf293]
08-Mar-2021 13:58:29.600 exiting (due to assertion failure)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1740Kea arm update: it claims in one place that TSIG is not supported.2021-03-24T10:56:50ZTomek MrugalskiKea arm update: it claims in one place that TSIG is not supported.The section 13.3.5.1 of ARM incorrectly says "Currently this value is not used as TSIG has not been implemented.". TSIG has been supported for years and that's a simple leftover that was not removed.The section 13.3.5.1 of ARM incorrectly says "Currently this value is not used as TSIG has not been implemented.". TSIG has been supported for years and that's a simple leftover that was not removed.kea1.9.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1741HttpResponse::getBodyAsJson is declared by has no definition2021-03-28T09:53:07ZThomas MarkwalderHttpResponse::getBodyAsJson is declared by has no definitionhttp::HttpReponse::getBodyAsJson is declared in the header but there is no definition of it. Thus if one attempts to use it, one is rewarded with an unresolved symbol:
```
/home/tmark/labs/build/keadev/open/git.1730/kea/src/lib/config/...http::HttpReponse::getBodyAsJson is declared in the header but there is no definition of it. Thus if one attempts to use it, one is rewarded with an unresolved symbol:
```
/home/tmark/labs/build/keadev/open/git.1730/kea/src/lib/config/tests/cmd_http_listener_unittests.cc:384: undefined reference to `isc::http::HttpResponse::getBodyAsJson() const'
collect2: error: ld returned 1 exit status
```kea1.9.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2563rndc modzone to change dnssec-policy retire existing keys immediately2021-04-01T11:19:56ZArth Pauliterndc modzone to change dnssec-policy retire existing keys immediately<!--
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
Changing dnssec-policy using rndc modzone for existing signed zone causes keymgr to retire existing keys. I have bind configured with "allow-new-zones yes;" so I could add, delete, modify zone using rndc. Also configured bind with 2 dnssec-policy: rsasha256 and ecdsap256. I'm hoping this should allow me to do algorithm rollover by changing dnssec-policy using rndc modzone. The following command immediately retire existing DNSKEY and create a new one.
```
rndc modzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy ecdsap256; file "data/example.com"; };'
```
### Tested version
* BIND-9.16.11 (Stable Release)
* BIND 9.16.12 (Stable Release)
### Steps to reproduce
1. Configure bind with "allow-new-zones yes;" and two dnssec-policy with different algorithm. This will allow rndc addzone to add zone and rndc modzone to change dnssec-policy of existing zone. I also configured logging with dnssec category.
2. Load the zone with dnssec-policy:
```
rndc addzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy rsasha256; file "data/example.com"; };'
```
dnssec log result:
```
09-Mar-2021 16:06:10.627 dnssec: info: zone example.com/IN (signed): generated salt: CB4EAB14FFF8A6D4731D94FD2EC9DFD8
09-Mar-2021 16:06:10.634 dnssec: info: zone example.com/IN (signed): reconfiguring zone keys
09-Mar-2021 16:06:10.700 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/25870 (KSK) created for policy rsasha256
09-Mar-2021 16:06:10.749 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/54564 (ZSK) created for policy rsasha256
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/25870 (KSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now active
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/54564 (ZSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now active
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): zone_addnsec3chain(1,INITIAL|CREATE,5,CB4EAB14FFF8A6D4731D94FD2EC9DFD8)
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): next key event: 09-Mar-2021 18:11:10.634
```
3. Check that both KSK & ZSK are RSASHA256 (Algorithm 8)
```
dig dnskey example.com. @localhost +multiline
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 8 (
AwEAAbPGinhOiZq3JyeUWyGF3DxjXtQqoBjQeWzoyhSJ
ZtrqVLkz6ocoQ3y6trcjGN2f7YTSWNPIffwdZ69XHmyV
QvUkJYCCrskiP6RzhZffU9AMP1GR1k5QXWX+/RMOCJta
yasvdQo/2gbplzz78nLmXRzhnSzl1GSNGeG9orGtdbyo
89uPP+SJv13zB5rR7mxIj78bl3eVV0bdWf4G4okBE64M
2NJqG0tJwpI2XFysEkNT0JtLPjtiKgK4dFUzxuc5Cq4W
258611VoGWXlqSwBI03UABwLrzO7q4R0oijEtNjWlSNw
vohw/EGkJcTARofVFFo9Aar0AoP3YzjbdA4r+Ls=
) ; KSK; alg = RSASHA256 ; key id = 41266
example.com. 3600 IN DNSKEY 256 3 8 (
AwEAAd0OQXZ//c6Msr1FVK9qJ8QSUehOETVgPmslvrfv
J94LwS9VAgJAE/mZfJdq/OJwcD6uvwycmfpuOjCpr5OL
k/eVAoVcIRBX2NGnhANPIqDo6n9VzqCeNcxX3tJt6uW4
JDxN2GLgaJ7mQAaQr8LIOTe+YLqbVs1s43YaDVfEfLxd
xh0sUS+HErTAt/7DVPV+nkgf2S8yuwdHniVDFfGOgGbp
t42OlVJaqHo7lj6boAZRaIPTX+aoGKuOz4EhXnRwqmwK
/Y9W9NIkT0H0MHSlfcM0B3KtRBwJ+jD3XM7hu8mm4XBU
cFArX/Od/wP3VCB4CNArtoZS4/agMFIEEBIVMhc=
) ; ZSK; alg = RSASHA256 ; key id = 44445
```
4. Change the zone dnssec-policy using rndc modzone
```
rndc modzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy ecdsap256; file "data/example.com"; };'
```
dnssec log result:
```
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/25870 (KSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/54564 (ZSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY exampl.com/ECDSAP256SHA256/23518 (KSK) created for policy ecdsap256
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) created for policy ecdsap256
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 25870/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 54564/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/23518 (KSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now active
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/12118 (ZSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now active
```
5. Check both KSK & ZSK are now both ECDSHAP256 (algorithm 13) and no more RSASHA256 DNSKEY
```
dig dnskey example.com. @localhost +multiline
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 256 3 13 (
bn2PN0mWvMhjgDiVCnO/dDwPS8JaK6Cas5vBI6D7gds8
PXlMeTSJRQSVcyM1OuZIo/V5JIFiQUiiME1IBD+TNw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 14912
example.com. 3600 IN DNSKEY 257 3 13 (
u6dqheaPjAhwSzuVrroi9na4L4biKfUQDBWRfsjcDyfz
EkPvHIoOZ/DM+FQynz+vyrZ7HnG6fCk9jtz/cmB8vw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 2113
```
### What is the current *bug* behavior?
Using rndc modzone to change zone dnssec-policy retire existing keys immidiately.
```
rndc modzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy ecdsap256; file "data/example.com"; };'
```
### (What actually happens.)
The initial RSASHA256 DNSKEYs were retired immediately and were replaced by ECDSAP256 after running "rndc modzone example.com" with another dnssec-policy containing ECDSAP256 algorithm.
### What is the expected *correct* behavior?
If algoritm rollover is supported with dnssec-policy, existing RSHASHA256 keys and ECDSAP256 keys should be visible.
The following command should show 4 DNSKEY. There should be 2 DNSKEY with algorithm 8 and 2 DNSKEY with algorithm 13.
```
dig dnskey example.com. @localhost +multiline
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 8 (
AwEAAbPGinhOiZq3JyeUWyGF3DxjXtQqoBjQeWzoyhSJ
ZtrqVLkz6ocoQ3y6trcjGN2f7YTSWNPIffwdZ69XHmyV
QvUkJYCCrskiP6RzhZffU9AMP1GR1k5QXWX+/RMOCJta
yasvdQo/2gbplzz78nLmXRzhnSzl1GSNGeG9orGtdbyo
89uPP+SJv13zB5rR7mxIj78bl3eVV0bdWf4G4okBE64M
2NJqG0tJwpI2XFysEkNT0JtLPjtiKgK4dFUzxuc5Cq4W
258611VoGWXlqSwBI03UABwLrzO7q4R0oijEtNjWlSNw
vohw/EGkJcTARofVFFo9Aar0AoP3YzjbdA4r+Ls=
) ; KSK; alg = RSASHA256 ; key id = 41266
example.com. 3600 IN DNSKEY 256 3 8 (
AwEAAd0OQXZ//c6Msr1FVK9qJ8QSUehOETVgPmslvrfv
J94LwS9VAgJAE/mZfJdq/OJwcD6uvwycmfpuOjCpr5OL
k/eVAoVcIRBX2NGnhANPIqDo6n9VzqCeNcxX3tJt6uW4
JDxN2GLgaJ7mQAaQr8LIOTe+YLqbVs1s43YaDVfEfLxd
xh0sUS+HErTAt/7DVPV+nkgf2S8yuwdHniVDFfGOgGbp
t42OlVJaqHo7lj6boAZRaIPTX+aoGKuOz4EhXnRwqmwK
/Y9W9NIkT0H0MHSlfcM0B3KtRBwJ+jD3XM7hu8mm4XBU
cFArX/Od/wP3VCB4CNArtoZS4/agMFIEEBIVMhc=
) ; ZSK; alg = RSASHA256 ; key id = 44445
example.com. 3600 IN DNSKEY 256 3 13 (
bn2PN0mWvMhjgDiVCnO/dDwPS8JaK6Cas5vBI6D7gds8
PXlMeTSJRQSVcyM1OuZIo/V5JIFiQUiiME1IBD+TNw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 14912
example.com. 3600 IN DNSKEY 257 3 13 (
u6dqheaPjAhwSzuVrroi9na4L4biKfUQDBWRfsjcDyfz
EkPvHIoOZ/DM+FQynz+vyrZ7HnG6fCk9jtz/cmB8vw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 2113
```
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
named.conf
```
options {
key-directory "/data/keys";
allow-new-zones yes;
request-ixfr yes;
ixfr-from-differences yes;
provide-ixfr yes;
};
# DNSSEC Policy ECDSA
dnssec-policy "ecdsap256" {
nsec3param iterations 5 optout no salt-length 16;
keys {
ksk key-directory lifetime P1Y algorithm 13;
zsk key-directory lifetime 60d algorithm 13;
};
// Signatures
signatures-refresh P1D;
signatures-validity P2D;
signatures-validity-dnskey P7D;
// Keys
dnskey-ttl 3600;
publish-safety PT3600S;
retire-safety PT3600S;
};
# DNSSEC Policy RSASHA2
dnssec-policy "rsasha256" {
nsec3param iterations 5 optout no salt-length 16;
keys {
ksk key-directory lifetime P1Y algorithm RSASHA256;
zsk key-directory lifetime 30d algorithm RSASHA256;
};
// Signatures
signatures-refresh P1D;
signatures-validity P7D;
signatures-validity-dnskey P14D;
// Keys
dnskey-ttl 3600;
publish-safety PT3600S;
retire-safety PT3600S;
};
```
### Relevant logs and/or screenshots
```
09-Mar-2021 16:06:10.627 dnssec: info: zone example.com/IN (signed): generated salt: CB4EAB14FFF8A6D4731D94FD2EC9DFD8
09-Mar-2021 16:06:10.634 dnssec: info: zone example.com/IN (signed): reconfiguring zone keys
09-Mar-2021 16:06:10.700 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/25870 (KSK) created for policy rsasha256
09-Mar-2021 16:06:10.749 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/54564 (ZSK) created for policy rsasha256
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/25870 (KSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now active
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/54564 (ZSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now active
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): zone_addnsec3chain(1,INITIAL|CREATE,5,CB4EAB14FFF8A6D4731D94FD2EC9DFD8)
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): next key event: 09-Mar-2021 18:11:10.634
09-Mar-2021 16:07:48.457 dnssec: info: zone example.com/IN (signed): reconfiguring zone keys
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/25870 (KSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/54564 (ZSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) created for policy ecdsap256
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) created for policy ecdsap256
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 25870/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 54564/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/23518 (KSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now active
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/12118 (ZSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now active
09-Mar-2021 16:07:48.464 dnssec: info: zone example.com/IN (signed): next key event: 09-Mar-2021 17:12:48.457
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/508Benchmark loading many leases into a DB2021-04-09T11:10:14ZMarcin SiodelskiBenchmark loading many leases into a DBThe purpose of this ticket is to see how long it would take to load many leases into the Stork database, in case we decide that Stork should cache the lease information gathered from multiple Kea servers. This work is related to the http...The purpose of this ticket is to see how long it would take to load many leases into the Stork database, in case we decide that Stork should cache the lease information gathered from multiple Kea servers. This work is related to the https://gitlab.isc.org/isc-projects/stork/-/wikis/Leases-Tracking document.0.17Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2564nslookup segfaults for SERVFAIL2022-04-26T13:18:18ZJohn Peronenslookup segfaults for SERVFAIL### Summary
nslookup (and host) segfault when the answer is SERVFAIL. dig works as expected.
### BIND version used
BIND 9.17.10 (Development Release) <id:5fbd5ff><br>
Tested also 9.17.9 with the same results
### Steps to reproduce
nsl...### Summary
nslookup (and host) segfault when the answer is SERVFAIL. dig works as expected.
### BIND version used
BIND 9.17.10 (Development Release) <id:5fbd5ff><br>
Tested also 9.17.9 with the same results
### Steps to reproduce
nslookup redpress.gr<br>
Segmentation fault
### What is the current *bug* behavior?
isc-net-0000[21534]: segfault at ffffffffffffffff ip 000000000040f661 sp 00007faad57a9820 error 4 in nslookup[400000+17000]
### What is the expected *correct* behavior?
nslookup redpress.gr<br>
Server: 127.0.0.1<br>
Address: 127.0.0.1#53<br>
<br>
** server can't find redpress.gr: SERVFAILMay 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2565A flaw in serve-stale's interaction with fetch limits causes crashes for dual...2021-03-11T15:32:06ZMichal NowakA flaw in serve-stale's interaction with fetch limits causes crashes for dual-mode (authoritative + recursive) serversThere's a [crash](https://gitlab.isc.org/isc-private/bind9/-/jobs/1564386) on `v9_16_sub` in the `serve-stale` system test:
```
rbtdb.c:5195: REQUIRE(version == ((void *)0)) failed, back trace
```
```
Core was generated by `/builds/isc-p...There's a [crash](https://gitlab.isc.org/isc-private/bind9/-/jobs/1564386) on `v9_16_sub` in the `serve-stale` system test:
```
rbtdb.c:5195: REQUIRE(version == ((void *)0)) failed, back trace
```
```
Core was generated by `/builds/isc-private/bind9/bin/named/.libs/lt-named -D serve-stale-ns1 -X named.'.
Program terminated with signal 6, Aborted.
#0 0x00007f6a3c45b387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
55 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
#0 0x00007f6a3c45b387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007f6a3c45ca78 in __GI_abort () at abort.c:90
#2 0x000000000041fe04 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:267
#3 0x00007f6a3e6f2ba0 in isc_assertion_failed (file=file@entry=0x7f6a3faf3b13 "rbtdb.c", line=line@entry=5195, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7f6a3fb12e6a "version == ((void *)0)") at assertions.c:46
#4 0x00007f6a3f9e88e4 in cache_findext (db=0x7f6a2792b020, name=0x7f69d800ece0, version=<optimized out>, type=16, options=3072, now=1615310907, nodep=0x7f6a3a8f9c20, foundname=0x7f69d800ec90, methods=0x7f6a3a8f9c58, clientinfo=0x0, rdataset=0x7f69d80135a0, sigrdataset=0x0) at rbtdb.c:5195
#5 0x00007f6a3f96f3a0 in dns_db_findext (db=0x7f6a2792b020, name=name@entry=0x7f69d800ece0, version=0x7f6a27977348, type=<optimized out>, options=options@entry=3072, now=1615310907, nodep=nodep@entry=0x7f6a3a8f9c20, foundname=0x7f69d800ec90, methods=methods@entry=0x7f6a3a8f9c58, clientinfo=clientinfo@entry=0x0, rdataset=0x7f69d80135a0, sigrdataset=0x0) at db.c:526
#6 0x00007f6a3fd7615c in query_lookup (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:6011
#7 0x00007f6a3fd77f2a in query_delegation_recurse (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:9109
#8 0x00007f6a3fd782a7 in query_delegation (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:9036
#9 0x00007f6a3fd78688 in query_notfound (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:8813
#10 0x00007f6a3fd75821 in query_gotanswer (qctx=qctx@entry=0x7f6a3a8f9790, res=res@entry=23) at query.c:7791
#11 0x00007f6a3fd764bd in query_lookup (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:6217
#12 0x00007f6a3fd77cf4 in query_zone_delegation (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:8960
#13 0x00007f6a3fd7805b in query_delegation (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:8988
#14 0x00007f6a3fd7582e in query_gotanswer (qctx=qctx@entry=0x7f6a3a8f9790, res=res@entry=65565) at query.c:7794
#15 0x00007f6a3fd764bd in query_lookup (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:6217
#16 0x00007f6a3fd777c7 in ns__query_start (qctx=qctx@entry=0x7f6a3a8f9790) at query.c:5659
#17 0x00007f6a3fd7b5f2 in query_setup (client=client@entry=0x7f69d8005a08, qtype=qtype@entry=16) at query.c:5372
#18 0x00007f6a3fd7bf7a in ns_query_start (client=client@entry=0x7f69d8005a08, handle=handle@entry=0x7f69d80058a0) at query.c:12294
#19 0x00007f6a3fd588ad in ns__client_request (handle=0x7f69d80058a0, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at client.c:2250
#20 0x00007f6a3e70b3e4 in isc__nm_async_readcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7f6a3a8fa8a0) at netmgr.c:1861
#21 0x00007f6a3e70b4c0 in isc__nm_readcb (sock=sock@entry=0x7f6a2050bf10, uvreq=<optimized out>, eresult=eresult@entry=0) at netmgr.c:1836
#22 0x00007f6a3e70fdd8 in udp_recv_cb (handle=<optimized out>, nrecv=53, buf=0x7f6a3a8fa9d0, addr=0x7f6a3a8faa20, flags=<optimized out>) at udp.c:466
#23 0x00007f6a3d30906f in uv__udp_io () from /lib64/libuv.so.1
#24 0x00007f6a3d30a8c3 in uv__io_poll () from /lib64/libuv.so.1
#25 0x00007f6a3d2fa0d0 in uv_run () from /lib64/libuv.so.1
#26 0x00007f6a3e70bedc in nm_thread (worker0=0xdc8da0) at netmgr.c:553
#27 0x00007f6a3e729950 in isc__trampoline_run (arg=0xdb7b00) at trampoline.c:191
#28 0x00007f6a3c7faea5 in start_thread (arg=0x7f6a3a8fe700) at pthread_create.c:307
#29 0x00007f6a3c52396d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
```
`thread apply all bt full`: [1564386-bt.txt](/uploads/67fe32e3b33e7ce89b71b4a5c5211c37/1564386-bt.txt)
core: [core.1436.gz](/uploads/9042f6a521c3f71dbf283efe3a5019dd/core.1436.gz)
`named.run`: [named.run](/uploads/8b31e811f7f9a25da955d6c079642ae2/named.run)March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2566dig: Machine friendly output expected (tabs, spaces, etc)2021-03-19T09:11:34Zflindebergdig: Machine friendly output expected (tabs, spaces, etc)<!--
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
`dig` is not consistent with the use of tabs and spaces in output, which is confusing per the the `man`-page itself (for the `+[no]multiline`-option):
> The default is to print each record on a single line to facilitate machine parsing of the dig output.
This should, in my interpretation, mean that the intention is for `dig` to produce machine friendly output by default. Therefore this is filed as a `bug` rather than a feature request. However, I realize the hassle of of changing the default output format since most often it is possible to work around it, and most users, I assume, have not encountered it. I encountered it when going through entire zones-files by AXFR when I realized that some outputs were a bit off after doing some yoga on the zone-contents.
### BIND version used
`BIND 9.16.12 (Stable Release) <id:aeb943d>`
### Steps to reproduce
Illustration (using one long domain name and one short domain name which causes the issue):
```
> dig +noall +answer ns iis.se abbekaslagerologistik.se | cut -f1,4,5
iis.se. 3417 IN
iis.se. 3417 IN
iis.se. 3417 IN
abbekaslagerologistik.se. 118 ns1.teleservice.net.
abbekaslagerologistik.se. 118 ns2.teleservice.net.
```
I get different fields depending on how many tabs and spaces `dig` chooses to use for that particular record. I would expect that "machine friendly" output would be in line with POSIX command behavior.
Also note above that `field1` is `iis.se` and `abbekaslagerologistik.se. 118` (since there is a space here, not a tab). And that the `abbekaslagerologistik.se.` lack a `field3`.
### What is the current *bug* behavior?
Using alias defined at https://superuser.com/a/1503113/ in below examples.
> alias whitespace="sed 's/ /·/g;s/\t/→/g;s/\r/§/g;s/$/¶/g'"
For example:
```
> dig +noall +answer ns iis.se abbekaslagerologistik.se
iis.se. 358 IN NS ns.nic.se.
iis.se. 358 IN NS i.ns.se.
iis.se. 358 IN NS ns3.nic.se.
abbekaslagerologistik.se. 120 IN NS ns1.teleservice.net.
abbekaslagerologistik.se. 120 IN NS ns2.teleservice.net.
```
With whitespaces marked (`→` is tab, `·` is space, `¶` newline):
```
> dig +noall +answer ns iis.se abbekaslagerologistik.se | whitespace
iis.se.→→→208→IN→NS→ns.nic.se.¶
iis.se.→→→208→IN→NS→i.ns.se.¶
iis.se.→→→208→IN→NS→ns3.nic.se.¶
abbekaslagerologistik.se.·120→IN→NS→ns1.teleservice.net.¶
abbekaslagerologistik.se.·120→IN→NS→ns2.teleservice.net.¶
```
This output is not machine friendly, it is rather human friendly :-) This has the effect than when machine friendly tools, such as `cut` are used, the output becomes both human and machine hostile:
```
> dig +noall +answer ns iis.se abbekaslagerologistik.se | cut -f1,4,5
iis.se. 3417 IN
iis.se. 3417 IN
iis.se. 3417 IN
abbekaslagerologistik.se. 118 ns1.teleservice.net.
abbekaslagerologistik.se. 118 ns2.teleservice.net.
```
```
> dig +noall +answer ns iis.se abbekaslagerologistik.se | cut -f1,4,5 | whitespace
iis.se.→3244→IN¶
iis.se.→3244→IN¶
iis.se.→3244→IN¶
abbekaslagerologistik.se.·120→ns1.teleservice.net.¶
abbekaslagerologistik.se.·120→ns2.teleservice.net.¶
```
### What is the expected *correct* behavior?
Illustration using `sed` and `tr` to provide expected behavior. `sed` to get rid of spaces, and `tr` to get rid of double tabs (and converted spaces). This command line is based on bashisms (i.e. `$'\t'`), which most shells seem to support.
```
> dig +noall +answer ns iis.se abbekaslagerologistik.se | sed 's/ /\t/g' | tr -s $'\t' | cut -f1,4,5
iis.se. NS ns.nic.se.
iis.se. NS i.ns.se.
iis.se. NS ns3.nic.se.
abbekaslagerologistik.se. NS ns1.teleservice.net.
abbekaslagerologistik.se. NS ns2.teleservice.net.
```
And with whitespace to illustrate the machine friendlyness:
```
> dig +noall +answer ns iis.se abbekaslagerologistik.se | sed 's/ /\t/g' | tr -s $'\t' | cut -f1,4,5 | whitespace
iis.se.→NS→ns.nic.se.¶
iis.se.→NS→i.ns.se.¶
iis.se.→NS→ns3.nic.se.¶
abbekaslagerologistik.se.→NS→ns1.teleservice.net.¶
abbekaslagerologistik.se.→NS→ns2.teleservice.net.¶
```
### Relevant configuration files
Defaults
### Relevant logs and/or screenshots
See above
### Possible fixes
I have not looked into the codebase (yet), unsure if I will since it is possible to work around it.https://gitlab.isc.org/isc-projects/bind9/-/issues/2567warning: array subscript is of type 'char' on NetBSD 92021-03-29T12:16:09ZMichal Nowakwarning: array subscript is of type 'char' on NetBSD 9`main` produces warnings on NetBSD 9.1 with Clang 10.0.1:
```
url.c:240:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (isalpha(ch)) {
^~~~~~~~~~~
/usr/include/sys/ctype_inline.h...`main` produces warnings on NetBSD 9.1 with Clang 10.0.1:
```
url.c:240:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (isalpha(ch)) {
^~~~~~~~~~~
/usr/include/sys/ctype_inline.h:49:44: note: expanded from macro 'isalpha'
#define isalpha(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_A))
^~~~
url.c:247:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (isalpha(ch)) {
^~~~~~~~~~~
/usr/include/sys/ctype_inline.h:49:44: note: expanded from macro 'isalpha'
#define isalpha(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_A))
^~~~
url.c:291:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (IS_USERINFO_CHAR(ch) || ch == '[' || ch == ']') {
^~~~~~~~~~~~~~~~~~~~
url.c:194:3: note: expanded from macro 'IS_USERINFO_CHAR'
(isalnum(c) || IS_MARK(c) || (c) == '%' || (c) == ';' || (c) == ':' || \
^~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
url.c:377:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (IS_USERINFO_CHAR(ch)) {
^~~~~~~~~~~~~~~~~~~~
url.c:194:3: note: expanded from macro 'IS_USERINFO_CHAR'
(isalnum(c) || IS_MARK(c) || (c) == '%' || (c) == ';' || (c) == ':' || \
^~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
url.c:387:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (IS_HOST_CHAR(ch)) {
^~~~~~~~~~~~~~~~
url.c:199:26: note: expanded from macro 'IS_HOST_CHAR'
#define IS_HOST_CHAR(c) (isalnum(c) || (c) == '.' || (c) == '-')
^~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
url.c:394:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (IS_HOST_CHAR(ch)) {
^~~~~~~~~~~~~~~~
url.c:199:26: note: expanded from macro 'IS_HOST_CHAR'
#define IS_HOST_CHAR(c) (isalnum(c) || (c) == '.' || (c) == '-')
^~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
url.c:413:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (isxdigit(ch) || ch == ':' || ch == '.') {
^~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:58:45: note: expanded from macro 'isxdigit'
#define isxdigit(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_X))
^~~~
url.c:430:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (isalnum(ch) || ch == '%' || ch == '.' || ch == '-' ||
^~~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
url.c:439:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (isdigit(ch)) {
^~~~~~~~~~~
/usr/include/sys/ctype_inline.h:51:44: note: expanded from macro 'isdigit'
#define isdigit(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_D))
^~~~
9 warnings generated.
```
```
netmgr/http.c:2694:20: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (MATCH('_') || MATCH_ALPHA()) {
^~~~~~~~~~~~~
netmgr/http.c:2588:24: note: expanded from macro 'MATCH_ALPHA'
#define MATCH_ALPHA() isalpha(st->str[0])
^~~~~~~~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:49:44: note: expanded from macro 'isalpha'
#define isalpha(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_A))
^~~~
netmgr/http.c:2701:23: warning: array subscript is of type 'char' [-Wchar-subscripts]
while (MATCH('_') || MATCH_ALNUM()) {
^~~~~~~~~~~~~
netmgr/http.c:2589:24: note: expanded from macro 'MATCH_ALNUM'
#define MATCH_ALNUM() isalnum(st->str[0])
^~~~~~~~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
netmgr/http.c:2735:6: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (MATCH_ALNUM() || MATCH('_') || MATCH('.') || MATCH('-') ||
^~~~~~~~~~~~~
netmgr/http.c:2589:24: note: expanded from macro 'MATCH_ALNUM'
#define MATCH_ALNUM() isalnum(st->str[0])
^~~~~~~~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
netmgr/http.c:2751:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (!MATCH_XDIGIT()) {
^~~~~~~~~~~~~~
netmgr/http.c:2590:24: note: expanded from macro 'MATCH_XDIGIT'
#define MATCH_XDIGIT() isxdigit(st->str[0])
^~~~~~~~~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:58:45: note: expanded from macro 'isxdigit'
#define isxdigit(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_X))
^~~~
netmgr/http.c:2756:7: warning: array subscript is of type 'char' [-Wchar-subscripts]
if (!MATCH_XDIGIT()) {
^~~~~~~~~~~~~~
netmgr/http.c:2590:24: note: expanded from macro 'MATCH_XDIGIT'
#define MATCH_XDIGIT() isxdigit(st->str[0])
^~~~~~~~~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:58:45: note: expanded from macro 'isxdigit'
#define isxdigit(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_X))
^~~~
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2568test_client.c: error: static declaration of 'yield' follows non-static declar...2022-04-11T14:48:24ZMichal Nowaktest_client.c: error: static declaration of 'yield' follows non-static declaration on SolarisSolaris 11.4 and OpenIndiana define [`yield(2)`](https://illumos.org/man/2/yield) in `unistd.h`. Defining function of the same name in `test_client.c` fails with:
```
test_client.c:329:1: error: static declaration of 'yield' follows non-...Solaris 11.4 and OpenIndiana define [`yield(2)`](https://illumos.org/man/2/yield) in `unistd.h`. Defining function of the same name in `test_client.c` fails with:
```
test_client.c:329:1: error: static declaration of 'yield' follows non-static declaration
329 | yield(void) {
| ^~~~~
In file included from test_client.c:24:
/usr/include/unistd.h:563:13: note: previous declaration of 'yield' was here
563 | extern void yield(void);
| ^~~~~
```
`/usr/include/unistd.h`:
```
#if !defined(__XOPEN_OR_POSIX) || defined(__EXTENSIONS__)
extern void yield(void);
#endif /* !defined(__XOPEN_OR_POSIX) || defined(__EXTENSIONS__) */
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2569nsupdate on Solaris produces different failure text than expected2021-03-29T12:22:12ZMichal Nowaknsupdate on Solaris produces different failure text than expectedThe `nsupdate` system test fails on Solaris 11.4 because `nsupdate` fails with "failure" where "not found" is expected:
```
I:nsupdate:ensure unresolvable server name is fatal in non-interactive mode (40)
couldn't get address for 'unreso...The `nsupdate` system test fails on Solaris 11.4 because `nsupdate` fails with "failure" where "not found" is expected:
```
I:nsupdate:ensure unresolvable server name is fatal in non-interactive mode (40)
couldn't get address for 'unresolvable..': failure
syntax error
I:nsupdate:failed
I:nsupdate:ensure unresolvable server name is not fatal in interactive mode (41)
couldn't get address for 'unresolvable..': failure
I:nsupdate:failed
```
```shell
n=`expr $n + 1`
ret=0
echo_i "ensure unresolvable server name is fatal in non-interactive mode ($n)"
$NSUPDATE <<END > nsupdate.out 2>&1 && ret=1
server unresolvable..
END
cat nsupdate.out
grep "couldn't get address for 'unresolvable..': not found" nsupdate.out > /dev/null || ret=1
grep "syntax error" nsupdate.out > /dev/null || ret=1
[ $ret = 0 ] || { echo_i "failed"; status=1; }
n=`expr $n + 1`
ret=0
echo_i "ensure unresolvable server name is not fatal in interactive mode ($n)"
$NSUPDATE -i <<END > nsupdate.out 2>&1 || ret=1
server unresolvable..
END
cat nsupdate.out
grep "couldn't get address for 'unresolvable..': not found" nsupdate.out > /dev/null || ret=1
[ $ret = 0 ] || { echo_i "failed"; status=1; }
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/stork/-/issues/509Look up individual lease by IP or MAC2021-03-29T12:30:18ZVicky Riskvicky@isc.orgLook up individual lease by IP or MAC(1): As an admin investigating a problem, I need to find out what is going on with specific IP/MAC address. I want to get as much information as possible related to this specific IP or MAC.
discussion from the Stork meeting:
this is ver...(1): As an admin investigating a problem, I need to find out what is going on with specific IP/MAC address. I want to get as much information as possible related to this specific IP or MAC.
discussion from the Stork meeting:
this is very specifically a help desk thing so should be available readonly and easy to read
IMHO this is the #1 use case to address first. (Vicky)
this might require looking in the forensic log rather than the lease db, but if a client is having trouble - the admin might want to see some history on the client. A SP is not going to bother with this in general, but an enterprise would. A SP in general is not going to root cause a problem with an individual endpoint, they will try restarting, replacing hw, that kind of thing first, and most of these problems are either (1) signal strength which Stork won't know about or (2) I forgot the other thing, but also something Stork wouldn't know about.0.16Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/510Search for 'tainted' leases, symptom of duplicate IP2021-04-29T14:17:17ZVicky Riskvicky@isc.orgSearch for 'tainted' leases, symptom of duplicate IPAs an administrator I want to know if there are devices on my network using IP addresses that I am also trying to assign from my DHCP service.
One way of identifying these possible conflicts is by searching for OFFERS from Kea that are...As an administrator I want to know if there are devices on my network using IP addresses that I am also trying to assign from my DHCP service.
One way of identifying these possible conflicts is by searching for OFFERS from Kea that are REFUSED by the client. This is not the same thing as ['ping check'](https://kb.isc.org/docs/why-doesnt-kea-support-ping-check) because the check is performed by the client rather than the server, but the information is useful to the server administrator for the same reason - it indicates that and IP you are trying to assign is already in use and that situation should be investigated.0.17Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/171Issue in bind tarball2022-01-20T10:30:53ZMaloy GhoshIssue in bind tarballThe binary tarball of bind-9.11.14 contains this code (`bind-9.11.14/lib/isc/stats.c:300`)
```
static inline void
setcounter(isc_stats_t *stats,
const isc_statscounter_t counter,
const uint64_t value)
{
#if ISC_PLA...The binary tarball of bind-9.11.14 contains this code (`bind-9.11.14/lib/isc/stats.c:300`)
```
static inline void
setcounter(isc_stats_t *stats,
const isc_statscounter_t counter,
const uint64_t value)
{
#if ISC_PLATFORM_HAVESTDATOMIC
atomic_store_explicit(&stats->counters[counter], value,
memory_order_relaxed);
#elif ISC_STATS_HAVEATOMICQ
isc_atomic_storeq((int64_t *)&stats->counters[counter], value);
#else
# if ISC_STATS_USEMULTIFIELDS
isc_atomic_store((int32_t *)&stats->counters[counter].hi,
(uint32_t)((value >> 32) & 0xffffffff));
isc_atomic_store((int32_t *)&stats->counters[counter].lo,
(uint32_t)(value & 0xffffffff));
# else
stats->counters[counter] = val;
# endif
#endif
}
```
It is the `stats->counters[counter] = val` line, results in error during cross-compilation using arm toolchains. It should be `stats->counters[counter] = value`4.4.3-beta1https://gitlab.isc.org/isc-projects/kea/-/issues/1745Suggested improvement of vivso documentation2023-03-13T09:05:39ZPeter DaviesSuggested improvement of vivso documentationSuggested improvement of vivso documentation:
It may be helpful to users that we, in our documentation, describe more clearly the automatic option 125 "vendor-'vendor-id'" space.
This information can be gained by studying the exam...Suggested improvement of vivso documentation:
It may be helpful to users that we, in our documentation, describe more clearly the automatic option 125 "vendor-'vendor-id'" space.
This information can be gained by studying the examples in the ARM and in the source code, but this is conceivably not sufficient.
[ RT #18092 ](https://support.isc.org/Ticket/Display.html?id=18092)kea2.1.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2570Testing issue2021-03-11T11:59:54ZDan MahoneyTesting issueThis is a testing issue, please ignore.This is a testing issue, please ignore.https://gitlab.isc.org/isc-projects/bind9/-/issues/2572BIND fails to build when space or ( is in the path2021-04-13T11:26:59ZMichal NowakBIND fails to build when space or ( is in the pathBuilding BIND 9.17.11 from source tarball fails when there's space or `(` in source directory's path:
```
$ pwd
/home/newman/break neck/bind-9.17.11
$ ./configure --prefix=/tmp/bind9 && make -j12 && make install
...
CCLD libdns.la
...Building BIND 9.17.11 from source tarball fails when there's space or `(` in source directory's path:
```
$ pwd
/home/newman/break neck/bind-9.17.11
$ ./configure --prefix=/tmp/bind9 && make -j12 && make install
...
CCLD libdns.la
/usr/bin/sed: can't read neck/bind-9.17.11/lib/isc/libisc.la: No such file or directory
libtool: error: 'neck/bind-9.17.11/lib/isc/libisc.la' is not a valid libtool archive
make[5]: *** [Makefile:991: libdns.la] Error 1
```
```
$ pwd
/home/newman/breakneck(1)/bind-9.17.11
./configure --prefix=/tmp/bind9 && make -j12 && make install
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
./configure: eval: line 2834: syntax error near unexpected token `('
./configure: eval: line 2834: `${SHELL} /home/newman/breakneck(1)/bind-9.17.11/missing --is-lightweight'
```
Combination of Firefox and GNOME Files app created the following path for me in which I was unable to build BIND: `/tmp/mozilla_newman0/download-19 (1)/v9_17_11/release/bind-9.17.11`.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/kea/-/issues/1747systemd support files provided with ISC Kea packages reference wrong service ...2021-05-06T04:36:23ZMichael McNallysystemd support files provided with ISC Kea packages reference wrong service names (Kea 1.8.2)[A support customer reports](https://support.isc.org/Ticket/Display.html?id=18102) that, due to an error in the files provided to support use with systemd, a couple of the Kea services do not properly restart when using ISC-provided pack...[A support customer reports](https://support.isc.org/Ticket/Display.html?id=18102) that, due to an error in the files provided to support use with systemd, a couple of the Kea services do not properly restart when using ISC-provided packages on systems that use systemd.
From the support ticket:
>>>
Hello ISC,
I've just installed two brand new servers with kea 1.8.2 and enabled the kea-ctrl-agent, and kea-dhcp4 services via aystemd.
But it's only kea-dhcp4 that starts..
I think this is caused by some mispelling in the systemd unit files.
cat /lib/systemd/system/kea-ctrl-agent.service
```
...
[Install]
WantedBy=kea-dhcp4-server.service
WantedBy=kea-dhcp6-server.service
WantedBy=kea-dhcp-ddns.service
```
The kea-dhcp4-server and kea-dhcp6-server services don't exists.. - But if I change the values to:
```
[Install]
WantedBy=kea-dhcp4.service
WantedBy=kea-dhcp6.service
WantedBy=kea-dhcp-ddns.service
```
It works very well..
>>>
They are using:
- Kea 1.8.2
- Centos 7kea1.8.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2574Assertion failure in xfrin_destroy -> xfrin_log -> dns_zone_name2021-03-15T08:30:15ZMichal NowakAssertion failure in xfrin_destroy -> xfrin_log -> dns_zone_namehttps://gitlab.isc.org/isc-private/bind9/-/jobs/1568849
Likely the same as https://gitlab.isc.org/isc-projects/bind9/-/issues/2258.
```
D:inline:Core was generated by `/builds/isc-private/bind9/bin/named/.libs/lt-named -D inline-ns3 -X ...https://gitlab.isc.org/isc-private/bind9/-/jobs/1568849
Likely the same as https://gitlab.isc.org/isc-projects/bind9/-/issues/2258.
```
D:inline:Core was generated by `/builds/isc-private/bind9/bin/named/.libs/lt-named -D inline-ns3 -X named.lock'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:#0 0x00007f42ed6eb438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
D:inline:[Current thread is 1 (Thread 0x7f42e8e78700 (LWP 15340))]
D:inline:#0 0x00007f42ed6eb438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
D:inline:#1 0x00007f42ed6ed03a in __GI_abort () at abort.c:89
D:inline:#2 0x000000000042a835 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_require, cond=0x7f42efbad620 "(__builtin_expect(!!((zone) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(zone))->magic == ((('Z') << 24 | ('O') << 16 | ('N') << 8 | ('E')))), 1))") at main.c:259
D:inline:#3 0x00007f42efe319ea in isc_assertion_failed (file=file@entry=0x7f42efbb30bb "zone.c", line=line@entry=15623, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7f42efbad620 "(__builtin_expect(!!((zone) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(zone))->magic == ((('Z') << 24 | ('O') << 16 | ('N') << 8 | ('E')))), 1))") at assertions.c:46
D:inline:#4 0x00007f42efb428ca in dns_zone_name (zone=<optimized out>, buf=buf@entry=0x7f42e8e741c0 "\020F\347\350B\177", length=length@entry=1055) at zone.c:15623
D:inline:#5 0x00007f42efb34661 in xfrin_log (xfr=xfr@entry=0x7f42d00645f0, level=level@entry=-1, fmt=fmt@entry=0x7f42efbac835 "Transfer status: %s") at xfrin.c:1650
D:inline:#6 0x00007f42efb352bb in xfrin_destroy (xfr=0x7f42d00645f0) at xfrin.c:1518
D:inline:#7 dns_xfrin_detach (xfrp=<optimized out>) at xfrin.c:748
D:inline:#8 0x00007f42efb361bb in xfrin_recv_done (handle=<optimized out>, result=<optimized out>, region=<optimized out>, cbarg=<optimized out>) at xfrin.c:1492
D:inline:#9 0x00007f42efe08d1d in isc__nm_async_readcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7f42e8e749b0) at netmgr/netmgr.c:1952
D:inline:#10 0x00007f42efe08ea3 in isc__nm_readcb (sock=sock@entry=0x7f42d1592100, uvreq=uvreq@entry=0x7f42c0012330, eresult=eresult@entry=0) at netmgr/netmgr.c:1927
D:inline:#11 0x00007f42efe0f55c in processbuffer (sock=0x7f42d1592100) at netmgr/tcpdns.c:997
D:inline:#12 process_sock_buffer (sock=0x7f42d1592100) at netmgr/tcpdns.c:1639
D:inline:#13 0x00007f42efe0f6cb in read_cb (stream=<optimized out>, nread=150, buf=0x7f42e8e74ac0) at netmgr/tcpdns.c:1060
D:inline:#14 0x00007f42ee6b1aff in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#15 0x00007f42ee6b224c in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#16 0x00007f42ee6b7055 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#17 0x00007f42ee6a8efc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#18 0x00007f42efe09b87 in nm_thread (worker0=0x152f730) at netmgr/netmgr.c:553
D:inline:#19 0x00007f42efe58a4b in isc__trampoline_run (arg=0x15ba760) at trampoline.c:184
D:inline:#20 0x00007f42ee4896ba in start_thread (arg=0x7f42e8e78700) at pthread_create.c:333
D:inline:#21 0x00007f42ed7bd4dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
```BIND 9.17 Backburner