ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-08-02T15:41:17Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/229Forward to OpenDNS, with non-standard tags (aka Cisco Umbrella)2023-08-02T15:41:17ZVicky Riskvicky@isc.orgForward to OpenDNS, with non-standard tags (aka Cisco Umbrella)### Description
1) Customer would like to use BIND resolvers to resolve queries for internal zones and any that the Customer are authoritative for, and forward all queries for external addresses to the hosted OpenDNS resolver service (a...### Description
1) Customer would like to use BIND resolvers to resolve queries for internal zones and any that the Customer are authoritative for, and forward all queries for external addresses to the hosted OpenDNS resolver service (aka Cisco Umbrella). The object is to use OpenDNS to filter these external queries and control responses to the client.
### Request
2) ISC will develop an OpenDNS-filtering feature in BIND that will add three additional bit of information required by OpenDNS to queries forwarded to the OpenDNS system. These three fields are: Virtual ApplianceID (a numeric ID the Customer will statically configure into the BIND server used to identify the geographical site), an Organizational ID (also statically configured by the Customer, used to identify the Customer's resolvers), and a ClientIP address (IPv4 or IPv6 address, can be RFC 1918, which BIND will get from the DNS query and pass through to OpenDNS in the forwarded query).
3) The additional information sent to OpenDNS will be encoded in a ‘Protoss’ format EDNS option specified by OpenDNS.
4) ISC will minimize caching of responses from the OpenDNS resolver in BIND, although caching of approximately a second is unavoidable. In case of caching, ISC will cache responses per client.
5) ISC will perform interoperability testing with OpenDNS by accessing a test OpenDNS account provided by Cisco.
6) This new feature will be provided to the customer in a BIND 9.11.x-S subscriber-only release. These are stable releases supported by ISC for subscribers, but are not part of the public open source. There will be some minimal documentation provided about how to enable the feature and configure the two new options.
### Links / references
Evan has been in communication with the OpenDNS development staff about the format of the proprietary options.BIND-9.11.4-SEvan HuntEvan Hunt2018-06-13https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/12Create kea-ctrl-agent configuration2023-08-02T15:08:02ZDarren AnkneyCreate kea-ctrl-agent configurationGather necessary details for use in kea-ctrl-agent configuration. This could be tricky as `Control Socket:` for both `kea-dhcp4` and `kea-dhcp6` config files will be needed. These files are / will be created separately which could intr...Gather necessary details for use in kea-ctrl-agent configuration. This could be tricky as `Control Socket:` for both `kea-dhcp4` and `kea-dhcp6` config files will be needed. These files are / will be created separately which could introduce the possibility of user-error.https://gitlab.isc.org/isc-projects/stork/-/issues/1123Bug in handling an empty HA failure time2023-08-02T12:48:49ZSlawek FigielBug in handling an empty HA failure timeThe issue was reported by @marcin during [1.12 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1122#note_393110).
We introduced regression in the dashboard related to the `showHAFailureTime`:
![Zrzut_ekranu_2023-08-2_...The issue was reported by @marcin during [1.12 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1122#note_393110).
We introduced regression in the dashboard related to the `showHAFailureTime`:
![Zrzut_ekranu_2023-08-2_o_12.55.44](https://gitlab.isc.org/isc-projects/stork/uploads/074f6cee431186acbd228f0f74e1988f/Zrzut_ekranu_2023-08-2_o_12.55.44.png)
The problem is we don't see services status beyond the first one that failed.
That's what I get in the console:
```
ERROR TypeError: n is null
showHAFailureTime http://localhost:8080/main.76ff0b13e4fb0d4e.js:1
Sfe http://localhost:8080/main.76ff0b13e4fb0d4e.js:1
```1.12Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/20Add support for kea-dhcp6 configuration generation2023-08-02T11:17:07ZDarren AnkneyAdd support for kea-dhcp6 configuration generationCurrently, only `kea-dhcp4` configurations can be generated. This is a stub ticket that will track adding support for `kea-dhcp6` in this milestone. Many tickets will be needed probably as there are several concerns. A partial list of ...Currently, only `kea-dhcp4` configurations can be generated. This is a stub ticket that will track adding support for `kea-dhcp6` in this milestone. Many tickets will be needed probably as there are several concerns. A partial list of the concerns follows.
- Subnets will need different fields shown
- Some validation will need to change based on type chosen (the validation should return an error if `kea-dhcp6` isn't supported)
- `interfaces-config` will need different validation depending on type
- The logging configuration will need to change in some way depending on typehttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/19Expanded interfaces-config validation2023-08-02T11:16:58ZDarren AnkneyExpanded interfaces-config validationExpand the `interfaces-config` validation to allow matching of more interfaces. Especially this will be needed for `kea-dhcp6` support. See the ARM for the `interfaces-config` that are allowed. Separate pattern matching may be needed ...Expand the `interfaces-config` validation to allow matching of more interfaces. Especially this will be needed for `kea-dhcp6` support. See the ARM for the `interfaces-config` that are allowed. Separate pattern matching may be needed between `kea-dhcp4` and `kea-dhcp6`.https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/18Add hook support2023-08-02T11:16:50ZDarren AnkneyAdd hook supportAdd support for hooks in the configuration. Some restrictions:
- Only the open source hooks
- With the exception of HA, if the hook requires additional information, don't include.
- Use a checklist to enable the desired hooks
- Gather t...Add support for hooks in the configuration. Some restrictions:
- Only the open source hooks
- With the exception of HA, if the hook requires additional information, don't include.
- Use a checklist to enable the desired hooks
- Gather the file location of the hooks libraries (probably need some simple `find` instructions here)
- HA hook will need gathering of additional parametershttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/17High Availability support2023-08-02T11:16:42ZDarren AnkneyHigh Availability supportAdd support for a simple HA configuration. Explain that the entire Kea configuration should be the same on both servers with the exception of `"this-server-name"`. Just gather some information, don't allow complicated configurations. ...Add support for a simple HA configuration. Explain that the entire Kea configuration should be the same on both servers with the exception of `"this-server-name"`. Just gather some information, don't allow complicated configurations. Only allow hot-standby mode for simplicity.https://gitlab.isc.org/isc-projects/stork/-/issues/11211.12 release preparation2023-08-02T11:02:30ZWlodzimierz Wencel1.12 release preparationWlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4200Repeated crashes from BIND 9.16.40-S1 and 9.16.42.S1 consistently from either...2023-08-02T10:18:37ZCathy AlmondRepeated crashes from BIND 9.16.40-S1 and 9.16.42.S1 consistently from either db.c:1263 or db.c:138### Summary
This organisation run 20 or so servers, they are all on BIND 9.16.40-S1 and 9.16.42.S1. The servers that run 9.16.42-S1 are recently upgraded. The servers running 9.16.40-S1 have been doing so for almost as long as this ve...### Summary
This organisation run 20 or so servers, they are all on BIND 9.16.40-S1 and 9.16.42.S1. The servers that run 9.16.42-S1 are recently upgraded. The servers running 9.16.40-S1 have been doing so for almost as long as this version has been available. The crashes started around June 29/30, so something has changed that is triggering them.
Here is a sample of the crashes as reported in their logs:
```
mpcold1/named.log:2023-07-02T11:43:09+00:00 mpcold1 named[28600]: 02-Jul-2023 11:43:09.241 general: critical: db.c:1263: REQUIRE((__b
uiltin_expect(!!((db) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(db))->magic == ((('D') << 24 | ('N') << 16 |
('S') << 8 | ('D')))), 1))) failed
mpcold1/named.log:2023-07-02T11:43:09+00:00 mpcold1 named[28600]: 02-Jul-2023 11:43:09.241 general: critical: exiting (due to asserti
on failure)
mpcold2/named.log:2023-07-05T14:50:13+00:00 mpcold2 named[2841]: 05-Jul-2023 14:50:13.161 general: critical: db.c:138: REQUIRE((__bui
ltin_expect(!!((source) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(source))->magic == ((('D') << 24 | ('N') <
< 16 | ('S') << 8 | ('D')))), 1))) failed
mpcold2/named.log:2023-07-05T14:50:13+00:00 mpcold2 named[2841]: 05-Jul-2023 14:50:13.161 general: critical: exiting (due to assertio
n failure)
mpcold3/named.log:2023-07-02T09:18:11+00:00 mpcold3 named[60441]: 02-Jul-2023 09:18:11.174 general: critical: db.c:1263: REQUIRE((__b
uiltin_expect(!!((db) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(db))->magic == ((('D') << 24 | ('N') << 16 |
('S') << 8 | ('D')))), 1))) failed
mpcold3/named.log:2023-07-02T09:18:11+00:00 mpcold3 named[60441]: 02-Jul-2023 09:18:11.174 general: critical: exiting (due to asserti
on failure)
mpcold3/named.log:2023-07-04T19:41:07+00:00 mpcold3 named[28125]: 04-Jul-2023 19:41:07.874 general: critical: db.c:1263: REQUIRE((__b
uiltin_expect(!!((db) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(db))->magic == ((('D') << 24 | ('N') << 16 |
('S') << 8 | ('D')))), 1))) failed
mpcold3/named.log:2023-07-04T19:41:07+00:00 mpcold3 named[28125]: 04-Jul-2023 19:41:07.874 general: critical: exiting (due to asserti
on failure)
mpcold4/named.log:2023-07-02T09:54:16+00:00 mpcold4 named[81687]: 02-Jul-2023 09:54:16.146 general: critical: db.c:1263: REQUIRE((__b
uiltin_expect(!!((db) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(db))->magic == ((('D') << 24 | ('N') << 16 |
('S') << 8 | ('D')))), 1))) failed
mpcold4/named.log:2023-07-02T09:54:16+00:00 mpcold4 named[81687]: 02-Jul-2023 09:54:16.146 general: critical: exiting (due to asserti
on failure)
mpcold4/named.log:2023-07-03T06:39:10+00:00 mpcold4 named[14845]: 03-Jul-2023 06:39:10.816 general: critical: db.c:138: REQUIRE((__bu
iltin_expect(!!((source) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(source))->magic == ((('D') << 24 | ('N')
<< 16 | ('S') << 8 | ('D')))), 1))) failed
mpcold4/named.log:2023-07-03T06:39:10+00:00 mpcold4 named[14845]: 03-Jul-2023 06:39:10.816 general: critical: exiting (due to asserti
on failure)
mpcold4/named.log:2023-07-04T11:12:28+00:00 mpcold4 named[71958]: 04-Jul-2023 11:12:28.531 general: critical: db.c:1263: REQUIRE((__b
uiltin_expect(!!((db) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(db))->magic == ((('D') << 24 | ('N') << 16 |
('S') << 8 | ('D')))), 1))) failed
```
### BIND version used
9.16.40-S1 and 9.16.42-S1 (I don't have named -V, but can get this). Self-built and RPMs created that they install on their suite of resolvers. Stripped binaries - we're working on this as we have a lot of core dumps ...
### Steps to reproduce
No reproduction, just wait...
### What is the current *bug* behavior?
BIND crashes.
### What is the expected *correct* behavior?
BIND doesn't crash.
### Relevant configuration files
Significantly, what we have here is resolvers that are acting as proxies in front of Intranet auth servers. The queries they receive had originally been fielded by load-balancers, that flip the RD bit and then send them on to one of two views (one is auth only, the other accepts recursion). We're interested in the recursive side of things, and the fact the query header RD bit has been flipped is interesting for the background picture, but shouldn't affect the scenario that we have a resolver repeatedly crashing. The important components of the options are:
```
options {
directory "/var/named";
//listen-on port 53 { _obscured_; _obscured_; _obscured_; _obscured_; };
listen-on port 53 { _obscured_; _obscured_; _obscured_; _obscured_; _obscured_; _obscured_; };
query-source address _obscured_;
query-source-v6 address _obscured_;
dnssec-enable yes;
dnssec-validation no;
//edns-udp-size 1024;
version "";
stale-cache-enable no;
allow-update { none ; };
allow-transfer { none; };
transfer-source _obscured_;
transfers-per-ns 1;
transfers-in 10;
recursive-clients 5000;
tcp-idle-timeout 30;
tcp-clients 750;
notify no;
send-cookie no;
require-server-cookie no;
ecs-forward {any;};
ecs-zones { obscured; };
fetches-per-zone 35 drop;
fetch-quota-params 100 .1 .3 .7;
fetches-per-server 50 drop;
rate-limit {
slip 2; // Every other response truncated
window 15; // Seconds to bucket
responses-per-second 100; // # of good responses per prefix-length/sec
referrals-per-second 80; // referral responses
nodata-per-second 25; // nodata responses
nxdomains-per-second 20; // nxdomain responses
errors-per-second 25; // error responses
all-per-second 500; // When we drop all
log-only no; // Debugging mode
qps-scale 5000; // x / 1000 * per-second = new drop limit
//exempt-clients { 127.0.0.1; _obscured_; _obscured_ !};
ipv4-prefix-length 24; // Define the IPv4 block size
ipv6-prefix-length 56; // Define the IPv6 block size
max-table-size 1200000; // 40 bytes * this number = max memory
min-table-size 500; // pre-allocate to speed startup
};
};
```
### Relevant logs and/or screenshots
See crashes logged above.
Significantly in the one I first looked at, just ahead of the crash was this:
> Jul 4 11:22:09 mppacd2 named[2884]: client @0x7f7eb03864e0
> _obscured_#44786 (_obscured_): view Rec-
> instance: recursive-clients soft limit exceeded (4901/4900/5000),
> aborting oldest query
> Jul 4 11:22:09 mppacd2 named[2884]: client @0x7f7e7c720f20
> _obscured-different_#62182 (_obscured-different_): view Rec-
> instance: no more recursive clients (5000/4900/5000): quota reached
However, exploring further - this is not consistently associated with the crashes - the quota is being reached with no crashes, and the crashes occur without quota reached being logged.
Note however that both fetch-limits and RRL are being triggered.
More data is available from [Support ticket #22339](https://support.isc.org/Ticket/Display.html?id=22339)
### Possible fixes
I checked the crash code locations - here are my musings
db.c:1263
```
isc_result_t
dns_db_getservestalerefresh(dns_db_t *db, uint32_t *interval) {
REQUIRE(DNS_DB_VALID(db));
REQUIRE((db->attributes & DNS_DBATTR_CACHE) != 0);
if (db->methods->getservestalerefresh != NULL) {
return ((db->methods->getservestalerefresh)(db, interval));
}
return (ISC_R_NOTIMPLEMENTED);
}
```
db.c:138
```
dns_db_attach(dns_db_t *source, dns_db_t **targetp) {
/*
* Attach *targetp to source.
*/
REQUIRE(DNS_DB_VALID(source));
REQUIRE(targetp != NULL && *targetp == NULL);
(source->methods->attach)(source, targetp);
ENSURE(*targetp == source);
}
```
The crash is for the exact same reason in each - this test fails:
` REQUIRE(DNS_DB_VALID(source));`
But why do we not have a valid DB pointer? `dns_db_attach()` is used all over the place - too many for me to do anything useful with without stack traces that show me the circumstances around the call. But there are only a handful of locations where we call `dns_db_getservestalerefresh()` so I took a meander...
The likeliest candidate is in query.c from query_lookup(). Note that we're getting the pointer to the db from the client. (Aside: also that we're getting the value of the length of time in which stale answers are directly returned from cache before attempting to refresh them (in case a previous attempt in doing so has failed), without first checking if we're going to use stale content at all, or even if we have stale cache enabled. So this is unnecessary, except that we then decide what to do with the value. But this lookup from cache DB should work anyway.)
I'm bothered that the pointer to the cachedb is dud. Might this be a race between looking in cache to construct query response (on a timeout) versus the same client being dropped simultaneously because of hitting recursive clients quota?
```
(void)dns_db_getservestalerefresh(qctx->client->view->cachedb,
&stale_refresh);
```
That's the call - the pointer to cachedb that is invalid has come from the client structure. Why is that 'bad'? Where did we get the pointer to the client struct from, and why is only this operation crashing if this is a race between 'do something with this client' and 'this client is being dropped because of some quota or something'?
Looking at the other locations, I doubt that the crash has come from server.c - that's just a call with a direct pointer to the cache DB in order to get the value to output in response to an rndc query to get the values.
Meanwhile, I see in cache.c that the call to dns_db_getservestalerefresh() has a wrapper:
dns_cache_getservestalerefresh()
But I think this is also not useful. I see it used in server.c whilst checking what its value is to determine whether or not it's OK for two views to share the same cache. And see what dns_cache_getservestalerefresh() does before it calls dns_db_getservestalerefresh() - calls REQUIRE(VALID_CACHE(cache)). I do not think we passed this way in the direction of the crash...August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/kea/-/issues/29922.5.0 release checklist2023-08-02T09:57:05ZAndrei Pavelandrei@isc.org2.5.0 release checklist# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual fr...# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
For new stable releases or maintenance releases, please don't use `kea-dev` build farm. Use dedicated build farm for each release cycle.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [x] Finish release notes and conduct its review. Also please notify @sgoldlust or @vicky that release notes are ready for review.
1. [x] Check that packges can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [x] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [x] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 1.9.7 --repo-dir ~/isc/repos/kea/` Use `--upload` to commit changes. <br>
Help: `GITLAB_TOKEN="..." ./update-code-for-release.py --help`<br>
This script makes the following changes and actions:
1. run prepare_kea_release.sh that does:
1. add release entries in ChangeLogs
1. update Kea version in configure.ac
1. update copyright years in files that were changed in current year
1. sort message files
1. regenerate message files headers
2. regenerate parsers using Bison from Docker<br>
With `--upload`:
3. create an issue in GitLab for release changes in kea repo
4. create branches and merge requests for kea and kea-premium
5. commit the changes in both repos
6. checkout created branches in both repos
7. commit and push the changes to GitLab server
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [ ] Did we add any additional 3rd party software? Update if needed
1. [ ] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [ ] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [ ] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [ ] Check and update Build Requirements
1. [ ] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [ ] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick:
1. `rc1` if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [ ] Update Release Notes with ChangeLog entries
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. Kea-2.2.2): <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description: <br>
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- if release engineer is holding personal signing key, please use [sign, verify, and upload script](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh)
- if release enginner do NOT have signing key, please contact team member.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Update ReadTheDocs
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [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 *kea-announce*.
- [x] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(Support)*** Inform Marketing of the release.
- [x] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [ ] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [ ] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).kea2.5.0https://gitlab.isc.org/isc-projects/kea/-/issues/29872.2.1 release checklist2023-08-02T09:44:58ZAndrei Pavelandrei@isc.org2.2.1 release checklist# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual fr...# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
For new stable releases or maintenance releases, please don't use `kea-dev` build farm. Use dedicated build farm for each release cycle.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [x] Finish release notes and conduct its review. Also please notify @sgoldlust or @vicky that release notes are ready for review.
1. [x] Run [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/) as running parameter `TarballOrPkg` select `packages` and [release-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/) to test repositories for correctness.
1. If a new Cloudsmith repository is used, then:
1. [x] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [x] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates Gitlab issue and MR for release changes
- adds release entries to ChangeLogs
- regenerates BNF grammar
- regenerates documentation
- regenerates messages
- reorders messages in alphabetical order
- regenerates parsers
- updates copyright dates
- pushes the changes to MR
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [ ] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [ ] Did we add any additional 3rd party software? Update if needed
1. [ ] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [ ] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [ ] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [ ] Check and update Build Requirements
1. [ ] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [ ] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [ ] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [ ] Update Release Notes with ChangeLog entries
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
Wait until tarballs are signed.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"`, `TarballOrPkg: "both"` and click Build button.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. For stable releases, change the default version to point to this stable release.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. Kea-2.2.2): <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description: <br>
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [ ] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Wait for the signing ticket from the release engineer.
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [x] ***(Support)*** Sign the tarballs.
- [x] ***(Support)*** Upload signature files to repo.isc.org.
- [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 *kea-announce*.
- [x] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [x] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [x] ***(Marketing)*** Announce on social media.
~~ - [ ] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).~~kea2.2.1https://gitlab.isc.org/isc-projects/stork/-/issues/973Excessive errors when certs are inaccessible2023-08-02T09:32:55ZTomek MrugalskiExcessive errors when certs are inaccessibleThe stork agent prints excessive errors (140+ lines), including a total of 6 back traces, full of cryptic error that's useless for average users when TLS certs are inaccessible.
Example output: $1041
Steps to reproduce:
1. files in /v...The stork agent prints excessive errors (140+ lines), including a total of 6 back traces, full of cryptic error that's useless for average users when TLS certs are inaccessible.
Example output: $1041
Steps to reproduce:
1. files in /var/lib/stork-agent/certs/ are owned by `stork-agent` (permissions 600)
2. run `stork-agent` as a different user
Another case to check here is the behavior when the files (or whole dir) are missing.1.12Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4196Possible race between RPZ and catalog zones db update notify callback registr...2023-08-02T08:53:52ZArаm SаrgsyаnPossible race between RPZ and catalog zones db update notify callback registrationsThis is a follow-up issue from an MM discussion.
Excerpt from the discussion:
>```
>If the updatenotify in catz cb runs at the same time as RPZ updatenotify (this could happen) the list becomes trashed.
>...
>The register / unregistere...This is a follow-up issue from an MM discussion.
Excerpt from the discussion:
>```
>If the updatenotify in catz cb runs at the same time as RPZ updatenotify (this could happen) the list becomes trashed.
>...
>The register / unregistered can run in parallel.
>```August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/4059Oracle Linux 8 shell doesn't always restore environment variable correctly2023-08-02T08:49:35ZMark AndrewsOracle Linux 8 shell doesn't always restore environment variable correctlyJob [#3374668](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3374668) failed for 0592aaa4a97351f736418b2bbc53e89113a578c5:
I saw that dig was making AAAA queries instead of A queries by default a couple of times developing !7888. Ea...Job [#3374668](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3374668) failed for 0592aaa4a97351f736418b2bbc53e89113a578c5:
I saw that dig was making AAAA queries instead of A queries by default a couple of times developing !7888. Earlier in the resolver test we use `HOME="$(pwd)" dig_with_opts @10.53.0.4 . > dig.out.1.${n} || ret=1` a few times. This shouldn't have a long term effect on HOME but that is the only explanation that makes sense. Creating an explicit sub shell should fix the issue. For !7888 I explicitly set the type.
Note below the type was not specified but should default to A.
```
% more dig.out.60
; <<>> DiG 9.19.14-dev <<>> -p 14345 +tcp @10.53.0.5 options-formerr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54036
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 31786a72177b15f101000000645c36ee6cd499386040212e (good)
;; QUESTION SECTION:
;options-formerr. IN AAAA
;; AUTHORITY SECTION:
options-formerr. 1 IN SOA . . 0 0 0 0 0
;; Query time: 0 msec
;; SERVER: 10.53.0.5#14345(10.53.0.5) (TCP)
;; WHEN: Thu May 11 00:29:34 UTC 2023
;; MSG SIZE rcvd: 106
%
```August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/4229nextpart failed, set -e fallout?2023-08-02T08:27:07ZMark Andrewsnextpart failed, set -e fallout?Job [#3549936](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3549936) failed for c24edb125bc7eeb6ed4e86e336b27bab5d7092cd:Job [#3549936](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3549936) failed for c24edb125bc7eeb6ed4e86e336b27bab5d7092cd:August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/4226dig help message https-plain-get vs http-plain-get2023-08-02T08:24:45ZOli Schacherdig help message https-plain-get vs http-plain-get### Summary
`dig -h` says:
```
+[no]https-plain-get (Use GET instead of default POST method while using plain HTTP)
```
but the option is actually called `+[no]http-plain-get`, without the s
### BIND version used
`DiG 9.18.17`...### Summary
`dig -h` says:
```
+[no]https-plain-get (Use GET instead of default POST method while using plain HTTP)
```
but the option is actually called `+[no]http-plain-get`, without the s
### BIND version used
`DiG 9.18.17`
### Steps to reproduce
run `dig -h`
or for the more adventurous:
```
dig @dns.switch.ch isc.org +https-plain-get
Invalid option: +https-plain-get
[....]
```
### What is the current *bug* behavior?
dig -h claims the option name is `+[no]https-plain-get`
### What is the expected *correct* behavior?
`dig -h` should say the option name is `+[no]http-plain-get`
### Relevant configuration files
n/a
### Relevant logs and/or screenshots
n/a
### Possible fixes
change https://gitlab.isc.org/isc-projects/bind9/-/blob/6a6f2e58e9e4a2e5d30ebb6113e429712dc09b34/bin/dig/dig.c#L228August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3677Add inline-signing to dnssec-policy2023-08-02T08:22:51ZMatthijs Mekkingmatthijs@isc.orgAdd inline-signing to dnssec-policyOn the one hand I don't think "inline-signing" is really a *key and signing* policy option, so it feels misplaced.
On the other hand it is kind of cumbersome to include "inline-signing yes;" in all of your zones that use/inherit dnssec-...On the one hand I don't think "inline-signing" is really a *key and signing* policy option, so it feels misplaced.
On the other hand it is kind of cumbersome to include "inline-signing yes;" in all of your zones that use/inherit dnssec-policy.
I do believe the latter argument is a stronger one the "it feels wrong" argument though, so I am leaning more towards of adding an "inline-signing" option inside "dnssec-policy".August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4223dns_badcache uses yet another own hash table implementation2023-08-02T08:14:15ZOndřej Surýdns_badcache uses yet another own hash table implementation...replace it with isc_hashmap (or isc_ht)...replace it with isc_hashmap (or isc_ht)August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4194Extend DNS COOKIE support2023-08-02T08:10:44ZMark AndrewsExtend DNS COOKIE supportThe current EDNS COOKIE support does not return BADCOOKIE unless require-cookie is true. Start returning BADCOOKIE on all instances of bad server cookies.The current EDNS COOKIE support does not return BADCOOKIE unless require-cookie is true. Start returning BADCOOKIE on all instances of bad server cookies.August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/4239Add dnstap-output support for tcp2023-08-02T08:00:29ZMr BenAdd dnstap-output support for tcp### Description
goals:Add dnstap-output support for tcp
### Request
###
Now the output of dnstap only supports file and unix domain socket to generate logs. I expect to output logs in the form of tcp, so that the log server can be on ...### Description
goals:Add dnstap-output support for tcp
### Request
###
Now the output of dnstap only supports file and unix domain socket to generate logs. I expect to output logs in the form of tcp, so that the log server can be on other hosts. Reduce the overhead of the dns server itself.
The reason for such a requirement is that in the production environment, even if the dns server itself generates logs, they will still be output to other places for analysis and detection through tcp/udp. It is better to output directly to other hosts.
###
### Links / references
###
Like coredns, it supports tcp output log.
dnstap /tmp/dnstap.sock
dnstap unix:///tmp/dnstap.sock full
dnstap tcp://127.0.0.1:6000 full
dnstap tcp://example.com:6000 full
###Not planned