ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-11-13T11:17:10Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2220Update OS images (Fedora 33, OpenBSD 6.8, FreeBSD 12.2)2020-11-13T11:17:10ZMichal NowakUpdate OS images (Fedora 33, OpenBSD 6.8, FreeBSD 12.2)Update OS images, all are either already out or out in a few weeks.
- [x] OpenBSD 6.8: https://gitlab.isc.org/isc-projects/images/-/merge_requests/81
- [x] Fedora 33: https://gitlab.isc.org/isc-projects/images/-/merge_requests/82
- [x] F...Update OS images, all are either already out or out in a few weeks.
- [x] OpenBSD 6.8: https://gitlab.isc.org/isc-projects/images/-/merge_requests/81
- [x] Fedora 33: https://gitlab.isc.org/isc-projects/images/-/merge_requests/82
- [x] FreeBSD 12.2: https://gitlab.isc.org/isc-projects/images/-/merge_requests/83
- [x] Also there's Ubuntu 20.10 (Groovy Gorilla) a non-LTS release which we don't intend to add to our OS images, but should probably build and test on as a one-off sanity test.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/kea/-/issues/1474Update references to RFC 89252020-11-02T10:31:43ZFrancis DupontUpdate references to RFC 8925kea1.9.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/141dhcp-lease-list fails to parse /var/lib/dhcpd.leases when db-time-format is s...2020-12-03T15:38:00ZGregMoreldhcp-lease-list fails to parse /var/lib/dhcpd.leases when db-time-format is set to locale---
name: Bug Report
about: dhcp-lease-list script fails to parse leases file if db-time-format is set to locale
---
**Describe the bug**
`dhcp-lease-list` script fails to parse `/var/lib/dhcpd.leases` file if `db-time-format` is set ...---
name: Bug Report
about: dhcp-lease-list script fails to parse leases file if db-time-format is set to locale
---
**Describe the bug**
`dhcp-lease-list` script fails to parse `/var/lib/dhcpd.leases` file if `db-time-format` is set to `locale`
**To Reproduce**
1. In `dhcpd.conf`, set `db-time-format locale`
2. Restart dhcp service
3. On a dhcp client, run `dhclient -r`
4. On the server, run `dhcp-lease-list`: the lease does not appear
**Expected behavior**
Leases should appear in `dhcp-lease-list` command's output, even if `db-time-format` is set to `locale`
**Environment**
- ISC DHCP version: 4.4.1
- OS: Ubuntu Server 20.04 x64
**Additional Information**
After investigation, the problem occurs because of the following part in `dhcp-lease-list` Perl script:
```Perl
# skip invalid lines
next if not ($lease =~ /^\s+([\.\d]+)\s+{.*starts \d+ ([\/\d\ \:]+);.*ends \d+ ([\/\d\ \:]+);.*ethernet ([a-f0-9:]+);(.*client-hostname \"(\S+)\";)*/s);
```
Indeed, this regex does not match leases written with date format that respect the `db-time-format locale` flag, that is (according to `man dhcpd.leases`):
> If the db-time-format was configured to local, then the date fields appear as follows:\
`epoch <seconds-since-epoch>; # <day-name> <month-name> <day-number> <hours>:<minutes>:<seconds> <year>`Outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1473No equivalent circuit-id identifier for host-reservations in dhcp62020-11-12T19:54:53ZKevin ClarkNo equivalent circuit-id identifier for host-reservations in dhcp6When attempting to replicate our dhcp4 config to dhcp6 we ran into the fact that circuit-id is no longer a valid host reservation identifier. I see that it is now option 18 in IPv6 ('interface-id').
Is it possible to get this comparabl...When attempting to replicate our dhcp4 config to dhcp6 we ran into the fact that circuit-id is no longer a valid host reservation identifier. I see that it is now option 18 in IPv6 ('interface-id').
Is it possible to get this comparable feature added to the dhcp6 server without having to resort to flex-id?https://gitlab.isc.org/isc-projects/bind9/-/issues/2219BIND 9.11 built with --disable-atomic seems to be leaking memory on FreeBSD2022-12-26T07:03:18ZMichał KępieńBIND 9.11 built with --disable-atomic seems to be leaking memory on FreeBSD![bind-9.11-freebsd-authoritative-12h](/uploads/18d80662f773ad077866e73eb6731f61/bind-9.11-freebsd-authoritative-12h.png)
The problem does not seem to exist in atomics-enabled builds or on
Linux. Perhaps a missing `isc_mutex_destroy()`...![bind-9.11-freebsd-authoritative-12h](/uploads/18d80662f773ad077866e73eb6731f61/bind-9.11-freebsd-authoritative-12h.png)
The problem does not seem to exist in atomics-enabled builds or on
Linux. Perhaps a missing `isc_mutex_destroy()` call somewhere?
The graph above was prepared for an "authoritative" mode ["stress"
test][1] run. The leak is also triggered in "recursive" mode, though to
a smaller extent.
[1]: https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stressBIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/stork/-/issues/432sphinx as hard dependency (is it really necessary?)2022-11-29T09:14:40ZTomek Mrugalskisphinx as hard dependency (is it really necessary?)@marcin reported that Stork fails to build if `sphinx` is not present. Original report here: https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169328
One (easier) way to semi-address this would be to update the docs and say th...@marcin reported that Stork fails to build if `sphinx` is not present. Original report here: https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169328
One (easier) way to semi-address this would be to update the docs and say that `sphinx` and `sphinx-rtd-theme` is now mandatory.
A better way would be to check if sphinx is available and don't generate docs and man pages if it isn't. This would make the user experience better.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/431doc updates: prerequisite section2020-10-27T15:59:41ZTomek Mrugalskidoc updates: prerequisite sectionAs reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169318 by @marcin:
Prerequisites section of the Stork ARM is outdated. A couple of examples:
```
Stork Server and Stork Agent have been tested thoroughly on t...As reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169318 by @marcin:
Prerequisites section of the Stork ARM is outdated. A couple of examples:
```
Stork Server and Stork Agent have been tested thoroughly on the Ubuntu 18.04 system. They have been tested and run on the Fedora 31 system as well.
```
So we fixed list of systems in one place but left this. I think we generally have too many places where we list systems on which it has been tested.
Another place:
```
The status-get command was introduced in Kea 1.7.3. At this time, Stork works with Kea version 1.7.3 and later versions only, although we intend to backport the status-get command to Kea 1.6.3.
```
In fact, we have already back ported it to 1.6.3.0.13Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/430UI tooltips misaligned2021-01-28T10:43:36ZTomek MrugalskiUI tooltips misalignedAs reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169320 by @godfryd:
![image](/uploads/6ba0d52a3875a0d8261d90788910060b/image.png)
Help box text is centered instead of aligned to the left.
This is probably d...As reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169320 by @godfryd:
![image](/uploads/6ba0d52a3875a0d8261d90788910060b/image.png)
Help box text is centered instead of aligned to the left.
This is probably due to the fact that question mark icon is located in the table header which is also centered. The problem applies to other boxes that have its question mark icon in table headers.0.15https://gitlab.isc.org/isc-projects/stork/-/issues/429SSE events from HA2 are shown on HA1.2020-12-07T11:16:17ZTomek MrugalskiSSE events from HA2 are shown on HA1.As reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169307 by @godfryd:
`SSE` events from `HA2` are shown on `HA1`.
Repro:
1. Add machines `agent-kea-ha1` and `agent-kea-ha2`
2. Kill DHCPv4 daemon on `agent-kea...As reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169307 by @godfryd:
`SSE` events from `HA2` are shown on `HA1`.
Repro:
1. Add machines `agent-kea-ha1` and `agent-kea-ha2`
2. Kill DHCPv4 daemon on `agent-kea-ha2` using Stork Env Simulator on http://localhost:5000/
3. Observe list of events on Kea app on `agent-kea-ha1`
4. After a minute or 2 there are automatically added events about Kea from `agent-kea-ha2`
When the page is refreshed with F5 key then only this Kea events are presented.0.14Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/428HA reports incorrect IP address for remote peer2022-11-16T11:54:50ZTomek MrugalskiHA reports incorrect IP address for remote peerAs reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169306 by @godfryd:
![image](/uploads/11c8c2e8ebb90feae6df7a4f05908065/image.png)
Kea HA status, in case of remote party, displays CA address (127.0.0.1) inst...As reported here https://gitlab.isc.org/isc-projects/stork/-/issues/426#note_169306 by @godfryd:
![image](/uploads/11c8c2e8ebb90feae6df7a4f05908065/image.png)
Kea HA status, in case of remote party, displays CA address (127.0.0.1) instead of Stork Agent address.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1471set default log check verbosity from the environment2020-10-16T12:09:23ZFrancis Dupontset default log check verbosity from the environmentThe src/lib/testutils/log_utils.h allows the check logs in unit tests and offer a logCheckVerbose method to set the verbosity flags i.e. to display real and expected logs. Unfortunately in practice to use it you have to edit the file and...The src/lib/testutils/log_utils.h allows the check logs in unit tests and offer a logCheckVerbose method to set the verbosity flags i.e. to display real and expected logs. Unfortunately in practice to use it you have to edit the file and rebuild. I propose to make its default (currently false so not verbose) depending in an environment variable e.g. KEA_LOG_CHECK_VERBOSE.
Idea from https://gitlab.isc.org/isc-projects/kea/-/merge_requests/972#note_169904kea1.9.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2218Ensure use of "echo_i" where possible in system tests2020-10-30T10:23:25ZMichal NowakEnsure use of "echo_i" where possible in system testsInstead of using `echo_i`, some tests print output via `echo "I:...`, which in many instances misses test name, e.g. `tsiggss`:
```
S:tsiggss:2020-10-15T10:16:58+0200
T:tsiggss:1:A
A:tsiggss:System test tsiggss
I:tsiggss:PORTS:12408,1240...Instead of using `echo_i`, some tests print output via `echo "I:...`, which in many instances misses test name, e.g. `tsiggss`:
```
S:tsiggss:2020-10-15T10:16:58+0200
T:tsiggss:1:A
A:tsiggss:System test tsiggss
I:tsiggss:PORTS:12408,12409,12410,12411,12412,12413,12414,12415,12416,12417
I:tsiggss:starting servers
I:testing updates to testdc1 as administrator (1)
```
I am not sure which branch was that but recently I saw a file with all `*.log` files merged (and sorted?) and it wasn't clear to which a "failed" info line belong.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/kea/-/issues/1470Trying to config-set or config-test responds with "Missing mandatory 'Control...2020-10-14T19:55:04Zdlewis-shTrying to config-set or config-test responds with "Missing mandatory 'Control-agent' parameter"The docs say nothing of this 'Control-agent' parameter, and I am just trying to update the Dhcp4 config with and API call with the following payload:
```
{
"command": "config-test",
"arguments": {
"Dhcp4": {
...The docs say nothing of this 'Control-agent' parameter, and I am just trying to update the Dhcp4 config with and API call with the following payload:
```
{
"command": "config-test",
"arguments": {
"Dhcp4": {
:
}
}
}
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2217TLS offloading with DOH2021-02-03T16:10:01ZVicky Riskvicky@isc.orgTLS offloading with DOHApparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate...Apparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate dance
* client authentication - TLS client certs + augmenting HTTP headers with proxied-for information
* logging at HTTP level
* offload the TLS processing on a dedicated system to reduce the impact of TLS on the BIND server and to centralize the certificate mgmt
- [ ] Please test this to see if it works
- [ ] Please document that this is supported in the ARM
ref: https://support.isc.org/Ticket/ModifyLinks.html?id=16797February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2216Changing NSEC3PARAM clearing the Opt-Out flag does not work2023-11-02T16:26:05ZMatthijs Mekkingmatthijs@isc.orgChanging NSEC3PARAM clearing the Opt-Out flag does not work### Summary
When changing the NSEC3 parameters, and only clear the Opt-Out flag, `named` is checking if the chain already exists. It falsely claims so.
### BIND version used
9.17 (but pretty sure its also in older versions)
### Steps...### Summary
When changing the NSEC3 parameters, and only clear the Opt-Out flag, `named` is checking if the chain already exists. It falsely claims so.
### BIND version used
9.17 (but pretty sure its also in older versions)
### Steps to reproduce
1. Set up a zone with inline-signing.
2. Start `named`.
3. Run `rndc signing -nsec3param 1 1 5 -` to change to NSEC3.
4. Now run `rndc signing -nsec3param 1 0 5 -` to clear the Opt-Out flag.
### What is the current *bug* behavior?
BIND 9 will keep using the NSEC3 chain with the Opt-Out flag set.
### What is the expected *correct* behavior?
BIND 9 should rebuilt the NSEC3 chain, clearing the Opt-Out flags.
### Relevant configuration files
```
zone "example." {
type master;
file "example.db";
inline-signing yes;
auto-dnssec maintain;
};
```
### Relevant logs and/or screenshots
N/A
### Possible fixes
The code first checks if there is a private TYPE65534 record that indicates if a NSEC3 chain is in progress. If that is not the case (because it is cleared or the chain has been completed), the code checks the NSEC3PARAM record. Since that has its flags always set to `0` the data compare matches, and the code thinks an existing chain exists.
We could check the NSEC3 chain for the Flags fields, but to make sure a complete chain exists, we should check every NSEC3 record.Not plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/427developer documentation is needed for system tests2020-10-19T08:36:32ZMichal Nowikowskideveloper documentation is needed for system tests0.13Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2215DNS_ZONEFLAG_NOIXFR is misnamed2020-10-30T10:31:56ZBrian ConryDNS_ZONEFLAG_NOIXFR is misnamedAll of the other zone flags are prefixed `DNS_ZONEFLG` instead of `DNS_ZONEFLAG`All of the other zone flags are prefixed `DNS_ZONEFLG` instead of `DNS_ZONEFLAG`November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/2214forward zones aren't zones and shouldn't be configured as if they were2021-03-04T10:08:09ZBrian Conryforward zones aren't zones and shouldn't be configured as if they were"zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zone..."zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zones or `rndc addzone`.
The configuration block declaring them should be renamed to `forward` or something else unambiguous.
Alternatively, all of the things that operates on zones and can't handle a forward "zone" should be fixed so that they can.https://gitlab.isc.org/isc-projects/bind9/-/issues/2213Inline signing: AXFR before zone load on a secondary server prevents zone fro...2023-11-02T17:00:03ZMichał KępieńInline signing: AXFR before zone load on a secondary server prevents zone from being servedConsider an inline-signing secondary server ("bump-in-the-wire") that is
starting up with a previous version of a signed zone available locally.
The typical chain of events is that the server first loads the zone from
storage and then l...Consider an inline-signing secondary server ("bump-in-the-wire") that is
starting up with a previous version of a signed zone available locally.
The typical chain of events is that the server first loads the zone from
storage and then listens to any incoming NOTIFY messages indicating that
the unsigned zone has changed. When the unsigned zone gets updated, its
signed counterpart also gets updated accordingly and the process repeats
itself. This works as expected.
However, if the secondary server receives a NOTIFY for an inline-signed
zone and manages to transfer the unsigned zone in *before* attempting to
load the previous version of the signed zone from storage, things will
break in a way which prevents the inline-signed zone from being served:
```
13-Oct-2020 15:38:01.994 client @0x7f41ac0012f8 10.53.0.2#60440: received notify for zone 'bits'
13-Oct-2020 15:38:01.994 zone bits/IN (unsigned): notify from 10.53.0.2#60440: no serial
13-Oct-2020 15:38:01.994 queue_soa_query: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.461 soa_query: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 refresh_callback: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 refresh_callback: zone bits/IN (unsigned): serial: new 2011072450, old not loaded
13-Oct-2020 15:38:02.464 queue_xfrin: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 zone bits/IN (unsigned): Transfer started.
13-Oct-2020 15:38:02.464 zone bits/IN (unsigned): no database exists yet, requesting AXFR of initial version from 10.53.0.2#32589
13-Oct-2020 15:38:02.464 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: connected using 10.53.0.3#43661
13-Oct-2020 15:38:02.464 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: sent request data
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: received 168 bytes
;bits. IN AXFR
bits. 0 IN SOA ns2.bits. . 2011072450 20 20 1814400 3600
bits. 300 IN NS ns3.bits.
added.bits. 0 IN A 1.2.3.4
ns2.bits. 300 IN A 10.53.0.2
ns3.bits. 300 IN A 10.53.0.3
bits. 0 IN SOA ns2.bits. . 2011072450 20 20 1814400 3600
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: got nonincremental response
13-Oct-2020 15:38:02.467 dns_zone_verifydb: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): replacing zone database
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): zone transfer finished: success
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): transferred serial 2011072450
13-Oct-2020 15:38:02.467 zone_needdump: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone_settimer: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone_settimer: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: Transfer status: success
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: Transfer completed: 1 messages, 6 records, 168 bytes, 0.003 secs (56000 bytes/sec) (serial 2011072450)
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: freeing transfer context
13-Oct-2020 15:38:02.467 zone bits/IN (signed): number of nodes in database: 4
13-Oct-2020 15:38:02.467 zone bits/IN (signed): journal rollforward failed: journal out of sync with zone
13-Oct-2020 15:38:02.467 zone bits/IN (signed): not loaded due to errors.
13-Oct-2020 15:38:02.467 zone_postload: zone bits/IN (signed): done
13-Oct-2020 15:38:02.467 zone_needdump: zone bits/IN (signed): enter
13-Oct-2020 15:38:02.467 zone bits/IN (signed): receive_secure_db: out of range
```
The underlying cause is that in the broken case,
`lib/dns/journal.c:roll_forward()` retrieves the latest SOA serial
number for the zone from the AXFR rather than from the local copy of the
signed zone.
The time window during which this can happen is rather slim, so I do not
think it is a serious issue, but I decided to open a bug report anyway,
because things are certainly working suboptimally here - it seems to me
that `named` should be able to recover from such a sequence of events
just fine, serving the signed zone in the end.
This was found during [release testing for BIND 9.16.8][1]. I prepared
a crude patch which allows reliably triggering this issue in the
`inline` system test:
```diff
diff --git a/bin/tests/system/inline/tests.sh b/bin/tests/system/inline/tests.sh
index 7d7df7487f4..430f6fcbb77 100755
--- a/bin/tests/system/inline/tests.sh
+++ b/bin/tests/system/inline/tests.sh
@@ -475,7 +475,9 @@ status=`expr $status + $ret`
n=`expr $n + 1`
echo_i "restart bump in the wire signer server ($n)"
ret=0
+export SKIPLOAD="bits"
start_server --noclean --restart --port ${PORT} inline ns3 || ret=1
+unset SKIPLOAD
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret`
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index b8cd90b129a..57bb239c9d5 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -1995,6 +1995,16 @@ zone_load(dns_zone_t *zone, unsigned int flags, bool locked) {
REQUIRE(DNS_ZONE_VALID(zone));
+ {
+ char origin[DNS_NAME_FORMATSIZE];
+ char *skipload = getenv("SKIPLOAD");
+
+ dns_name_format(&zone->origin, origin, sizeof(origin));
+ if (skipload != NULL && !strcmp(skipload, origin)) {
+ return (ISC_R_SUCCESS);
+ }
+ }
+
if (!locked) {
LOCK_ZONE(zone);
}
```
Applying the above patch should result in:
```
I:inline:stop bump in the wire signer server (29)
I:inline:restart bump in the wire signer server (30)
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary (31)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone (32)
I:inline:failed
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary, noixfr (33)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone, noixfr (34)
```
and log lines similar to the ones quoted above appearing in
`ns3/named.run`.
AFAICT, all maintained branches are affected.
[1]: https://wiki.isc.org/bin/view/QA/BindQaResults_9_11_24#9.16.8Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2212NSEC3 Resalt2023-09-07T05:10:15ZMatthijs Mekkingmatthijs@isc.orgNSEC3 ResaltAdd an option to resalt `nsec3-resalt duration`. If not set, or set to 0, do not resalt. Otherwise, schedule a resalt task, similar to `zone_rekey`. This option should be checked for range (i.e. don't resalt every minute).Add an option to resalt `nsec3-resalt duration`. If not set, or set to 0, do not resalt. Otherwise, schedule a resalt task, similar to `zone_rekey`. This option should be checked for range (i.e. don't resalt every minute).Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org