BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-24T07:53:48Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4554Signature expiration calculation backwards compatibility bug2024-02-24T07:53:48ZMatthijs Mekkingmatthijs@isc.orgSignature expiration calculation backwards compatibility bugThe `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `sig...The `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `signatures-validity - signatures-refresh`) which is wrong: it should be using a range of 0 to `signatures-refresh`.
The `sig-validity-interval` that was used for `auto-dnssec` defined two parameters, the first being the signatures validity (same as `dnssec-policy`'s `signatures-validity`), the optional second one being the minimum bound of the signatures validity. It also serves as a signatures refresh. Basically the refresh value is the difference between the first and second parameter.
So the second parameter actually has two meanings: It serves as a jitter and a refresh value.
With `dnssec-policy` there is not yet a way to define `jitter`. The `signatures-refresh` is actually defined as the.
Two things need to be done:
- [x] Add a configuration option to `dnssec-policy` to set desired jitter.
- [x] Ensure resign interval is used correctly.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4553return value for check DS shadows value for running keymgr2024-03-07T22:43:18ZMatthijs Mekkingmatthijs@isc.orgreturn value for check DS shadows value for running keymgrChecking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.Checking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4552keymgr: bug in Depends function2024-03-13T10:53:30ZMatthijs Mekkingmatthijs@isc.orgkeymgr: bug in Depends functionWhile working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certa...While working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certain record type is going to be swapped. For example, with the ZSK Pre-Publish rollover method the signatures created by the successor key `z` are being propagated first, so that the zone signatures for `x` and `z` can be swapped (smooth rollover). In this case, we say that `z` is the successor of `x` for the `ZRRSIG` record type. Here, `x` is the predecessor key that is going to be withdrawn from the zone. The set `Dep(x, T)` is a separately administrated set of keys that have a dependency on `x` for record type `T`.
For example, with the ZSK Pre-Publish method, the `ZRRSIG` records of key `x` can be withdrawn if there is a succeeding `ZRRSIG` of key `z` introduced in the zone. Key `x` now depends on key `z`, therefore `z` will be in the set `Dep(x, ZRRSIG)`. The successor relation requires that the predecessor key must not have any other keys relying on it. In other words, the set `Dep(x, T)` must be empty.
---
But if the key is phased out (all its states are in `HIDDEN`), there is no longer a dependency. Since the relationship is still maintained (`Predecessor` and `Successor` metadata), the `keymgr_dep` function still returned `true`. In other words, the set `Dep(x, T)` is not considered empty.
This slows down key rollovers, only retiring keys when the successor key has been fully propagated.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4551dnssec-keygen man page contradictory on whether TSIG keys can be generated2024-03-08T05:39:15ZChristopher Headdnssec-keygen man page contradictory on whether TSIG keys can be generated### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the secti...### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the section for the `-a` option:
> In prior releases, HMAC algorithms could be generated for use as TSIG keys, but that feature was removed in BIND 9.13.0. Use tsig-keygen to generate TSIG keys.
It looks like the top matter probably wasn’t updated when TSIG was spun out into `tsig-keygen`.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4550Resolve license aggregation for "reuse lint"2024-02-07T16:19:55ZMichal NowakResolve license aggregation for "reuse lint"`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: Pen...`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: PendingDeprecationWarning: Copyright and licensing
information for 'COPYRIGHT' has been found in both 'COPYRIGHT' and in the DEP5 file located at '.reuse/dep5'.
The information for these two sources has been aggregated. In the future this behaviour will change, and you will
need to explicitly enable aggregation. See <https://github.com/fsfe/reuse-tool/issues/779>. You need do nothing
yet. Run with `--suppress-deprecation` to hide this warning.
...
```Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4541values of ruletype field for update-policy statement2024-03-08T05:30:58Zperlangvalues of ruletype field for update-policy statementOne document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``...One document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``, ``ms-self``,
``ms-selfsub``, ``ms-subdomain``, ``ms-subdomain-self-rhs``, ``krb5-self``,
``krb5-selfsub``, ``krb5-subdomain``, ``krb5-subdomain-self-rhs``,
``tcp-self``, ``6to4-self``, and ``external``.
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4535"digdelv" system test often fails the "try the next server after a TCP socket...2024-02-24T07:57:52ZMichał Kępień"digdelv" system test often fails the "try the next server after a TCP socket connection error/timeout" checkFor at least the past two weeks or so, the following check in the
`digdelv` system test has been failing particularly often, for no
apparent reason that I could think of:
```
2024-01-14 04:17:49 INFO:digdelv I:digdelv_tmp_aq8itlsn:c...For at least the past two weeks or so, the following check in the
`digdelv` system test has been failing particularly often, for no
apparent reason that I could think of:
```
2024-01-14 04:17:49 INFO:digdelv I:digdelv_tmp_aq8itlsn:check that dig tries the next server after a TCP socket connection error/timeout (89)
2024-01-14 04:18:09 INFO:digdelv I:digdelv_tmp_aq8itlsn:failed
```
It is an intermittent failure. It seems to be at least strongly
"preferring" FreeBSD jobs (and may even be exclusive to these, but I
have not checked all of its occurrences):
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3926964
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3938693
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3938692
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939505
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939504
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939503
The check itself dates back to March 2022 (!5976), so it is surprising
to only see an uptick in its failures now. Perhaps some other fix
merged in the meantime changed `dig` behavior in a way that trips this
logic up?May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4531Improvements to the parental-agents definition in the arm2024-03-08T05:42:15ZDan MahoneyImprovements to the parental-agents definition in the armHi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [X] Search the existing issues in GitLab (both open and closed) to see if your report m...Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [X] Search the existing issues in GitLab (both open and closed) to see if your report might be a duplicate. We have a large database here and many issues have already been fixed in the latest versions!
- [X] Make sure this is **not** a support question. If you have specific trouble configuring or debugging your setup, please use the bind-users mailing list: https://lists.isc.org/mailman/listinfo/bind-users
- [X] You have read and understood the "out in the open" support policy: https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ . Even though it was written by the PowerDNS folks, we follow it as well!
Before continuing, **please select the appropriate issue template in the drop-down menu above, under the heading _Description_**.
(There is no "doc" template. Maybe there should be.)
The current doc for parental-agents laid out in the 9.18 arm is, some formatting tweaks for gitlab aside:
> Grammar zone (primary, secondary): `parental-agents [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... };`
>
> Grammar topmost: `parental-agents <string> [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... }; // may occur multiple times`
>
> Blocks: topmost, zone (primary, secondary)
>
> Tags: zone
>
> Defines a list of delegation agents to be used by primary and secondary zones.
>
> 8.2.10. `parental-agents` Block Definition and Usage
>
> `parental-agents` lists allow for a common set of parental agents to be easily used by multiple primary and secondary zones. A parental agent is the entity that is allowed to change a zone’s delegation information (defined in RFC 7344).
What is not apparent from the above:
* If you define a "topmost" parental agent, you must still define it in a zone for it to be used. There is no way to configure a default parental agent, nor to have it apply to zones without stating it for each. The example cited in the 9.18 migration article in the KB only mentions the pure-zone-based version, and doesn't give a good example of how to do it with a globally-defined one.
* The "usage" statement for the zone does not make it apparent how to specify an agent defined topmost -- this implies either two "zone" usage statements (Grammar zone with no defined topmost agent, grammar zone with the agent defined only in the zone statement), or a more complex definition of the "Grammar Zone" statement where it's either "parental-agents { "string"; } followed by the rest of the possible options. (I guess it's possible to use a topmost-defined parental agent but ALSO add others? -- I'm not sure how to properly bracket those options, depending on if that's the case.)
* **"A parental agent is the entity that is allowed to change a zone's delegation information"** is untrue in this case. While that is one possible usage (for example, specifying "a0.org.afilias-nst.info." for an agent for example.org), The a0.org.afilias-nst.info. is not allowed to change the delegation information -- some hidden SRS server and a stealth master are, as part of the DNSSEC process. A parental-agent may also be set to 8.8.8.8 or any other TSIG-relationship-defined validating resolver, none of which are allowed to change anything about the delegation.
* Also, the "allowed to change" wording implies that there is some nsupdate-like relationship required between our zone and it, that's to be configured, especially because things like TSIG keys are offered as options.
* It isn't immediately clear that the only thing BIND does is send DS queries.
A better phrasing here might be:
"A parental agent is a trusted DNS server that can confirm that a zone's delegation information has been updated in the parent zone of the one being configured, as defined in (rfc foo section bar). [An optional statement about what is implied by "trusted" (TSIG/DNSSEC/ACLs on the parental-agent server) could go here.]"March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4528rndc reconfig/reload ignores changes to listen-on statements when port or int...2024-03-11T14:38:57ZArtem Boldarievrndc reconfig/reload ignores changes to listen-on statements when port or interface address are left unchangedOne could change `listen-on` statements to change DNS transports without changing both port and interface addresses. For example, one could change a line:
```
listen-on port 1234;
```
to
```
listen-on port 1234 tls some-tls-config;
``...One could change `listen-on` statements to change DNS transports without changing both port and interface addresses. For example, one could change a line:
```
listen-on port 1234;
```
to
```
listen-on port 1234 tls some-tls-config;
```
and then run `rndc reconfig`. However, that would not work because we lack a mechanism for changing listener type. Moreover, the example above will crash BIND with abort() because the code will try to update a TLS context on a listener that does not support TLS.
The problem was found while investigating issue #4518, which can be considered a special case of this issue: it can be described as a lack of ability to update/recreate listeners on reconfiguration.
The solution is to always recreate listeners on listener type change (e.g. Do53->DoT or enabling PROXY). That partially raises the issue mentioned in #3122, but there is no way around that except for allowing any process to bind "privileged" ports on affected platforms (read: BSDs). That might bring some troubles, but:
It is a very edge case, as listener types do not change often. The fact that no one has reported the issue in at least two years or more proves that.
We have no mechanism to dynamically change layers in an active listener, and it is hard to justify adding such a complex mechanism in the critical part of the code.
**P.S.**
Historically, we would recreate listeners on reconfiguration for new transports in order to ensure that TLS certificates are reloaded, but we changed that (see #3122 and, to a lesser extent, #3415, as well as the related merge requests for additional details). That made this issue more apparent, although even back then, reconfiguration would have been broken for plain HTTP/2 listeners.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4521Timeout in dig not handled in system tests2024-03-07T22:44:44ZMark AndrewsTimeout in dig not handled in system testsJob [#3918128](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3918128) failed for 47a16b58326221f6c7972b32d67fdecfdcd202ba:
```
bin/tests/system/rndc_tmp_geya4m_a/dig.out.4.test31:;; communications error to 10.53.0.4#24164: timed out
...Job [#3918128](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3918128) failed for 47a16b58326221f6c7972b32d67fdecfdcd202ba:
```
bin/tests/system/rndc_tmp_geya4m_a/dig.out.4.test31:;; communications error to 10.53.0.4#24164: timed out
bin/tests/system/rndc_tmp_geya4m_a/dig.out.1.test55:;; communications error to 10.53.0.6#24164: timed out
bin/tests/system/rndc_tmp_geya4m_a/dig.out.1.test55:;; communications error to 10.53.0.6#24164: timed out
bin/tests/system/rndc_tmp_geya4m_a/dig.out.1.test55:;; communications error to 10.53.0.6#24164: timed out
```
Also in serve-staleMarch 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4520Log message in lib/ns/update.c needs updating2024-03-08T05:21:18ZMark AndrewsLog message in lib/ns/update.c needs updatingThis message in lib/ns/update.c should report the actual type being ignored. It could be CDNSKEY, DNSKEY, or CDS.
```
update_log(client, zone,
...This message in lib/ns/update.c should report the actual type being ignored. It could be CDNSKEY, DNSKEY, or CDS.
```
update_log(client, zone,
LOGLEVEL_PROTOCOL,
"attempt to "
"delete in use "
"DNSKEY ignored");
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4517dnssec-verify reports errors in NSEC3 chain2024-02-24T07:53:57ZLibor Peltandnssec-verify reports errors in NSEC3 chain### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the f...### Summary
Please see the attached zone file. The output of dnssec-verify is:
```
$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Bad NSEC3 record for fadb1aa3f.6DA7ffbF, bit map mismatch
Expected and found NSEC3 chains not equal
Break in NSEC3 chain at: VKGD3TE5QRGB6S0KJH6UV3FKS9FUMRIV
Expected: 01EAMK8ES71TN6TKHOK512LQMCORC5O9
Found: 0R6S95GSLHH7HT7MFN2N1NJGNFS7Q2CQ
DNSSEC completeness test failed (failure).
```
I'd say that the NSEC3 chain is however correct.
Some notes:
- opt-out is not used
- `fadb1aa3f.6da7ffbf.` -> `01eamk8es71tn6tkhok512lqmcorc5o9.6da7ffbf.` (first NSEC3 lexicographically, but this probably doesnt care)
- `427e09.owa.6da7ffbf.` -> `vkgd3te5qrgb6s0kjh6uv3fks9fumriv.6da7ffbf.` (last NSEC3 lexicographically)
- node `fadb1aa3f.6da7ffbf.` is "weird" in the way that it's a delegation with non-authoritative data: MX and even DNSKEY(!), but this shouldn't influence the chaining of NSEC3, moreover, it relates to the bitmap at 01EAMK... and not VKGD3T...
### BIND version affected
```
$ dnssec-verify -V
dnssec-verify 9.18.18-0ubuntu0.22.04.1-Ubuntu
```
### Steps to reproduce
Use faketime as the RRSIGs are expired already. It doesn't matter since the errors are related to NSEC3s and not signatures.
The zone file in question is attached.
Just call `$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone`
### What is the current *bug* behavior?
Verify reports errors in the attached zone's NSEC3 chain.
### What is the expected *correct* behavior?
No errors reported.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4513System tests fail with Net::DNS 1.422024-01-03T01:01:34ZMark AndrewsSystem tests fail with Net::DNS 1.42Net::DNS::Nameserver->main_loop no longer loops. This breaks reclimit and chain system tests which use Net::DNS::Nameserver in ans.pl.Net::DNS::Nameserver->main_loop no longer loops. This breaks reclimit and chain system tests which use Net::DNS::Nameserver in ans.pl.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4510Wrongly considering signatures-validity in "key lifetime is shorter than the ...2024-03-07T22:43:37ZLibor PeltanWrongly considering signatures-validity in "key lifetime is shorter than the time it takes to do a rollover"### Summary
For testing purposes, I tried to configure as short ZSK lifetime as possible (like 10 seconds). I kept failing with the error `key lifetime is shorter than the time it takes to do a rollover` until I discovered (by trial and...### Summary
For testing purposes, I tried to configure as short ZSK lifetime as possible (like 10 seconds). I kept failing with the error `key lifetime is shorter than the time it takes to do a rollover` until I discovered (by trial and error!) that this error wrongly considers `signatures-validity` and `signatures-refresh`.
This is in contrary to the documentation https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-dnskey-ttl which claims that the ZSK lifetime minimum depends only on `dnskey-ttl`, `publish-safety`, `max-zone-ttl`, `retire-safety`, and `zone-propagation-delay`. See also #3416 .
It would be possible to fix this by adjusting the documentation, but I'd prefer to adjust the behaviour: there is no reason why ZSK lifetime should depend on RRSIG validity, only TTLs matter.
### BIND version affected
`BIND 9.18.18-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)`
### Steps to reproduce
```
dnssec-policy "triumph." {
keys {
zsk lifetime 18 algorithm ecdsa256;
ksk lifetime unlimited algorithm ecdsa256;
};
dnskey-ttl 3;
max-zone-ttl 4;
zone-propagation-delay 2;
publish-safety 1;
retire-safety 1;
};
```
(signatures-validity defaults to 14d and signatures-refresh to 5d, the difference is 9d and the zsk lifetime is denied unless I set it to more than 9d)
### What is the current *bug* behavior?
The configuration load fails with the aforementioned error whenever I set the ZSK lifetime to less than `signatures-validity - signatures-refresh`, which is contrary to the documentation https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-dnskey-ttl
### What is the expected *correct* behavior?
Either the documentation should be aligned with the observed behavior, or the behavior (appearance of the error and failure to load conf) should be adjusted to not consider signatures-validity.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4508Crash in "host"2024-03-07T22:44:28ZAnand BuddhdevCrash in "host"### Summary
Running "host" with the -C option causes it to crash sometimes. I've observed it on my MacOS Sonoma 14.2.1 laptop, and I've also seen a report by Francisco Obispo of a similar crash on the bind-users mailing list.
### BIND ...### Summary
Running "host" with the -C option causes it to crash sometimes. I've observed it on my MacOS Sonoma 14.2.1 laptop, and I've also seen a report by Francisco Obispo of a similar crash on the bind-users mailing list.
### BIND version affected
```
BIND 9.18.21 (Extended Support Version) <id:cb6cff6>
running on Darwin x86_64 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10 PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64
built by make with '--prefix=/usr/local/Cellar/bind/9.18.21' '--sysconfdir=/usr/local/etc/bind' '--localstatedir=/usr/local/var' '--with-json-c' '--with-libidn2=/usr/local/opt/libidn2' '--with-openssl=/usr/local/opt/openssl@3' '--without-lmdb' 'CC=clang' 'PKG_CONFIG_PATH=/usr/local/opt/json-c/lib/pkgconfig:/usr/local/opt/libidn2/lib/pkgconfig:/usr/local/opt/libnghttp2/lib/pkgconfig:/usr/local/opt/libuv/lib/pkgconfig:/usr/local/opt/openssl@3/lib/pkgconfig' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/14'
compiled by CLANG Apple LLVM 15.0.0 (clang-1500.1.0.2.5)
compiled with OpenSSL version: OpenSSL 3.2.0 23 Nov 2023
linked to OpenSSL version: OpenSSL 3.2.0 23 Nov 2023
compiled with libuv version: 1.47.0
linked to libuv version: 1.47.0
compiled with libnghttp2 version: 1.58.0
linked to libnghttp2 version: 1.58.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.17
linked to json-c version: 0.17
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /usr/local/etc/bind/named.conf
rndc configuration: /usr/local/etc/bind/rndc.conf
DNSSEC root key: /usr/local/etc/bind/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
```
### Steps to reproduce
Run `host -C by` or `host -C id.iq`
### What is the current *bug* behavior?
Sometimes, "host" crashes with this error:
```
% host -C by
Nameserver 31.44.1.137:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261150 3600 600 604800 3600
Nameserver 2a0e:b81:8001:1001::2:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261150 3600 600 604800 3600
netmgr/netmgr.c:1737: REQUIRE(handlep != ((void*)0) && *handlep == ((void*)0)) failed, back trace
0 libisc-9.18.21.dylib 0x000000011055bdd3 default_callback + 63
1 libisc-9.18.21.dylib 0x000000011055bd74 isc_assertion_failed + 10
2 libisc-9.18.21.dylib 0x0000000110546e12 isc__nmhandle_attach + 104
3 host 0x000000010ffd2e8f launch_next_query + 145
4 host 0x000000010ffd188f start_udp + 150
5 host 0x000000010ffd4963 recv_done + 3929
6 libisc-9.18.21.dylib 0x000000011054bd35 isc__nm_async_readcb + 149
7 libisc-9.18.21.dylib 0x000000011054aa8e isc__nm_readcb + 271
8 libisc-9.18.21.dylib 0x0000000110558f36 udp_recv_cb + 459
9 libisc-9.18.21.dylib 0x0000000110559fb4 isc__nm_udp_read_cb + 72
10 libuv.1.dylib 0x00000001104ded89 uv__udp_io + 354
11 libuv.1.dylib 0x00000001104e1c9f uv__io_poll + 1680
12 libuv.1.dylib 0x00000001104d214d uv_run + 258
13 libisc-9.18.21.dylib 0x0000000110545036 nm_thread + 115
14 libisc-9.18.21.dylib 0x000000011057e7ef isc__trampoline_run + 22
15 libsystem_pthread.dylib 0x00007ff80a073202 _pthread_start + 99
16 libsystem_pthread.dylib 0x00007ff80a06ebab thread_start + 15
[1] 85023 abort host -C by
```
### What is the expected *correct* behavior?
```
% host -C by
Nameserver 31.44.1.137:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 2a0e:b81:8001:1001::2:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 93.125.25.73:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 2a00:c827:a:3::2:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 185.98.83.4:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 2a00:c827:a:2::2:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 93.125.25.72:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 2a01:ba80:e:c:1::4c:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
Nameserver 31.44.5.245:
by has SOA record dns1.tld.becloud.by. support.becloud.by. 2312261200 3600 600 604800 3600
```
### Relevant configuration files
No relevant configuration file.
### Relevant logs
No relevant log.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4500Log the change that generated "not exact" when applying a diff.2024-01-04T16:56:21ZMark AndrewsLog the change that generated "not exact" when applying a diff.Provide more information a "not exact" response is detected. Log name, class, type and operation being attempted.Provide more information a "not exact" response is detected. Log name, class, type and operation being attempted.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/bind9/-/issues/4498[GL #4494] followup: regression test was too strict2024-01-04T16:58:18ZMark Andrews[GL #4494] followup: regression test was too strictThe delta which records the addition of the private record for the NSEC3 to NSEC conversion can sometimes not be the first delta. Update the system test to handle it in a later delta.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/38...The delta which records the addition of the private record for the NSEC3 to NSEC conversion can sometimes not be the first delta. Update the system test to handle it in a later delta.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/3883570January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/bind9/-/issues/4497Kindly mute the 'trust-anchor-telemetry' experimental warning.2023-12-18T14:15:22ZJakub MocKindly mute the 'trust-anchor-telemetry' experimental warning.<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
<!-- Concisely summarize the bug encountered. -->
Kindly mute the 'trust-anchor-telemetry' experimental warning.
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
```
BIND 9.18.20 (Extended Support Version) <id:>
running on FreeBSD amd64 13.2-RELEASE-p7 FreeBSD 13.2-RELEASE-p7 stable/23.7-n254871-d5ec322cffc SMP
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--enable-dnsrps' '--with-readline=libedit' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-querytrace' '--enable-tcp-fastopen' '--prefix=/usr/local' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13.2' 'build_alias=amd64-portbld-freebsd13.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -Wl,-rpath,/usr/local/lib -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 'PKG_CONFIG_LIBDIR=/usr/obj/usr/ports/dns/bind918/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig' 'READLINE_CFLAGS=-L/usr/local/lib'
compiled by CLANG FreeBSD Clang 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
compiled with OpenSSL version: OpenSSL 1.1.1w 11 Sep 2023
linked to OpenSSL version: OpenSSL 1.1.1w 11 Sep 2023
compiled with libuv version: 1.47.0
linked to libuv version: 1.47.0
compiled with libnghttp2 version: 1.58.0
linked to libnghttp2 version: 1.58.0
compiled with libxml2 version: 2.10.4
linked to libxml2 version: 21004
compiled with json-c version: 0.17
linked to json-c version: 0.17
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. Use _attached_ configuration file and start BIND server
### What is the current *bug* behavior?
<!-- What actually happens. -->
So this "experimental" features has been introduced about 5 years ago. Yet, after all that time, one or two warning lines are logged to syslog with `LOG_WARNING` severity, depending on whether you foolishly tried to mute the annoying hardcoded warning with the `trust-anchor-telemetry no;` option [as suggested in KB](https://kb.isc.org/docs/aa-01528). The hardcoded warning is annoying, doubling the pointless noise when you try to disable the feature - and, if fact, with a configuration that completely ignores DNSSEC since BIND is only used here to filter out AAAA for certain domains to avoid geolocation with IPv6 tunnels with certain domains - is just inexplicable.
### What is the expected *correct* behavior?
<!-- What you should see instead. -->
Do not log pointless warnings to syslog.
### Relevant configuration files
<!-- Paste any relevant configuration files here - 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`. -->
```
acl "Allow_ACL" {
127.0.0.0/8;
};
controls {
inet 127.0.0.1 port 9530 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
};
logging {
channel "default_log" {
file "/var/log/named/named.log" versions 3 size 5242880;
print-time yes;
print-severity yes;
print-category yes;
};
channel "query_log" {
file "/var/log/named/query.log" versions 3 size 5242880;
print-time yes;
};
channel "rpz_log" {
file "/var/log/named/rpz.log" versions 3 size 5242880;
print-time yes;
};
category "default" {
"default_log";
};
category "general" {
"default_log";
};
category "queries" {
"query_log";
};
category "rpz" {
"rpz_log";
};
category "lame-servers" {
"null";
};
};
options {
directory "/usr/local/etc/namedb/working";
dump-file "/var/dump/named_dump.db";
listen-on port 53530 {
127.0.0.1/32;
};
listen-on-v6 port 53530 {
::1/128;
};
pid-file "/var/run/named/pid";
statistics-file "/var/stats/named.stats";
allow-recursion {
"Allow_ACL";
};
dnssec-validation no;
max-cache-size 80%;
recursion yes;
allow-query {
"Allow_ACL";
};
};
key "rndc-key" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
plugin query "/usr/local/lib/bind/filter-aaaa.so" {
filter-aaaa-on-v4 break-dnssec;
filter-aaaa-on-v6 break-dnssec;
};
zone "." {
type hint;
file "/usr/local/etc/namedb/named.root";
};
zone "localhost" {
type primary;
file "/usr/local/etc/namedb/primary/localhost-forward.db";
};
zone "127.in-addr.arpa" {
type primary;
file "/usr/local/etc/namedb/primary/localhost-reverse.db";
};
zone "0.ip6.arpa" {
type primary;
file "/usr/local/etc/namedb/primary/localhost-reverse.db";
};
```
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->
```
<28>1 2023-12-18T08:21:44+01:00 gw.example.com named 57351 - [meta sequenceId="31"] /usr/local/etc/namedb/named.conf:27: option 'trust-anchor-telemetry' is experimental and subject to change in the future
<28>1 2023-12-18T08:21:44+01:00 gw.example.com named 57351 - [meta sequenceId="30"] config.c: option 'trust-anchor-telemetry' is experimental and subject to change in the future
```January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/bind9/-/issues/4495Conversion from NSEC3 to NSEC removes the NSEC3PARAM too early2024-02-23T11:40:30ZMark AndrewsConversion from NSEC3 to NSEC removes the NSEC3PARAM too earlyThe NSEC3PARAM was being removed immediately by `dns_nsec3param_deletechains` rather than waiting for the NSEC chain to be generated then removing it as part of the clean up. This could result in named returning unsigned answers which w...The NSEC3PARAM was being removed immediately by `dns_nsec3param_deletechains` rather than waiting for the NSEC chain to be generated then removing it as part of the clean up. This could result in named returning unsigned answers which would not validate as secure. This state was transitory being corrected when the NSEC chain completed building.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/bind9/-/issues/4494add_sigs was using the wrong time in kasp mode2023-12-20T01:13:44ZMark Andrewsadd_sigs was using the wrong time in kasp mode`add_sigs` in lib/dns/zone.c and lib/dns/update.c with `kasp` was using `inception` as a proxy for `now`.
This resulted in RRSIGs not being generated for new keys. It could also result in the wrong keys being used.
I was fixing the `ns...`add_sigs` in lib/dns/zone.c and lib/dns/update.c with `kasp` was using `inception` as a proxy for `now`.
This resulted in RRSIGs not being generated for new keys. It could also result in the wrong keys being used.
I was fixing the `nsec3-to-nsec` test in `autosign` to actually convert from NSEC3 to NSEC and noted that the
change was not signed when it should have been as the zone was signed in the setup phase.
```
14-Dec-2023 18:07:01.331 del nsec3-to-nsec.example. 300 IN SOA mname1. . 2009102722 20 20 1814400 3600
14-Dec-2023 18:07:01.331 del nsec3-to-nsec.example. 0 IN NSEC3PARAM 1 0 0 BEEF
14-Dec-2023 18:07:01.331 add nsec3-to-nsec.example. 300 IN SOA mname1. . 2009102723 20 20 1814400 3600
14-Dec-2023 18:07:01.331 add nsec3-to-nsec.example. 0 IN TYPE65534 \# 8 000140000002BEEF
```
There are other issues that need to be address with this but lets clear this one first.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Mark AndrewsMark Andrews