ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-27T13:54:38Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2340Enable logging of rpz re-writes to dnstap.2024-03-27T13:54:38ZPeter DaviesEnable logging of rpz re-writes to dnstap.### Description
Enable logging of rpz re-writes to dnstap.
The ability to send rpz rewrite information that is generated by category rpz to the dnstap output stream.
[RT #17273](https://support.isc.org/Ticket/Display.html?id=17273)### Description
Enable logging of rpz re-writes to dnstap.
The ability to send rpz rewrite information that is generated by category rpz to the dnstap output stream.
[RT #17273](https://support.isc.org/Ticket/Display.html?id=17273)Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2336Implement TSIG-GSS on Windows2020-12-04T08:37:04ZMark AndrewsImplement TSIG-GSS on WindowsWindows should have the necessary components to do this using Windows APIs.Windows should have the necessary components to do this using Windows APIs.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2331Check whether `dig +trace` works on main2023-11-02T17:00:03ZOndřej SurýCheck whether `dig +trace` works on mainWe should double check that `dig +trace` still works, because it often executes nm_read() inside readcb.We should double check that `dig +trace` still works, because it often executes nm_read() inside readcb.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2330Add a test that max-udp-size can send a 4096 octet UDP response if it is set ...2022-03-01T09:42:51ZOndřej SurýAdd a test that max-udp-size can send a 4096 octet UDP response if it is set to that value.Stemmed from the MR: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4449#note_180129
People expect that `max-udp-size` changes the EDNS Buffer Size and the throttling by `nocookie-udp-size` was bit unexpected. Let's add a t...Stemmed from the MR: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4449#note_180129
People expect that `max-udp-size` changes the EDNS Buffer Size and the throttling by `nocookie-udp-size` was bit unexpected. Let's add a test that matches the people's expectations.Not plannedhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/152Support DHCP relay on interfaces with zero MAC address2022-03-09T19:06:03ZQingtao CaoSupport DHCP relay on interfaces with zero MAC addressThe dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC a...The dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC address, the ipsecX interfaces built upon such wwanX interfaces won't have L2 addresses, resulting in the dhcrelay daemon unable to use them.
I will try to propose a patchset to support such interfaces.Outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2301Add FIPS mode enabled builds to GitLab CI2022-06-22T15:06:44ZMichal NowakAdd FIPS mode enabled builds to GitLab CIBIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/...BIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281 ([performs](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281/diffs#87db583be5c13c1f7b3c958b10e03d67b6a2ca06) builds with `--enable-fips-mode`)
- [ ] System test can run without MD5 (there's plenty of `algorithm hmac-md5;` in system test or implicit expectation of MD5 in `dig` invocations in `acl` and `allow-query` system tests)
- [ ] Red Hat FIPS patches by @pemensik at https://src.fedoraproject.org/rpms/bind/tree/master for `v9_11` evaluated
- [ ] FIPS-enabled host or VM image (most likely with CentOS)
- [ ] CI job(s) with `--enable-fips-mode` in the build stage and subsequent unit and system test CI jobsNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2297Add long term server properties database2023-11-02T16:26:05ZMark AndrewsAdd long term server properties databaseAdd long term server properties database which is updated from routine traffic so that named doesn't have to relearn server characteristics.
e.g. Supports DNS COOKIEAdd long term server properties database which is updated from routine traffic so that named doesn't have to relearn server characteristics.
e.g. Supports DNS COOKIENot plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/450Stork build process from release sources with minimal build dependencies2022-06-28T17:18:14ZCarsten StrotmannStork build process from release sources with minimal build dependenciesIt would be nice to be able to build the Stork agent/server binaries from the release sources with just
go build ...
instead of the rake process and all it's dependencies. The generated API source files could be part of the release sou...It would be nice to be able to build the Stork agent/server binaries from the release sources with just
go build ...
instead of the rake process and all it's dependencies. The generated API source files could be part of the release sources, as they should be stable for a release.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2260Fix pkcs11 system test to handle revoked key collisions.2022-03-01T09:42:56ZMark AndrewsFix pkcs11 system test to handle revoked key collisions.Job [#1286395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1286395) failed for c19a35c945ebc21272143253d408e145b949a966:
```
S:pkcs11:2020-11-10T04:19:15+0000
T:pkcs11:1:A
A:pkcs11:System test pkcs11
I:pkcs11:PORTS:30765,30766,3076...Job [#1286395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1286395) failed for c19a35c945ebc21272143253d408e145b949a966:
```
S:pkcs11:2020-11-10T04:19:15+0000
T:pkcs11:1:A
A:pkcs11:System test pkcs11
I:pkcs11:PORTS:30765,30766,30767,30768,30769,30770,30771,30772,30773,30774
=I:pkcs11:Generating keys for Native PKCS#11
dnssec-keyfromlabel: fatal: dnssec-keyfromlabel: ./Krsasha256.example.+008+38641 could collide with another key upon revokation
I:pkcs11:setup.sh script failed
R:pkcs11:FAIL
E:pkcs11:2020-11-10T04:19:15+0000
FAIL pkcs11 (exit status: 1)
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2257Follow-up from "use netmgr for xfrin"2022-03-01T09:43:01ZOndřej SurýFollow-up from "use netmgr for xfrin"The following discussion from !4246 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4246#note_175084): (+1 comment)
> This is the last weird thing:
>
> ...The following discussion from !4246 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4246#note_175084): (+1 comment)
> This is the last weird thing:
>
> a) how do we get here with the (previous) transfer still attached?
> b) should this be `dns_xfrin_shutdown(&zone->xfr);`?Not plannedhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/144Cisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to sa...2020-12-03T15:37:35ZGunnar HaslingerCisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to same VPN-Clients**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the sam...**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the same IP as it got yesterday. Our idea is to provide an IP-lease-Pool big enough to have pseudo-static Client-IP-Addresses. The address the client gets on it's first connect should be the same it gets the following days/months.
**Currently VPN-Clients are not assigned the same IP-Address, because:**
- Cisco ASA is acting as DHCP-Client for the VPN-Clients
- The Client-MAC of all VPN-Clients is the same (the ASA MAC)
The Client-UID (Client identifier) sent by the ASA is a combined-string of `"cisco-$MAC-$Hostname$Counter-inside"`.
- For example: `cisco-0050.5680.4b04-ClientA4567-inside`
- The Prefix "cisco" + MAC-Address of the Cisco-ASA is always the same: `cisco-0050.5680.4b04`
- The Hostname (e.g. "ClientA") is the real (unique) Hostname of our Client-Machines
- The counter counts up on every connection.
- Suffix "-inside" is always the same
- If "ClientA" disconnects and connects again it will be like `cisco-0050.5680.4b04-ClientA4568-inside` (the last digits count up)
- There seem to be no way to configure the Cisco ASA to not count up the Client-UIDs last digits on each connection
- We tried to use Option "`ignore-client-uids true;`" to reassign the same IP-Address - but this does not work, because without UID only the MAC-Address is used to re-assign the IP-Address, but all Clients have the same (Cisco ASA) MAC-Address.
**Are there any suggestions?**
- If there is no solution for this scenario, we are interested to implement an new ISC DHCPd Option "`hostname-as-uid true;`" to create the possibility to address this scenario.
- This option "`hostname-as-uid true;`" could be used like the existing "`ignore-client-uids true;`" Option, but instead of not saving the Client-UID we would override the received Client-UID with the received hostname-option.
- All functionality like storing the uid to the lease-file, checking if there is a lease for the client with the given Client-UID etc... will be done with the "replaced uid" (= Hostname) instead of the real received Client-UID.
- Are there any other suggestions or comments on this?
- Is there interest to accept a merge request if we implement such a feature?Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/142Overflow in lease time and potentially in renew/rebind of IPv6 client2022-03-07T13:16:09ZChristos ChryssochoidisOverflow in lease time and potentially in renew/rebind of IPv6 client---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6...---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6.c` cause overflow in systems using a **32 bit signed integer for the TIME data type**. As a result dhclient enters an infinite loop since a negative relative expiration time is considered immediately expired.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcp server IPv6 with a config containing the following:
```
default-lease-time 4294967294; # or -2
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
```
2. A client solicits a new lease by broadcasting a SOLICIT packet. The above server sends then an ADVERTISE, following by the client sending a REQUEST, and finally the server sending a REPLY.
3. The client then immediately repeats sending a SOLICIT packet.
4. This cycle goes on forever.
**Expected behavior**
After receiving the REPLY packet the client should not repeat sending a SOLICIT packet.
**Environment:**
isc-dhclient-4.1-ESV-R16
- OS: Embedded Linux (**MIPS64n32** architecture)
**Additional Information**
An example config for IPv6 dhcp server is the following:
[dhcpd6-example.conf](/uploads/556d0909d055e86398985aa5abc5ef74/dhcpd6-example.conf)
In the logs I'm seeing the following line:
> PRC: Renewal event scheduled in 3600 seconds, to run for 3600 seconds. PRC: Depreference scheduled in 7200 seconds. PRC: Expiration scheduled in **-2 seconds.**
**Some initial questions**
> - Are you sure your feature is not already implemented in the latest ISC DHCP version?
I've tested it with the latest ESV version of dhclient.
> - Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
It's a client issue, therefore migrating to Kea doesn't seem to provide solution to this problem.
> - Are you sure what you would like to do is not possible using some other mechanisms?
No.
> - Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
No.
**Describe the solution you'd like**
I'm attaching a patch that seems to solve this issue:[dhclient.patch](/uploads/d13a046a05524006b6571e003a35e327/dhclient.patch)
**Context**
Seems to happen when the TIME data type used for lifetime and renew/rebind time calculations is a 32 bit signed integer type.
**Participating in development**
Yes, I am willing to participate in the development.
**Contacting you**
contact email: christos.chryssochoidis@nokia.comOutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2234Add ARM64 build, unit and system test CI jobs2020-10-26T12:30:11ZMichal NowakAdd ARM64 build, unit and system test CI jobsWe used to have ARM64 host before, but it was removed due to it's connectivity problems.
We should add ARM64 CI jobs for two reasons:
1. we support the ARM64 platform and distributions are [actively packaging it](https://gitlab.isc.org...We used to have ARM64 host before, but it was removed due to it's connectivity problems.
We should add ARM64 CI jobs for two reasons:
1. we support the ARM64 platform and distributions are [actively packaging it](https://gitlab.isc.org/isc-projects/bind9/-/issues/2167)
2. Fedora on ARM64 is one of stress test targets and we should ensure that BIND works on this platform before we proceed to later stages of the release process
This requires ARM64 host, possibly AWS, performance-wise we should be close to AMD64 hosts not to block pipelines.
OS platform should be Fedora to match stress test CI jobs.Not plannedhttps://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/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/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.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2186rndc thaw does not correctly process zone changes2022-03-01T09:47:44ZJean-Christophe Manciotrndc thaw does not correctly process zone changes- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL ...- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL 604800 --> $TTL 3600
# rndc thaw sdxlive.com
```
Most RRs keep their original TTL:
```
# bind-get-all-resource-records.sh sdxlive.com|grep " 604800 "
zone sdxlive.com/IN: loaded serial 2020092411 (DNSSEC signed)
OK
sdxlive.com. 604800 IN NS ns1.sdxlive.com.
sdxlive.com. 604800 IN RRSIG NS 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. WgQwG0FpqPOPiTZKi65qn01Fe4g3qRkQ0OybOLawl7PlWWKc9XdYMTwf 7AP3c/fKnE0l0BujSSir8HKf4IBVjw==
sdxlive.com. 604800 IN A 176.139.106.168
sdxlive.com. 604800 IN RRSIG A 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. sqeyUzMxZ6JlK+hr6XlLKBJHAZmmVo+ku8oElfuc+6rH8Cr+uKNovK6F Awu76tmcURpR5grYDA0vsC5Cl3B0aQ==
sdxlive.com. 604800 IN MX 1 mail.sdxlive.com.
sdxlive.com. 604800 IN RRSIG MX 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. xZiYSxYb4gX3e2ZbcC2cmEHT7IKUT/c+wil3ZioViRsW+4RLH/LAJ6Mp eC9+ooWgN7jjArM4EvEQCl6xkuln3Q==
and so on...
```
Same issue if I begin with a ```rndc sync -clean sdxlive.com``` before the zone freeze.
Am I missing something?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2182statschannel python test leave no forensic traces to work out what went wrong.2023-11-02T17:00:03ZMark Andrewsstatschannel python test leave no forensic traces to work out what went wrong.Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Not plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/407automate combining ChangeLog into release notes2021-03-02T18:22:51ZMichal Nowikowskiautomate combining ChangeLog into release notesoutstanding