BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-09-19T09:22:12Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3422Documentation clarifications on dnssec-policy and dynamic zones2023-09-19T09:22:12ZMatthijs Mekkingmatthijs@isc.orgDocumentation clarifications on dnssec-policy and dynamic zonesSection 4.2.28 (dnssec-policy Statement Definition and Usage) should probably mention that inline-signing is implicitly enabled unless the zone is a dynamic zone, and should also reference (i.e. link to) section 4.2.36.4?
Section 4.2.36....Section 4.2.28 (dnssec-policy Statement Definition and Usage) should probably mention that inline-signing is implicitly enabled unless the zone is a dynamic zone, and should also reference (i.e. link to) section 4.2.36.4?
Section 4.2.36.4 (Dynamic Update Policies) should outline the consequences (of using dynamic zones) on zone file management, including:
The zone file can no longer be manually updated while named is running, without first performing rndc freeze and then after editing performing rndc thaw.
Comments and formatting in the zone file will be lost when dynamic updates (including DNSSEC signing) occur?July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3420rrsetorder system test succeeds despite of a failure log line2022-06-23T10:52:19ZArаm Sаrgsyаnrrsetorder system test succeeds despite of a failure log linehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2589750
```
...
...
I:rrsetorder:Random selection return 12 of 24 possible orders in 36 samples
I:rrsetorder:failed
I:rrsetorder:Checking order none (cache)
I:rrsetorder:Checking default ...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2589750
```
...
...
I:rrsetorder:Random selection return 12 of 24 possible orders in 36 samples
I:rrsetorder:failed
I:rrsetorder:Checking order none (cache)
I:rrsetorder:Checking default order (cache)
I:rrsetorder:Default selection return 12 of 24 possible orders in 36 samples
I:rrsetorder:Checking default order no match in rrset-order (cache)
I:rrsetorder:exit status: 0
I:rrsetorder:stopping servers
R:rrsetorder:PASS
E:rrsetorder:2022-06-20T14:30:48+0000
PASS: rrsetorder
```
Seems to be a missing case of `status=$((status+ret))`.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3416ZSK rollover dnssec-policy: key lifetime is shorter than the time it takes to...2023-12-28T12:16:42ZTom ShawZSK rollover dnssec-policy: key lifetime is shorter than the time it takes to do a rollover<!--
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
Setting up DNSSec using a dnssec policy a previously working configuration now fails due to the Key duration and roll over periods being too "short".
### BIND version used
```
BIND 9.19.2-1+ubuntu22.04.1+isc+1-Ubuntu (Development Release) <id:>
running on Linux x86_64 5.15.0-39-generic #42-Ubuntu SMP Thu Jun 9 23:42:32 UTC 2022
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' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--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/bind9-YovKit/bind9-9.19.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.2.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
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
Use the policy provided below and apply this to a zone.
### What is the current *bug* behavior?
Service fails to start.
### What is the expected *correct* behavior?
I should expect the dnssec-policy set to honour the configuration. A warning at best, would be appropriate here. This configuration worked in the previous development release.
The duration of the keys is a security consideration and not something BIND should enforce. If I want my keys to roll over every hour, I should be able to allow this.
The warning provides a 30day message when in fact the security policy (provided below) allows BIND to start. It would be useful to see some sort of timeline view in the docs relating to the config values for a dnssec policy as the values are unexplained and best guess values have been used.
### Relevant configuration files
none working config
```
dnssec-policy "standard" {
keys {
ksk lifetime PT120M algorithm ECDSAP384SHA384;
zsk lifetime PT40M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT3M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT1M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT60M;
signatures-validity-dnskey PT60M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
```
working modified config (less than 30d)
```
dnssec-policy "standard" {
keys {
ksk lifetime PT120M algorithm ECDSAP384SHA384;
zsk lifetime PT55M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT3M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT1M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT40M;
signatures-validity-dnskey PT40M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
```
### Relevant logs and/or screenshots
```
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:43: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:66: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than the time it takes to do a ro>
Jun 17 16:22:02 ninja.flipkick.media named[2161]: loading configuration: failure
Jun 17 16:22:02 ninja.flipkick.media named[2161]: exiting (due to fatal error)
Jun 17 16:22:02 ninja.flipkick.media systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE
```
### Possible fixes
Allow any period for key duration. 30 days is a poor security policy when working with an Edge computing system and I have resolved the CDS/DS key updates https://github.com/flipkickmedia/cme-dnssec-service - I can get a fully working dnssec system up and running in seconds. With this new update, I have to wait 30d to see if the system works.
I would expect a warning at best, and my TLD providers update the DS keys when I update them (<3H)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3415"rndc reconfig" does not reload http statements2024-01-11T14:13:02ZThomas Beati"rndc reconfig" does not reload http statements### Summary
When we add an endpoint in an http statement in named.conf and run ```rndc reconfig```, the new endpoint is not effective. \
Bind needs to be restarted for the endpoint to be effective. \
The reconfig was working in 9.18.2.
...### Summary
When we add an endpoint in an http statement in named.conf and run ```rndc reconfig```, the new endpoint is not effective. \
Bind needs to be restarted for the endpoint to be effective. \
The reconfig was working in 9.18.2.
### BIND version used
Bug introduced in 9.18.3
BIND 9.18.3 (Stable Release) <id:16aefa3>
### Steps to reproduce
1) Bind is started as an http server:
```
http local-http-server {
endpoints {
"/endpoint1/dns-query";
};
};
option {
...
listen-on port 8443 tls tls_conf http local-http-server {any;};
...
}
```
2) Add an endpoint in named.conf :
```
http local-http-server {
endpoints {
"/endpoint1/dns-query";
"/endpoint2/dns-query";
};
};
```
3) Run ```rndc reconfig```
### What is the current *bug* behavior ?
Configuration is not reloaded, the new endpoint responds with 404 error.
### What is the expected *correct* behavior?
Configuration is reloaded, the new endpoint responds to dns queries.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3412systems/test/run.sh to pass through VIRTUAL_ENV and PERL5LIB2022-06-23T10:45:14ZStacey Marshallsystems/test/run.sh to pass through VIRTUAL_ENV and PERL5LIB### Description
Have tests/system use required Python (dnspython) and PERL modules (Digest::HMAC and Net::DNS) from
user directories, avoid using privileges.
### Request
Have run.sh pass Python virtualenv variable `VIRTUAL_ENV` and PE...### Description
Have tests/system use required Python (dnspython) and PERL modules (Digest::HMAC and Net::DNS) from
user directories, avoid using privileges.
### Request
Have run.sh pass Python virtualenv variable `VIRTUAL_ENV` and PERL's
`PERL5LIB` from user environment to make (gmake).
```
--- run.sh.in.orig 2022-06-16 10:52:39.000000000 +0100
+++ run.sh.in 2022-06-16 11:00:23.000000000 +0100
@@ -90,6 +90,8 @@
LOG_FLAGS="$log_flags" \
TEST_LARGE_MAP="${TEST_LARGE_MAP}" \
CI_ENABLE_ALL_TESTS="${CI_ENABLE_ALL_TESTS}" \
+ ${VIRTUAL_ENV:+"VIRTUAL_ENV=${VIRTUAL_ENV}"} \
+ ${PERL5LIB:+"PERL5LIB=${PERL5LIB}"} \
make -e check
exit $?
fi
```
Note: The *pythonenv* must be setup to use the same version of python as the test uses, for example /usr/bin/python.
### Links / references
Python's virtual environments are well documented.
- [Virtual Environments and Packages](https://docs.python.org/3/tutorial/venv.html)
Perl's use of PERL5LIB is not so well documented,
- [Search www.perl.COM for PERL5LLIB](https://www.google.com/search?q=PERL5LIB+site%3Awww.perl.COM).
- A good summary can be found on [Stackoverlflow](https://stackoverflow.com/questions/2526804/how-is-perls-inc-constructed-aka-what-are-all-the-ways-of-affecting-where-pe)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3408Drop support for Debian 9 (Stretch)2022-07-15T11:05:43ZPetr Špačekpspacek@isc.orgDrop support for Debian 9 (Stretch)LTS version of Debian 9 reaches EOL on [2022-06-30](https://wiki.debian.org/DebianReleases).
Proposal:
- [x] drop it from .gitlab-ci.yaml on all supported branches
- [x] stop bothering ourselves with libraries and Python versions used b...LTS version of Debian 9 reaches EOL on [2022-06-30](https://wiki.debian.org/DebianReleases).
Proposal:
- [x] drop it from .gitlab-ci.yaml on all supported branches
- [x] stop bothering ourselves with libraries and Python versions used by Debian 9
- [x] drop it from list of Regularly Tested Platforms in the ARM
- [x] update [KB article](https://kb.isc.org/docs/supported-platforms)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3402synth-from-dnssec might prevent resolution of grafted (non-delegated) namespaces2022-07-07T09:58:47ZPetr Špačekpspacek@isc.orgsynth-from-dnssec might prevent resolution of grafted (non-delegated) namespaces### Summary
This is all about setup where delegation chain is incomplete and `named.conf` is configured to "graft" a domain without delegation.
Example setup:
- public root zone does not have delegation for `internal`
- named.conf cont...### Summary
This is all about setup where delegation chain is incomplete and `named.conf` is configured to "graft" a domain without delegation.
Example setup:
- public root zone does not have delegation for `internal`
- named.conf contains forwarding or stub zone for `test.internal`
### BIND version used
- ~"Affects v9.19": v9_19_2
- ~"Affects v9.18": v9_18_2
- ~"Affects v9.16": 5c327f209b4bdd9cda8e50c2808b5253321868c0
### Steps to reproduce
1. Configure graft:
```
options {
validate-except { internal; };
synth-from-dnssec yes;
};
zone test.internal {
type forward;
forwarders { 192.0.2.1; };
forward only;
};
```
2. Query for `internal2` to populate cache with proof-of-nonexistence from the root zone:
```
# dig internal2
```
3. Query for a name inside the grafted domain:
```
# dig bla.test.internal
```
### What is the current behavior?
Synthesized NXDOMAIN, based on proof from the root:
```
;; AUTHORITY SECTION:
. 86399 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022061400 1800 900 604800 86400
```
### What is the expected (_not necessarily correct!_) behavior?
A customer was surprised by this after upgrade from ~"v9.16" to ~"v9.18". Technically this is incorrect configuration and qualifies as squatting on a ICANN namespace, but it might not be as rare as we would wish.
### Relevant configuration files
Tested variants with the same result:
- `validate-except { test.internal; };`
- static-stub zone for test.internal
- primary zone for `internal` + forward zone for `test.internal` without delegation
- primary zone for `internal` + forward zone for `test.internal` **with** a "fake" delegation from `internal.` to `test.internal` - **this surprised me**
- primary zone for `internal` + static-stub zone for `test.internal` **with** a "fake" delegation from `internal.` to `test.internal` - **this surprised me** ([empty.db](/uploads/85816fc0dbc6786d760d297eb16bfd32/empty.db) [named.conf](/uploads/025f10df1fff9216ac4accf0b7938974/named.conf))
### Possible approaches
We need to discuss what's the best approach to this protocol-wise invalid configuration. Variants I came up with:
- [ ] Leave it as it is and let users suffer consequences of non-compliant configurations.
- [ ] Except zones listed in `validate-except` also from `synth-from-dnssec`.
- :skull_crossbones: Introduce a new knob for exceptions, like `synth-from-dnssec-except`.
- [ ] Ignore proofs of nonexistence from parent zones for explicitly configured zones (does not include type forward because it's not in the zone table)
- [x] Ignore proofs of nonexistence from parent zones for explicitly configured grafts (includes local zones + the forward table)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3401race condition in route_connected() leads to crash on startup/shutdown2022-06-14T20:06:20ZPetr Špačekpspacek@isc.orgrace condition in route_connected() leads to crash on startup/shutdown### Summary
Assertion failure in route_connected()->in ns_interfacemgr_attach():
```
#6 0x00007f901a31bab8 in ns_interfacemgr_attach (source=0x7f9015294000, target=0x7f901677aaf8) at interfacemgr.c:418
418 REQUIRE(NS_INTERFACEMGR_VALI...### Summary
Assertion failure in route_connected()->in ns_interfacemgr_attach():
```
#6 0x00007f901a31bab8 in ns_interfacemgr_attach (source=0x7f9015294000, target=0x7f901677aaf8) at interfacemgr.c:418
418 REQUIRE(NS_INTERFACEMGR_VALID(source));
```
### BIND version used
- ~"Affects v9.19" : v9_19_2
- ~"Affects v9.18" : v9_18_4
It seems that ~"v9.16" is not affected, or at least is not easily reproducible. I was not able to crash it after 2000 iterations and has given up.
### Steps to reproduce
Easiest reproducer so far is this Bash loop:
```shell
for I in $(seq 1 1000); do /tmp/main/sbin/named -g -c /dev/null -n1 2>&1 & sleep 0.0$RANDOM; pkill named; done
```
### What is the current *bug* behavior?
Crash after couple hundred iterations.
### What is the expected *correct* behavior?
Well, no crash :-)
### Relevant configuration files
None, see `-c /dev/null`.
### Relevant logs and/or screenshots
[gdb.log](/uploads/b55e7fd115e84085ae1f630551424d84/gdb.log)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3400uv_start_read() may get called with a closed tcp session2022-06-14T09:57:49ZPeter Daviesuv_start_read() may get called with a closed tcp sessionuv_start_read() may get called with a closed tcp session:
There may be a timing issue in BIND 9.18.? BIND could crash if a tcp connected was closed or reset in the time between the TCP connection is established and isc_nm_read() is ca...uv_start_read() may get called with a closed tcp session:
There may be a timing issue in BIND 9.18.? BIND could crash if a tcp connected was closed or reset in the time between the TCP connection is established and isc_nm_read() is called.
The callback tcp_connected() calls isc_nm_read() which schedules isc__nm_async_tcpdnsread() on the nmworker loop.
If the connection is closed in the meantime uv_start_read() is called in the next iteration of the loop
[RT #20876](https://support.isc.org/Ticket/Display.html?id=20876)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/3397document interaction between auto-dnssec/dnssec-policy/allow-update/update-po...2022-12-22T08:21:38ZPetr Špačekpspacek@isc.orgdocument interaction between auto-dnssec/dnssec-policy/allow-update/update-policy/inling-signingVarious combinations of {auto-dnssec, dnssec-policy} x {allow-update, update-policy} x inling-signing cause different behavior in terms of serial number increments and data storage. I cannot find clear documentation in the ARM, and appar...Various combinations of {auto-dnssec, dnssec-policy} x {allow-update, update-policy} x inling-signing cause different behavior in terms of serial number increments and data storage. I cannot find clear documentation in the ARM, and apparently it is somewhat confusing people (see #3381).
I'm not sure what's best way to address this. Maybe create a table describing what goes where?
Or describe it separately for each option?
What I have learnt:
- if a primary zone does not allow updates named does not want modify it (is that 100% true)?
- auto-dnssec or dnssec-policy require write access
- in case of a static zone this forces inline-signing and writes updates to a new separate file with signatures and custom serial
- in case of a dynamic zone:
- without inline-signing: updates + signatures go to the the original zone file and uses the same "serial number series"
- with explicit inline-signing: updates go to the original file (without signatures) and bump its serial a bit, but changes _also_ go to the .signed file together with signatures and this separate file has separate "serial number series" disconnected from the original file
A table copied from https://gitlab.isc.org/isc-projects/bind9/-/issues/3381#note_291481:
| updates allowed | signing method | inline-signing config | signatures | data updates |
|-----------------|----------------------|-----------------------|---------------------------------------|---------------|
| no | auto-dnssec maintain | no / unspecified | error: inline-signing must be enabled | - |
| no | auto-dnssec maintain | yes | db.signed | - |
| no | dnssec-policy | no | error: inline-signing must be enabled | - |
| no | dnssec-policy | yes / unspecified | db.signed | - |
| yes | auto-dnssec maintain | no / unspecified | original file | signed + original file |
| yes | auto-dnssec maintain | yes | db.signed | signed + original file |
| yes | dnssec-policy | no / unspecified | original file | signed + original file |
| yes | dnssec-policy | yes | db.signed | signed + original file |July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3395Change default NSEC3 iterations to 0 also for dnssec-signzone2022-07-04T20:56:43ZPetr Špačekpspacek@isc.orgChange default NSEC3 iterations to 0 also for dnssec-signzoneWe have already changed default NSEC3 iterations value for `dnssec-policy` in MR !5513, but we forgot to update `dnssec-signzone` to use the same default.
Currently `dnssec-signzone` in BIND 9.19.1 still defaults to 10 iterations, which...We have already changed default NSEC3 iterations value for `dnssec-policy` in MR !5513, but we forgot to update `dnssec-signzone` to use the same default.
Currently `dnssec-signzone` in BIND 9.19.1 still defaults to 10 iterations, which is not in line with current recommendations.
I propose to treat this as omission in !5513 and fix it even for ~"v9.18" . Sooner the better before lots of people migrate.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/3386Do not keep stale NXDOMAIN answers in cache2022-12-08T13:06:54ZVicky Riskvicky@isc.orgDo not keep stale NXDOMAIN answers in cacheRelated to #1283. Related to #1831.
From the discussion at 2022 All-hands
Create new issue to not keep stale NXDOMAIN in cache.Related to #1283. Related to #1831.
From the discussion at 2022 All-hands
Create new issue to not keep stale NXDOMAIN in cache.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/3362Fix race condition in kasp system test2022-06-08T12:04:02ZMatthijs Mekkingmatthijs@isc.orgFix race condition in kasp system testThe following discussion from !6315 should be addressed:
- [ ] @aram started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6315#note_286736): (+1 comment)
> @matthijs I just removed the ~"LGTM (Merge OK...The following discussion from !6315 should be addressed:
- [ ] @aram started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6315#note_286736): (+1 comment)
> @matthijs I just removed the ~"LGTM (Merge OK)" because of a suspicious failure in the kasp system test.
>
> https://gitlab.isc.org/isc-projects/bind9/-/jobs/2517061
>
> I don't see how this MR could have caused it, so if you also think that it's unrelated please let me know.
A timing issue: The test checks for "all zones loaded" to ensure the new zone content is loaded. But this is the unsigned zone, the signed zone still needs to be produced. The dig requests comes in before that process has finished.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3320Rewrite ARM DNSSEC Chapter2022-07-07T08:39:09ZMatthijs Mekkingmatthijs@isc.orgRewrite ARM DNSSEC ChapterJuly 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3309Destination port is missing from dnstap captures of client traffic2022-06-22T11:54:38ZMichał KępieńDestination port is missing from dnstap captures of client trafficWith the following configuration:
```
options {
listen-on port 5300 { 127.0.0.1; };
listen-on-v6 port 5300 { ::1; };
dnstap { client; };
dnstap-output file "dnstap.log";
};
```
`named` produces the following dnstap data:
```
$ dns...With the following configuration:
```
options {
listen-on port 5300 { 127.0.0.1; };
listen-on-v6 port 5300 { ::1; };
dnstap { client; };
dnstap-output file "dnstap.log";
};
```
`named` produces the following dnstap data:
```
$ dnstap-read dnstap.log
27-Apr-2022 13:25:53.672 CQ ::1:36670 -> ::1:0 UDP 48b isc.org/IN/A
27-Apr-2022 13:25:53.675 CQ 127.0.0.1:53203 -> 127.0.0.1:0 UDP 48b isc.org/IN/A
27-Apr-2022 13:25:53.998 CR ::1:36670 <- ::1:0 UDP 80b isc.org/IN/A
27-Apr-2022 13:25:53.998 CR 127.0.0.1:53203 <- 127.0.0.1:0 UDP 80b isc.org/IN/A
```
Note the `::1:0` and `127.0.0.1:0`. The proper, expected data is:
```
$ dnstap-read dnstap.log
27-Apr-2022 13:27:04.725 CQ ::1:58931 -> ::1:5300 UDP 48b isc.org/IN/A
27-Apr-2022 13:27:04.725 CQ 127.0.0.1:44892 -> 127.0.0.1:5300 UDP 48b isc.org/IN/A
27-Apr-2022 13:27:05.215 CR ::1:58931 <- ::1:5300 UDP 80b isc.org/IN/A
27-Apr-2022 13:27:05.215 CR 127.0.0.1:44892 <- 127.0.0.1:5300 UDP 80b isc.org/IN/A
```July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3207dig +nssearch org crashes when network is unreachable2022-06-14T14:03:05ZPetr Menšíkdig +nssearch org crashes when network is unreachable<!--
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 -6 nssearch org crashes with assertion failure
### BIND version used
```
BIND 9.18.0 (Stable Release) <id:>
running on Linux x86_64 5.16.12-200.fc35.x86_64 #1 SMP PREEMPT Wed Mar 2 19:06:17 UTC 2022
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--with-gssapi=yes' '--with-lmdb=yes' '--with-json-c' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 ' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 11.2.1 20220127 (Red Hat 11.2.1-9)
compiled with OpenSSL version: OpenSSL 1.1.1l FIPS 24 Aug 2021
linked to OpenSSL version: OpenSSL 1.1.1l FIPS 24 Aug 2021
compiled with libuv version: 1.43.0
linked to libuv version: 1.44.1
compiled with libnghttp2 version: 1.45.1
linked to libnghttp2 version: 1.45.1
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.6.0
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
- have ipv6 local connectivity, but not with working default route to public internet
- dig -6 +nssearch org
### What is the current *bug* behavior?
```
../../../bin/dig/dighost.c:1651: REQUIRE(targetp != ((void *)0) && *targetp == ((void *)0)) failed, back trace
/lib64/libisc-9.18.0.so(+0x39ce3)[0x7ffff7a5ece3]
/lib64/libisc-9.18.0.so(isc_assertion_failed+0x10)[0x7ffff7a5e1d0]
/usr/bin/dig(+0x16e70)[0x55555556ae70]
/usr/bin/dig(+0xee4e)[0x555555562e4e]
/usr/bin/dig(+0x10001)[0x555555564001]
/lib64/libisc-9.18.0.so(isc__nm_async_readcb+0xb1)[0x7ffff7a4d381]
/lib64/libisc-9.18.0.so(isc__nm_readcb+0x9b)[0x7ffff7a4d4bb]
/lib64/libisc-9.18.0.so(+0x29a35)[0x7ffff7a4ea35]
/lib64/libuv.so.1(uv_run+0xce)[0x7ffff755f09e]
/lib64/libisc-9.18.0.so(+0x2d5be)[0x7ffff7a525be]
/lib64/libisc-9.18.0.so(isc__trampoline_run+0x1a)[0x7ffff7a858ba]
/lib64/libc.so.6(+0x8db1a)[0x7ffff760fb1a]
/lib64/libc.so.6(+0x112650)[0x7ffff7694650]
```
### What is the expected *correct* behavior?
Should report error state or nothing at all.
### 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`.)
### Relevant logs and/or screenshots
```
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff76118f3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff75c46a6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff75ae7d3 in __GI_abort () at abort.c:79
#4 0x00007ffff7a5e1d5 in isc_assertion_failed (file=file@entry=0x55555556c134 "../../../bin/dig/dighost.c", line=line@entry=1651,
type=type@entry=isc_assertiontype_require, cond=cond@entry=0x5555555712c0 "targetp != ((void *)0) && *targetp == ((void *)0)")
at ../../../lib/isc/assertions.c:50
#5 0x000055555556ae70 in _query_attach.constprop.0 (source=0x7ffff63e3c40, targetp=0x7ffff5128d68, line=<optimized out>,
file=0x55555556c134 "../../../bin/dig/dighost.c") at ../../../bin/dig/dighost.c:1651
#6 0x0000555555562e4e in start_udp (query=<optimized out>) at ../../../bin/dig/dighost.c:2936
#7 0x0000555555564001 in recv_done (handle=0x7ffff63e0180, eresult=ISC_R_TIMEDOUT, region=0x7ffff5dfd290, arg=<optimized out>)
at ../../../bin/dig/dighost.c:3607
#8 0x00007ffff7a4d381 in isc__nm_async_readcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7ffff5dfd2d0) at ../../../lib/isc/netmgr/netmgr.c:2798
#9 0x00007ffff7a4d4bb in isc__nm_readcb (sock=sock@entry=0x7ffff6395e00, uvreq=<optimized out>, eresult=eresult@entry=ISC_R_TIMEDOUT)
at ../../../lib/isc/netmgr/netmgr.c:2771
#10 0x00007ffff7a4ea35 in isc__nmsocket_readtimeout_cb (timer=0x7ffff6396230) at ../../../lib/isc/netmgr/netmgr.c:2087
#11 0x00007ffff755f09e in uv__run_timers (loop=0x7ffff622f010) at src/timer.c:178
#12 uv_run (loop=loop@entry=0x7ffff622f010, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:382
#13 0x00007ffff7a525be in nm_thread (worker0=0x7ffff622f000) at ../../../lib/isc/netmgr/netmgr.c:691
#14 0x00007ffff7a858ba in isc__trampoline_run (arg=0x555555594f70) at ../../../lib/isc/trampoline.c:187
#15 0x00007ffff760fb1a in start_thread (arg=<optimized out>) at pthread_create.c:443
#16 0x00007ffff7694650 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
```
```
# {A}:{B} censors actual used range
# ping -6 -c 1 d0.org.afilias-nst.org.
PING d0.org.afilias-nst.org.(d0.org.afilias-nst.org (2001:500:f::1)) 56 data bytes
From 2620:52:{A}:{B}::3fc (2620:52:{A}:{B}::3fc) icmp_seq=1 Destination unreachable: Address unreachable
--- d0.org.afilias-nst.org. ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3152BIND does not iterate over the authoritative nameservers, if the first (or on...2022-07-21T10:21:41ZThomas AmgartenBIND does not iterate over the authoritative nameservers, if the first (or one) responds with a FORMERR### Summary
BIND stops iterating/querying over the list of authoritative nameserver for a domain, if it reaches one, which responds with a FORMERR or misbehaves in another way (lame-server). This misleads then to a SERVFAIL response.
#...### Summary
BIND stops iterating/querying over the list of authoritative nameserver for a domain, if it reaches one, which responds with a FORMERR or misbehaves in another way (lame-server). This misleads then to a SERVFAIL response.
### BIND version used
9.18.0
### Steps to reproduce
**BIND-9.18.0**
```
$ dig @127.0.0.1 www.owkb.ch
; <<>> DiG 9.18.0 <<>> @127.0.0.1 www.owkb.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36528
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6aa7ff83c845470901000000620b7d343b1a9d8a88fbf0d9 (good)
;; QUESTION SECTION:
;www.owkb.ch. IN A
;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Feb 15 11:15:16 CET 2022
;; MSG SIZE rcvd: 68
```
BIND is logging the following message:
```
15-Feb-2022 11:33:07.667 resolver: notice: DNS format error from 77.109.136.195#53 resolving owkb.ch/DNSKEY for <unknown>: server sent FORMERR
15-Feb-2022 11:33:07.667 lame-servers: info: broken trust chain resolving 'www.owkb.ch/A/IN': 185.206.180.142#53
```
But in the case above, when BIND would try to reach all authoritative servers (and not just stops after the misbehaving ones), then it should be able to verify DNSSEC and responds properly back to the client.
See the ouput from 9.16.25 below:
**BIND-9.16.25**
```
$ dig @127.0.0.1 www.owkb.ch
; <<>> DiG 9.16.25 <<>> @127.0.0.1 www.owkb.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39897
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 273929569b369f3d01000000620b7d7914c334213c48199b (good)
;; QUESTION SECTION:
;www.owkb.ch. IN A
;; ANSWER SECTION:
www.owkb.ch. 600 IN A 45.81.71.30
;; Query time: 109 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 15 11:16:25 CET 2022
;; MSG SIZE rcvd: 84
```
### What is the current *bug* behavior?
To point out, where/what the problem could be:
**Getting a list of all authoritative NS for "owkb.ch"**
```
$ dig @a.nic.ch +norec +noall +add ns owkb.ch | grep -v AAAA
ns4.securedns.ch. 3600 IN A 185.206.180.142
ns3.securedns.ch. 3600 IN A 77.109.136.195
ns2.securedns.ch. 3600 IN A 91.194.196.37
ns1.securedns.ch. 3600 IN A 91.194.196.36
```
**FORMERR with cookies for server 91.194.196.36**
```
$ dig @91.194.196.36 +noall +comments +norec www.owkb.ch
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 24006
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e19b7e7d84c089e4 (echoed)
```
**FORMERR with cookies for server 91.194.196.37**
```
$ dig @91.194.196.37 +noall +comments +norec www.owkb.ch
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 2743
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 56e9d26b88d25fe1 (echoed)
```
**FORMERR with cookies for server 77.109.136.195**
```
$ dig @77.109.136.195 +noall +comments +norec www.owkb.ch
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 44738
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6f279bcb6f849430 (echoed)
```
**Response OK (with cookies) for server 185.206.180.142**
```
$ dig @185.206.180.142 +noall +comments +norec www.owkb.ch
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9053
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
```
In the case above, only the authoritative server with the IP address "185.206.180.142" works properly with Cookies.
But: When I query a misbehaving server without cookies, then I got proper answer:
**Querying a misbehaving server without cookies**
```
$ dig @91.194.196.36 +noall +comments +norec +nocookie www.owkb.ch
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61017
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 400
```
So, the current issue and my assumption now is (as a difference to BIND-9.16.25, where this worked well) that BIND-9.18.0 doesn't re-query the authoritative servers without EDNS/Cookies and doesn't iterate over the nameserver, if one responds with a failure. I agree, that only one of the mentioned four authoritative nameserver is working properly here, but I'm not sure, if BIND's behavior here is correct.
### What is the expected *correct* behavior?
The 9.16.25-behavior. I'm, expecting, that BIND should iterate over the NS-RRset and should try to query all authoritative nameservers.
### Relevant configuration files
To prove my assumption, please have a look to the following snippets:
**resolution_not_working.txt:** Trace from a freshly started BIND-9.18.0, where we can see, that BIND-9.18.0 doesn't query the other authoritative nameservers, when it receives a FORMERR
<details><summary>resolution_not_working.txt</summary>
```
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.236.1 10.100.102.21 DNS 94 Standard query 0x4c24 A www.owkb.ch OPT
2 0.000697 10.100.102.21 199.7.83.42 DNS 87 Standard query 0x1f0c A _.ch OPT
3 0.006673 199.7.83.42 10.100.102.21 DNS 714 Standard query response 0x1f0c A _.ch NS a.nic.ch NS b.nic.ch NS d.nic.ch NS e.nic.ch NS f.nic.ch DS RRSIG A 130.59.31.41 A 130.59.31.43 A 194.0.25.39 A 194.0.17.1 A 194.146.106.10 AAAA 2001:620:0:ff::56 AAAA 2001:620:0:ff::58 AAAA 2001:678:20::39 AAAA 2001:678:3::1 AAAA 2001:67c:1010:2::53 OPT
4 0.007058 10.100.102.21 194.0.17.1 DNS 92 Standard query 0xb956 A _.owkb.ch OPT
5 0.008952 194.0.17.1 10.100.102.21 DNS 486 Standard query response 0xb956 A _.owkb.ch NS ns3.securedns.ch NS ns1.securedns.ch NS ns2.securedns.ch NS ns4.securedns.ch DS RRSIG A 185.206.180.142 A 77.109.136.195 A 91.194.196.37 A 91.194.196.36 AAAA 2001:1620:20ad:200::37 AAAA 2a01:6980:aca9:100::22 AAAA 2a01:6980:aca9:100::21 OPT
6 0.009227 10.100.102.21 91.194.196.36 DNS 94 Standard query 0x558d A www.owkb.ch OPT
7 0.012826 91.194.196.36 10.100.102.21 DNS 94 Standard query response 0x558d Format error A www.owkb.ch OPT
8 0.013053 10.100.102.21 192.168.236.1 DNS 110 Standard query response 0x4c24 Server failure A www.owkb.ch OPT
```
</details>
**resolution_working.txt:** Trace from a freshly started BIND-9.16.25, where we can see, that BIND-9.16.25 does query the other authoritative nameserver and also query without EDNS, when a FORMERR is received.
<details><summary>resolution_working.txt</summary>
```
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.236.1 10.100.102.21 DNS 94 Standard query 0xb2e0 A www.owkb.ch OPT
2 0.000474 10.100.102.21 199.7.91.13 DNS 87 Standard query 0xe325 A _.ch OPT
3 0.002459 199.7.91.13 10.100.102.21 DNS 542 Standard query response 0xe325 A _.ch NS a.nic.ch NS b.nic.ch NS d.nic.ch NS e.nic.ch NS f.nic.ch DS RRSIG A 130.59.31.41 A 130.59.31.43 A 194.0.25.39 OPT
4 0.003004 10.100.102.21 130.59.31.41 DNS 92 Standard query 0xa6d6 A _.owkb.ch OPT
5 0.003030 10.100.102.21 192.112.36.4 DNS 91 Standard query 0x1bc1 A e.nic.ch OPT
6 0.003081 10.100.102.21 192.112.36.4 DNS 91 Standard query 0xb193 A f.nic.ch OPT
7 0.005370 130.59.31.41 10.100.102.21 DNS 458 Standard query response 0xa6d6 A _.owkb.ch NS ns3.securedns.ch NS ns1.securedns.ch NS ns2.securedns.ch NS ns4.securedns.ch DS RRSIG A 185.206.180.142 A 77.109.136.195 A 91.194.196.37 A 91.194.196.36 AAAA 2001:1620:20ad:200::37 AAAA 2a01:6980:aca9:100::22 AAAA 2a01:6980:aca9:100::21 OPT
8 0.006457 10.100.102.21 91.194.196.37 DNS 94 Standard query 0xc8f7 A www.owkb.ch OPT
9 0.010055 91.194.196.37 10.100.102.21 DNS 94 Standard query response 0xc8f7 Format error A www.owkb.ch OPT
10 0.010413 10.100.102.21 91.194.196.37 DNS 71 Standard query 0xa777 A www.owkb.ch
11 0.013931 91.194.196.37 10.100.102.21 DNS 87 Standard query response 0xa777 A www.owkb.ch A 45.81.71.30
12 0.014416 10.100.102.21 130.59.31.43 DNS 85 Standard query 0x255b DNSKEY ch OPT
13 0.019445 130.59.31.43 10.100.102.21 DNS 411 Standard query response 0x255b DNSKEY ch DNSKEY DNSKEY DNSKEY RRSIG OPT
14 0.020095 192.112.36.4 10.100.102.21 DNS 554 Standard query response 0x1bc1 A e.nic.ch NS f.nic.ch NS e.nic.ch NS b.nic.ch NS d.nic.ch NS a.nic.ch DS RRSIG A 194.0.17.1 A 194.146.106.10 OPT
15 0.020215 192.112.36.4 10.100.102.21 DNS 554 Standard query response 0xb193 A f.nic.ch NS a.nic.ch NS b.nic.ch NS f.nic.ch NS e.nic.ch NS d.nic.ch DS RRSIG A 194.146.106.10 A 194.0.17.1 OPT
16 0.020515 10.100.102.21 91.194.196.36 DNS 94 Standard query 0xcb0f DS www.owkb.ch OPT
17 0.020753 10.100.102.21 194.146.106.10 DNS 91 Standard query 0x8afc A e.nic.ch OPT
18 0.020891 10.100.102.21 194.146.106.10 DNS 91 Standard query 0x4113 A f.nic.ch OPT
19 0.024610 91.194.196.36 10.100.102.21 DNS 94 Standard query response 0xcb0f Format error DS www.owkb.ch OPT
20 0.024855 10.100.102.21 91.194.196.36 DNS 71 Standard query 0xaf3f DS www.owkb.ch
21 0.028338 91.194.196.36 10.100.102.21 DNS 144 Standard query response 0xaf3f DS www.owkb.ch SOA ns1.securedns.ch
22 0.028730 10.100.102.21 185.206.180.142 DNS 94 Standard query 0x000d DS www.owkb.ch OPT
23 0.031501 194.146.106.10 10.100.102.21 DNS 221 Standard query response 0x8afc A e.nic.ch A 194.0.17.1 RRSIG OPT
24 0.031634 194.146.106.10 10.100.102.21 DNS 221 Standard query response 0x4113 A f.nic.ch A 194.146.106.10 RRSIG OPT
25 0.055298 185.206.180.142 10.100.102.21 DNS 82 Standard query response 0x000d DS www.owkb.ch OPT
26 0.055582 10.100.102.21 185.206.180.142 TCP 66 33505 → 53 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
27 0.082008 185.206.180.142 10.100.102.21 TCP 66 53 → 33505 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
28 0.082055 10.100.102.21 185.206.180.142 TCP 54 33505 → 53 [ACK] Seq=1 Ack=1 Win=29312 Len=0
29 0.082222 10.100.102.21 185.206.180.142 DNS 108 Standard query 0x5f79 DS www.owkb.ch OPT
30 0.108949 185.206.180.142 10.100.102.21 TCP 60 53 → 33505 [ACK] Seq=1 Ack=55 Win=29312 Len=0
31 0.109262 185.206.180.142 10.100.102.21 DNS 592 Standard query response 0x5f79 DS www.owkb.ch SOA ns1.securedns.ch RRSIG NSEC3 RRSIG OPT
32 0.109283 10.100.102.21 185.206.180.142 TCP 54 33505 → 53 [ACK] Seq=55 Ack=539 Win=30336 Len=0
33 0.109695 10.100.102.21 185.206.180.142 TCP 54 33505 → 53 [FIN, ACK] Seq=55 Ack=539 Win=30336 Len=0
34 0.109863 10.100.102.21 77.109.136.195 DNS 90 Standard query 0x8060 DNSKEY owkb.ch OPT
35 0.112018 77.109.136.195 10.100.102.21 DNS 90 Standard query response 0x8060 Format error DNSKEY owkb.ch OPT
36 0.112283 10.100.102.21 77.109.136.195 DNS 67 Standard query 0x6eef DNSKEY owkb.ch
37 0.114336 77.109.136.195 10.100.102.21 DNS 491 Standard query response 0x6eef DNSKEY owkb.ch DNSKEY DNSKEY
38 0.114612 10.100.102.21 77.109.136.195 TCP 66 52793 → 53 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
39 0.116673 77.109.136.195 10.100.102.21 TCP 66 53 → 52793 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
40 0.116702 10.100.102.21 77.109.136.195 TCP 54 52793 → 53 [ACK] Seq=1 Ack=1 Win=29312 Len=0
41 0.116786 10.100.102.21 77.109.136.195 DNS 81 Standard query 0xaf6f DNSKEY owkb.ch
42 0.118761 77.109.136.195 10.100.102.21 DNS 653 Standard query response 0xaf6f DNSKEY owkb.ch DNSKEY DNSKEY DNSKEY
43 0.118781 10.100.102.21 77.109.136.195 TCP 54 52793 → 53 [ACK] Seq=28 Ack=600 Win=30464 Len=0
44 0.119068 10.100.102.21 91.194.196.37 DNS 67 Standard query 0x7420 DNSKEY owkb.ch
45 0.119098 10.100.102.21 77.109.136.195 TCP 54 52793 → 53 [FIN, ACK] Seq=28 Ack=600 Win=30464 Len=0
46 0.120844 77.109.136.195 10.100.102.21 TCP 60 53 → 52793 [ACK] Seq=600 Ack=29 Win=65536 Len=0
47 0.120872 77.109.136.195 10.100.102.21 TCP 60 53 → 52793 [FIN, ACK] Seq=600 Ack=29 Win=65536 Len=0
48 0.120889 10.100.102.21 77.109.136.195 TCP 54 52793 → 53 [ACK] Seq=29 Ack=601 Win=30464 Len=0
49 0.122745 91.194.196.37 10.100.102.21 DNS 491 Standard query response 0x7420 DNSKEY owkb.ch DNSKEY DNSKEY
50 0.122926 10.100.102.21 91.194.196.37 TCP 66 42337 → 53 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
51 0.126422 91.194.196.37 10.100.102.21 TCP 66 53 → 42337 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
52 0.126445 10.100.102.21 91.194.196.37 TCP 54 42337 → 53 [ACK] Seq=1 Ack=1 Win=29312 Len=0
53 0.126515 10.100.102.21 91.194.196.37 DNS 81 Standard query 0xdc41 DNSKEY owkb.ch
54 0.129737 91.194.196.37 10.100.102.21 DNS 653 Standard query response 0xdc41 DNSKEY owkb.ch DNSKEY DNSKEY DNSKEY
55 0.129762 10.100.102.21 91.194.196.37 TCP 54 42337 → 53 [ACK] Seq=28 Ack=600 Win=30464 Len=0
56 0.130084 10.100.102.21 91.194.196.36 DNS 67 Standard query 0x8478 DNSKEY owkb.ch
57 0.130110 10.100.102.21 91.194.196.37 TCP 54 42337 → 53 [FIN, ACK] Seq=28 Ack=600 Win=30464 Len=0
58 0.133226 91.194.196.37 10.100.102.21 TCP 60 53 → 42337 [ACK] Seq=600 Ack=29 Win=131328 Len=0
59 0.133307 91.194.196.37 10.100.102.21 TCP 60 53 → 42337 [FIN, ACK] Seq=600 Ack=29 Win=131328 Len=0
60 0.133320 10.100.102.21 91.194.196.37 TCP 54 42337 → 53 [ACK] Seq=29 Ack=601 Win=30464 Len=0
61 0.133791 91.194.196.36 10.100.102.21 DNS 491 Standard query response 0x8478 DNSKEY owkb.ch DNSKEY DNSKEY
62 0.133992 10.100.102.21 91.194.196.36 TCP 66 35661 → 53 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
63 0.136092 185.206.180.142 10.100.102.21 TCP 60 53 → 33505 [FIN, ACK] Seq=539 Ack=56 Win=29312 Len=0
64 0.136107 10.100.102.21 185.206.180.142 TCP 54 33505 → 53 [ACK] Seq=56 Ack=540 Win=30336 Len=0
65 0.137485 91.194.196.36 10.100.102.21 TCP 66 53 → 35661 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
66 0.137509 10.100.102.21 91.194.196.36 TCP 54 35661 → 53 [ACK] Seq=1 Ack=1 Win=29312 Len=0
67 0.137596 10.100.102.21 91.194.196.36 DNS 81 Standard query 0x818d DNSKEY owkb.ch
68 0.140906 91.194.196.36 10.100.102.21 DNS 653 Standard query response 0x818d DNSKEY owkb.ch DNSKEY DNSKEY DNSKEY
69 0.140927 10.100.102.21 91.194.196.36 TCP 54 35661 → 53 [ACK] Seq=28 Ack=600 Win=30464 Len=0
70 0.141225 10.100.102.21 185.206.180.142 DNS 90 Standard query 0x2e6b DNSKEY owkb.ch OPT
71 0.141252 10.100.102.21 91.194.196.36 TCP 54 35661 → 53 [FIN, ACK] Seq=28 Ack=600 Win=30464 Len=0
72 0.144281 91.194.196.36 10.100.102.21 TCP 60 53 → 35661 [ACK] Seq=600 Ack=29 Win=131328 Len=0
73 0.144299 91.194.196.36 10.100.102.21 TCP 60 53 → 35661 [FIN, ACK] Seq=600 Ack=29 Win=131328 Len=0
74 0.144313 10.100.102.21 91.194.196.36 TCP 54 35661 → 53 [ACK] Seq=29 Ack=601 Win=30464 Len=0
75 0.167684 185.206.180.142 10.100.102.21 DNS 1112 Standard query response 0x2e6b DNSKEY owkb.ch DNSKEY DNSKEY DNSKEY RRSIG RRSIG OPT
76 0.168504 10.100.102.21 91.194.196.36 DNS 94 Standard query 0xabcf A www.owkb.ch OPT
77 0.172171 91.194.196.36 10.100.102.21 DNS 94 Standard query response 0xabcf Format error A www.owkb.ch OPT
78 0.172415 10.100.102.21 91.194.196.36 DNS 71 Standard query 0xa4d9 A www.owkb.ch
79 0.175976 91.194.196.36 10.100.102.21 DNS 87 Standard query response 0xa4d9 A www.owkb.ch A 45.81.71.30
80 0.176349 10.100.102.21 185.206.180.142 DNS 94 Standard query 0x22ac A www.owkb.ch OPT
81 0.202836 185.206.180.142 10.100.102.21 DNS 265 Standard query response 0x22ac A www.owkb.ch A 45.81.71.30 RRSIG OPT
82 0.203274 10.100.102.21 192.168.236.1 DNS 126 Standard query response 0xb2e0 A www.owkb.ch A 45.81.71.30 OPT
```
</details>July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3143Local addresses are missing from dnstap captures of resolver traffic2023-09-28T15:01:51ZMichał KępieńLocal addresses are missing from dnstap captures of resolver trafficSince !4601 was merged, the following dnstap output is produced by
`named` in the default configuration when a resolver is queried for
`pl/DNSKEY` (only resolver traffic was included for clarity):
<details>
<summary>named -6</summary>
...Since !4601 was merged, the following dnstap output is produced by
`named` in the default configuration when a resolver is queried for
`pl/DNSKEY` (only resolver traffic was included for clarity):
<details>
<summary>named -6</summary>
```
10-Feb-2022 17:55:08.521 RQ :::36241 -> 2001:503:c27::2:30:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:55:08.521 RQ :::53541 -> 2001:503:c27::2:30:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:08.601 RR :::36241 <- 2001:503:c27::2:30:53 UDP 864b ./IN/DNSKEY
10-Feb-2022 17:55:09.317 RQ :::34801 -> 2001:503:c27::2:30:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:09.404 RR :::34801 <- 2001:503:c27::2:30:53 UDP 845b ./IN/NS
10-Feb-2022 17:55:12.617 RQ :::41106 -> 2001:503:ba3e::2:30:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:12.617 RQ :::51237 -> 2001:503:ba3e::2:30:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:12.640 RR :::41106 <- 2001:503:ba3e::2:30:53 UDP 1097b ./IN/NS
10-Feb-2022 17:55:12.640 RR :::51237 <- 2001:503:ba3e::2:30:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:55:12.640 RQ :::37509 -> 2620:10a:80aa::48:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:12.640 RQ :::47186 -> 2001:500:2d::d:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.640 RR :::47186 <- 2001:500:2d::d:53 UDP 914b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.644 RQ :::43215 -> 2620:10a:80aa::48:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.667 RR :::37509 <- 2620:10a:80aa::48:53 UDP 31b pl/IN/DNSKEY
10-Feb-2022 17:55:12.674 RR :::43215 <- 2620:10a:80aa::48:53 UDP 761b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.667 RQ :::0 -> 2620:10a:80aa::48:53 TCP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:12.720 RR :::0 <- 2620:10a:80aa::48:53 TCP 1385b pl/IN/DNSKEY
```
</details>
<details>
<summary>named -4</summary>
```
10-Feb-2022 17:55:42.617 RQ 0.0.0.0:52361 -> 202.12.27.33:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:55:42.617 RQ 0.0.0.0:37000 -> 202.12.27.33:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:42.647 RR 0.0.0.0:52361 <- 202.12.27.33:53 UDP 864b ./IN/DNSKEY
10-Feb-2022 17:55:42.664 RR 0.0.0.0:37000 <- 202.12.27.33:53 UDP 1097b ./IN/NS
10-Feb-2022 17:55:45.890 RQ 0.0.0.0:58104 -> 193.0.14.129:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:45.894 RR 0.0.0.0:58104 <- 193.0.14.129:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:55:45.894 RQ 0.0.0.0:53854 -> 93.190.128.146:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:45.914 RR 0.0.0.0:53854 <- 93.190.128.146:53 UDP 59b pl/IN/DNSKEY
10-Feb-2022 17:55:45.914 RQ 0.0.0.0:0 -> 93.190.128.146:53 TCP 59b pl/IN/DNSKEY
10-Feb-2022 17:55:45.954 RR 0.0.0.0:0 <- 93.190.128.146:53 TCP 1413b pl/IN/DNSKEY
```
</details>
Meanwhile, the expected output (as produced by BIND 9.16 and older
versions) looks more like this:
<details>
<summary>named -6</summary>
```
10-Feb-2022 17:57:44.523 RQ 2001:470:64df:111::e02:52125 -> 2001:500:200::b:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:57:44.523 RQ 2001:470:64df:111::e02:48774 -> 2001:500:200::b:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:44.583 RR 2001:470:64df:111::e02:52125 <- 2001:500:200::b:53 UDP 56b ./IN/DNSKEY
10-Feb-2022 17:57:44.583 RR 2001:470:64df:111::e02:48774 <- 2001:500:200::b:53 UDP 56b ./IN/NS
10-Feb-2022 17:57:44.583 RQ 2001:470:64df:111::e02:39731 -> 2001:500:200::b:53 UDP 56b ./IN/DNSKEY
10-Feb-2022 17:57:44.583 RQ 2001:470:64df:111::e02:60246 -> 2001:500:200::b:53 UDP 56b ./IN/NS
10-Feb-2022 17:57:44.639 RR 2001:470:64df:111::e02:39731 <- 2001:500:200::b:53 UDP 892b ./IN/DNSKEY
10-Feb-2022 17:57:44.639 RR 2001:470:64df:111::e02:60246 <- 2001:500:200::b:53 UDP 1229b ./IN/NS
10-Feb-2022 17:57:47.643 RQ 2001:470:64df:111::e02:55999 -> 2001:500:2::c:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:47.643 RQ 2001:470:64df:111::e02:47594 -> 2001:500:2::c:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:48.446 RQ 2001:470:64df:111::e02:41403 -> 2001:500:2::c:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:48.446 RQ 2001:470:64df:111::e02:49003 -> 2001:500:2::c:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:49.246 RQ 2001:470:64df:111::e02:49059 -> 2001:500:2::c:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:49.246 RQ 2001:470:64df:111::e02:51667 -> 2001:500:2::c:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:51.513 RQ 2001:470:64df:111::e02:54552 -> 2001:dc3::35:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:51.513 RQ 2001:470:64df:111::e02:47949 -> 2001:dc3::35:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:51.579 RR 2001:470:64df:111::e02:54552 <- 2001:dc3::35:53 UDP 1097b ./IN/NS
10-Feb-2022 17:57:51.583 RQ 2001:470:64df:111::e02:49651 -> 2001:7fe::53:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.579 RR 2001:470:64df:111::e02:47949 <- 2001:dc3::35:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:57:51.643 RR 2001:470:64df:111::e02:49651 <- 2001:7fe::53:53 UDP 942b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.583 RQ 2001:470:64df:111::e02:44144 -> 2001:a10:121:1::156:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:51.643 RQ 2001:470:64df:111::e02:56067 -> 2620:10a:80aa::48:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.633 RR 2001:470:64df:111::e02:44144 <- 2001:a10:121:1::156:53 UDP 59b pl/IN/DNSKEY
10-Feb-2022 17:57:51.709 RR 2001:470:64df:111::e02:56067 <- 2620:10a:80aa::48:53 UDP 761b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.633 RQ 2001:470:64df:111::e02:34815 -> 2001:a10:121:1::156:53 TCP 59b pl/IN/DNSKEY
10-Feb-2022 17:57:51.713 RR 2001:470:64df:111::e02:34815 <- 2001:a10:121:1::156:53 TCP 1413b pl/IN/DNSKEY
```
</details>
<details>
<summary>named -4</summary>
```
10-Feb-2022 17:58:17.419 RQ 192.168.111.245:60076 -> 202.12.27.33:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:58:17.419 RQ 192.168.111.245:35292 -> 202.12.27.33:53 UDP 40b ./IN/NS
10-Feb-2022 17:58:17.452 RR 192.168.111.245:35292 <- 202.12.27.33:53 UDP 1097b ./IN/NS
10-Feb-2022 17:58:17.452 RR 192.168.111.245:60076 <- 202.12.27.33:53 UDP 864b ./IN/DNSKEY
10-Feb-2022 17:58:18.749 RQ 192.168.111.245:37632 -> 199.7.83.42:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:58:18.769 RR 192.168.111.245:37632 <- 199.7.83.42:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:58:18.769 RQ 192.168.111.245:44178 -> 185.159.198.48:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:58:18.789 RR 192.168.111.245:44178 <- 185.159.198.48:53 UDP 31b pl/IN/DNSKEY
10-Feb-2022 17:58:18.789 RQ 192.168.111.245:45483 -> 185.159.198.48:53 TCP 43b pl/IN/DNSKEY
10-Feb-2022 17:58:18.832 RR 192.168.111.245:45483 <- 185.159.198.48:53 TCP 1385b pl/IN/DNSKEY
```
</details>
See also #4344July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3138Upload captured scripts to Coverity Scan for analysis2022-06-14T20:11:18ZMichal NowakUpload captured scripts to Coverity Scan for analysisCoverity Scan 2021.12.1 - to be released on February 13, 2022 - is going to support analysis of Python 3 scripts in addition to current PHP, Python 2, and Ruby ones. I expect the future version of the Coverity Build tool to leverage the ...Coverity Scan 2021.12.1 - to be released on February 13, 2022 - is going to support analysis of Python 3 scripts in addition to current PHP, Python 2, and Ruby ones. I expect the future version of the Coverity Build tool to leverage the [`--fs-capture-search <path/to/source/code>`](https://scan.coverity.com/download?tab=other) option and that's what we should add to CI.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3061ifconfig.sh down messes up loopback interfaces2022-07-07T08:35:47ZIan Donaldsonifconfig.sh down messes up loopback interfaces<!--
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
ifconfig.sh up works fine, but ifconfig.sh down doesn't undo things correctly
and messes up main loopback interface, leaves 2 test interfaces lying around
### BIND version used
This bug has been around for a long time but here is a build with it...
```
BIND 9.16.16 (Stable Release) <id:0c314d8>
running on SunOS i86pc 5.11 11.4.40.107.3
built by make with '--prefix=/opt/local/bind' '--mandir=/opt/local/man' '--with-python=/opt/local/bin/python3.8' 'CPPFLAGS=-I/usr/include/kerberosv5'
compiled by GCC 7.3.0
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20912
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /opt/local/bind/etc/named.conf
rndc configuration: /opt/local/bind/etc/rndc.conf
DNSSEC root key: /opt/local/bind/etc/bind.keys
nsupdate session key: /opt/local/bind/var/run/named/session.key
named PID file: /opt/local/bind/var/run/named/named.pid
named lock file: /opt/local/bind/var/run/named/named.lock
```
Also present in 9.16.24
### Steps to reproduce
as root:
```
bin/tests/system/ifconfig.sh up
ordinarily a 'make test' would be done here...
bin/tests/system/ifconfig.sh down
```
### What is the current *bug* behavior?
```
ifconfig -a
lo0: flags=3001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,FIXEDMTU,VIRTUAL> mtu 1500 index 1
inet 127.0.0.1 netmask ff000000
...
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
...
bin/tests/system/ifconfig.sh up
bin/tests/system/ifconfig.sh down
ifconfig: could not create address: Can't assign requested address
ifconfig: cannot unplumb lo0:0: Invalid interface name
ifconfig: cannot unplumb lo0:0: Invalid interface name
ifconfig: could not create address: Can't assign requested address
ifconfig: could not create address: Can't assign requested address
ifconfig: setifaddr: SIOCGLIFNETMASK: lo0:20: no such interface
ifconfig: setifaddr: SIOCGLIFNETMASK: lo0:20: no such interface
ifconfig: setifflags: SIOCGLIFFLAGS: lo0:20: no such interface
ifconfig: cannot unplumb lo0:20: No such interface
ifconfig -a
lo0: flags=3001000848<LOOPBACK,RUNNING,MULTICAST,IPv4,FIXEDMTU,VIRTUAL> mtu 1500 index 1
inet 10.53.0.1 netmask ff000000
lo0:12: flags=3001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,FIXEDMTU,VIRTUAL> mtu 1500 index 1
inet 10.53.1.2 netmask ff000000
lo0:22: flags=3001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,FIXEDMTU,VIRTUAL> mtu 1500 index 1
inet 10.53.2.2 netmask ff000000
...
lo0: flags=2002000848<LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
lo0:12: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 fd92:7065:b8e:99ff::2/64
lo0:22: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 fd92:7065:b8e:ff::2/64
...
```
Note lo0 is down and lo12, lo22 are lying around still.
Fixed via:
```
ifconfig lo0 127.0.0.1 up
ifconfig lo0:12 down unplumb
ifconfig lo0:22 down unplumb
ifconfig lo0 inet6 up
ifconfig lo0:12 inet6 down unplumb
ifconfig lo0:22 inet6 down unplumb
```
### What is the expected *correct* behavior?
ifconfig -a before and after should look the same; lo0 shouldn't be touched
### Relevant configuration files
none
### Relevant logs and/or screenshots
### Possible fixes
Trivial fix; remove "-1" in the down section for int calculation.
Also make down do things in same order as up; don't see any advantage to doing
it in reverse order.
diff is against 9.16.24 release
```
*** bin/tests/system/ifconfig.sh.orig Tue Dec 7 12:24:49 2021
--- bin/tests/system/ifconfig.sh Fri Dec 17 03:33:55 2021
***************
*** 160,169 ****
2) ipv6="00" ;;
*) ipv6="" ;;
esac
! for ns in 10 9 8 7 6 5 4 3 2 1
do
[ $i -gt 0 -a $ns -gt 2 ] && continue
! int=`expr $i \* 10 + $ns - 1`
case "$sys" in
*-pc-solaris2.5.1)
ifconfig lo0:$int 0.0.0.0 down
--- 160,169 ----
2) ipv6="00" ;;
*) ipv6="" ;;
esac
! for ns in 1 2 3 4 5 6 7 8 9 10
do
[ $i -gt 0 -a $ns -gt 2 ] && continue
! int=`expr $i \* 10 + $ns`
case "$sys" in
*-pc-solaris2.5.1)
ifconfig lo0:$int 0.0.0.0 down
```July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Mark AndrewsMark Andrews