ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-06-14T09:57:49Zhttps://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/3398Possible race between resolver query timeout and validation in BIND 9.162022-07-04T20:08:18ZArаm SаrgsyаnPossible race between resolver query timeout and validation in BIND 9.16A customer's BIND 9.6.27 `named` instance has crashed after days of working.
Here is the backtrace:
```
Thread 1 (Thread 0x7faa1ecba700 (LWP 2298)):
#0 0x00007faa22f2b5f7 in raise () from /lib64/libc.so.6
#1 0x00007faa22f2cce8 in abo...A customer's BIND 9.6.27 `named` instance has crashed after days of working.
Here is the backtrace:
```
Thread 1 (Thread 0x7faa1ecba700 (LWP 2298)):
#0 0x00007faa22f2b5f7 in raise () from /lib64/libc.so.6
#1 0x00007faa22f2cce8 in abort () from /lib64/libc.so.6
#2 0x000000000042ac65 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>,
cond=<optimized out>) at ./main.c:272
#3 0x00007faa2477afea in isc_assertion_failed (file=file@entry=0x7faa25b66c3f "resolver.c", line=line@entry=4561,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7faa25b67660 "(__builtin_expect(!!((fctx) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(fctx))->magic == ((('F') << 24 | ('!') << 16 | ('!') << 8 | ('!')))), 1))") at assertions.c:48
#4 0x00007faa25ab2aee in fctx_unlink (fctx=fctx@entry=0x7fa9b9b27ab0) at resolver.c:4561
#5 0x00007faa25ab4532 in maybe_destroy (fctx=fctx@entry=0x7fa9b9b27ab0, locked=true) at resolver.c:5722
#6 0x00007faa25ac1728 in validated (task=<optimized out>, event=0x7fa854ad0f60) at resolver.c:5815
#7 0x00007faa247aa0fe in task_run (task=0x7fa7db68a690) at task.c:851
#8 isc_task_run (task=0x7fa7db68a690) at task.c:944
#9 0x00007faa2478ebfd in isc__nm_async_task (ev0=ev0@entry=0x7fa977674df0, worker=0x1669e40) at netmgr.c:873
#10 0x00007faa24794598 in process_netievent (worker=worker@entry=0x1669e40, ievent=0x7fa977674df0) at netmgr.c:952
#11 0x00007faa24794779 in process_queue (worker=worker@entry=0x1669e40, type=type@entry=NETIEVENT_TASK) at netmgr.c:1021
#12 0x00007faa24794ec3 in process_all_queues (worker=0x1669e40) at netmgr.c:792
#13 async_cb (handle=0x166a1a0) at netmgr.c:821
#14 0x00007faa23dbb4b3 in uv__async_io () from /lib64/libuv.so.1
#15 0x00007faa23dce983 in uv__io_poll () from /lib64/libuv.so.1
#16 0x00007faa23dbbc88 in uv_run () from /lib64/libuv.so.1
#17 0x00007faa2479482f in nm_thread (worker0=0x1669e40) at netmgr.c:727
#18 0x00007faa247ac845 in isc__trampoline_run (arg=0x190d2d0) at trampoline.c:198
#19 0x00007faa232bedc5 in start_thread () from /lib64/libpthread.so.0
#20 0x00007faa22fec1cd in clone () from /lib64/libc.so.6
```
Here's only the most important part isolated:
```
#3 0x00007faa2477afea in isc_assertion_failed (file=file@entry=0x7faa25b66c3f "resolver.c", line=line@entry=4561,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7faa25b67660 "(__builtin_expect(!!((fctx) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(fctx))->magic == ((('F') << 24 | ('!') << 16 | ('!') << 8 | ('!')))), 1))") at assertions.c:48
#4 0x00007faa25ab2aee in fctx_unlink (fctx=fctx@entry=0x7fa9b9b27ab0) at resolver.c:4561
#5 0x00007faa25ab4532 in maybe_destroy (fctx=fctx@entry=0x7fa9b9b27ab0, locked=true) at resolver.c:5722
#6 0x00007faa25ac1728 in validated (task=<optimized out>, event=0x7fa854ad0f60) at resolver.c:5815
#7 0x00007faa247aa0fe in task_run (task=0x7fa7db68a690) at task.c:851
```
Both in the beginning of `validated()` and in the beginning of `fctx_unlink()` there is a `REQUIRE(VALID_FCTX(fctx));` check. The first one passed successfully, while the second one caused a crash.
So somewhere between `validated()` and `fctx_unlink()`, the fetch context (`fctx`) was unexpectedly destroyed.
# Destroyed in the same thread? (not likely)
There can be two scenarios - either this happened during the execution of the same callback (should be easy to find), or another thread interfered and destroyed the context while `validated()` was doing its job. So let's start with the first one. For a moment it seemed that there is such a code path leading to a double `fctx_destroy()`:
```
validated() -> maybe_destroy() -> dns_validator_cancel() -> dns_resolver_destroyfetch() -> fctx_decreference() -> fctx_destroy()
-> fctx_destroy()
```
But the problem is that before calling `dns_validator_cancel()`, the `maybe_destroy()` makes sure that the bucket is locked:
```c
bucketnum = fctx->bucketnum;
if (!locked) {
LOCK(&res->buckets[bucketnum].lock);
}
```
... and `dns_resolver_destroyfetch()` also locks that same bucket:
```c
FTRACE("destroyfetch");
bucketnum = fctx->bucketnum;
LOCK(&res->buckets[bucketnum].lock);
```
But we actually do not experience any deadlocks, which most likely means that this exact code path never(?) executes.
# A multi-threading error?
Can two different tasks (threads) work with (and try to destroy) the same fetch context? All the fetch callbacks are running on the same task (derived from the bucket number), apart from the final callback which runs on a task chosen by the creator of the fetch.
So I can only imagine the following scenario how this could have happened:
1. [T1] The fetch times out, the timeout callback `fctx_timeout()` gets called, which initiates sending the final timeout event of the fetch to the creator's callback, through `fctx_done()` -> `fctx_sendevents()`.
2. [T1] Simultaneously, a validation completes so then the task starts executing the `validated()` function.
3. [T1] `validated()` locks the bucket lock, unlinks the current validator from the `fctx->validators` list (which happens to clear the list), destroys the validator, and for a short moment unlocks the bucket lock.
4. [T2] At that same brief moment, the creator's final callback sees that there are no more active fetches on `fctx`, and the `fctx->validators` list is empty, so it destroys the fetch context.
5. [T1] `validated()` locks the bucket lock again, calls `maybe_destroy()` which tries to destroy the fetch context again, and so it crashes.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/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/3392CID 352554: Null pointer dereferences (REVERSE_INULL) /bin/dig/dighost.c: 3...2022-06-07T10:26:49ZArаm SаrgsyаnCID 352554: Null pointer dereferences (REVERSE_INULL) /bin/dig/dighost.c: 3056 in start_tcp()A new Coverity report. This is quite benign, the check (which is not needed) was introduced in e37b782c.
```
1 new defect(s) introduced to bind-master found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 d...A new Coverity report. This is quite benign, the check (which is not needed) was introduced in e37b782c.
```
1 new defect(s) introduced to bind-master found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 352554: Null pointer dereferences (REVERSE_INULL)
/bin/dig/dighost.c: 3056 in start_tcp()
________________________________________________________________________________________________________
*** CID 352554: Null pointer dereferences (REVERSE_INULL)
/bin/dig/dighost.c: 3056 in start_tcp()
3050
3051 if (ISC_LINK_LINKED(query, link)) {
3052 next = ISC_LIST_NEXT(query, link);
3053 } else {
3054 next = NULL;
3055 }
>>> CID 352554: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "connectquery" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
3056 if (connectquery != NULL) {
3057 query_detach(&connectquery);
3058 }
3059 query_detach(&query);
3060 if (next == NULL) {
3061 clear_current_lookup();
```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/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/3380member zones are deleted if RRsig appears in the catalog zone2022-07-07T10:18:03ZTomas Velechmember zones are deleted if RRsig appears in the catalog zoneIf RRsig appears in the catalog zone, all member zones are immediately deleted. Affected version is Bind 9.16
```
general: warning: catz: unknown record in catalog zone - ff558fb7a97903f2e4ad534c6a6453b6139adefd.zones.prod-public.catal...If RRsig appears in the catalog zone, all member zones are immediately deleted. Affected version is Bind 9.16
```
general: warning: catz: unknown record in catalog zone - ff558fb7a97903f2e4ad534c6a6453b6139adefd.zones.prod-public.catalog IN RRSIG(failure) - ignoring
general: info: catz: deleting zone ‚example.com‘ from catalog 'prod-public.catalog' - success
general: warning: catz: catz_delzone_taskaction: zone ‚example.com‘ deleted
```
---
***Note from QA:** The labels on this issue are confusing because its
history is confusing, too. This problem also affected BIND 9.18+ in the
recent past, but it was inadvertently addressed by commit
0b2d5490cd8b17a01852fcd9e0a0e0c4b9c93ab6 (part of !6012, merged in May
2022). The problem is that we did not recognize at the time that that
commit fixes the issue which was reported here (only subsequently, and
for BIND 9.16) and therefore we did not announce that in the release
notes for May 2022 releases. The net result is that even though this
issue is not labeled with the ~"Affects v9.19" and ~"Affects v9.18"
labels, the [release note for this issue was put into all June 2022
releases][1] despite the fact that the problem was already solved in
BIND 9.18+ back in May 2022. In other words, a bit of historical
accuracy has been sacrificed in exchange for preventing confusion (to
some extent).*
[1]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6373#note_290000July 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/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/3357test_send_timeout fails on FreeBSD2022-07-07T08:06:04ZMichal Nowaktest_send_timeout fails on FreeBSD`test_send_timeout` of the `timeouts` system test fails on FreeBSD 13.0/13.1 with [DNS python 2.2.1](https://www.freshports.org/dns/py-dnspython/) on `v9_16` (and only there):
```
S:timeouts:2022-05-16T17:21:18+0000
T:timeouts:1:A
A:tim...`test_send_timeout` of the `timeouts` system test fails on FreeBSD 13.0/13.1 with [DNS python 2.2.1](https://www.freshports.org/dns/py-dnspython/) on `v9_16` (and only there):
```
S:timeouts:2022-05-16T17:21:18+0000
T:timeouts:1:A
A:timeouts:System test timeouts
I:timeouts:PORTRANGE:5300 - 5399
I:timeouts:starting servers
D:timeouts:============================= test session starts ==============================
D:timeouts:platform freebsd13 -- Python 3.8.13, pytest-4.6.11, py-1.9.0, pluggy-0.13.1 -- /usr/local/bin/python3.8
D:timeouts:cachedir: .pytest_cache
D:timeouts:hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/root/bind9/bin/tests/system/timeouts/.hypothesis/examples')
D:timeouts:rootdir: /root/bind9/bin/tests/system/timeouts
D:timeouts:plugins: hypothesis-6.28.0
D:timeouts:collecting ... collected 8 items
D:timeouts:
D:timeouts:tests-tcp.py::test_initial_timeout PASSED [ 12%]
D:timeouts:tests-tcp.py::test_idle_timeout PASSED [ 25%]
D:timeouts:tests-tcp.py::test_keepalive_timeout PASSED [ 37%]
D:timeouts:tests-tcp.py::test_pipelining_timeout PASSED [ 50%]
D:timeouts:tests-tcp.py::test_long_axfr PASSED [ 62%]
D:timeouts:tests-tcp.py::test_send_timeout FAILED [ 75%]
D:timeouts:tests-tcp.py::test_max_transfer_idle_out SKIPPED [ 87%]
D:timeouts:tests-tcp.py::test_max_transfer_time_out SKIPPED [100%]
D:timeouts:
D:timeouts:=================================== FAILURES ===================================
D:timeouts:______________________________ test_send_timeout _______________________________
D:timeouts:
D:timeouts:named_port = 5300
D:timeouts:
D:timeouts: def test_send_timeout(named_port):
D:timeouts: with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
D:timeouts: sock.connect(("10.53.0.1", named_port))
D:timeouts:
D:timeouts: # Send and receive single large RDATA over TCP
D:timeouts: msg = create_msg("large.example.", "TXT")
D:timeouts: (sbytes, stime) = dns.query.send_tcp(sock, msg, timeout())
D:timeouts: (response, rtime) = dns.query.receive_tcp(sock, timeout())
D:timeouts:
D:timeouts: # Send and receive 28 large (~32k) DNS queries that should
D:timeouts: # fill the default maximum 208k TCP send buffer
D:timeouts: for n in range(28):
D:timeouts: (sbytes, stime) = dns.query.send_tcp(sock, msg, timeout())
D:timeouts:
D:timeouts: # configure idle interval is 5 seconds, sleep 6 to make sure we are
D:timeouts: # above the interval
D:timeouts: time.sleep(6)
D:timeouts:
D:timeouts: with pytest.raises(EOFError):
D:timeouts: try:
D:timeouts: (sbytes, stime) = dns.query.send_tcp(sock, msg, timeout())
D:timeouts: (response, rtime) = dns.query.receive_tcp(sock, timeout())
D:timeouts: except ConnectionError as e:
D:timeouts:> raise EOFError from e
D:timeouts:E Failed: DID NOT RAISE <class 'EOFError'>
D:timeouts:
D:timeouts:tests-tcp.py:206: Failed
D:timeouts:================ 1 failed, 5 passed, 2 skipped in 69.28 seconds ================
I:timeouts:stopping servers
R:timeouts:FAIL
E:timeouts:2022-05-16T17:22:32+0000
```
This is [not yet visible in the CI](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2512908/raw) because FreeBSD images use DNS python 1.16.0 and `timeouts` system test requires DNS python v2.
The problem will be visible when FreeBSD images get rebuild (e.g. by FreeBSD 13.0 -> 13.1 upgrade).
Git bisect points to 7a386256b6e80520637583268b9e9fef5fe0f743, a backport of 6ddac2d56de980717aaba7fc0ad73af0f3890399, which is already linked to isc-projects/bind9#3214 and isc-projects/bind9#3283, but I don't see core files nor `uv_tcp_close_reset`-liked issues in `ns1/named.run`.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/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/3168Refactor recursion tracking in lib/ns/query.c2022-10-10T07:40:54ZMichał KępieńRefactor recursion tracking in lib/ns/query.cWhile #3147 was fixed with a change that should be safe to backport
(!5870 only touches statistics-related code), a number of problems in
`lib/ns/query.c` were identified while that problem was being
investigated:
1. [x] (!5882) Code d...While #3147 was fixed with a change that should be safe to backport
(!5870 only touches statistics-related code), a number of problems in
`lib/ns/query.c` were identified while that problem was being
investigated:
1. [x] (!5882) Code duplication.
2. [x] (!5883) Logically unrelated bits of code (e.g. prefetch and RPZ)
share common code paths (e.g. `prefetch_done()`) even
though they do not need to.
3. [x] (!5884) Various features able to initiate recursion use common
memory locations (e.g. `client->fetchhandle`,
`client->query.fetch`), which forces them all to
"cooperate" with each other even though they are all
logically separate.
4. [x] (!5885) One of the overloaded variables is
`client->recursionquota`, which causes recursion quota
to be handled inconsistently.
5. [x] (!5886) The `check_recursionquota()` function needs to be
cleaned up.
Unlike #3147, IMHO addressing the above issues is 9.19+ material due to
the amount of changes involved.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/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 Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2506Catalog zones ignores already loaded non primary zones on secondary2022-06-14T19:46:59ZChuck StearnsCatalog zones ignores already loaded non primary zones on secondarySequence of events:
1. A forward zone foo.com not loaded in named as part of named.conf on Primary;
2. A forward zone foo.com already loaded in named as part of named.conf on Secondary only.
3. A Primary zone foo.com is added to Catal...Sequence of events:
1. A forward zone foo.com not loaded in named as part of named.conf on Primary;
2. A forward zone foo.com already loaded in named as part of named.conf on Secondary only.
3. A Primary zone foo.com is added to Catalog Zones as primary zone on Primary server -- Success
4. Catalog zone transfer took place
5. Secondary servers added zone foo.com as Primary zone though Forward zone foo.com is already loaded.
According to the draft RFC for DNS Catalog Zones https://tools.ietf.org/html/draft-ietf-dnsop-dns-catalog-zones-01:
" If there is a clash between an existing member zone's name and an
incoming member zone's name (via transfer or update), the new
instance of the zone MUST be ignored and an error SHOULD be logged." (6.1)
It appears that the catalog zone code is probably checking the zone table for an existing zone called foo.com, but it's not checking the forwarder table.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/2371Add stress testing with RPZ2022-06-28T18:44:28ZMichal NowakAdd stress testing with RPZhttps://gitlab.isc.org/isc-private/bind-qa/-/issues/11 added RPZ to the stress test, https://gitlab.isc.org/isc-private/bind-qa/-/merge_requests/27 prepared stress test for GitLab CI. I recently run the code locally and it worked fine.
...https://gitlab.isc.org/isc-private/bind-qa/-/issues/11 added RPZ to the stress test, https://gitlab.isc.org/isc-private/bind-qa/-/merge_requests/27 prepared stress test for GitLab CI. I recently run the code locally and it worked fine.
The missing piece is to add stress test RPZ to the `performance` stage in CI. For that to happen, following items need to be addressed:
- [x] isc-private/devops#130 Let AWS stress test machines access 149.20.57.31
- [x] https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4526 Add RPZ stress test job for all supported platforms and maintained branches, seeJuly 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2147Remove the "glue-cache" option (not the feature!)2022-07-12T06:00:17ZMichał KępieńRemove the "glue-cache" option (not the feature!)This issue is meant to be a reminder about the plan for fully obsoleting
the `glue-cache` option in the 9.19 development cycle. See #2146 for
details - this separate issue was created so that we do not forget to
follow through with the ...This issue is meant to be a reminder about the plan for fully obsoleting
the `glue-cache` option in the 9.19 development cycle. See #2146 for
details - this separate issue was created so that we do not forget to
follow through with the removal schedule after the option gets
deprecated.
I set the due date for this issue rather arbitrarily, assuming we will
be in the 9.19 cycle at that time.July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michał KępieńMichał Kępień