ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-01-17T15:42:35Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/196Stork server crashed ("inet_family" contains null values)2023-01-17T15:42:35ZTomek MrugalskiStork server crashed ("inet_family" contains null values)I was running the latest master (8486047fbd6cfac836f77dbd57d6e5c53e69b57d) and got the following error:
```
$ docker-compose logs server
WARNING: Some networks were defined but are not used by any service: subnet-04, subnet-03
Attachin...I was running the latest master (8486047fbd6cfac836f77dbd57d6e5c53e69b57d) and got the following error:
```
$ docker-compose logs server
WARNING: Some networks were defined but are not used by any service: subnet-04, subnet-03
Attaching to stork_server_1
server_1 | INFO[2020-03-09 21:50:57] main.go:18 Starting Stork Server, version 0.5.0, build date 2020-03-09 22:41
server_1 | INFO[2020-03-09 21:50:57] agentcomm.go:85 Stopping communication with agents
server_1 | INFO[2020-03-09 21:50:57] agentcomm.go:93 Stopped communication with agents
server_1 | FATA[2020-03-09 21:50:57] main.go:23 unexpected error: ERROR #23502 column "inet_family" contains null values
server_1 | problem with migrating database
server_1 | isc.org/stork/server/database.Migrate
server_1 | /home/thomson/devel/stork/backend/server/database/migrations.go:55
server_1 | isc.org/stork/server/database.MigrateToLatest
server_1 | /home/thomson/devel/stork/backend/server/database/migrations.go:64
server_1 | isc.org/stork/server/database.NewPgDB
server_1 | /home/thomson/devel/stork/backend/server/database/connection.go:57
server_1 | isc.org/stork/server.NewStorkServer
server_1 | /home/thomson/devel/stork/backend/server/server.go:75
server_1 | main.main
server_1 | /home/thomson/devel/stork/backend/cmd/stork-server/main.go:21
server_1 | runtime.main
server_1 | /home/thomson/devel/stork/tools/1.13.5/go/src/runtime/proc.go:203
server_1 | runtime.goexit
server_1 | /home/thomson/devel/stork/tools/1.13.5/go/src/runtime/asm_amd64.s:1357
```
This is something I built with `rake docker_up`.1.9Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/195Can the DHCPv4 and DHCPv6 be different apps in Stork?2020-09-04T15:08:03ZVicky Riskvicky@isc.orgCan the DHCPv4 and DHCPv6 be different apps in Stork?I know we are not nitpicking the UI yet, but ... I wanted to at least lodge this request.
In the screen shot below, Kea almost always looks RED like there is an alert, because not all Kea apps are running. Can we just list, DHCPv4 or Ke...I know we are not nitpicking the UI yet, but ... I wanted to at least lodge this request.
In the screen shot below, Kea almost always looks RED like there is an alert, because not all Kea apps are running. Can we just list, DHCPv4 or Kea DHCPv4 there, instead of Kea(red) because DHCPV6 isn't running? And of course, DHCPv6 or Kea DHCPv6 if that was running?
![Screen_Shot_2020-03-09_at_1.21.14_PM](/uploads/b8bc0c27b3894426fe63393bede1f5cd/Screen_Shot_2020-03-09_at_1.21.14_PM.png)0.11Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1669"kasp" system test is failing consistently on Windows2020-04-09T06:50:14ZMichał Kępień"kasp" system test is failing consistently on WindowsThe same four checks always fail on Windows:
```
kasp1.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp1.log-I:kasp:error: bad next key event time 20909 for zone step2.algorithm-roll.kasp (expect 21600)
kasp...The same four checks always fail on Windows:
```
kasp1.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp1.log-I:kasp:error: bad next key event time 20909 for zone step2.algorithm-roll.kasp (expect 21600)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp1.log-I:kasp:error: bad next key event time 24513 for zone step5.algorithm-roll.kasp (expect 25200)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp1.log-I:kasp:error: bad next key event time 20916 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp1.log-I:kasp:error: bad next key event time 24519 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp1.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp2.log-I:kasp:error: bad next key event time 20956 for zone step2.algorithm-roll.kasp (expect 21600)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp2.log-I:kasp:error: bad next key event time 24559 for zone step5.algorithm-roll.kasp (expect 25200)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp2.log-I:kasp:error: bad next key event time 20962 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp2.log-I:kasp:error: bad next key event time 24564 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp2.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp3.log-I:kasp:error: bad next key event time 20936 for zone step2.algorithm-roll.kasp (expect 21600)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp3.log-I:kasp:error: bad next key event time 24539 for zone step5.algorithm-roll.kasp (expect 25200)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp3.log-I:kasp:error: bad next key event time 20943 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp3.log-I:kasp:error: bad next key event time 24545 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp3.log:I:kasp:failed
```
I am not sure how long this has been going on because another Windows-specific issue (!3184) has been masking this problem.
@matthijs: I have not yet looked at this problem closely, please take a look if you have some time. Keep in mind that the `kasp` test takes a lot more to run on Windows than on Unix systems (about 15 minutes; yes, you read that right). We will need to get this fixed before tagging or else we will have trouble producing release tarballs (as CI pipelines will not be able to pass).April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1668Unable to inhibit ip v6 on mirror zone.2020-03-10T04:19:01ZPeter DaviesUnable to inhibit ip v6 on mirror zone.
### Summary
unable to inhibit ip v6 on mirror zone.
### BIND version used
```
BIND 9.16.0 (Stable Release) <id:6270e602ea>
running on Linux x86_64 5.0.0-38-generic #41-Ubuntu SMP Tue Dec 3 00:27:35 UTC 2019
built by make with '--e...
### Summary
unable to inhibit ip v6 on mirror zone.
### BIND version used
```
BIND 9.16.0 (Stable Release) <id:6270e602ea>
running on Linux x86_64 5.0.0-38-generic #41-Ubuntu SMP Tue Dec 3 00:27:35 UTC 2019
built by make with '--enable-fixed-rrset' '--enable-dnstap' '--enable-querytrace' '--with-openssl' '--enable-threads' '--with-libxml2' '--with-libjson'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1b 26 Feb 2019
linked to OpenSSL version: OpenSSL 1.1.1b 26 Feb 2019
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/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
Add a mirror zone with NS records that resolve to AAAA records
### What is the current *bug* behavior?
(What actually happens.)
```
09-Mar-2020 12:29:46.434 general: info: zone ./IN: refresh: failure trying master 2620:0:2830:202::132#53 (source ::#0): operation canceled
09-Mar-2020 12:29:46.434 general: info: zone ./IN: refresh: failure trying master 2620:0:2d0:202::132#53 (source ::#0): operation canceled
09-Mar-2020 12:57:54.624 general: info: zone ./IN: refresh: failure trying master 2001:500:84::b#53 (source ::#0): operation canceled
09-Mar-2020 12:57:55.124 general: info: zone ./IN: refresh: failure trying master 2001:500:2f::f#53 (source ::#0): operation canceled
09-Mar-2020 12:57:55.124 general: info: zone ./IN: refresh: failure trying master 2001:7fd::1#53 (source ::#0): operation canceled
09-Mar-2020 12:57:55.624 general: info: zone ./IN: refresh: failure trying master 2620:0:2830:202::132#53 (source ::#0): operation canceled
09-Mar-2020 12:57:55.624 general: info: zone ./IN: refresh: failure trying master 2620:0:2d0:202::132#53 (source ::#0): operation canceled
09-Mar-2020 13:24:27.815 general: info: zone ./IN: refresh: failure trying master 2001:500:84::b#53 (source ::#0): operation canceled
09-Mar-2020 13:24:28.315 general: info: zone ./IN: refresh: failure trying master 2001:500:2f::f#53 (source ::#0): operation canceled
09-Mar-2020 13:24:28.315 general: info: zone ./IN: refresh: failure trying master 2001:7fd::1#53 (source ::#0): operation canceled
09-Mar-2020 13:24:28.815 general: info: zone ./IN: refresh: failure trying master 2620:0:2830:202::132#53 (source ::#0): operation canceled
09-Mar-2020 13:24:28.815 general: info: zone ./IN: refresh: failure trying master 2620:0:2d0:202::132#53 (source ::#0): operation canceled
09-Mar-2020 13:53:34.012 general: info: zone ./IN: refresh: failure trying master 2001:500:84::b#53 (source ::#0): operation canceled
09-Mar-2020 13:53:34.512 general: info: zone ./IN: refresh: failure trying master 2001:500:2f::f#53 (source ::#0): operation canceled
09-Mar-2020 13:53:34.512 general: info: zone ./IN: refresh: failure trying master 2001:7fd::1#53 (source ::#0): operation canceled
09-Mar-2020 13:53:35.012 general: info: zone ./IN: refresh: failure trying master 2620:0:2830:202::132#53 (source ::#0): operation canceled
09-Mar-2020 13:53:35.012 general: info: zone ./IN: refresh: failure trying master 2620:0:2d0:202::132#53 (source ::#0): operation canceled
```
### What is the expected *correct* behavior?
bind should not be trying to use ipv6 addresses.
### Relevant configuration files
```
server ::/0 { bogus yes; };
listen-on-v6 { none; };
zone "." {.
type mirror;
file "s/db.root";
};
```
### Relevant logs and/or screenshots
### Possible fixeshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1667Release Checklist for BIND 9.11.17, BIND 9.11.17-S1, BIND 9.16.1, BIND 9.17.02020-03-20T05:08:01ZMichał KępieńRelease Checklist for BIND 9.11.17, BIND 9.11.17-S1, BIND 9.16.1, BIND 9.17.0## Release Schedule
**Tagging Deadline:** Wednesday, March 11th, 2020
**Public Release:** Wednesday, March 18th, 2020
## Release Checklist
## 2 Working Days Before the Tagging Deadline
- [x] ***(QA)*** Check whether all issues assi...## Release Schedule
**Tagging Deadline:** Wednesday, March 11th, 2020
**Public Release:** Wednesday, March 18th, 2020
## Release Checklist
## 2 Working Days Before the Tagging Deadline
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
## Before the Tagging Deadline
- [x] ***(QA)*** Inform Support/Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(SwEng)*** Update API files for libraries with new version information.
- [x] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(SwEng)*** Update `CHANGES`.
- [x] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(SwEng)*** Update `README.md`.
- [x] ***(SwEng)*** Update `version`.
- [x] ***(SwEng)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that all the above steps were performed correctly.
- [x] ***(QA)*** Check that the contents of release notes match the merge requests comprising the releases.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.)
- [x] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
## Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
## On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(SwEng)*** Push tags for the published releases to the public repository.
- [x] ***(SwEng)*** Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`).
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: Preferred command line: `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc.March 2020 (9.11.17, 9.16.1, 9.17.0)Cathy AlmondCathy Almond2020-03-18https://gitlab.isc.org/isc-projects/kea/-/issues/1145Kea ARM must have pointers to cloudsmith/native packages2020-03-17T10:58:15ZTomek MrugalskiKea ARM must have pointers to cloudsmith/native packagesKea ARM does not mention native packages and doesn't have any links to Cloudsmith. It absolutely should.Kea ARM does not mention native packages and doesn't have any links to Cloudsmith. It absolutely should.kea1.7.6https://gitlab.isc.org/isc-projects/bind9/-/issues/1665Intermittent padding system test failure2023-10-23T13:58:49ZMatthijs Mekkingmatthijs@isc.orgIntermittent padding system test failurehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/742007
```
I:padding:error: opad (5) != npad (6)
I:padding:failed
```https://gitlab.isc.org/isc-projects/bind9/-/jobs/742007
```
I:padding:error: opad (5) != npad (6)
I:padding:failed
```BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1664double unlock on dns_db_newversion failure in zone.c2020-03-09T23:47:13ZMark Andrewsdouble unlock on dns_db_newversion failure in zone.clib/dns/zone.c:
```
20483 if (zone->db != NULL) {
20484 dns_db_attach(zone->db, &db);
20485 }
4. unlock: isc_rwlock_unlock unlocks zone->dblock.rwlock. [show details]
5. Condition !!(isc_rwlock_u...lib/dns/zone.c:
```
20483 if (zone->db != NULL) {
20484 dns_db_attach(zone->db, &db);
20485 }
4. unlock: isc_rwlock_unlock unlocks zone->dblock.rwlock. [show details]
5. Condition !!(isc_rwlock_unlock(&zone->dblock, isc_rwlocktype_read) == 0), taking true branch.
6. Condition !!(isc_rwlock_unlock(&zone->dblock, isc_rwlocktype_read) == 0), taking true branch.
20486 ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
7. Condition db == NULL, taking false branch.
20487 if (db == NULL) {
20488 goto failure;
20489 }
20490
20491 dns_db_currentversion(db, &oldver);
20492 result = dns_db_newversion(db, &newver);
8. Condition result != 0, taking true branch.
20493 if (result != ISC_R_SUCCESS) {
CID 288540 (#1 of 1): Double unlock (LOCK)
9. double_unlock: isc_rwlock_unlock unlocks zone->dblock.rwlock while it is unlocked.
20494 ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
20495 dnssec_log(zone, ISC_LOG_ERROR,
20496 "setnsec3param:dns_db_newversion -> %s",
20497 dns_result_totext(result));
20498 goto failure;
20499 }
```April 2020 (9.11.18, 9.16.2, 9.17.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/stork/-/issues/193Test Stork on FreeBSD and OpenBSD2023-11-26T13:32:21ZTomek MrugalskiTest Stork on FreeBSD and OpenBSDOne of the fundamental requirements for the Stork project was that it's supposed to be portable. We decided that the two systems Stork should run on are Ubuntu and FreeBSD. Jeff confirmed that our commitment to FreeBSD remains as import...One of the fundamental requirements for the Stork project was that it's supposed to be portable. We decided that the two systems Stork should run on are Ubuntu and FreeBSD. Jeff confirmed that our commitment to FreeBSD remains as important as it was throughout the years. So far we're running Stork on Ubuntu and did some quick tests on FreeBSD and discovered some problems with running it there.
Note the following excerpt from Rakefile:
```Rakefile
when "FreeBSD"
OS="FreeBSD"
# TODO: there are no swagger built packages for FreeBSD
GOSWAGGER_BIN=""
puts "WARNING: There are no FreeBSD packages for GOSWAGGER_BIN"
GO_SUFFIX="freebsd-amd64"
# TODO: there are no protoc built packages for FreeBSD (at least as of 3.10.0)
PROTOC_ZIP_SUFFIX=""
puts "WARNING: There are no protoc packages built for FreeBSD"
NODE_SUFFIX="node-v10.16.3.tar.xz"
GOLANGCILINT_SUFFIX="freebsd-amd64"
```
One of the possible ways to avoid problems with missing goswagger binaries is to generate the API bindings only when they're changed and keep them checked into the repo. See #182 for related problem.
As for the protoc, there are [no FreeBSD builds](https://github.com/protocolbuffers/protobuf/releases/download) as of March 2020. However, that can be compiled from sources.
**EDIT:** Updated title to reflect OpenBSD changes.1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/192Deploying Stork agent2021-01-28T10:43:25ZTomek MrugalskiDeploying Stork agentI did a demo in early March. One of the comments from @jsosborn was about stork-agent deployment. We don't have any solution for that. I think we can consider the following:
- have the stork-agent binary being available for download fro...I did a demo in early March. One of the comments from @jsosborn was about stork-agent deployment. We don't have any solution for that. I think we can consider the following:
- have the stork-agent binary being available for download from the stork-server.
- once the user clicks "deploy stork agent", he/she will be shown a list of commands to copy-paste into the target machine.
- this could be something like wget https://stork-address/deploy/stork-deploy.sh && sh stork-deploy.sh.
Obviously, this is just a proposal and the actual deployment can be done differently.
In the future, we will have Stork agent in native packages, so the instructions may be somewhat simpler.
In the FAR future, we will have an automated deployment (where the server connects to the target machine and does something), but this will always be an optional step as it is controversial. Some (many?) admins will never reveal their password to third party software (such as stork). Also, there are many current solution (puppet, chef, ansible) that are dealing with deploying software. We don't want to reinvent them. Perhaps a note with links to those solution would be useful?0.15Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1663Zone not signed nor loaded with NSEC32021-10-22T11:29:41ZLibor PeltanZone not signed nor loaded with NSEC3**Scenario I** (what works):
(1) I configure options `inline-signing`, `auto-dnssec: maintain`, `key-directory`. \
(2) I create a pair of keys with `dnssec-keygen`. \
(3) I put the resulting DNSKEY records into the unsigned zone file. \...**Scenario I** (what works):
(1) I configure options `inline-signing`, `auto-dnssec: maintain`, `key-directory`. \
(2) I create a pair of keys with `dnssec-keygen`. \
(3) I put the resulting DNSKEY records into the unsigned zone file. \
(4) I start Bind.
The result: the zone is signed with NSEC chain and published. (Further DDNS updates are processed including NSECs and RRSIGs reconstruction.)
**Scenario II** (what does not work):
The same, but in step (3), I also add a NSEC3PARAM record to the unsigned zone file.
**Expected:**
After startup, Bind should sign the zone with NSEC3 chain and publish it.
**Observed:**
(a) Bind does not sign the zone. Not even with NSECs. The file `example.com.zone.signed` does not appear. \
(b) Bind does not publish the zone at all. All queries are responded with SERVFAIL. \
(c) A log message says "all zones loaded", which is untrue according to (b). \
(d) The only log message possibly indicating any problem says "signed dynamic zone has no resign event scheduled", which gives no clue of what happened.
I consider ALL of these four points (a) - (d) bugs.
Workaround:
Let Bind start with NSEC chain with Scenario I, and after Bind starts up, perform NSEC -> NSEC3 transition with `rndc signing -nsec3param 1 0 10 <salt> example.com.`. However, I don't like this because I want to avoid publishing the zone with NSECs for any second.
Note:
My observations differ from #953
**Bind9 version**:
```
starting BIND 9.11.3-1ubuntu1.11-Ubuntu (Extended Support Version) <id:a375815> \
running on Linux x86_64 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 \
built with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libjson=/usr' '--without-lmdb' '--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib/softhsm/libsofthsm2.so' '--with-randomdev=/dev/urandom' '--with-eddsa=no' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-uW3Pyl/bind9-9.11.3+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
```BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1662AddressSanitizer: heap-use-after-free on address 0x61f00108e880 at pc 0x00000...2020-03-11T21:49:45ZOndřej SurýAddressSanitizer: heap-use-after-free on address 0x61f00108e880 at pc 0x000000b9b2d7 bp 0x7fffb28ac530 sp 0x7fffb28ac528```
=====================================================================
TIME: 2020-03-05.19:28:08
=====================================================================
FUZZER ARGS:
mutationsPerRun : 6
externalCmd : NULL
fuzzStdi...```
=====================================================================
TIME: 2020-03-05.19:28:08
=====================================================================
FUZZER ARGS:
mutationsPerRun : 6
externalCmd : NULL
fuzzStdin : FALSE
timeout : 10 (sec)
ignoreAddr : (nil)
ASLimit : 0 (MiB)
RSSLimit : 0 (MiB)
DATALimit : 0 (MiB)
wordlistFile : NULL
dynFileMethod :
fuzzTarget : /usr/local/google/home/swiecki/fuzz/bind/bind9/bin/named/named -A resolver:3.3.3.3:1 -f -c /usr/local/google/home/swiecki/fuzz/bind/dist/etc/named.conf
CRASH:
DESCRIPTION: AddressSanitizer: heap-use-after-free on address 0x61f00108e880 at pc 0x000000b9b2d7 bp 0x7fffb28ac530 sp 0x7fffb28ac528
ORIG_FNAME: [DYNAMIC]
FUZZ_FNAME: /usr/local/google/home/swiecki/fuzz/bind/SIGABRT.PC.b9b2d7.STACK.19b8eb8a5.CODE.-6.ADDR.0.INSTR.lea____0x507186(%rip),%rdi________#_0x000000000050718d.fuzz
PID: 391
SIGNAL: SIGABRT (6)
PC: 0xb9b2d7
FAULT ADDRESS: 0x0
INSTRUCTION: lea____0x507186(%rip),%rdi________#_0x000000000050718d
STACK HASH: 000000019b8eb8a5
STACK:
<0x0000000000b9b2d6> [func:isc_nmhandle_ref file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/isc/netmgr/netmgr.c line:1088 module:]
<0x0000000000ba3577> [func:isc__nm_tcp_send file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/isc/netmgr/tcp.c line:801 module:]
<0x0000000000ba9e4a> [func:isc__nm_tcpdns_send file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/isc/netmgr/tcpdns.c line:489 module:]
<0x00000000005a627b> [func:client_sendpkg file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/client.c line:364 module:]
<0x00000000005a7158> [func:ns_client_send file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/client.c line:632 module:]
<0x00000000005aa59e> [func:ns_client_error file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/client.c line:921 module:]
<0x00000000005d10ff> [func:query_error file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/query.c line:579 module:]
<0x00000000005cb7b6> [func:ns_query_done file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/query.c line:10863 module:]
<0x00000000005d6c5a> [func:query_gotanswer file:in query_gotanswer /usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/query.c
line:0 module:]
<0x0000000000610272> [func:query_resume file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/query.c line:6121 module:]
<0x00000000005cfb4a> [func:fetch_callback file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/ns/query.c line:5703 module:]
<0x0000000000bd0a07> [func:dispatch file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/isc/task.c line:1152 module:]
<0x0000000000bcca3b> [func:run file:/usr/local/google/home/swiecki/fuzz/bind/bind9/lib/isc/task.c line:1344 module:]
<0x00007ffff7c88fb6> [func:start_thread file: line:0 module:/lib/x86_64-linux-gnu/libpthread.so.0+0x8fb6]
<0x00007ffff79fe2de> [func:clone file: line:0 module:/lib/x86_64-linux-gnu/libc.so.6+0xfa2de]
=====================================================================
```
[HF.sanitizer.log.337](/uploads/31aeb76a19acc32c4de4d0f915bb15ac/HF.sanitizer.log.337)
[SIGABRT.PC.b9b2d7.STACK.19b8eb8a5.CODE.-6.ADDR.0.INSTR.lea____0x507186__rip___rdi__________0x000000000050718d.fuzz](/uploads/a49c3d6c52e3b4cb4788ceef2e959c84/SIGABRT.PC.b9b2d7.STACK.19b8eb8a5.CODE.-6.ADDR.0.INSTR.lea____0x507186__rip___rdi__________0x000000000050718d.fuzz)March 2020 (9.11.17, 9.16.1, 9.17.0)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/stork/-/issues/190preparation for 0.5 release2020-03-06T12:05:33ZMichal Nowikowskipreparation for 0.5 release0.5Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/189Fix docker traffic-dhcp build2020-03-06T07:45:50ZMatthijs Mekkingmatthijs@isc.orgFix docker traffic-dhcp build0.5Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1661"max-journal-size default" is based on the wrong DB size in 9.162020-05-19T00:37:13ZEvan Hunt"max-journal-size default" is based on the wrong DB size in 9.16In the work for #1515 (`max-ixfr-ratio`) it became clear that `dns_db_getsize()` was not returning the correct database size in bytes - it returns the sum of the sizes of all the rdataslabs in the database, which have a great deal of ext...In the work for #1515 (`max-ixfr-ratio`) it became clear that `dns_db_getsize()` was not returning the correct database size in bytes - it returns the sum of the sizes of all the rdataslabs in the database, which have a great deal of extra overhead space in them. This was corrected in master, but should also be fixed in 9.16 (even if we don't backport `max-ixfr-ratio`), because it's used to compute the maximum journal size when `max-journal-size` is set to `default`.April 2020 (9.11.18, 9.16.2, 9.17.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1660Review tcpdns closing2020-07-01T20:34:08ZWitold KrecickiReview tcpdns closingClosing TCPDNS socket is tricky, review it thoroughly to make sure there are no races (e.g. between closing the socket and closing socket timers).Closing TCPDNS socket is tricky, review it thoroughly to make sure there are no races (e.g. between closing the socket and closing socket timers).July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/stork/-/issues/188Add data model for host reservations2020-03-17T17:54:47ZMarcin SiodelskiAdd data model for host reservationsWe need a data model in the Stork database to store host reservations. Multiple reservations may appear for a single host and the host may be identified in various ways, e.g. using MAC address, using DHCP specific values such as client i...We need a data model in the Stork database to store host reservations. Multiple reservations may appear for a single host and the host may be identified in various ways, e.g. using MAC address, using DHCP specific values such as client identifier or anything else. This ticket adds such model to the database. The reservations should initially include IP addresses and delegated prefixes. We don't store DHCP options at this point for host reservations.0.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1143Implement ISC Code of Conduct for Kea2020-07-21T18:26:25ZVicky Riskvicky@isc.orgImplement ISC Code of Conduct for KeaWe have decided/been informed, that we need to extend the ISC code of conduct to Kea.
We are going to use the CoC already adopted for the BIND 9 project.
* [x] post Coc in this repo in a separate file (!688)
* [x] link to coc in readm...We have decided/been informed, that we need to extend the ISC code of conduct to Kea.
We are going to use the CoC already adopted for the BIND 9 project.
* [x] post Coc in this repo in a separate file (!688)
* [x] link to coc in readme (!688)
* [x] email user-list, kea-dev to explain/notify
* [x] add reference to coc on kea-users list signup page (at ISC and Nabble) (waiting for merge to main branch so we can link to the Coc in the repo)
* [x] update bounceback for new subscribers (waiting for merge to main branch so we can link to the Coc in the repo)
* [x] update Reporting Guidelines on ISC web site
* [x] add DHCP Dev Director to reporting teamkea1.7.10Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/187implement building deb and rpm packages with stork2020-03-17T14:05:20ZMichal Nowikowskiimplement building deb and rpm packages with stork0.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/186add support for pd-pools2023-02-08T16:52:48ZMichal Nowikowskiadd support for pd-poolsthey need to be handled in Stork server and in UI (subnets and shared networks pages)they need to be handled in Stork server and in UI (subnets and shared networks pages)1.9Slawek FigielSlawek Figiel