BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T17:00:03Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2331Check whether `dig +trace` works on main2023-11-02T17:00:03ZOndřej SurýCheck whether `dig +trace` works on mainWe should double check that `dig +trace` still works, because it often executes nm_read() inside readcb.We should double check that `dig +trace` still works, because it often executes nm_read() inside readcb.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2330Add a test that max-udp-size can send a 4096 octet UDP response if it is set ...2022-03-01T09:42:51ZOndřej SurýAdd a test that max-udp-size can send a 4096 octet UDP response if it is set to that value.Stemmed from the MR: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4449#note_180129
People expect that `max-udp-size` changes the EDNS Buffer Size and the throttling by `nocookie-udp-size` was bit unexpected. Let's add a t...Stemmed from the MR: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4449#note_180129
People expect that `max-udp-size` changes the EDNS Buffer Size and the throttling by `nocookie-udp-size` was bit unexpected. Let's add a test that matches the people's expectations.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2301Add FIPS mode enabled builds to GitLab CI2022-06-22T15:06:44ZMichal NowakAdd FIPS mode enabled builds to GitLab CIBIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/...BIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281 ([performs](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281/diffs#87db583be5c13c1f7b3c958b10e03d67b6a2ca06) builds with `--enable-fips-mode`)
- [ ] System test can run without MD5 (there's plenty of `algorithm hmac-md5;` in system test or implicit expectation of MD5 in `dig` invocations in `acl` and `allow-query` system tests)
- [ ] Red Hat FIPS patches by @pemensik at https://src.fedoraproject.org/rpms/bind/tree/master for `v9_11` evaluated
- [ ] FIPS-enabled host or VM image (most likely with CentOS)
- [ ] CI job(s) with `--enable-fips-mode` in the build stage and subsequent unit and system test CI jobsNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2297Add long term server properties database2023-11-02T16:26:05ZMark AndrewsAdd long term server properties databaseAdd long term server properties database which is updated from routine traffic so that named doesn't have to relearn server characteristics.
e.g. Supports DNS COOKIEAdd long term server properties database which is updated from routine traffic so that named doesn't have to relearn server characteristics.
e.g. Supports DNS COOKIENot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2260Fix pkcs11 system test to handle revoked key collisions.2022-03-01T09:42:56ZMark AndrewsFix pkcs11 system test to handle revoked key collisions.Job [#1286395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1286395) failed for c19a35c945ebc21272143253d408e145b949a966:
```
S:pkcs11:2020-11-10T04:19:15+0000
T:pkcs11:1:A
A:pkcs11:System test pkcs11
I:pkcs11:PORTS:30765,30766,3076...Job [#1286395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1286395) failed for c19a35c945ebc21272143253d408e145b949a966:
```
S:pkcs11:2020-11-10T04:19:15+0000
T:pkcs11:1:A
A:pkcs11:System test pkcs11
I:pkcs11:PORTS:30765,30766,30767,30768,30769,30770,30771,30772,30773,30774
=I:pkcs11:Generating keys for Native PKCS#11
dnssec-keyfromlabel: fatal: dnssec-keyfromlabel: ./Krsasha256.example.+008+38641 could collide with another key upon revokation
I:pkcs11:setup.sh script failed
R:pkcs11:FAIL
E:pkcs11:2020-11-10T04:19:15+0000
FAIL pkcs11 (exit status: 1)
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2257Follow-up from "use netmgr for xfrin"2022-03-01T09:43:01ZOndřej SurýFollow-up from "use netmgr for xfrin"The following discussion from !4246 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4246#note_175084): (+1 comment)
> This is the last weird thing:
>
> ...The following discussion from !4246 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4246#note_175084): (+1 comment)
> This is the last weird thing:
>
> a) how do we get here with the (previous) transfer still attached?
> b) should this be `dns_xfrin_shutdown(&zone->xfr);`?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2234Add ARM64 build, unit and system test CI jobs2020-10-26T12:30:11ZMichal NowakAdd ARM64 build, unit and system test CI jobsWe used to have ARM64 host before, but it was removed due to it's connectivity problems.
We should add ARM64 CI jobs for two reasons:
1. we support the ARM64 platform and distributions are [actively packaging it](https://gitlab.isc.org...We used to have ARM64 host before, but it was removed due to it's connectivity problems.
We should add ARM64 CI jobs for two reasons:
1. we support the ARM64 platform and distributions are [actively packaging it](https://gitlab.isc.org/isc-projects/bind9/-/issues/2167)
2. Fedora on ARM64 is one of stress test targets and we should ensure that BIND works on this platform before we proceed to later stages of the release process
This requires ARM64 host, possibly AWS, performance-wise we should be close to AMD64 hosts not to block pipelines.
OS platform should be Fedora to match stress test CI jobs.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2216Changing NSEC3PARAM clearing the Opt-Out flag does not work2023-11-02T16:26:05ZMatthijs Mekkingmatthijs@isc.orgChanging NSEC3PARAM clearing the Opt-Out flag does not work### Summary
When changing the NSEC3 parameters, and only clear the Opt-Out flag, `named` is checking if the chain already exists. It falsely claims so.
### BIND version used
9.17 (but pretty sure its also in older versions)
### Steps...### Summary
When changing the NSEC3 parameters, and only clear the Opt-Out flag, `named` is checking if the chain already exists. It falsely claims so.
### BIND version used
9.17 (but pretty sure its also in older versions)
### Steps to reproduce
1. Set up a zone with inline-signing.
2. Start `named`.
3. Run `rndc signing -nsec3param 1 1 5 -` to change to NSEC3.
4. Now run `rndc signing -nsec3param 1 0 5 -` to clear the Opt-Out flag.
### What is the current *bug* behavior?
BIND 9 will keep using the NSEC3 chain with the Opt-Out flag set.
### What is the expected *correct* behavior?
BIND 9 should rebuilt the NSEC3 chain, clearing the Opt-Out flags.
### Relevant configuration files
```
zone "example." {
type master;
file "example.db";
inline-signing yes;
auto-dnssec maintain;
};
```
### Relevant logs and/or screenshots
N/A
### Possible fixes
The code first checks if there is a private TYPE65534 record that indicates if a NSEC3 chain is in progress. If that is not the case (because it is cleared or the chain has been completed), the code checks the NSEC3PARAM record. Since that has its flags always set to `0` the data compare matches, and the code thinks an existing chain exists.
We could check the NSEC3 chain for the Flags fields, but to make sure a complete chain exists, we should check every NSEC3 record.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2213Inline signing: AXFR before zone load on a secondary server prevents zone fro...2023-11-02T17:00:03ZMichał KępieńInline signing: AXFR before zone load on a secondary server prevents zone from being servedConsider an inline-signing secondary server ("bump-in-the-wire") that is
starting up with a previous version of a signed zone available locally.
The typical chain of events is that the server first loads the zone from
storage and then l...Consider an inline-signing secondary server ("bump-in-the-wire") that is
starting up with a previous version of a signed zone available locally.
The typical chain of events is that the server first loads the zone from
storage and then listens to any incoming NOTIFY messages indicating that
the unsigned zone has changed. When the unsigned zone gets updated, its
signed counterpart also gets updated accordingly and the process repeats
itself. This works as expected.
However, if the secondary server receives a NOTIFY for an inline-signed
zone and manages to transfer the unsigned zone in *before* attempting to
load the previous version of the signed zone from storage, things will
break in a way which prevents the inline-signed zone from being served:
```
13-Oct-2020 15:38:01.994 client @0x7f41ac0012f8 10.53.0.2#60440: received notify for zone 'bits'
13-Oct-2020 15:38:01.994 zone bits/IN (unsigned): notify from 10.53.0.2#60440: no serial
13-Oct-2020 15:38:01.994 queue_soa_query: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.461 soa_query: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 refresh_callback: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 refresh_callback: zone bits/IN (unsigned): serial: new 2011072450, old not loaded
13-Oct-2020 15:38:02.464 queue_xfrin: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 zone bits/IN (unsigned): Transfer started.
13-Oct-2020 15:38:02.464 zone bits/IN (unsigned): no database exists yet, requesting AXFR of initial version from 10.53.0.2#32589
13-Oct-2020 15:38:02.464 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: connected using 10.53.0.3#43661
13-Oct-2020 15:38:02.464 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: sent request data
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: received 168 bytes
;bits. IN AXFR
bits. 0 IN SOA ns2.bits. . 2011072450 20 20 1814400 3600
bits. 300 IN NS ns3.bits.
added.bits. 0 IN A 1.2.3.4
ns2.bits. 300 IN A 10.53.0.2
ns3.bits. 300 IN A 10.53.0.3
bits. 0 IN SOA ns2.bits. . 2011072450 20 20 1814400 3600
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: got nonincremental response
13-Oct-2020 15:38:02.467 dns_zone_verifydb: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): replacing zone database
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): zone transfer finished: success
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): transferred serial 2011072450
13-Oct-2020 15:38:02.467 zone_needdump: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone_settimer: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone_settimer: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: Transfer status: success
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: Transfer completed: 1 messages, 6 records, 168 bytes, 0.003 secs (56000 bytes/sec) (serial 2011072450)
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: freeing transfer context
13-Oct-2020 15:38:02.467 zone bits/IN (signed): number of nodes in database: 4
13-Oct-2020 15:38:02.467 zone bits/IN (signed): journal rollforward failed: journal out of sync with zone
13-Oct-2020 15:38:02.467 zone bits/IN (signed): not loaded due to errors.
13-Oct-2020 15:38:02.467 zone_postload: zone bits/IN (signed): done
13-Oct-2020 15:38:02.467 zone_needdump: zone bits/IN (signed): enter
13-Oct-2020 15:38:02.467 zone bits/IN (signed): receive_secure_db: out of range
```
The underlying cause is that in the broken case,
`lib/dns/journal.c:roll_forward()` retrieves the latest SOA serial
number for the zone from the AXFR rather than from the local copy of the
signed zone.
The time window during which this can happen is rather slim, so I do not
think it is a serious issue, but I decided to open a bug report anyway,
because things are certainly working suboptimally here - it seems to me
that `named` should be able to recover from such a sequence of events
just fine, serving the signed zone in the end.
This was found during [release testing for BIND 9.16.8][1]. I prepared
a crude patch which allows reliably triggering this issue in the
`inline` system test:
```diff
diff --git a/bin/tests/system/inline/tests.sh b/bin/tests/system/inline/tests.sh
index 7d7df7487f4..430f6fcbb77 100755
--- a/bin/tests/system/inline/tests.sh
+++ b/bin/tests/system/inline/tests.sh
@@ -475,7 +475,9 @@ status=`expr $status + $ret`
n=`expr $n + 1`
echo_i "restart bump in the wire signer server ($n)"
ret=0
+export SKIPLOAD="bits"
start_server --noclean --restart --port ${PORT} inline ns3 || ret=1
+unset SKIPLOAD
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret`
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index b8cd90b129a..57bb239c9d5 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -1995,6 +1995,16 @@ zone_load(dns_zone_t *zone, unsigned int flags, bool locked) {
REQUIRE(DNS_ZONE_VALID(zone));
+ {
+ char origin[DNS_NAME_FORMATSIZE];
+ char *skipload = getenv("SKIPLOAD");
+
+ dns_name_format(&zone->origin, origin, sizeof(origin));
+ if (skipload != NULL && !strcmp(skipload, origin)) {
+ return (ISC_R_SUCCESS);
+ }
+ }
+
if (!locked) {
LOCK_ZONE(zone);
}
```
Applying the above patch should result in:
```
I:inline:stop bump in the wire signer server (29)
I:inline:restart bump in the wire signer server (30)
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary (31)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone (32)
I:inline:failed
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary, noixfr (33)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone, noixfr (34)
```
and log lines similar to the ones quoted above appearing in
`ns3/named.run`.
AFAICT, all maintained branches are affected.
[1]: https://wiki.isc.org/bin/view/QA/BindQaResults_9_11_24#9.16.8Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2212NSEC3 Resalt2023-09-07T05:10:15ZMatthijs Mekkingmatthijs@isc.orgNSEC3 ResaltAdd an option to resalt `nsec3-resalt duration`. If not set, or set to 0, do not resalt. Otherwise, schedule a resalt task, similar to `zone_rekey`. This option should be checked for range (i.e. don't resalt every minute).Add an option to resalt `nsec3-resalt duration`. If not set, or set to 0, do not resalt. Otherwise, schedule a resalt task, similar to `zone_rekey`. This option should be checked for range (i.e. don't resalt every minute).Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/21979.16.6 exited with assertion failure after minor in-flight configuration change2022-01-25T16:56:10ZHåvard Eidnes9.16.6 exited with assertion failure after minor in-flight configuration change<!--
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
10s after a minor configuration change, BIND exited with an assertion failure.
After a restart, it has continued working as normal.
### BIND version used
```
BIND 9.16.6 (Stable Release) <id:25846cf>
running on NetBSD amd64 9.0_RC1 NetBSD 9.0_RC1 (GENERIC) #0: Sat Dec 14 12:36:33 UTC 2019 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--enable-dnstap' '--with-protobuf-c=/usr/pkg' '--with-libfstrm=/usr/pkg' '--sysconfdir=/etc' '--localstatedir=/var'
compiled by GCC 7.4.0
compiled with OpenSSL version: OpenSSL 1.1.1c 28 May 2019
linked to OpenSSL version: OpenSSL 1.1.1c 28 May 2019
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with zlib version: 1.2.10
linked to zlib version: 1.2.10
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
The configuration changes introduced were:
```
--- named.conf 2020/10/02 10:02:54 1.23
+++ named.conf 2020/10/02 10:06:18 1.24
@@ -1,7 +1,6 @@
options {
directory "/etc/namedb";
- dnssec-enable yes;
dnssec-validation yes;
managed-keys-directory "keys";
@@ -17,6 +16,10 @@
// minimization for now. May be related to forwarding...
//qname-minimization off;
+ // Be nice, conform to DNS flag day 2020
+ edns-udp-size 1232;
+ max-udp-size 1232;
+
// Force these in preparation for anycast addresses
// which we never want to use as query source
query-source address 158.37.2.68;
@@ -82,7 +85,7 @@
};
};
-managed-keys {
+trust-anchors {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
```
### What is the current *bug* behavior?
```
Oct 2 12:06:07 tos-res named[6701]: reloading configuration succeeded
Oct 2 12:06:07 tos-res named[6701]: scheduled loading new zones
Oct 2 12:06:07 tos-res named[6701]: any newly configured zones are now loaded
Oct 2 12:06:07 tos-res named[6701]: running
Oct 2 12:06:17 tos-res named[6701]: resolver.c:10193: INSIST(((res->dbuckets[i].list).head == ((void *)0))) failed, back trace
Oct 2 12:06:17 tos-res named[6701]: #0 0x434978 in assertion_failed()+0x4d
Oct 2 12:06:17 tos-res named[6701]: #1 0x5edd88 in isc_assertion_failed()+0xa
Oct 2 12:06:17 tos-res named[6701]: #2 0x550e33 in dns_resolver_detach()+0x501
Oct 2 12:06:17 tos-res named[6701]: #3 0x5896cf in destroy()+0x129
Oct 2 12:06:17 tos-res named[6701]: #4 0x58a427 in adb_shutdown()+0x52
Oct 2 12:06:17 tos-res named[6701]: #5 0x610f77 in run()+0x6b2
Oct 2 12:06:17 tos-res named[6701]: #6 0x72753c20c1d8 in _fini()+0x72753bbc5778
Oct 2 12:06:17 tos-res named[6701]: #7 0x72753bc87af0 in _fini()+0x72753b641090
Oct 2 12:06:17 tos-res named[6701]: exiting (due to assertion failure)
```
### What is the expected *correct* behavior?
BIND should have continued working as normal.
I don't know, it *may* be coincidental, but 10s is "too close for comfort".
Besides, that BIND continues working now after a full restart tends to indicate
that the problem was the in-flight configuration change and not the configuration
change itself.
### Relevant configuration files
`named-checkconf -px` output follows:
```
logging {
channel "normal" {
syslog "local2";
severity dynamic;
};
channel "trash" {
syslog "local3";
severity dynamic;
};
channel "security" {
syslog "local4";
severity dynamic;
};
channel "qerrs" {
syslog "local1";
severity dynamic;
};
channel "queries" {
syslog "local0";
severity dynamic;
};
channel "client_log" {
file "/var/log/client.log" versions 30 size 10485760;
severity dynamic;
print-time yes;
};
channel "rpzlog" {
file "/var/log/named.rpz" versions 50 size 10485760;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "null" {
null ;
};
category "default" {
"normal";
"default_debug";
};
category "general" {
"normal";
"default_debug";
};
category "config" {
"normal";
"default_debug";
};
category "network" {
"normal";
"default_debug";
};
category "notify" {
"normal";
"default_debug";
};
category "xfer-in" {
"normal";
"default_debug";
};
category "xfer-out" {
"normal";
"default_debug";
};
category "dnssec" {
"security";
};
category "security" {
"security";
};
category "rpz" {
"rpzlog";
};
category "database" {
"null";
};
category "lame-servers" {
"null";
};
category "update-security" {
"null";
};
category "update" {
"null";
};
category "query-errors" {
"qerrs";
};
category "queries" {
"queries";
};
category "client" {
"client_log";
};
};
options {
datasize 8589934592;
directory "/etc/namedb";
dnstap-output unix"/var/run/named/dnstap.sock";
hostname "tos-res.uninett.no";
listen-on {
"any";
};
listen-on-v6 {
"any";
};
managed-keys-directory "keys";
querylog no;
server-id "tos-res.uninett.no";
dnssec-validation yes;
dnstap {
client query;
};
edns-udp-size 1232;
max-udp-size 1232;
qname-minimization relaxed;
query-source address 158.37.2.68 port 0;
query-source-v6 address 2001:700:0:804f::ca53 port 0;
recursion yes;
response-policy {
zone "dns-rpz.uninett.no";
zone "zone3.ph.rpz.switch.ch" policy disabled;
zone "zone3.mw.rpz.switch.ch" policy disabled;
zone "zone3.misc.rpz.switch.ch" policy disabled;
} break-dnssec yes;
allow-query {
"localnets";
78.91.0.0/16;
128.39.0.0/16;
129.177.0.0/16;
129.240.0.0/15;
129.242.0.0/16;
144.164.0.0/16;
151.157.0.0/16;
152.94.0.0/16;
156.116.0.0/16;
157.249.0.0/16;
158.36.0.0/14;
161.4.0.0/16;
192.111.33.0/24;
192.133.32.0/24;
192.146.238.0/23;
193.156.0.0/15;
2001:700::/32;
146.172.4.0/23;
148.122.20.52/31;
148.123.37.165/32;
2001:67c:29f4::/48;
44.141.124.0/24;
44.141.132.0/24;
193.35.52.0/22;
};
forward first;
forwarders {
158.38.0.168;
128.39.2.24;
};
};
statistics-channels {
inet 127.0.0.1 port 8053 allow {
127.0.0.1/32;
};
inet 158.37.2.68 port 8053 allow {
158.38.62.0/23;
158.38.10.0/24;
};
};
server 54.209.136.173/32 {
send-cookie no;
};
server 204.153.45.2/32 {
send-cookie no;
};
trust-anchors {
"." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
"." initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
"7.4.nrenum.net" initial-key 257 3 8 "AwEAAdyLRICD7vMGdRG+uwF9176xm5u+E22zJehX7luBrY8LeUsw0aT9
WxBe2aKYSoBbAROVcuQJ/8EbbL+XhX5RKieRZFLDS1hQc+BpLY4Vse5G
2OeWYbH9lWEUM6/XErTsUikYfchXxWg6PkidN/howfNmo7iHDgeG/Xfz
E+i2MLZHCCnNND6v2DE8aP4qYzmU/jEc7n4814z2HR1dzpK/eXZwY3Tv
MjnTh3cqayi8b2B7+tedwV874plFOtMdTwywnMnXf1R3C3HBIZXHu55F
Ptd7cMbikW0lEc7BRRYL50knDMk7jcnsnA7MI1hOu3vI1cNAUWM+CmWX
DXShJKcLF0s=";
};
zone "." {
type hint;
file "root.cache";
};
zone "localhost" {
type master;
file "localhost";
};
zone "127.IN-ADDR.ARPA" {
type master;
file "127";
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "loopback.v6";
};
zone "dns-rpz.uninett.no" {
type slave;
file "sz/dns-rpz.uninett.no";
masters {
158.38.212.119;
};
};
zone "zone3.ph.rpz.switch.ch" {
type slave;
file "sz/zone3.ph.rpz.switch.ch";
masters {
158.38.212.119;
};
};
zone "zone3.mw.rpz.switch.ch" {
type slave;
file "sz/zone3.mw.rpz.switch.ch";
masters {
158.38.212.119;
};
};
zone "zone3.misc.rpz.switch.ch" {
type slave;
file "sz/zone3.misc.rpz.switch.ch";
masters {
158.38.212.119;
};
};
```
### Relevant logs and/or screenshots
See above.
### Possible fixes
Sorry, don't know.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2186rndc thaw does not correctly process zone changes2022-03-01T09:47:44ZJean-Christophe Manciotrndc thaw does not correctly process zone changes- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL ...- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL 604800 --> $TTL 3600
# rndc thaw sdxlive.com
```
Most RRs keep their original TTL:
```
# bind-get-all-resource-records.sh sdxlive.com|grep " 604800 "
zone sdxlive.com/IN: loaded serial 2020092411 (DNSSEC signed)
OK
sdxlive.com. 604800 IN NS ns1.sdxlive.com.
sdxlive.com. 604800 IN RRSIG NS 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. WgQwG0FpqPOPiTZKi65qn01Fe4g3qRkQ0OybOLawl7PlWWKc9XdYMTwf 7AP3c/fKnE0l0BujSSir8HKf4IBVjw==
sdxlive.com. 604800 IN A 176.139.106.168
sdxlive.com. 604800 IN RRSIG A 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. sqeyUzMxZ6JlK+hr6XlLKBJHAZmmVo+ku8oElfuc+6rH8Cr+uKNovK6F Awu76tmcURpR5grYDA0vsC5Cl3B0aQ==
sdxlive.com. 604800 IN MX 1 mail.sdxlive.com.
sdxlive.com. 604800 IN RRSIG MX 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. xZiYSxYb4gX3e2ZbcC2cmEHT7IKUT/c+wil3ZioViRsW+4RLH/LAJ6Mp eC9+ooWgN7jjArM4EvEQCl6xkuln3Q==
and so on...
```
Same issue if I begin with a ```rndc sync -clean sdxlive.com``` before the zone freeze.
Am I missing something?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2182statschannel python test leave no forensic traces to work out what went wrong.2023-11-02T17:00:03ZMark Andrewsstatschannel python test leave no forensic traces to work out what went wrong.Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2154Investigate rpz system test failure2023-10-23T13:59:27ZMark AndrewsInvestigate rpz system test failureJob [#1161531](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1161531) failed for c5c2a4820b6dd705443e42a515cd20fc4293d35b:Job [#1161531](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1161531) failed for c5c2a4820b6dd705443e42a515cd20fc4293d35b:BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2153Rebuild RBTDB while rehashing2021-10-05T15:35:42ZBrian ConryRebuild RBTDB while rehashing@ondrej had an idea related to rebuilding the RBTDB while rehashing as a means of clearing out empty interior nodes.
This issue is a reminder.
Description to be updated and amended.@ondrej had an idea related to rebuilding the RBTDB while rehashing as a means of clearing out empty interior nodes.
This issue is a reminder.
Description to be updated and amended.BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2117BIND sometimes fixates on one server address for a zone2024-01-17T14:25:21ZBrian ConryBIND sometimes fixates on one server address for a zoneA customer has reported:
> I noticed I focused on the wrong nameservers before (I sent the nameservers for akamaiedge.net, instead of g.akamaiedge.net), but the issue is the same. The authoritative nameservers to consider are:
> ```
> n...A customer has reported:
> I noticed I focused on the wrong nameservers before (I sent the nameservers for akamaiedge.net, instead of g.akamaiedge.net), but the issue is the same. The authoritative nameservers to consider are:
> ```
> n0g.akamaiedge.net. 152 IN A 88.221.81.192
> n0g.akamaiedge.net. 152 IN AAAA 2600:1480:e800::c0
> n1g.akamaiedge.net. 152 IN A 2.16.65.53
> n2g.akamaiedge.net. 152 IN A 2.16.65.86
> n3g.akamaiedge.net. 152 IN A 2.16.65.44
> n4g.akamaiedge.net. 152 IN A 2.16.65.68
> n5g.akamaiedge.net. 162 IN A 2.16.65.77
> n6g.akamaiedge.net. 162 IN A 2.21.25.118
> n7g.akamaiedge.net. 181 IN A 2.17.41.132
> ```
> response times are:
> ```
> 88.221.81.192: 147 msec
> 2600:1480:e800::c0: 146 msec
> 2.16.65.53: 1 msec
> 2.16.65.86: 1 msec
> 2.16.65.44: 1 msec
> 2.16.65.68: 1 msec
> 2.16.65.77: 1 msec
> 2.21.25.118: 15 msec
> 2.17.41.132: 13 msec
> ```
They have provided data from `rndc dumpdb -all`.
selected cache data:
```
; glue
g.akamaiedge.net. 865 NS n0g.akamaiedge.net.
865 NS n7g.akamaiedge.net.
865 NS n5g.akamaiedge.net.
865 NS n4g.akamaiedge.net.
865 NS n3g.akamaiedge.net.
865 NS n1g.akamaiedge.net.
865 NS n2g.akamaiedge.net.
865 NS n6g.akamaiedge.net.
; answer
e11550.g.akamaiedge.net. 433 \-TYPE65 ;-$NXRRSET
; g.akamaiedge.net. SOA n0g.akamaiedge.net. hostmaster.akamai.com. 1599033648 1000 1000 1000 1800
; authanswer
n0g.akamaiedge.net. 2246 A 88.221.81.192
; authanswer
2246 AAAA 2600:1480:e800::c0
; authanswer
n1g.akamaiedge.net. 2246 A 2.16.65.53
; authanswer
n2g.akamaiedge.net. 2246 A 2.16.65.86
; authanswer
n3g.akamaiedge.net. 2246 A 2.16.65.44
; authanswer
n4g.akamaiedge.net. 2246 A 2.16.65.68
; authanswer
n5g.akamaiedge.net. 2256 A 2.16.65.77
; authanswer
n6g.akamaiedge.net. 2256 A 2.21.25.118
; authanswer
n7g.akamaiedge.net. 2275 A 2.17.41.132
```
selected ADB entries:
```
; selected ADB data
; n0g.akamaiedge.net [v4 TTL 46] [v6 TTL 46] [v4 success] [v6 success]
; 88.221.81.192 [srtt 121879] [flags 00004000] [edns 63/0/0/0/0] [plain 0/0] [udpsize 512] [ttl -991]
; 2600:1480:e800::c0 [srtt 146019] [flags 00004000] [edns 135/0/0/0/0] [plain 0/0] [udpsize 512] [ttl -991]
; n1g.akamaiedge.net [v4 TTL 46] [v4 success] [v6 unexpected]
; 2.16.65.53 [srtt 6] [flags 00000000] [edns 0/0/0/0/0] [plain 0/0] [ttl 810]
; n2g.akamaiedge.net [v4 TTL 46] [v4 success] [v6 unexpected]
; 2.16.65.86 [srtt 21] [flags 00000000] [edns 0/0/0/0/0] [plain 0/0] [ttl 810]
; n3g.akamaiedge.net [v4 TTL 46] [v4 success] [v6 unexpected]
; 2.16.65.44 [srtt 20] [flags 00000000] [edns 0/0/0/0/0] [plain 0/0] [ttl 810]
; n4g.akamaiedge.net [v4 TTL 46] [v4 success] [v6 unexpected]
; 2.16.65.68 [srtt 29] [flags 00000000] [edns 0/0/0/0/0] [plain 0/0] [ttl 810]
; n5g.akamaiedge.net [v4 TTL 56] [v4 success] [v6 unexpected]
; 2.16.65.77 [srtt 30] [flags 00000000] [edns 0/0/0/0/0] [plain 0/0] [ttl 810]
; n6g.akamaiedge.net [v4 TTL 56] [v4 success] [v6 unexpected]
; 2.21.25.118 [srtt 27] [flags 00000000] [edns 0/0/0/0/0] [plain 0/0] [ttl 810]
; n7g.akamaiedge.net [v4 TTL 75] [v4 success] [v6 unexpected]
; 2.17.41.132 [srtt 9] [flags 00000000] [edns 0/0/0/0/0] [plain 0/0] [ttl 810]
```
One thing to note about the ADB entries is that the entries for `n1g` through `n7g` have not been used and appear to have been added, but unused, prior to the `dumpdb` (new entries are initialized to a value between 1 and 32 microseconds).
The core of the cycle appears to be:
1. As long as at least one address is found in the ADB for at least one of the names in the NS rrset, no new data is fetched or moved into the ADB
2. As long a `named` is waiting for a response from an address, that ADB entry is preserved
3. `named` sets how long to wait for a response based on the current SRTT
4. An ADB entry can be used even if it is expired
While theoretically any address could be the one fixated on, by virtue point 3 above the ones with the higher SRTT are more likely to be selected than the ones with the lower SRTT.
This is also more likely to happen for a frequently-queried zone with many records with low TTLs, such as the zone of a CDN.
This is not the first time I've seen behavior that I've believed linked to this, but it is the first time a customer has noticed it and it's also the clearest documentation yet for it.
I expect that there are multiple possible solutions to this, with the hard part being choosing the one that we believe will be the easiest to implement and have the lowest chances of unintended consequences.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2113Hard require Net::DNS >= 0.752022-03-01T09:58:32ZOndřej SurýHard require Net::DNS >= 0.75I and @marka talked today that we should just simply require `Net::DNS` to run the system tests instead of doing `prereq.sh` because it's such essential library.I and @marka talked today that we should just simply require `Net::DNS` to run the system tests instead of doing `prereq.sh` because it's such essential library.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2110dnssec-signzone report() missing newline2023-10-31T20:15:55ZScott Nicholasdnssec-signzone report() missing newline<!--
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
A regression in report() function in dnssec-signzone printing newline.
### BIND version used
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
```
[root@foo named]# dnssec-signzone -3 deadc0ffee -E pkcs11 -S -K /var/named/keys -X +90d -x -o example.org example.org.zone
Fetching example.org/RSASHA256/26302 (KSK) from key repository.Fetching example.org/RSASHA256/27193 (ZSK) from key repository.Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 present, 0 revoked
example.org.zone.signed
```
### What is the expected *correct* behavior?
```
[root@foo named]# dnssec-signzone -3 deadc0ffee -E pkcs11 -S -K /var/named/keys -X +90d -x -o example.org example.org.zone
Fetching example.org/RSASHA256/26302 (KSK) from key repository.
Fetching example.org/RSASHA256/27193 (ZSK) from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 present, 0 revoked
example.org.zone.signed
```
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/dnssec/dnssec-signzone.c#L2729
BIND 9.11 has a putc('\n') there.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2099Implement ZoneMD signature generation and verification.2024-03-21T03:37:01ZMark AndrewsImplement ZoneMD signature generation and verification.ZoneMD is described in <https://datatracker.ietf.org/doc/html/rfc8976>.
The record type currently implemented #867.
ZONEMD generation and verification needs to be add to both dnssec-signzone and named.
ZONEMD verification needs to be ...ZoneMD is described in <https://datatracker.ietf.org/doc/html/rfc8976>.
The record type currently implemented #867.
ZONEMD generation and verification needs to be add to both dnssec-signzone and named.
ZONEMD verification needs to be added to dnssec-verify. Does this need a seperate flag to say to expect ZONEMD?
There needs to be a way to signal to named that ZONEMD generation is to be performed for a UPDATABLE zones. This generation will need to be performed in the post update stage and must be completed before the UPDATE request is responded to. This needs to occur after the zone's serial is computed. The NSEC and NSEC3 records generation for the zone apex needs to aware of whether ZONEMD is to be generated to not. If ZONEMD generation ends up requiring the zone to be walked incrementally we will need to delay other updates to the zone until ZONEMD completes. ZONEMD must be included in each delta for a zone that is being updated.
There needs to be a way to signal to named that ZONEMD should be generated for inline zones. Similar requirements to UPDATABLE zones apply to inline zones as well.
There needs to be a way to signal to named that ZONEMD validation needs to be performed for a zone. This needs to complete before the zones contents are made visible to clients. This needs to be performed for both IXFR and AXFR. This may need to be performed incrementally. If it is being performed incrementally other transfers of the zone need to be deferred.
For IXFR do we need to check ZONEMD for each delta or only at the end of the final delta of a IXFR?
For dnssec-signzone we need a way to signal that ZONEMD should be generated.
For dnssec-signzone do we need a seperate flag to verify the ZONEMD or do we use the existing flag.
For dnssec-signzone what is the behaviour if the existing zone has a ZONEMD? Do we have a "auto" state?
What impact does this have on kasp?BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2098Move wire_test to standalone tool with man page and such...2023-11-02T17:00:02ZOndřej SurýMove wire_test to standalone tool with man page and such...The following discussion from !4006 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4006#note_156160): (+3 comments)
> We did this a while ago, but I had to revert...The following discussion from !4006 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4006#note_156160): (+3 comments)
> We did this a while ago, but I had to revert it (see commit e45be9d1349). It's used for fuzz testing as well as system tests. I also use it myself sometimes for converting DNS data to and from wire format, and I know I'm not the only one because someone at infoblox asked me to restore it as part of the regular build instead of the test build.
>
> Rather than moving it to bin/tests/system I wonder if we should consider putting it in bin/tools, like we did with named-journalprint or named-rrchecker or nsec3hash.Not planned