ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-05-16T10:19:55Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2969Assertion failure in dns_resolver_destroyfetch()2022-05-16T10:19:55ZEvan HuntAssertion failure in dns_resolver_destroyfetch()This often seems to occur in the `forward` system test, while chasing DS records. It looks as if `fctx_cancelqueries()` is being run at the same time by two threads.
```
#2 0x000055d09e875e47 in assertion_failed (file=0x7fc3ca45280b "r...This often seems to occur in the `forward` system test, while chasing DS records. It looks as if `fctx_cancelqueries()` is being run at the same time by two threads.
```
#2 0x000055d09e875e47 in assertion_failed (file=0x7fc3ca45280b "resolver.c",
line=10603, type=isc_assertiontype_require,
cond=0x7fc3ca453c78 "((fctx) != ((void *)0) && ((const isc__magic_t *)(fctx))->magic == ((('F') << 24 | ('!') << 16 | ('!') << 8 | ('!'))))") at main.c:236
#3 0x00007fc3ca4e3c8d in isc_assertion_failed (
file=0x7fc3ca45280b "resolver.c", line=10603,
type=isc_assertiontype_require,
cond=0x7fc3ca453c78 "((fctx) != ((void *)0) && ((const isc__magic_t *)(fctx))->magic == ((('F') << 24 | ('!') << 16 | ('!') << 8 | ('!'))))")
at assertions.c:47
#4 0x00007fc3ca377303 in dns_resolver_destroyfetch (fetchp=0x7fc3c2bf4e08)
at resolver.c:10603
#5 0x00007fc3ca3ae320 in fetch_callback_ds (task=0x7fc3b6f55b80, event=0x0)
at validator.c:620
#6 0x00007fc3ca5126f9 in task_run (task=0x7fc3b6f55b80) at task.c:827
#7 0x00007fc3ca51290e in isc_task_run (task=0x7fc3b6f55b80) at task.c:907
#8 0x00007fc3ca4c2018 in isc__nm_async_task (worker=0x7fc3c7049df0,
ev0=0x7fc3b5a13780) at netmgr/netmgr.c:834
#9 0x00007fc3ca4c229c in process_netievent (worker=0x7fc3c7049df0,
ievent=0x7fc3b5a13780) at netmgr/netmgr.c:913
#10 0x00007fc3ca4c2dd5 in process_queue (worker=0x7fc3c7049df0,
type=NETIEVENT_TASK) at netmgr/netmgr.c:1007
#11 0x00007fc3ca4c1e59 in process_all_queues (worker=0x7fc3c7049df0)
at netmgr/netmgr.c:753
#12 0x00007fc3ca4c1edc in async_cb (handle=0x7fc3c704a150)
at netmgr/netmgr.c:782
#13 0x00007fc3c9df1a51 in uv__async_io (loop=0x7fc3c7049e00,
w=<optimized out>, events=<optimized out>) at src/unix/async.c:163
#14 0x00007fc3c9e035e5 in uv__io_poll (loop=loop@entry=0x7fc3c7049e00,
timeout=<optimized out>) at src/unix/linux-core.c:462
#15 0x00007fc3c9df21ec in uv_run (loop=0x7fc3c7049e00, mode=UV_RUN_DEFAULT)
at src/unix/core.c:389
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3272shutdown system test hangs indefinitely2022-05-16T10:22:57ZMichal Nowakshutdown system test hangs indefinitelyThe `shutdown` system test sometimes hangs indefinitely in the CI, rendering the job incomplete after 60-minute CI timeout. The system test almost exclusively fails in ASAN and TSAN jobs (one Alpine job has been observed):
- `system:cla...The `shutdown` system test sometimes hangs indefinitely in the CI, rendering the job incomplete after 60-minute CI timeout. The system test almost exclusively fails in ASAN and TSAN jobs (one Alpine job has been observed):
- `system:clang:asan` - https://gitlab.isc.org/isc-private/bind9/-/jobs/2440427
- `system:clang:tsan` - https://gitlab.isc.org/isc-projects/bind9/-/jobs/2439513
- `system:clang:tsan` - https://gitlab.isc.org/isc-projects/bind9/-/jobs/2439795
- `system:gcc:asan` - https://gitlab.isc.org/isc-projects/bind9/-/jobs/2439792
```
$ curl -sSL https://gitlab.isc.org/isc-projects/bind9/-/jobs/2439792/raw | grep '^[SR]:' | cut -d: -f2 | sort | uniq -c | awk '$1 != "2" { print }'
1 shutdown
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3163Add remote TLS certificate verification support, implement Strict and Mutual ...2022-05-16T10:24:55ZArtem BoldarievAdd remote TLS certificate verification support, implement Strict and Mutual TLS authentication[RFC 9103, Section 9.3,](https://www.rfc-editor.org/rfc/rfc9103.html#name-tls) discusses three TLS-based authentication mechanisms:
- Opportunistic TLS;
- Strict TLS;
- Mutual TLS.
Currently, the released version of BIND and its comple...[RFC 9103, Section 9.3,](https://www.rfc-editor.org/rfc/rfc9103.html#name-tls) discusses three TLS-based authentication mechanisms:
- Opportunistic TLS;
- Strict TLS;
- Mutual TLS.
Currently, the released version of BIND and its complementary tools have support for the first one.
In order to implement support for Strict and Mutual TLS, the functionality to verify the remote TLS certificates needs to be added first.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2813Build named with DLZ is broken on 9.162022-05-16T10:30:17ZMatthijs Mekkingmatthijs@isc.orgBuild named with DLZ is broken on 9.16```
gcc -include /home/vagrant/git/bind9/config.h -I/home/vagrant/git/bind9 -I../.. -I./include -I./unix/include -I. -I/home/vagrant/git/bind9/lib/ns/include -I../../lib/ns/include -I/home/vagrant/git/bind9/lib/dns/include -I../../lib/d...```
gcc -include /home/vagrant/git/bind9/config.h -I/home/vagrant/git/bind9 -I../.. -I./include -I./unix/include -I. -I/home/vagrant/git/bind9/lib/ns/include -I../../lib/ns/include -I/home/vagrant/git/bind9/lib/dns/include -I../../lib/dns/include -I/home/vagrant/git/bind9/lib/bind9/include -I../../lib/bind9/include -I/home/vagrant/git/bind9/lib/isccfg/include -I../../lib/isccfg/include -I/home/vagrant/git/bind9/lib/isccc/include -I../../lib/isccc/include -I/home/vagrant/git/bind9/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../contrib/dlz/drivers/include -I/usr/include/mysql -DCONTRIB_DLZ -DDLZ_MYSQL -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c ../../contrib/dlz/drivers/dlz_mysql_driver.c
../../contrib/dlz/drivers/dlz_mysql_driver.c:66:14: error: conflicting types for ‘my_bool’
typedef bool my_bool;
^~~~~~~
In file included from ../../contrib/dlz/drivers/dlz_mysql_driver.c:45:0:
/usr/include/mysql/mysql.h:53:14: note: previous declaration of ‘my_bool’ was here
typedef char my_bool;
^~~~~~~
Makefile:632: recipe for target 'dlz_mysql_driver.o' failed
make[2]: *** [dlz_mysql_driver.o] Error 1
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3296Check the algorithm name / oid for PRIVATEDNS and PRIVATEOID signatures.2022-05-16T10:34:23ZMark AndrewsCheck the algorithm name / oid for PRIVATEDNS and PRIVATEOID signatures.The fromwire and fromtext methods need to check that there are well formed algorithm names / oids in SIG and RRSIG records for algorithms 253 and 254 respectively. These checks are the same as have already been applied to KEY, DNSKEY et...The fromwire and fromtext methods need to check that there are well formed algorithm names / oids in SIG and RRSIG records for algorithms 253 and 254 respectively. These checks are the same as have already been applied to KEY, DNSKEY etc.
```
A.1.1. Private Algorithm Types
Algorithm number 253 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with a wire encoded
domain name, which MUST NOT be compressed. The domain name indicates
the private algorithm to use, and the remainder of the public key
area is determined by that algorithm. Entities should only use
domain names they control to designate their private algorithms.
Algorithm number 254 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with an unsigned
length byte followed by a BER encoded Object Identifier (ISO OID) of
that length. The OID indicates the private algorithm in use, and the
remainder of the area is whatever is required by that algorithm.
Entities should only use OIDs they control to designate their private
algorithms.
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3306Undefined macros in contrib/dlz/modules/wildcard/dlz_wildcard_dynamic.c2022-05-16T10:36:27ZJosef MöllersUndefined macros in contrib/dlz/modules/wildcard/dlz_wildcard_dynamic.cTrying to build `contrib/dlz/modules/wildcard/dlz_wildcard_dynamic.c` for 9.18.2 failed due to two undefined macros:
* `FALLTHROUGH` and
* `UNREACHABLE()`
As a quick stopgap measure I reverted the use of the macros by replacing them wi...Trying to build `contrib/dlz/modules/wildcard/dlz_wildcard_dynamic.c` for 9.18.2 failed due to two undefined macros:
* `FALLTHROUGH` and
* `UNREACHABLE()`
As a quick stopgap measure I reverted the use of the macros by replacing them with comments that were there in 9.18.1.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3313dlz_ldap_driver.c: error: this statement may fall through2022-05-16T10:45:08ZMichal Nowakdlz_ldap_driver.c: error: this statement may fall throughBuild configured with `--with-dlz-ldap` produces the following error/warning:
```
../../contrib/dlz/drivers/dlz_ldap_driver.c: In function ‘dlz_ldap_create’:
../../contrib/dlz/drivers/dlz_ldap_driver.c:957:20: error: this statement may f...Build configured with `--with-dlz-ldap` produces the following error/warning:
```
../../contrib/dlz/drivers/dlz_ldap_driver.c: In function ‘dlz_ldap_create’:
../../contrib/dlz/drivers/dlz_ldap_driver.c:957:20: error: this statement may fall through [-Werror=implicit-fallthrough=]
957 | if (result != ISC_R_SUCCESS) {
| ^
../../contrib/dlz/drivers/dlz_ldap_driver.c:960:9: note: here
960 | case 11:
| ^~~~
../../contrib/dlz/drivers/dlz_ldap_driver.c:962:20: error: this statement may fall through [-Werror=implicit-fallthrough=]
962 | if (result != ISC_R_SUCCESS) {
| ^
../../contrib/dlz/drivers/dlz_ldap_driver.c:965:9: note: here
965 | case 10:
| ^~~~
../../contrib/dlz/drivers/dlz_ldap_driver.c:966:20: error: this statement may fall through [-Werror=implicit-fallthrough=]
966 | if (strlen(argv[9]) > 0) {
| ^
../../contrib/dlz/drivers/dlz_ldap_driver.c:972:9: note: here
972 | case 9:
| ^~~~
```
Required for isc-projects/bind9#3310.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3318typo in rndc man page2022-05-16T10:46:29ZMark Andrewstypo in rndc man page`withdraw` should be `withdrawn`
```
-.. option:: dnssec (-status | -rollover -key id [-alg algorithm] [-when time] | -checkds [-key id [-alg algorithm]] [-when time] published | withdraw)) zone [class [view]]
+.. option:: dnssec (-stat...`withdraw` should be `withdrawn`
```
-.. option:: dnssec (-status | -rollover -key id [-alg algorithm] [-when time] | -checkds [-key id [-alg algorithm]] [-when time] published | withdraw)) zone [class [view]]
+.. option:: dnssec (-status | -rollover -key id [-alg algorithm] [-when time] | -checkds [-key id [-alg algorithm]] [-when time] published | withdrawn)) zone [class [view]]
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3317CID 352554 (#1 of 1): Dereference before null check (REVERSE_INULL)2022-05-16T10:48:02ZMark AndrewsCID 352554 (#1 of 1): Dereference before null check (REVERSE_INULL)```
3034 next = ISC_LIST_NEXT(query, link);
3035 } else {
3036 next = NULL;
3037 }
CID 352554 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking con...```
3034 next = ISC_LIST_NEXT(query, link);
3035 } else {
3036 next = NULL;
3037 }
CID 352554 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking connectquery suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
3038 if (connectquery != NULL) {
3039 query_detach(&connectquery);
3040 }
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3266"rndc" system test fails due to rate-limit of built-in "_bind" view2022-05-16T10:50:50ZAnton Castelli"rndc" system test fails due to rate-limit of built-in "_bind" view### Summary
A series of tests against the built-in "_bind" view sometimes fails due to the [rate-limit](../58bd26b6/bin/named/config.c#L262).
### BIND version used
9.18.1
### Steps to reproduce
Run the "rndc" system test on a suffic...### Summary
A series of tests against the built-in "_bind" view sometimes fails due to the [rate-limit](../58bd26b6/bin/named/config.c#L262).
### BIND version used
9.18.1
### Steps to reproduce
Run the "rndc" system test on a sufficiently fast machine. It is unclear to me what constitutes "sufficiently fast". I've had it succeed on low-end VMs and fail on real hardware.
### What is the current *bug* behavior?
Too many queries against the "_bind" built-in view occur within a second, causing the rate limiting to kick in and some of the tests fail.
### What is the expected *correct* behavior?
The "rndc" system test always succeeds.
### Relevant logs and/or screenshots
The log file from the "ns4" nameserver for the "rndc" test. See lines 3353-3356.
[rndc.ns4.named.run.fail](/uploads/d272cc6d1623657f398e514d1bd2b992/rndc.ns4.named.run.fail)
### Possible fixes
I first tried to override the built-in "_bind" view to remove the rate-limit, but this just caused more tests to fail due to the extra unexpected zones.
Eventually I simply introduced artificial delay after the third query. I don't know if this is the correct fix, but it seems to work consistently.
[rndc.git.patch](/uploads/2261c0a2e658d14da311aa6051a5d760/rndc.git.patch)May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3307socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument on OpenBSD2022-05-16T11:05:45ZMichal Nowaksocket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument on OpenBSDRunning the `geoip2` `v9_16` system test on OpenBSD produces the following warning:
```
I:geoip2:checking Country database by code using IPv6 (8)
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
socket.c:5111: setsocko...Running the `geoip2` `v9_16` system test on OpenBSD produces the following warning:
```
I:geoip2:checking Country database by code using IPv6 (8)
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
socket.c:5111: setsockopt(20, IPV6_V6ONLY) failed: Invalid argument
```
Its invoked by running `dig` seven times: `dig +tcp +short -p ${PORT} @fd92:7065:b8e:ffff::2 -6 txt example -b fd92:7065:b8e:ffff::$i`.
The test otherwise passed.
It's with us for a long time as it's present in [9.11.37](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2383391).May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3232RPZ rpz-nsip rules seem not to understand stub and static-stub zones and don'...2022-05-16T11:06:17ZCathy AlmondRPZ rpz-nsip rules seem not to understand stub and static-stub zones and don't handle DNS_R_GLUE result well ...From [Support ticket #20526](https://support.isc.org/Ticket/Display.html?id=20526)
After introducing a new rpz-nsip policy in a pre-existing zone (the first one in use in this environment) a zone which is the subject of a stub zone conf...From [Support ticket #20526](https://support.isc.org/Ticket/Display.html?id=20526)
After introducing a new rpz-nsip policy in a pre-existing zone (the first one in use in this environment) a zone which is the subject of a stub zone configuration then started logging messages of this type for all queries for names in and in delegations from this stub zone.
Switching to static-stub didn't help.
We think this relates to the way that named creates a zone db in memory for stub and static-stub zones, but unexpectedly (unexpectedly to RPZ that is) returns glue from it versus authoritative RRsets.
The RPZ code that is producing the logged message doesn't have a code to handle DNS_R_GLUE and thus this falls through to 'default' error handling.
Here are some (anonymised) examples of the log messages being reported:
```
Mar 19 18:05:17 r7 named[100011]: client @0x7f688c00b4f8 192.0.2.0.134#45337 (query1.alpha.example.com): rpz NSIP/NSDNAME rewrite query1.alpha.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:17 r7 named[100011]: client @0x7f688c007bf8 192.0.2.0.134#45337 (query1.alpha.example.com): rpz NSIP/NSDNAME rewrite query1.alpha.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:17 r7 named[100011]: client @0x7f69080eaf98 192.0.2.134#36690 (1.2.3.10.in-addr.arpa): rpz NSIP/NSDNAME rewrite 1.2.3.10.in-addr.arpa via 10.in-addr.arpa unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:17 r7 named[100011]: client @0x7f68f001bf28 192.0.2.0.168#39939 (query2.beta.gamma.example.com): rpz NSIP/NSDNAME rewrite query2.beta.gamma.example.com via beta.gamma.example.com unrecognized NS rpz_rrset_find() failed: glue
...
Mar 19 18:05:18 r7 named[100011]: client @0x7f68b8069c08 192.0.2.0.86#38447 (query3.delta.epsilon.example.com): rpz NSIP/NSDNAME rewrite query3.delta.epsilon.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:18 r7 named[100011]: client @0x7f68b002f2d8 192.0.2.0.157#51189 (query4.alpha.example.com): rpz NSIP/NSDNAME rewrite query4.alpha.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:18 r7 named[100011]: client @0x7f6870087de8 192.0.2.0.56#54972 (query5.alpha.example.com): rpz NSIP/NSDNAME rewrite query5.alpha.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:18 r7 named[100011]: client @0x7f68b002f2d8 192.0.2.0.157#51189 (query6.alpha.example.com): rpz NSIP/NSDNAME rewrite query6.alpha.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:18 r7 named[100011]: client @0x7f687000c908 192.0.2.0.56#54972 (query7.alpha.example.com): rpz NSIP/NSDNAME rewrite query7.alpha.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:18 r7 named[100011]: client @0x7f6920098de8 192.0.2.0.201#47323 (query8.zeta.example.com): rpz NSIP/NSDNAME rewrite query8.zeta.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
Mar 19 18:05:18 r7 named[100011]: client @0x7f68d86e9108 192.0.2.0.201#42436 (query8.zeta.example.com): rpz NSIP/NSDNAME rewrite query8.zeta.example.com via example.com unrecognized NS rpz_rrset_find() failed: glue
```
Coincidentally with this scenario, the site in question also experienced a temporary loss of Internet connectivity, but even after it was restored, the logging of the message `unrecognized NS rpz_rrset_find() failed: glue` persisted until rpz-nsip processing was prevented by adding `nsip-enable no` to the response policy.
Subsequently we discovered that a new rpz-nsip policy had been added to the policy zone at around the same time as the temporary loss of Internet connectivity.
Notably above (and we still need to check into this, as well as the qnames below `example.com` (the zone which was configured as type stub), there is also a query for a qname below `10.in-addr.arpa` producing the same error.
The server is dnssec-validating and running 9.16.26-S1 although there is a validate-except covering example.com.
----
The reporter wrote:
```
I have verified that there are no RPZ entries for any example.com name,
so I don't know why the RPZ was being triggered in the first place. All
of our RPZ entries look like this one:
<< sanitised name >>. 14400 IN CNAME .
so any match should result in a QNAME NXDOMAIN answer. But a rewrites were
being triggered for non-matches and resulted in SERVFAIL. I wonder if
this could be an interaction between RPZ and serve-stale, as the problem
started at about the same time as we had a firewall issue that blocked
access from our recursive servers to numerous authorities for a while.
Disabling the RPZ stopped the errors (named was reconfigured, not restarted).
```May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3221[1/5] Catalog zones lightweight cleanup2022-05-16T11:26:46ZArаm Sаrgsyаn[1/5] Catalog zones lightweight cleanupDo some lightweight code cleanup and fixes in preparation of adding some new feature from the latest DNS catalog zones draft.Do some lightweight code cleanup and fixes in preparation of adding some new feature from the latest DNS catalog zones draft.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3222[2/5] Catalog zones options new syntax based on custom properties2022-05-16T11:26:47ZArаm Sаrgsyаn[2/5] Catalog zones options new syntax based on custom propertiesAccording to DNS catalog zones draft version 5 document, catalog zone custom properties must be placed under the "ext" label.
In order to be compatible with the draft, BIND should support the new syntax.According to DNS catalog zones draft version 5 document, catalog zone custom properties must be placed under the "ext" label.
In order to be compatible with the draft, BIND should support the new syntax.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3223[3/5] Catalog zones change of ownership (coo) support2022-05-16T11:26:47ZArаm Sаrgsyаn[3/5] Catalog zones change of ownership (coo) supportCatalog zones change of ownership is special mechanism to facilitate controlled migration of a member zone from one catalog to another.
It is implemented using catalog zone property named "coo" and is documented in DNS catalog zones dra...Catalog zones change of ownership is special mechanism to facilitate controlled migration of a member zone from one catalog to another.
It is implemented using catalog zone property named "coo" and is documented in DNS catalog zones draft version 5 document.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3224[4/5] Concept of broken catalog zones2022-05-16T11:26:47ZArаm Sаrgsyаn[4/5] Concept of broken catalog zonesThe DNS catalog zones draft version 5 document describes various situations when a catalog zone must be considered as "broken" and not be processed.
BIND should implement those checks to be compatible with the draft.
As of version -05,...The DNS catalog zones draft version 5 document describes various situations when a catalog zone must be considered as "broken" and not be processed.
BIND should implement those checks to be compatible with the draft.
As of version -05, these are the situations listed in the draft that a catalog zone is "broken"
1. The names of member zones are represented on the RDATA side (instead of as a part of owner names) of a PTR record,
so that all valid domain names may be represented regardless of their length. This PTR record MUST be the only
record in the PTR RRset with the same name. More than one record in the RRset denotes a broken catalog zone which
MUST NOT be processed.
2. The CLASS field of every RR in a catalog zone MUST be IN (1).
3. All catalog zones MUST have a TXT RRset named version.$CATZ with exactly one RR. Catalog
consumers MUST NOT apply catalog zone processing to zones without the expected value in the version.$CATZ TXT RR
(in other words, such a catalog zone is "broken").
4. The coo property PTR RRset MUST consist of a single PTR record. More than one record in the RRset denotes a
broken catalog zone which MUST NOT be processed.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3225[5/5] Catalog zones member zone reset documentation2022-05-16T11:26:47ZArаm Sаrgsyаn[5/5] Catalog zones member zone reset documentationThe DNS catalog zones draft version 5 document requires that catalog zone consumers must reset the member zone's internal zone state when its unique label changes (either within the same catalog zone or during change of ownership perform...The DNS catalog zones draft version 5 document requires that catalog zone consumers must reset the member zone's internal zone state when its unique label changes (either within the same catalog zone or during change of ownership performed using the "coo" property).
BIND already behaves like that, and, in fact, doesn't support keeping the zone state during change of ownership even if the unique label has been kept the same, because BIND always removes the member zone and adds it back during unique label renaming or change of ownership.
BIND should document the described behavior and add a log message to inform when unique label renaming occurs.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3335Confusing parental-source documentation2022-05-16T11:54:19ZMatthijs Mekkingmatthijs@isc.orgConfusing parental-source documentationparental-source determines which local source address, and optionally UDP port, is used to send parental DS queries. **This address must appear in the secondary server’s parental-agents zone clause.** This statement sets the parental-sou...parental-source determines which local source address, and optionally UDP port, is used to send parental DS queries. **This address must appear in the secondary server’s parental-agents zone clause.** This statement sets the parental-source for all zones, but can be overridden on a per-zone or per-view basis by including a parental-source statement within the zone or view block in the configuration file.
The bold line is a copy paste error from `notify-source`.June 2022 (9.16.30, 9.16.30-S1, 9.18.4, 9.19.2)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3351named-checkconf *** buffer overflow detected *** with -D_FORTIFY_SOURCE=32022-05-16T12:02:17ZMartin Liškanamed-checkconf *** buffer overflow detected *** with -D_FORTIFY_SOURCE=3Using gcc12, one can utilize `-D_FORTIFY_SOURCE=3` that shows the following bug:
```
$ gdb ./bin/check/named-checkconf
...
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@en...Using gcc12, one can utilize `-D_FORTIFY_SOURCE=3` that shows the following bug:
```
$ gdb ./bin/check/named-checkconf
...
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(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 0x00007ffff76f31e3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff76a3306 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff768c813 in __GI_abort () at abort.c:79
#4 0x00007ffff76e61b7 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff782c3cf "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#5 0x00007ffff778b30a in __GI___fortify_fail (msg=msg@entry=0x7ffff782c375 "buffer overflow detected") at fortify_fail.c:26
#6 0x00007ffff77898b6 in __GI___chk_fail () at chk_fail.c:28
#7 0x00007ffff7789485 in ___snprintf_chk (s=<optimized out>, maxlen=maxlen@entry=1152, flag=flag@entry=2, slen=<optimized out>, format=format@entry=0x41ffef "%u/%s") at snprintf_chk.c:29
#8 0x000000000023293d in snprintf (__fmt=0x41ffef "%u/%s", __n=1152, __s=<optimized out>) at /usr/include/bits/stdio2.h:71
#9 check_zoneconf (zconfig=0x492b70, voptions=voptions@entry=0x0, config=config@entry=0x491a30, symtab=<optimized out>, files=files@entry=0x4919e0, keydirs=keydirs@entry=0x48f400, inview=0x48faa0, viewname=<optimized out>, defclass=1, actx=0x492760, logctx=0x49cc60, mctx=0x490360) at check.c:2500
#10 0x00000000002349b3 in check_viewconf (config=config@entry=0x491a30, voptions=voptions@entry=0x0, viewname=viewname@entry=0x0, vclass=vclass@entry=1, files=0x4919e0, keydirs=0x48f400, check_plugins=true, inview=<optimized out>, logctx=0x49cc60, mctx=0x490360) at check.c:4569
#11 0x0000000000237a3d in bind9_check_namedconf (config=0x491a30, check_plugins=true, logctx=<optimized out>, mctx=0x490360) at check.c:5253
#12 0x000000000022bb74 in main (argc=<optimized out>, argv=0x7fffffffdb28) at ./named-checkconf.c:739
```
That is caused by wrong order of `len -= strlen(tmp);` and `tmp += strlen(tmp);`. If you run it as it is, then you end with `len -= 0`, because `tmp` points to `\0`.
Please apply the following patch:
```patch
diff --git a/lib/bind9/check.c b/lib/bind9/check.c
index d2cc4bf..0f6c700 100644
--- a/lib/bind9/check.c
+++ b/lib/bind9/check.c
@@ -2495,8 +2495,8 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
} else if (dns_name_isula(zname)) {
ula = true;
}
- tmp += strlen(tmp);
len -= strlen(tmp);
+ tmp += strlen(tmp);
(void)snprintf(tmp, len, "%u/%s", zclass,
(ztype == CFG_ZONE_INVIEW) ? target
: (viewname != NULL) ? viewname
@@ -3244,8 +3244,8 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
char *tmp = keydirbuf;
size_t len = sizeof(keydirbuf);
dns_name_format(zname, keydirbuf, sizeof(keydirbuf));
- tmp += strlen(tmp);
len -= strlen(tmp);
+ tmp += strlen(tmp);
(void)snprintf(tmp, len, "/%s", (dir == NULL) ? "(null)" : dir);
tresult = keydirexist(zconfig, (const char *)keydirbuf,
kaspname, keydirs, logctx, mctx);
```June 2022 (9.16.30, 9.16.30-S1, 9.18.4, 9.19.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1223Add a section on using RPZ to the ARM2022-05-16T12:20:01ZVicky Riskvicky@isc.orgAdd a section on using RPZ to the ARMWe have additional notes on using several advanced features in the ARM. We should have such a section for RPZ - a complicated feature that is in widespread use that is pretty critical to those who use it. We need more than a command ref...We have additional notes on using several advanced features in the ARM. We should have such a section for RPZ - a complicated feature that is in widespread use that is pretty critical to those who use it. We need more than a command reference here.
Please also address WHY we expire RPZ zones, and whether a query for an expired RPZ zone should fail open or closed.June 2022 (9.16.30, 9.16.30-S1, 9.18.4, 9.19.2)Evan HuntEvan Hunt