BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-04-03T10:31:37Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3710ARM 9.18.9: Setting DF-Flag for outbound UDP packets is wrong documented2023-04-03T10:31:37ZThomas AmgartenARM 9.18.9: Setting DF-Flag for outbound UDP packets is wrong documented### Summary
ARM 9.18.9: DF-Flag for outbound UDP packets is wrong documented. As agreed on https://lists.isc.org/pipermail/bind-users/2022-November/107021.html, at least the following phrase in https://bind9.readthedocs.io/en/v9_18_9/ref...### Summary
ARM 9.18.9: DF-Flag for outbound UDP packets is wrong documented. As agreed on https://lists.isc.org/pipermail/bind-users/2022-November/107021.html, at least the following phrase in https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-edns-udp-size is no more correct:
> The named now sets the DON’T FRAGMENT flag on outgoing UDP packets.
Setting the DF-Flag (DON'T FRAGMENT) on the IP header for outbound UDP packets seems to be reverted in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4668/diffs, so the corresponding text should be adjusted.
### BIND version used
ARM 9.18.9
### Steps to reproduce
--
### What is the current *bug* behavior?
--
### What is the expected *correct* behavior?
--
### Relevant configuration files
--
### Relevant logs and/or screenshots
--
### Possible fixes
--April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3707named-checkzone change of behaviour in 9.16.352022-12-21T02:37:50ZThib Dnamed-checkzone change of behaviour in 9.16.35### Summary
Hello,
Not sure this is a bug of feature change, but since it wasn't mentioned in the changelog I believe this was not expected:
named-checkzone text output has changed in 9.16.35 (haven't tested on other new branches).
I...### Summary
Hello,
Not sure this is a bug of feature change, but since it wasn't mentioned in the changelog I believe this was not expected:
named-checkzone text output has changed in 9.16.35 (haven't tested on other new branches).
I believe this comes from this commit : https://gitlab.isc.org/isc-projects/bind9/-/commit/80e66fbd2d8a6dc581387116288f5d5c5cbcb0f6
### BIND version used
9.16.35
### Steps to reproduce
Run named-checkzone on a valid zone.
### What is the current *bug* behavior?
With 9.16.35 :
```
named-checkzone example.com named.example.com
zone example.com/IN: loaded serial 2022113010
OK
zone example.com/IN: final reference detached
```
### What is the expected *correct* behavior?
With 9.16.34 :
```
named-checkzone example.com named.example.com
zone example.com/IN: loaded serial 2022113010
OK
```
Not sure this line is relevant when performing a checkzone, and I'm pretty sure there are a few systems that use named-checkzone are parsing the output when running checkzones.
Best regards,
ThibaudDecember 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3702man page dig(1): Typo in options2022-12-02T11:39:31ZFabian P. Schmidtman page dig(1): Typo in optionsIn https://gitlab.isc.org/isc-projects/bind9/-/commit/ac0c2378cac7039afb8c717ca9038b1f70681ff3 a typo was introduced in the man page of dig(1) ([line 868](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/man/dig.1in#L868)):
> >...In https://gitlab.isc.org/isc-projects/bind9/-/commit/ac0c2378cac7039afb8c717ca9038b1f70681ff3 a typo was introduced in the man page of dig(1) ([line 868](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/man/dig.1in#L868)):
> > dig +qr www.isc.org any -x 127.0.0.1 isc.org ns **+noqr**
>
> shows how dig can be used from the command line to make three lookups: an ANY query for www.isc.org, a reverse lookup of 127.0.0.1, and a query for the NS records of isc.org. A global query option
> of +qr is applied, so that dig shows the initial query it made for each lookup. The final query has a local query option of **+qr** which means that dig does not print the initial query when it looks up
> the NS records for isc.org.
The second location emphasized in bold should link to `+noqr`.
## Solution
Patch attached:
[0001-Fix-noqr-option-typo-in-dig-1-man-page.patch](/uploads/91fe65e154371b415875914efb70ec96/0001-Fix-noqr-option-typo-in-dig-1-man-page.patch)
If you would like to see this patch submitted directly as a merge request, I'd kindly request the permission to create my fork of the repo on the ISC gitlab server.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3700consider deprecating "dialup" option2023-08-04T09:42:20ZPetr Špačekpspacek@isc.orgconsider deprecating "dialup" optionIt is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider th...It is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider the fun of finding out how following flags interact:
`lib/dns/zone.c`:
```c
19964 void
19965 dns_zone_setdialup(dns_zone_t *zone, dns_dialuptype_t dialup) {
19966 REQUIRE(DNS_ZONE_VALID(zone));
19967
19968 LOCK_ZONE(zone);
19969 DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_DIALNOTIFY |
19970 DNS_ZONEFLG_DIALREFRESH |
19971 DNS_ZONEFLG_NOREFRESH);
19972 switch (dialup) {
19973 case dns_dialuptype_no:
19974 break;
19975 case dns_dialuptype_yes:
19976 DNS_ZONE_SETFLAG(zone, (DNS_ZONEFLG_DIALNOTIFY |
19977 DNS_ZONEFLG_DIALREFRESH |
19978 DNS_ZONEFLG_NOREFRESH));
19979 break;
19980 case dns_dialuptype_notify:
19981 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19982 break;
19983 case dns_dialuptype_notifypassive:
19984 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19985 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19986 break;
19987 case dns_dialuptype_refresh:
19988 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALREFRESH);
19989 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19990 break;
19991 case dns_dialuptype_passive:
19992 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19993 break;
19994 default:
19995 UNREACHABLE();
19996 }
19997 UNLOCK_ZONE(zone);
19998 }
```August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/3699Hang on shutdown in the "tcp" system test2023-08-07T09:16:17ZMichał KępieńHang on shutdown in the "tcp" system testThe `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait ...The `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:[Current thread is 1 (Thread 0x7f1cecac22c0 (LWP 22507))]
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:#1 0x00007f1cea0aca7d in uv_barrier_wait () from /lib64/libuv.so.1
D:tcp:#2 0x00007f1cec14c414 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7f1ce5276000, ev0=ev0@entry=0x7f1ce4b7d800) at netmgr/tcpdns.c:670
D:tcp:#3 0x00007f1cec146a92 in process_netievent (arg=0x7f1ce4b7d800) at netmgr/netmgr.c:463
D:tcp:#4 0x00007f1cec146db3 in isc__nm_process_ievent (worker=<optimized out>, event=<optimized out>) at netmgr/netmgr.c:567
D:tcp:#5 0x00007f1cec14b585 in stop_tcpdns_child (sock=sock@entry=0x7f1ce53eac00, tid=tid@entry=0) at netmgr/tcpdns.c:605
D:tcp:#6 0x00007f1cec14bed4 in isc__nm_tcpdns_stoplistening (sock=0x7f1ce53eac00) at netmgr/tcpdns.c:632
D:tcp:#7 0x00007f1cec143356 in isc_nm_stoplistening (sock=<optimized out>) at netmgr/netmgr.c:2091
D:tcp:#8 0x00007f1cebae0559 in ns_interface_shutdown (ifp=ifp@entry=0x7f1ce528a500) at interfacemgr.c:742
D:tcp:#9 0x00007f1cebae08d9 in purge_old_interfaces (mgr=mgr@entry=0x7f1ce53d3460) at interfacemgr.c:828
D:tcp:#10 0x00007f1cebae0b8b in ns_interfacemgr_shutdown (mgr=0x7f1ce53d3460) at interfacemgr.c:447
D:tcp:#11 0x000000000044288a in shutdown_server (task=<optimized out>, event=<optimized out>) at server.c:10124
D:tcp:#12 0x00007f1cec178944 in task_run (task=<optimized out>, task@entry=0x7f1ce5225e80) at task.c:470
D:tcp:#13 0x00007f1cec178a85 in task__run (arg=0x7f1ce5225e80) at task.c:287
D:tcp:#14 0x00007f1cec160bf4 in isc__job_cb (idle=0x7f1ce52236c8) at job.c:75
D:tcp:#15 0x00007f1cea0a6a49 in uv.run_idle () from /lib64/libuv.so.1
D:tcp:#16 0x00007f1cea09fbf8 in uv_run () from /lib64/libuv.so.1
D:tcp:#17 0x00007f1cec166d31 in loop_run (loop=0x7f1ce52a1e40) at loop.c:270
D:tcp:#18 loop_thread (arg=0x7f1ce52a1e40) at loop.c:297
D:tcp:#19 0x00007f1cec167dd3 in isc_loopmgr_run (loopmgr=0x7f1ce5223540) at loop.c:477
D:tcp:#20 0x00000000004238e0 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1545
```
I do not recall seeing this particular backtrace before, so I assumed it
makes sense to at least retain job artifacts and have this problem
catalogued as a GitLab issue.
Perhaps a total red herring, but `isc__nm_async_tcpdnsstop()` is also
present in the backtrace for one of the threads in a failed unit test
job reported [elsewhere][2], which also happened on Oracle Linux 8.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2935216
[2]: https://gitlab.isc.org/isc-projects/bind9/-/issues/3642Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3694Deprecate setting alternate transfer source2022-12-02T12:56:00ZMatthijs Mekkingmatthijs@isc.orgDeprecate setting alternate transfer sourceThis was an undocumented BIND 8 feature that was ported to BIND 9 in the early days. But there is no good use case for it.
See #3714 for the corresponding option removal issue.This was an undocumented BIND 8 feature that was ported to BIND 9 in the early days. But there is no good use case for it.
See #3714 for the corresponding option removal issue.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3693crash when restarting server with active statschannel connection2022-12-02T11:34:37ZOndřej Surýcrash when restarting server with active statschannel connection### Summary
### BIND version used
- ~"Affects v9.19" : 9128e540f096c915846037c4db41824692513abf
- ~"Affects v9.18" : v9_18_9 is also affected
### Steps to reproduce
1. Start named
2. $ telnet ::1 8080
3. SIGINT the server
4. Enjoy fi...### Summary
### BIND version used
- ~"Affects v9.19" : 9128e540f096c915846037c4db41824692513abf
- ~"Affects v9.18" : v9_18_9 is also affected
### Steps to reproduce
1. Start named
2. $ telnet ::1 8080
3. SIGINT the server
4. Enjoy fireworks
### What is the current *bug* behavior?
Crash on assertion:
```
httpd.c:902: REQUIRE(httpd->readhandle == handle) failed, back trace
```
### What is the expected *correct* behavior?
Does not crash.
### Relevant configuration files
```
statistics-channels {
inet ::1 port 8080;
};
```December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3683use after free in catalog zone processing2022-12-07T01:56:15ZMark Andrewsuse after free in catalog zone processingI was in the process of adding tls restricted transfers to the catz system
test and hadn't properly modified everything (see attached diff) and ns2
dropped core from what looks like a use after free error.
The end of ns2/named.run:
```
...I was in the process of adding tls restricted transfers to the catz system
test and hadn't properly modified everything (see attached diff) and ns2
dropped core from what looks like a use after free error.
The end of ns2/named.run:
```
17-Nov-2022 19:11:31.886 received message from 10.53.0.1#5300
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25047
;; flags: qr aa; QUESTION: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;catalog1.example. IN IXFR
;; ANSWER SECTION:
catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
catalog1.example. 3600 IN SOA . . 63 86400 3600 86400 3600
catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
1ba056ba375209a66a2c9a0617b1df714b998112.zones.catalog1.example. 3600 IN PTR tls1.example.
catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
17-Nov-2022 19:11:31.886 transfer of 'catalog1.example/IN/default' from 10.53.0.1#5300: got incremental response
17-Nov-2022 19:11:31.886 writing to journal
17-Nov-2022 19:11:31.886 del catalog1.example. 3600 IN SOA . . 63 86400 3600 86400 3600
17-Nov-2022 19:11:31.886 add catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
17-Nov-2022 19:11:31.886 add 1ba056ba375209a66a2c9a0617b1df714b998112.zones.catalog1.example. 3600 IN PTR tls1.example.
17-Nov-2022 19:11:31.886 dns_zone_verifydb: zone catalog1.example/IN/default: enter
17-Nov-2022 19:11:31.886 catz.c:2041:dns_catz_dbupdate_callback(): fatal error:
17-Nov-2022 19:11:31.886 pthread_mutex_lock(): Invalid argument (22)
17-Nov-2022 19:11:31.886 exiting (due to fatal error in library)
```
```
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x000000019869ce28 __pthread_kill + 8
1 libsystem_pthread.dylib 0x00000001986cf43c pthread_kill + 292
2 libsystem_c.dylib 0x0000000198617454 abort + 124
3 named 0x000000010446a42c library_fatal_error + 356 (main.c:278)
4 libisc-9.19.8-dev.dylib 0x00000001049cec7c isc_error_fatal + 72 (error.c:70)
5 libdns-9.19.8-dev.dylib 0x0000000104535c6c dns_catz_dbupdate_callback + 312 (catz.c:2041)
6 libdns-9.19.8-dev.dylib 0x000000010453a37c dns_db_closeversion + 264 (db.c:412)
7 libdns-9.19.8-dev.dylib 0x00000001046b514c ixfr_commit + 164 (xfrin.c:478)
8 libdns-9.19.8-dev.dylib 0x00000001046b4b54 xfr_rr + 1444 (xfrin.c:631)
9 libdns-9.19.8-dev.dylib 0x00000001046b3f54 xfrin_recv_done + 2544 (xfrin.c:1412)
10 libisc-9.19.8-dev.dylib 0x00000001049b4420 isc__nm_async_readcb + 408 (netmgr.c:2253)
11 libisc-9.19.8-dev.dylib 0x00000001049b2180 isc__nm_readcb + 332 (netmgr.c:2226)
12 libisc-9.19.8-dev.dylib 0x00000001049bd040 isc__nm_tcpdns_processbuffer + 636 (tcpdns.c:851)
13 libisc-9.19.8-dev.dylib 0x00000001049b2da8 processbuffer + 60 (netmgr.c:1722)
14 libisc-9.19.8-dev.dylib 0x00000001049b2c6c isc__nm_process_sock_buffer + 52 (netmgr.c:1743)
15 libisc-9.19.8-dev.dylib 0x00000001049bd340 isc__nm_tcpdns_read_cb + 604 (tcpdns.c:914)
16 libuv.1.dylib 0x00000001056de570 uv__stream_io + 1020
17 libuv.1.dylib 0x00000001056e57c0 uv__io_poll + 1744
18 libuv.1.dylib 0x00000001056d5d00 uv_run + 252
19 libisc-9.19.8-dev.dylib 0x00000001049e5504 loop_run + 460 (loop.c:270)
20 libisc-9.19.8-dev.dylib 0x00000001049e3c08 loop_thread + 44 (loop.c:297)
21 libisc-9.19.8-dev.dylib 0x00000001049e3ac0 isc_loopmgr_run + 456 (loop.c:477)
22 named 0x0000000104469fc4 main + 424 (main.c:1545)
23 libdyld.dylib 0x00000001986ed430 start + 4
```
[diff](/uploads/eaa1cbd5b7f3ab504554a35d53217359/diff)December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3678stale-serve and RPZ put in SERVFAIL cache unexpected record2023-05-30T13:33:10ZMaksym Odinintsevstale-serve and RPZ put in SERVFAIL cache unexpected record### Summary
When I enable serve-stale, and disable access to external upstream servers (recursion), I see unexpected records in SERVFAIL cache. I see SERVFAIL record for records what should be rewritten with RPZ trigger instead of reque...### Summary
When I enable serve-stale, and disable access to external upstream servers (recursion), I see unexpected records in SERVFAIL cache. I see SERVFAIL record for records what should be rewritten with RPZ trigger instead of requested record.
### BIND version used
```
BIND 9.18.1-1ubuntu1.2-Ubuntu (Stable Release) <id:>
running on Linux x86_64 5.15.0-1022-aws #26-Ubuntu SMP Thu Oct 13 12:59:25 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' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-2lYtkE/bind9-9.18.1=. -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.43.0
linked to libuv version: 1.43.0
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
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
Configure a minimal BIND 9 recursive resolver with a response policy zone, and then attempt to resolve `321.test.myctl.com.`:
`dig 321.test.myctl.com A @127.0.0.1`
filter upstreams via iptables (for example), and attempt to resolve it again, you will receive SERVFAIL:
```
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> 321.test.myctl.com A @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20981
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8f82c8b75e5cd86b0100000063725d504d726ced8e1e2034 (good)
;; QUESTION SECTION:
;321.test.myctl.com. IN A
;; Query time: 4999 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Nov 14 15:22:56 UTC 2022
;; MSG SIZE rcvd: 75
```
dump named db via `rndc dumpdb` and look for SERVFAIL cache:
```
; SERVFAIL cache
;
; test.myctl.com/A [ttl 968]
```
In named.log we can see:
```
resolver: debug 1: fetch: 321.test.myctl.com/A
resolver: debug 1: fetch: 321.test.myctl.com/A
serve-stale: info: 321.test.myctl.com resolver failure, stale answer used
serve-stale: info: test.myctl.com resolver failure, stale answer unavailable
query-errors: info: client @0x7feb441e9f48 127.0.0.1#44401 (321.test.myctl.com): query failed (SERVFAIL) for 321.test.myctl.com/IN/A at query.c:5925
serve-stale: info: 321.test.myctl.com resolver failure, stale answer used
serve-stale: info: test.myctl.com resolver failure, stale answer unavailable
query-errors: info: client @0x7feb44209ef8 127.0.0.1#48831 (321.test.myctl.com): query failed (SERVFAIL) for 321.test.myctl.com/IN/A at query.c:5925
general: info: received control channel command 'dumpdb'
general: info: dumpdb started
```
Ask the same query second time, anew can see how it was resolved successfully:
```
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> 321.test.myctl.com A @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31429
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bdf9d11efa69889d0100000063725d5303f554388f84744c (good)
;; QUESTION SECTION:
;321.test.myctl.com. IN A
;; ANSWER SECTION:
321.test.myctl.com. 30 IN CNAME test.myctl.com.
test.myctl.com. 293 IN CNAME test-cname-a.myctl.com.
test-cname-a.myctl.com. 30 IN A 127.0.0.1
;; ADDITIONAL SECTION:
test.rpz.local. 1 IN SOA localhost. root.localhost. 1 604800 86400 2419200 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Nov 14 15:22:59 UTC 2022
;; MSG SIZE rcvd: 205
```
In named.log file we can see that:
```
serve-stale: info: 321.test.myctl.com query within stale refresh time, stale answer used
rpz: info: client @0x7feb441e9f48 127.0.0.1#43954 (321.test.myctl.com): rpz QNAME Local-Data rewrite test.myctl.com/A/IN via test.myctl.com.test.rpz.local
resolver: debug 1: fetch: test-cname-a.myctl.com/A
serve-stale: info: 321.test.myctl.com query within stale refresh time, stale answer used
rpz: info: client @0x7feb44209ef8 127.0.0.1#59298 (321.test.myctl.com): rpz QNAME Local-Data rewrite test.myctl.com/A/IN via test.myctl.com.test.rpz.local
resolver: debug 1: fetch: test-cname-a.myctl.com/A
serve-stale: info: test-cname-a.myctl.com resolver failure, stale answer used
serve-stale: info: test-cname-a.myctl.com resolver failure, stale answer used
```
If we disable serve-stale in config then we see only asked queries in SERVFAIL cache:
```
; SERVFAIL cache
;
; 321.test.myctl.com/A [ttl 976]
```
### What is the current *bug* behavior?
`test.myctl.com` existence in the SERVFAIL cache is unexpected. If load it pretty high to subdomains with RPZ and CNAMEs, this record will be presented almost always in SERVFAIL cache, and any queries to `test.myctl.com` will fail.
### What is the expected *correct* behavior?
I'd expect SERVFAILS only for exact requested queries, instead of something in between, or even answer with stale-data.
### Relevant configuration files
```
logging {
channel "standard_var_log" {
file "/var/log/named/named.log" versions 3 size 104857600;
severity debug 1;
print-time yes;
print-severity yes;
print-category yes;
};
channel "query_var_log" {
file "/var/log/named/querylog" versions 200 size 262144000;
print-time yes;
};
category "default" {
"standard_var_log";
};
category "lame-servers" {
"null";
};
category "queries" {
"query_var_log";
};
};
options {
directory "/var/cache/bind";
listen-on-v6 {
"any";
};
dnssec-validation no;
response-policy {
zone "test.rpz.local" max-policy-ttl 86400;
} break-dnssec yes qname-wait-recurse no;
stale-answer-enable yes;
stale-answer-client-timeout off;
stale-cache-enable yes;
};
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "test.rpz.local" in {
type master;
file "/etc/bind/db.rpz.local";
allow-query {
"localhost";
};
allow-transfer {
"localhost";
};
forwarders {
};
};
zone "myctl.com" in {
type master;
file "/etc/bind/myctl.com.local";
allow-query {
"localhost";
};
allow-transfer {
"localhost";
};
forwarders {
};
};
```
```
# cat myctl.com.local
; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN .
$TTL 86400
myctl.com IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
IN NS ns-canada.topdns.com.
IN NS ns-usa.topdns.com.
IN NS ns-uk.topdns.com.
$ORIGIN myctl.com
test-cname-a NS ns-canada.topdns.com.
NS ns-usa.topdns.com.
NS ns-uk.topdns.com.
test NS ns-canada.topdns.com.
NS ns-usa.topdns.com.
NS ns-uk.topdns.com.
$ORIGIN test.myctl.com
$TTL 300
* CNAME test.myctl.com.
```
```
# cat db.rpz.local
; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$TTL 900
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
IN NS localhost.
$TTL 293
test.myctl.com CNAME test-cname-a.myctl.com.
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3676Deprecate and remove "Operating System Resource Limits"2022-12-07T18:50:32ZOndřej SurýDeprecate and remove "Operating System Resource Limits"From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used inst...From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used instead of ``1073741824`` to specify a limit of one
gigabyte. ``unlimited`` requests unlimited use, or the maximum available
amount. ``default`` uses the limit that was in force when the server was
started. See the description of ``size_spec`` in :ref:`configuration_file_elements`.
The following options set operating system resource limits for the name
server process. Some operating systems do not support some or any of the
limits; on such systems, a warning is issued if an unsupported
limit is used.
``coresize``
This sets the maximum size of a core dump. The default is ``default``.
``datasize``
This sets the maximum amount of data memory the server may use. The default is
``default``. This is a hard limit on server memory usage; if the
server attempts to allocate memory in excess of this limit, the
allocation will fail, which may in turn leave the server unable to
perform DNS service. Therefore, this option is rarely useful as a way
to limit the amount of memory used by the server, but it can be
used to raise an operating system data size limit that is too small
by default. To limit the amount of memory used by the
server, use the ``max-cache-size`` and ``recursive-clients`` options
instead.
``files``
This sets the maximum number of files the server may have open concurrently.
The default is ``unlimited``.
``stacksize``
This sets the maximum amount of stack memory the server may use. The default is
``default``.
```
These are options that are better left to be managed by the environment, and not from within the `named`, just deprecate these options in 9.18 and remove the options from 9.19+.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3674nsupdate -t timeout does not work2023-04-03T16:19:30ZPetr Špačekpspacek@isc.orgnsupdate -t timeout does not work### Summary
nsupdate option -t is broken and does not have any effect in v9.18 and v9.19 branches. It works in v9.16.
### BIND version used
Versions affected:
- ~"Affects v9.18": 9.18.10-dev 59cb6fa
- ~"Affects v9.19": 9.19.8-dev 48a9...### Summary
nsupdate option -t is broken and does not have any effect in v9.18 and v9.19 branches. It works in v9.16.
### BIND version used
Versions affected:
- ~"Affects v9.18": 9.18.10-dev 59cb6fa
- ~"Affects v9.19": 9.19.8-dev 48a9265
Not affected:
- ~"v9.16": 9.16.36-dev 0fcec7a22c07d9f6fedb097d164c227cfc06db79
### Steps to reproduce
Setup "something" which accepts UDP packets or TCP connections and does not respond.
In short, use `nsupdate -t`, either using TCP or TCP.
#### TCP
```
socat tcp6-listen:5301 -
time nsupdate -L 99 -p 5301 -v -t 1 /tmp/n/upd
```
- observe time to timeout - 30+ seconds
#### UDP
```
socat udp6-listen:5353 - &
time /tmp/main/bin/nsupdate -p 5353 -L 99 -t 1 /tmp/n/upd
```
nsupdate input file (content is not important): [upd](/uploads/db8018d4524417395dc1f2c96d8e1a75/upd)
### What is the current *bug* behavior?
- Explicitly specified timeout value 1 is ignored.
- Default timeout 300 seconds (specified in man page) is also ignored.
### What is the expected *correct* behavior?
Timeouts work.
### Relevant logs and/or screenshots
- [main-tcp.log](/uploads/a97aafe817c004a10ee6e95668627a4a/main-tcp.log)
- [main-udp.log](/uploads/7ef5f9e83f3210b18cde3b5eb1bac673/main-udp.log)
Please note the TCP is also suspicious because it seems it retries over the same connection? Huh?
Based on man page description of `-u` I would expect retries to apply only to UDP.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3673Delay trust anchor management until all zones are loaded2023-04-29T07:36:54ZMark AndrewsDelay trust anchor management until all zones are loadedIf you have a trust anchor that requires a zone to be loaded for the DNSKEY to be fetched you can get spurious `Failed to create fetch for DNSKEY update.` logged if the timing is wrong.
Using !7049 and logging why dns_resolver_createfet...If you have a trust anchor that requires a zone to be loaded for the DNSKEY to be fetched you can get spurious `Failed to create fetch for DNSKEY update.` logged if the timing is wrong.
Using !7049 and logging why dns_resolver_createfetch fails we see:
```
11-Nov-2022 12:38:26.400 fetch: sub.foo/DNSKEY
11-Nov-2022 12:38:26.400 zone 78.100.IN-ADDR.ARPA/IN: loaded; checking validity
11-Nov-2022 12:38:26.400 fctx 0x121eb3010(sub.foo/DNSKEY): create
11-Nov-2022 12:38:26.400 dns_zone_verifydb: zone 74.100.IN-ADDR.ARPA/IN: enter
dns_resolver_createfetch(sub.foo, DNSKEY) -> zone not loaded
11-Nov-2022 12:38:26.400 managed-keys-zone: Failed to create fetch for sub.foo DNSKEY update
22 12:38:26.400 managed-keys-zone: Failed to create fetch for DNSKEY update
```
The serve is authoritative for `foo` but it has not loaded at this point in the start up so named can't determine where to send the DNSKEY request.
this should self correct but is not optimal. Waiting for all the zones to load then initiating trust anchor management should avoid errors like this.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/3670Firefox cannot read stats channel - too many headers in request2022-11-17T11:46:39ZPetr Špačekpspacek@isc.orgFirefox cannot read stats channel - too many headers in request### Summary
Firefox web browser sends so many headers that it exceeds the hardcoded header-count limit of 10 and causes connection to the statics channel to be reset.
### BIND version used
- 9.19.8-dev 48a9265
### Steps to reproduce
...### Summary
Firefox web browser sends so many headers that it exceeds the hardcoded header-count limit of 10 and causes connection to the statics channel to be reset.
### BIND version used
- 9.19.8-dev 48a9265
### Steps to reproduce
- get Firefox 106.0.5
- try to open the stats channel using HTTP URL
### What is the current *bug* behavior?
Error message:
> The connection was reset
> The connection to the server was reset while the page was loading.
### Relevant configuration files
```
statistics-channels {
inet ::1 port 8080;
};
```
### Relevant logs and/or screenshots
No logs from `named` - and I think that's a bug by itself.
Firefox on my machine sends at least 13 HTTP headers in the request.
### Possible fixes
- Bump the number
- Add logging, pleaseDecember 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3668Private-key-format v1.2 with algorithm HMAC-MD5 broken on upgrade 9.18.7 -> 9...2023-09-05T15:40:30ZGert DoeringPrivate-key-format v1.2 with algorithm HMAC-MD5 broken on upgrade 9.18.7 -> 9.18.8<!--
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
Upgrading bind-tools 9.18.7 to 9.18.8 broke our calls to nsupdate, with nsupdate now refusing to read the existing key.
```
$ nsupdate -k Kdyn.space.net.+157+31584.private -v /tmp/upd.txt
09-Nov-2022 19:19:30.108 Kdyn.space.net.+157+31584.private:1: unknown option 'Private-key-format:'
09-Nov-2022 19:19:30.109 Kdyn.space.net.+157+31584.private:4: unexpected token near end of file
could not read key from Kdyn.space.net.+157+31584.{private,key}: unexpected token
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
...
update failed: REFUSED
```
### BIND version used
```
$ nsupdate -V
nsupdate 9.18.8
```
### Steps to reproduce
This is a standard nsupdate key, containing (key itself redacted)
```
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: XXXXXXXX==
```
and a standard update script containing
```
server newton.space.net
zone dyn.space.net
update delete openvpn-ma-nomatch.openvpn-tcp.dyn.space.net A
update add openvpn-ma-nomatch.openvpn-tcp.dyn.space.net 300 A 10.40.68.10
show
send
zone 68.40.10.in-addr.arpa
update delete 10.68.40.10.in-addr.arpa PTR
update add 10.68.40.10.in-addr.arpa 300 PTR openvpn-ma-nomatch.openvpn-tcp.dyn.space.net.
show
send
```
... this works fine with 9.18.7, and does not work with 9.18.8
### What is the current *bug* behavior?
nsupdate complains about not being able to parse the key (see above), and sends an unsigned packet
### What is the expected *correct* behavior?
no error message, send a signed update
### 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
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
git bisect leads me to
```
commit 0bbc0c61e3c98aded2e2b230b52c1d66c8bbd5fe (HEAD)
Author: Mark Andrews <marka@isc.org>
Date: Thu Sep 15 19:18:53 2022 +1000
Convert DST_ALG defines to enum and group HMAC algorithms
The HMACs and GSSAPI are just using unallocated values.
Moving them around shouldn't cause issues.
Only the dnssec system test knew the internal number in use for hmacmd5.
```
which moves HMAC_MD5 from 157 to 160 - not sure why that upsets nsupdate, or why that magic number would be exposed anywhere, but this is the commit that breaks things...July 2023 (9.18.17, 9.18.17-S1, 9.19.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/3667deprecate auto-dnssec feature in favor of dnssec-policy2023-02-18T03:56:51ZPetr Špačekpspacek@isc.orgdeprecate auto-dnssec feature in favor of dnssec-policyAs discussed in person in Porto, I think it's high time to deprecate [auto-dnssec](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#semi-automatic-signing) in ~"v9.18" branch. Doing so _now_ would give users 3 years of warning be...As discussed in person in Porto, I think it's high time to deprecate [auto-dnssec](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#semi-automatic-signing) in ~"v9.18" branch. Doing so _now_ would give users 3 years of warning before ~"v9.18" is out of support.
IMHO in ~"v9.19" we should remove it altogether ASAP.
There is a question what to do with zones which use `auto-dnssec` on upgrade. I think it would be wrong to just skip over the config statement and pretend it is not configured because it would be major break in user's expectation. I think in this case it should be hard error (from ~"v9.19" onwards, of course.)December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3665"dupsigs" system test intermittently causes named to hang2023-04-06T14:54:39ZMichał Kępień"dupsigs" system test intermittently causes named to hanghttps://gitlab.isc.org/isc-private/bind9/-/jobs/2888774
It appears that `named` did not shut down upon receiving a SIGTERM
signal. Core dump was preserved.
<details>
<summary>Click to expand/collapse full test output</summary>
```
S:...https://gitlab.isc.org/isc-private/bind9/-/jobs/2888774
It appears that `named` did not shut down upon receiving a SIGTERM
signal. Core dump was preserved.
<details>
<summary>Click to expand/collapse full test output</summary>
```
S:dupsigs:2022-11-07T23:09:10+0000
T:dupsigs:1:A
A:dupsigs:System test dupsigs
I:dupsigs:PORTRANGE:5300 - 5399
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+31045.key
keys/signing.test/Ksigning.test.+008+31045.private
keys/signing.test/Ksigning.test.+008+34155.key
keys/signing.test/Ksigning.test.+008+34155.private
keys/signing.test/Ksigning.test.+008+39696.key
keys/signing.test/Ksigning.test.+008+39696.private
keys/signing.test/Ksigning.test.+008+48211.key
keys/signing.test/Ksigning.test.+008+48211.private
keys/signing.test/Ksigning.test.+008+49109.key
keys/signing.test/Ksigning.test.+008+49109.private
keys/signing.test/Ksigning.test.+008+50088.key
keys/signing.test/Ksigning.test.+008+50088.private
keys/signing.test/Ksigning.test.+008+52456.key
keys/signing.test/Ksigning.test.+008+52456.private
keys/signing.test/Ksigning.test.+008+54099.key
keys/signing.test/Ksigning.test.+008+54099.private
keys/signing.test/Ksigning.test.+008+57000.key
keys/signing.test/Ksigning.test.+008+57000.private
keys/signing.test/Ksigning.test.+008+49109.key
keys/signing.test/Ksigning.test.+008+49109.private
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+54099.key
keys/signing.test/Ksigning.test.+008+54099.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+54099.key
keys/signing.test/Ksigning.test.+008+54099.private
keys/signing.test/Ksigning.test.+008+57000.key
keys/signing.test/Ksigning.test.+008+57000.private
keys/signing.test/Ksigning.test.+008+50088.key
keys/signing.test/Ksigning.test.+008+50088.private
KSK=Ksigning.test.+008+49109
ZSK0=Ksigning.test.+008+01243
ZSK1=Ksigning.test.+008+18273
ZSK2=Ksigning.test.+008+54099
ZSK3=Ksigning.test.+008+57000
ZSK4=Ksigning.test.+008+50088
I:dupsigs:starting servers
=============== 0 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
=============== 35 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
I:dupsigs:failed
=============== 70 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
I:dupsigs:failed
=============== 105 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
I:dupsigs:failed
I:dupsigs:exit status: 3
I:dupsigs:stopping servers
I:dupsigs:ns1 didn't die when sent a SIGTERM
I:dupsigs:stopping servers failed
I:dupsigs:Core dump(s) found: dupsigs/ns1/core.6262
R:dupsigs:FAIL
D:dupsigs:backtrace from dupsigs/ns1/core.6262:
D:dupsigs:--------------------------------------------------------------------------------
D:dupsigs:Core was generated by `/builds/isc-private/bind9/bin/named/.libs/named -D dupsigs-ns1 -X named.lock -m'.
D:dupsigs:Program terminated with signal SIGABRT, Aborted.
D:dupsigs:#0 0x00007fc0aa3755c0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffcdf293790, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
D:dupsigs:[Current thread is 1 (Thread 0x7fc0a8091840 (LWP 6262))]
D:dupsigs:#0 0x00007fc0aa3755c0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffcdf293790, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
D:dupsigs:#1 0x00007fc0aa3a0414 in usleep (useconds=useconds@entry=10000) at ../sysdeps/posix/usleep.c:32
D:dupsigs:#2 0x00007fc0aaac7f03 in isc__taskmgr_destroy (managerp=managerp@entry=0x5567f5431d40 <named_g_taskmgr>) at task.c:1091
D:dupsigs:#3 0x00007fc0aaaa7ab2 in isc_managers_destroy (netmgrp=0x5567f5431d20 <named_g_nm>, taskmgrp=0x5567f5431d40 <named_g_taskmgr>) at managers.c:85
D:dupsigs:#4 0x00005567f53cdb1a in destroy_managers () at ./main.c:1742
D:dupsigs:#5 cleanup () at ./main.c:1478
D:dupsigs:#6 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:1742
D:dupsigs:--------------------------------------------------------------------------------
D:dupsigs:full backtrace from dupsigs/ns1/core.6262 saved in dupsigs/ns1/core.6262-backtrace.txt
D:dupsigs:core dump dupsigs/ns1/core.6262 archived as dupsigs/ns1/core.6262.gz
E:dupsigs:2022-11-07T23:26:34+0000
```
</details>April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3662Extend mkeys system test to handle islands of trust2023-03-16T11:04:00ZMark AndrewsExtend mkeys system test to handle islands of trustThere are two scenarios to be tested.
1) island of trust where the DNSKEYs are found by recursion from the root.
2) island of trust where the DNSKEYs are found from an intermediate zone loaded on the server.
Also extend error reporting...There are two scenarios to be tested.
1) island of trust where the DNSKEYs are found by recursion from the root.
2) island of trust where the DNSKEYs are found from an intermediate zone loaded on the server.
Also extend error reporting to include DNSKEY name.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3655message decompresion can be slow2022-11-22T09:42:52ZPetr Špačekpspacek@isc.orgmessage decompresion can be slowVersion: e004ca4
Artificial DNS message full of compression pointers can cause `named` to spend lots of time in decompression loop. Flame chart then looks like this:
![512b_prereqs.svg](/uploads/719c28c1600753ffef4f264b731ed752/512b_pr...Version: e004ca4
Artificial DNS message full of compression pointers can cause `named` to spend lots of time in decompression loop. Flame chart then looks like this:
![512b_prereqs.svg](/uploads/719c28c1600753ffef4f264b731ed752/512b_prereqs.svg)
Reproducer:
1. get DNSPerf version with https://github.com/DNS-OARC/dnsperf/pull/201 (new option -B)
2. Fire at named with crafted DNS message. Here is binary in format for dnsperf: [tcpnotify.bin](/uploads/d0fe09936d516148a2c43914a7ae26de/tcpnotify.bin). Raw example DNS message is here: [512notify.bin](/uploads/9242d4ad0b0df44a31b45007084ae00c/512notify.bin).
3. Observe throughput going down, compared to 512-byte [message without lots of decompression](/uploads/13b7daee22cc83264b283b340b2d3e9c/tcpupd1rr512b.bin).December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3652reference manual update-policies unmatched parenthesis2022-11-07T12:48:42ZJorisreference manual update-policies unmatched parenthesis### Summary
In the _BIND 9 Administrator Reference Manual_ Configuration reference there are multiple references to the update-policy grammer where the paranthesis is unmatched:
` update-policy ( local | { ( deny | grant ) <string...### Summary
In the _BIND 9 Administrator Reference Manual_ Configuration reference there are multiple references to the update-policy grammer where the paranthesis is unmatched:
` update-policy ( local | { ( deny | grant ) <string> ( 6to4-self | external | krb5-self | krb5-selfsub | krb5-subdomain | ms-self | ms-selfsub | ms-subdomain | name | self | selfsub | selfwild | subdomain | tcp-self | wildcard | zonesub ) [ <string> ] <rrtypelist>; ... };`
I believe a closing parenthesis is required between the last and penultimate character, forming <rrtypelist>; ... }**)**;
The wrong block is reiterated multiple times, at least in "Zone Types", "Dynamic Update Policies", "view Block grammar" and "update-policy" grammer.
See for example https://bind9.readthedocs.io/en/v9_19_6/reference.html#dynamic-update-policies
### BIND version used
Verified in v9_16 and v9_19_6 (latest at the time of writing).
### Steps to reproduce
Open https://bind9.readthedocs.io/en/v9_19_6/reference.html#dynamic-update-policies
Find the grammer line for update-policy
Paste it in a code syntax highlighting editor
Observe there is no closing match for the '(' before 'local'
### What is the current *bug* behavior?
May confuse users
### What is the expected *correct* behavior?
See above
### Relevant configuration files
Not applicable
### Relevant logs and/or screenshots
Not applicable
### Possible fixes
See above, add closing parenthesis.November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/3651update danger to check for Approved2022-12-06T10:48:19ZEvan Huntupdate danger to check for ApprovedWe've started using Approve rather than LGTM to mark merge requests as ready to merge, but danger will still report:
```
elif "LGTM (Merge OK)" not in mr_labels:
warn(
"This merge request is currently in review. "
"I...We've started using Approve rather than LGTM to mark merge requests as ready to merge, but danger will still report:
```
elif "LGTM (Merge OK)" not in mr_labels:
warn(
"This merge request is currently in review. "
"It should not be merged until it is marked with the *LGTM* label."
)
```
I'd fix it myself, but I'm so unfamiliar with the gitlab API, I don't even know how Mr. Labels got set in the first place.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Tom KrizekTom Krizek