ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-04-01T11:20:17Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2561Typo in doc/dnssec-guide/signing.rst2021-04-01T11:20:17ZPhil RegnauldTypo in doc/dnssec-guide/signing.rst```patch
--- signing.rst.orig 2021-03-08 12:23:18.000000000 +0100
+++ signing.rst 2021-03-08 12:22:58.000000000 +0100
@@ -736,7 +736,7 @@
dnssec-policy standard {
dnskey-ttl 600;
- key {
+ keys {
ksk ...```patch
--- signing.rst.orig 2021-03-08 12:23:18.000000000 +0100
+++ signing.rst 2021-03-08 12:22:58.000000000 +0100
@@ -736,7 +736,7 @@
dnssec-policy standard {
dnskey-ttl 600;
- key {
+ keys {
ksk lifetime 365d algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2563rndc modzone to change dnssec-policy retire existing keys immediately2021-04-01T11:19:56ZArth Pauliterndc modzone to change dnssec-policy retire existing keys immediately<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Changing dnssec-policy using rndc modzone for existing signed zone causes keymgr to retire existing keys. I have bind configured with "allow-new-zones yes;" so I could add, delete, modify zone using rndc. Also configured bind with 2 dnssec-policy: rsasha256 and ecdsap256. I'm hoping this should allow me to do algorithm rollover by changing dnssec-policy using rndc modzone. The following command immediately retire existing DNSKEY and create a new one.
```
rndc modzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy ecdsap256; file "data/example.com"; };'
```
### Tested version
* BIND-9.16.11 (Stable Release)
* BIND 9.16.12 (Stable Release)
### Steps to reproduce
1. Configure bind with "allow-new-zones yes;" and two dnssec-policy with different algorithm. This will allow rndc addzone to add zone and rndc modzone to change dnssec-policy of existing zone. I also configured logging with dnssec category.
2. Load the zone with dnssec-policy:
```
rndc addzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy rsasha256; file "data/example.com"; };'
```
dnssec log result:
```
09-Mar-2021 16:06:10.627 dnssec: info: zone example.com/IN (signed): generated salt: CB4EAB14FFF8A6D4731D94FD2EC9DFD8
09-Mar-2021 16:06:10.634 dnssec: info: zone example.com/IN (signed): reconfiguring zone keys
09-Mar-2021 16:06:10.700 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/25870 (KSK) created for policy rsasha256
09-Mar-2021 16:06:10.749 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/54564 (ZSK) created for policy rsasha256
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/25870 (KSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now active
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/54564 (ZSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now active
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): zone_addnsec3chain(1,INITIAL|CREATE,5,CB4EAB14FFF8A6D4731D94FD2EC9DFD8)
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): next key event: 09-Mar-2021 18:11:10.634
```
3. Check that both KSK & ZSK are RSASHA256 (Algorithm 8)
```
dig dnskey example.com. @localhost +multiline
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 8 (
AwEAAbPGinhOiZq3JyeUWyGF3DxjXtQqoBjQeWzoyhSJ
ZtrqVLkz6ocoQ3y6trcjGN2f7YTSWNPIffwdZ69XHmyV
QvUkJYCCrskiP6RzhZffU9AMP1GR1k5QXWX+/RMOCJta
yasvdQo/2gbplzz78nLmXRzhnSzl1GSNGeG9orGtdbyo
89uPP+SJv13zB5rR7mxIj78bl3eVV0bdWf4G4okBE64M
2NJqG0tJwpI2XFysEkNT0JtLPjtiKgK4dFUzxuc5Cq4W
258611VoGWXlqSwBI03UABwLrzO7q4R0oijEtNjWlSNw
vohw/EGkJcTARofVFFo9Aar0AoP3YzjbdA4r+Ls=
) ; KSK; alg = RSASHA256 ; key id = 41266
example.com. 3600 IN DNSKEY 256 3 8 (
AwEAAd0OQXZ//c6Msr1FVK9qJ8QSUehOETVgPmslvrfv
J94LwS9VAgJAE/mZfJdq/OJwcD6uvwycmfpuOjCpr5OL
k/eVAoVcIRBX2NGnhANPIqDo6n9VzqCeNcxX3tJt6uW4
JDxN2GLgaJ7mQAaQr8LIOTe+YLqbVs1s43YaDVfEfLxd
xh0sUS+HErTAt/7DVPV+nkgf2S8yuwdHniVDFfGOgGbp
t42OlVJaqHo7lj6boAZRaIPTX+aoGKuOz4EhXnRwqmwK
/Y9W9NIkT0H0MHSlfcM0B3KtRBwJ+jD3XM7hu8mm4XBU
cFArX/Od/wP3VCB4CNArtoZS4/agMFIEEBIVMhc=
) ; ZSK; alg = RSASHA256 ; key id = 44445
```
4. Change the zone dnssec-policy using rndc modzone
```
rndc modzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy ecdsap256; file "data/example.com"; };'
```
dnssec log result:
```
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/25870 (KSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/54564 (ZSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY exampl.com/ECDSAP256SHA256/23518 (KSK) created for policy ecdsap256
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) created for policy ecdsap256
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 25870/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 54564/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/23518 (KSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now active
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/12118 (ZSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now active
```
5. Check both KSK & ZSK are now both ECDSHAP256 (algorithm 13) and no more RSASHA256 DNSKEY
```
dig dnskey example.com. @localhost +multiline
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 256 3 13 (
bn2PN0mWvMhjgDiVCnO/dDwPS8JaK6Cas5vBI6D7gds8
PXlMeTSJRQSVcyM1OuZIo/V5JIFiQUiiME1IBD+TNw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 14912
example.com. 3600 IN DNSKEY 257 3 13 (
u6dqheaPjAhwSzuVrroi9na4L4biKfUQDBWRfsjcDyfz
EkPvHIoOZ/DM+FQynz+vyrZ7HnG6fCk9jtz/cmB8vw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 2113
```
### What is the current *bug* behavior?
Using rndc modzone to change zone dnssec-policy retire existing keys immidiately.
```
rndc modzone example.com. '{ type slave; masters { 192.168.0.53; }; dnssec-policy ecdsap256; file "data/example.com"; };'
```
### (What actually happens.)
The initial RSASHA256 DNSKEYs were retired immediately and were replaced by ECDSAP256 after running "rndc modzone example.com" with another dnssec-policy containing ECDSAP256 algorithm.
### What is the expected *correct* behavior?
If algoritm rollover is supported with dnssec-policy, existing RSHASHA256 keys and ECDSAP256 keys should be visible.
The following command should show 4 DNSKEY. There should be 2 DNSKEY with algorithm 8 and 2 DNSKEY with algorithm 13.
```
dig dnskey example.com. @localhost +multiline
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 8 (
AwEAAbPGinhOiZq3JyeUWyGF3DxjXtQqoBjQeWzoyhSJ
ZtrqVLkz6ocoQ3y6trcjGN2f7YTSWNPIffwdZ69XHmyV
QvUkJYCCrskiP6RzhZffU9AMP1GR1k5QXWX+/RMOCJta
yasvdQo/2gbplzz78nLmXRzhnSzl1GSNGeG9orGtdbyo
89uPP+SJv13zB5rR7mxIj78bl3eVV0bdWf4G4okBE64M
2NJqG0tJwpI2XFysEkNT0JtLPjtiKgK4dFUzxuc5Cq4W
258611VoGWXlqSwBI03UABwLrzO7q4R0oijEtNjWlSNw
vohw/EGkJcTARofVFFo9Aar0AoP3YzjbdA4r+Ls=
) ; KSK; alg = RSASHA256 ; key id = 41266
example.com. 3600 IN DNSKEY 256 3 8 (
AwEAAd0OQXZ//c6Msr1FVK9qJ8QSUehOETVgPmslvrfv
J94LwS9VAgJAE/mZfJdq/OJwcD6uvwycmfpuOjCpr5OL
k/eVAoVcIRBX2NGnhANPIqDo6n9VzqCeNcxX3tJt6uW4
JDxN2GLgaJ7mQAaQr8LIOTe+YLqbVs1s43YaDVfEfLxd
xh0sUS+HErTAt/7DVPV+nkgf2S8yuwdHniVDFfGOgGbp
t42OlVJaqHo7lj6boAZRaIPTX+aoGKuOz4EhXnRwqmwK
/Y9W9NIkT0H0MHSlfcM0B3KtRBwJ+jD3XM7hu8mm4XBU
cFArX/Od/wP3VCB4CNArtoZS4/agMFIEEBIVMhc=
) ; ZSK; alg = RSASHA256 ; key id = 44445
example.com. 3600 IN DNSKEY 256 3 13 (
bn2PN0mWvMhjgDiVCnO/dDwPS8JaK6Cas5vBI6D7gds8
PXlMeTSJRQSVcyM1OuZIo/V5JIFiQUiiME1IBD+TNw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 14912
example.com. 3600 IN DNSKEY 257 3 13 (
u6dqheaPjAhwSzuVrroi9na4L4biKfUQDBWRfsjcDyfz
EkPvHIoOZ/DM+FQynz+vyrZ7HnG6fCk9jtz/cmB8vw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 2113
```
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
named.conf
```
options {
key-directory "/data/keys";
allow-new-zones yes;
request-ixfr yes;
ixfr-from-differences yes;
provide-ixfr yes;
};
# DNSSEC Policy ECDSA
dnssec-policy "ecdsap256" {
nsec3param iterations 5 optout no salt-length 16;
keys {
ksk key-directory lifetime P1Y algorithm 13;
zsk key-directory lifetime 60d algorithm 13;
};
// Signatures
signatures-refresh P1D;
signatures-validity P2D;
signatures-validity-dnskey P7D;
// Keys
dnskey-ttl 3600;
publish-safety PT3600S;
retire-safety PT3600S;
};
# DNSSEC Policy RSASHA2
dnssec-policy "rsasha256" {
nsec3param iterations 5 optout no salt-length 16;
keys {
ksk key-directory lifetime P1Y algorithm RSASHA256;
zsk key-directory lifetime 30d algorithm RSASHA256;
};
// Signatures
signatures-refresh P1D;
signatures-validity P7D;
signatures-validity-dnskey P14D;
// Keys
dnskey-ttl 3600;
publish-safety PT3600S;
retire-safety PT3600S;
};
```
### Relevant logs and/or screenshots
```
09-Mar-2021 16:06:10.627 dnssec: info: zone example.com/IN (signed): generated salt: CB4EAB14FFF8A6D4731D94FD2EC9DFD8
09-Mar-2021 16:06:10.634 dnssec: info: zone example.com/IN (signed): reconfiguring zone keys
09-Mar-2021 16:06:10.700 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/25870 (KSK) created for policy rsasha256
09-Mar-2021 16:06:10.749 dnssec: info: keymgr: DNSKEY example.com/RSASHA256/54564 (ZSK) created for policy rsasha256
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/25870 (KSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now active
09-Mar-2021 16:06:10.750 dnssec: info: Fetching example.com/RSASHA256/54564 (ZSK) from key repository.
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now published
09-Mar-2021 16:06:10.750 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now active
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): zone_addnsec3chain(1,INITIAL|CREATE,5,CB4EAB14FFF8A6D4731D94FD2EC9DFD8)
09-Mar-2021 16:06:10.765 dnssec: info: zone example.com/IN (signed): next key event: 09-Mar-2021 18:11:10.634
09-Mar-2021 16:07:48.457 dnssec: info: zone example.com/IN (signed): reconfiguring zone keys
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/25870 (KSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: retire DNSKEY example.com/RSASHA256/54564 (ZSK)
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) created for policy ecdsap256
09-Mar-2021 16:07:48.458 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) created for policy ecdsap256
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 25870/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/25870 (KSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Removing expired key 54564/RSASHA256 from DNSKEY RRset.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/RSASHA256/54564 (ZSK) is now deleted
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/23518 (KSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/23518 (KSK) is now active
09-Mar-2021 16:07:48.459 dnssec: info: Fetching example.com/ECDSAP256SHA256/12118 (ZSK) from key repository.
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now published
09-Mar-2021 16:07:48.459 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/12118 (ZSK) is now active
09-Mar-2021 16:07:48.464 dnssec: info: zone example.com/IN (signed): next key event: 09-Mar-2021 17:12:48.457
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1789some doxygen errors made it into 1.9.62021-04-01T09:12:29ZAndrei Pavelandrei@isc.orgsome doxygen errors made it into 1.9.6kea1.9.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2601typo in definition of atomic_exchange_explicit for Clang on Unix2021-03-31T21:40:56ZRoland Illigtypo in definition of atomic_exchange_explicit for Clang on Unix### Summary
stdatomic.h says:
~~~c
#define atomic_exchange_explicit(obj, desired, order) \
__c11_atomic_exchange_explicit(obj, expected, order)
~~~
This only works if the second argument to that macro is the identifier 'expected'.
Oth...### Summary
stdatomic.h says:
~~~c
#define atomic_exchange_explicit(obj, desired, order) \
__c11_atomic_exchange_explicit(obj, expected, order)
~~~
This only works if the second argument to that macro is the identifier 'expected'.
Otherwise this (hopefully) produces a 'no such local variable' message from the compiler.
### Steps to reproduce
Compile `queue.c` with compiler options that trigger the faulty macro.
The original code in `queue.c` is:
~~~c
item = atomic_exchange(&(lh->items[idx]),
(uintptr_t)&queue->taken);
~~~
This produces the following line after preprocessing:
~~~c
item = __c11_atomic_exchange_explicit(&(lh->items[idx]), expected, memory_order_seq_cst);
~~~
This line does not contain `queue->taken` anymore.
### What is the current *bug* behavior?
Compilation fails because `expected` is not a defined variable.
### What is the expected *correct* behavior?
Compilation succeeds.
### Possible fixes
Write 'desired' instead of 'expected'.Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/kea/-/issues/17721.9.6 release changes2021-03-31T17:58:53ZAndrei Pavelandrei@isc.org1.9.6 release changeskea1.9.6https://gitlab.isc.org/isc-projects/kea/-/issues/17711.9.6 release checklist2021-03-31T17:57:39ZAndrei Pavelandrei@isc.org1.9.6 release checklist---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# 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 actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.isc.org/job/kea-dev/job/tarball-internal/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. 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-1.9.2
1. [x] Finish release notes and conduct its review
1. [x] Run [release-pkgs-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
The following steps may involve changing files in the repository.
1. [x] Create a Kea issue for code changes that will be made due to the following checks:
1. Check 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. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] 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. [x] Check installation hierarchy
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whatspaces, etc.
1. [x] 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] Update information in sources about copyright dates, new version, etc, script: [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh).
1. [x] Regenerate parsers using docs.isc.org, script: [regen-parsers.sh](https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/regen-parsers.sh).
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 branch to master.
## Build selection and upload package
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick 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 sizes - is new package reasonable?
1. Check installation tree, compare it with previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from current release has lower number then corresponding lib from previous release? (!)
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of 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
1. Go to [release-tarball-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-tarball-upload-internal/) 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 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 error)
1. final if the last rc number was ok, this will push selected tarball to repo.isc.org, to a directory with no suffixes
1. [x] If none of the results force you to fix and rebuild package, send sanity checks request if not already triggered automatically by `release-tarball-upload-internal`.
## Sanity Checks
1. [x] Create Sanity Checks announcement, put there:
- 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 an issue created in next step
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
1. [x] Create a GitLab issue for sanity checks, put there the announcement
1. [x] Send the announcement to dhcp-team@isc.org
## Releasing Tarballs
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final
1. [x] When the upload is completed then copy SHA checksums from the log and write an email to signers@isc.org requesting signatures
of final tarballs on repo.isc.org indicating release directories. Attach SHA checksums to the request.
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Create git tags `Kea-a.b.c` in Kea main and premium repositories.
1. Update ReadTheDocs
1. [x] Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. [x] Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. [x] For stable releases, change the default version to point to this stable release.
### On the Day of Public Release
- [ ] ***(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 *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new major 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 support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [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.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [x] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [x] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] 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`
- [x] Bump up `REF_KEA_VERSION` in `qa-dhcp/kea/jenkins/tarball-internal.jenkinsfile` to `x.y.z` i.e. released versionkea1.9.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1778Sanity checks for Kea 1.9.6 rc12021-03-31T17:32:06ZAndrei Pavelandrei@isc.orgSanity checks for Kea 1.9.6 rc1```
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. please, state in Sanity Checks issue in GitLab
what ch...```
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. please, state in Sanity Checks issue in GitLab
what check you are doing in a thread/discussion (not as comment).
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/1.9.6-rc1
/data/shared/sweng/kea/releases/premium-1.9.6-rc1
/data/shared/sweng/kea/releases/subscription-1.9.6-rc1
SHA256 (1.9.6-rc1) = ffbb061f5df27a3a6f00b138ded00d79561c1f45c5d5d7b339697f760911290f
SHA256 (premium-1.9.6-rc1) = 9836e533018e3c61de83e226bace1541b108285c052fbaf43fa04b5c7e2a27cd
SHA256 (subscription-1.9.6-rc1) = 816b18a3c40ab4e7d78d5af1f72adf916e2abfa538f177e6488f93c1bf157abb
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/293/
Release version is 1.9.6-isc0027220210330111222 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```kea1.9.6https://gitlab.isc.org/isc-projects/kea/-/issues/1786bump configure.ac version to 1.9.7-git2021-03-31T17:27:01ZAndrei Pavelandrei@isc.orgbump configure.ac version to 1.9.7-gitkea1.9.7https://gitlab.isc.org/isc-projects/kea/-/issues/1697Disabling high-availability hook leaves "DHCP service is globally disabled" a...2021-03-31T12:57:54ZMike KazantsevDisabling high-availability hook leaves "DHCP service is globally disabled" after reconfiguration**Describe the bug**
Running "config-set" on Kea to disable HA hook can leave DHCP service in a disabled state, refusing to handle any DHCP requests.
**To Reproduce**
Steps to reproduce the behavior:
1. Start kea-dhcpv4 with HA hook...**Describe the bug**
Running "config-set" on Kea to disable HA hook can leave DHCP service in a disabled state, refusing to handle any DHCP requests.
**To Reproduce**
Steps to reproduce the behavior:
1. Start kea-dhcpv4 with HA hook enabled and configured to have primary/secondary role, which will transition it to WAITING state, disabling DHCP service until partner host can be contacted.
2. Run "config-set" API command to update Kea configuration with HA hook disabled in that new configuration.
3. Try testing DHCP service using any client.
4. Verbose Kea logs should report something like "DHCP service is globally disabled".
**Expected behavior**
- HA hook does not leave DHCP service in a disabled state after unloading.
- DHCP service working normally after reconfiguration that disables HA hook.
**Environment:**
- Kea version: 1.8.2
- OS: Alpine Linux 3.13
- Built and used with memfile backend.
**Additional Information**
Running this as a testing setup in a docker containers, with python script configuring Kea.\
Not sure if issue is 100% reproducible, but happened to me at least a couple of times already.
Attached logs:
- [kea-ha-service-disabling.debug-brief.log](/uploads/99f490081744c6b69d3e42812cf6acfd/kea-ha-service-disabling.debug-brief.log)
- [kea-ha-service-disabling.debug-all.log](/uploads/d65c6d01d3ff6dc6e329d1337173163c/kea-ha-service-disabling.debug-all.log)
Full configuration loaded each time should be available in the attached kea-ha-service-disabling.debug-all.log file, in DHCP4_CONFIG_RECEIVED lines, don't think it has anything special or very relevant, aside from that hook being present in one configuration and removed in the next one.
Attached kea-ha-service-disabling.debug-brief.log is a filtered version of "debug-all" file, which I believe illustrates the issue well, without any extra noise in it, with even shorter gist being:
```
2021-02-06T18:39:01.624 a DEBUG kea-dhcp4.dhcp4 DHCP4_CONFIG_RECEIVED ...
2021-02-06T18:39:01.658 a INFO kea-dhcp4.ha-hooks HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the a is in the WAITING state
2021-02-06T18:39:01.658 a INFO kea-dhcp4.ha-hooks HA_SERVICE_STARTED started high availability service in load-balancing mode as secondary server
...
2021-02-06T18:39:01.820 a INFO kea-dhcp4.commands COMMAND_RECEIVED Received command 'config-set'
2021-02-06T18:39:01.820 a DEBUG kea-dhcp4.dhcp4 DHCP4_CONFIG_RECEIVED ...
2021-02-06T18:39:01.839 a INFO kea-dhcp4.ha-hooks HA_DEINIT_OK unloading High Availability hooks library successful
...
2021-02-06T18:40:05.371 a DEBUG kea-dhcp4.packets DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to 255.255.255.255:67 over interface ens3
2021-02-06T18:40:05.371 a DEBUG kea-dhcp4.bad-packets DHCP4_PACKET_DROP_0008 [hwtype=1 ], cid=[no info], tid=0x0: DHCP service is globally disabled
```
Also, I've seen note on new dhcp-enable/dhcp-disable API commands in the recent ChangeLog entry:
```
1858. [bug] razvan
The DHCP service can be independently enabled or disabled by
the user command, by the database connection mechanics or
by the HA library. The DHCP service is disabled when any
of those originators disables the service, and it is enabled
when all those who previously disabled the service enable it.
```
But "when all those who previously disabled the service enable it" seem to imply that it won't be a good workaround for this bug if HA hook indeed does not re-enable the service when removed - it'll stay disabled regardless of API command, or require to masquerade that command as if it was from HA hook, which seem to be suboptimal in a number of ways.
**Extra Question**
Can someone knowledgeable with Kea internals think of a good workaround with a current stable Kea version?\
I.e. is there a good way to reliably disable HA hook at an arbitrary time without risk of leaving DHCP in a broken state?
I can think that maybe HA hook should be first transitioned into passive-backup or somesuch state, from which it explicitly enables DHCP on deinit (assuming that it does, didn't look at the code to confirm), but maybe there's a simplier hack/workaround?
Thanks in advance for any suggestions.
**Contacting you**
Will try to monitor replies here.kea1.9.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/185[CVE-2018-5737] serve-stale crash2021-03-31T12:02:44ZTony Finch[CVE-2018-5737] serve-stale crashOne of my recursive servers crashed messily this evening, logging more than a million lines of
```
27-Mar-2018 18:20:35.862 general: info: 105.91.84.115.in-addr.arpa resolver failure, stale answer used
[snip 100MB logs]
27-Mar-2018...One of my recursive servers crashed messily this evening, logging more than a million lines of
```
27-Mar-2018 18:20:35.862 general: info: 105.91.84.115.in-addr.arpa resolver failure, stale answer used
[snip 100MB logs]
27-Mar-2018 18:24:03.414 general: info: 105.91.84.115.in-addr.arpa resolver failure, stale answer used
27-Mar-2018 18:24:03.414 general: critical: rbtdb.c:2115: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
27-Mar-2018 18:24:03.414 general: critical: exiting (due to assertion failure)
```
Earlier today I turned on serve-stale in production, so it did not last long before crashing!
I'm afraid I don't have the start of the logspam because I only keep 100MB logs, but the obvious query will reproduce the problem.
Tangentially related, I think the serve-stale logging needs work: it's very noisy, so it should be in its own category, and perhaps some of the messages should have at debugging rather than informational level...
Full configuration below. It's possibly of note that I have two views with a shared cache using attach-cache.
```
acl "blackhole" {
240.0.0.0/4;
};
acl "secure" {
"localhost";
131.111.56.56/32;
131.111.57.57/32;
2001:630:212:110::d:7a7/128;
2001:630:212:110:221:9bff:fe16:a526/128;
2001:630:212:110:646f:7461:742e:6174/128;
131.111.9.53/32;
131.111.9.73/32;
2001:630:212:8::d:aa/128;
2001:630:212:8::d:aaaa/128;
};
acl "loopback" {
127.0.0.0/8;
::1/128;
};
acl "cudn" {
127.0.0.0/8;
::1/128;
2001:630:210::/44;
2a00:1098:5::/48;
128.232.0.0/16;
129.169.0.0/16;
131.111.0.0/16;
192.18.195.0/24;
192.84.5.0/24;
192.153.213.0/24;
193.60.80.0/20;
193.63.252.0/23;
!172.31.0.0/16;
172.16.0.0/12;
10.128.0.0/9;
};
acl "isc" {
"ipreg";
key "university_of_cambridge-a1ec5f18.sns-pba.isc.org";
};
acl "secondaries" {
"cudn";
"isc";
key "tsig-cam-maths";
key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
194.81.227.226/32;
2001:630:0:44::e2/128;
193.63.105.17/32;
2001:630:0:45::11/128;
193.63.106.103/32;
2001:630:0:46::67/128;
193.62.157.66/32;
2001:630:0:47::42/128;
93.93.130.49/32;
69.56.173.190/32;
2600:3c00::f03c:91ff:fe96:beac/128;
93.93.128.67/32;
2a00:1098:0:80:1000::10/128;
185.24.221.32/32;
2a02:2770:11:0:21a:4aff:febe:759b/128;
};
acl "ipreg" {
key "tsig-ipreg";
"secure";
};
controls {
inet 0.0.0.0 port 953 allow {
"secure";
};
inet :: port 953 allow {
"secure";
};
};
logging {
channel "log" {
file "../log/named.log" versions 10 size 10485760;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"log";
};
category "cname" {
"default_debug";
};
category "dnssec" {
"default_debug";
};
category "lame-servers" {
"default_debug";
};
category "query-errors" {
"default_debug";
};
category "resolver" {
"default_debug";
};
category "security" {
"default_debug";
};
category "update-security" {
"default_debug";
};
};
masters "notify-isc" {
149.20.67.14 key "university_of_cambridge-a1ec5f18.sns-pba.isc.org";
199.6.0.100 key "university_of_cambridge-a1ec5f18.sns-pba.isc.org";
};
masters "notify-auth" {
2001:630:212:8::d:a0 key "tsig-ipreg";
2001:630:212:12::d:a1 key "tsig-ipreg";
2001:630:212:8::d:a2 key "tsig-ipreg";
2001:630:212:12::d:a3 key "tsig-ipreg";
};
masters "notify-rec" {
"notify-auth";
2001:630:212:8::d:92 key "tsig-ipreg";
2001:630:212:8::d:93 key "tsig-ipreg";
2001:630:212:8::d:94 key "tsig-ipreg";
2001:630:212:8::d:95 key "tsig-ipreg";
};
masters "master-ipreg" {
2001:630:212:8::d:aa key "tsig-ipreg";
};
masters "master-fanf" {
2001:630:212:110::d:7a7 key "tsig-fanf";
2001:630:212:110:646f:7461:742e:6174 key "tsig-fanf";
};
masters "master-cl" {
2001:630:212:200::d:a0;
128.232.0.19;
2001:630:212:200::d:a1;
128.232.0.18;
};
masters "master-eng" {
129.169.8.8;
129.169.8.9;
};
masters "master-maths" {
131.111.16.129;
131.111.16.30;
131.111.16.32;
};
masters "master-janet-rpz" {
2001:630:1:128::166;
194.82.174.166;
2001:630:1:12a::235;
194.83.56.235;
};
masters "master-imperial" {
2001:630:12:600:1::80 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
2001:630:12:600:1::81 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
2001:630:12:600:1::82 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
195.97.216.196 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
};
masters "master-salford" {
146.87.136.156;
146.87.136.157;
};
masters "master-york" {
144.32.129.200;
144.32.128.230;
};
masters "master-sanger" {
193.62.203.30;
};
masters "master-chiark" {
212.13.197.229;
};
masters "master-srcf" {
131.111.179.79;
};
masters "master-exim" {
2001:630:212:8::e:f0e key "tsig-cam-exim";
131.111.8.88 key "tsig-cam-exim";
2a02:898:31::53:0 key "tsig-cam-exim";
94.142.241.91 key "tsig-cam-exim";
2604:a880:800:a1::419:1001 key "tsig-cam-exim";
159.203.114.39 key "tsig-cam-exim";
};
options {
blackhole {
"blackhole";
};
directory "/home/named/run";
recursive-clients 12345;
server-id hostname;
tcp-clients 1234;
dnssec-validation auto;
max-cache-size 17179869184;
max-stale-ttl 3600;
no-case-compress {
"any";
};
rrset-order {
order random;
};
stale-answer-enable yes;
allow-query {
"cudn";
};
notify no;
zone-statistics full;
};
statistics-channels {
inet 0.0.0.0 port 8053 allow {
"cudn";
};
inet :: port 8053 allow {
"cudn";
};
};
view "main" {
match-destinations {
!131.111.9.99/32;
!2001:630:212:8::d:2/128;
!131.111.12.99/32;
!2001:630:212:12::d:3/128;
!131.111.9.118/32;
!2001:630:212:8::d:fff2/128;
!131.111.12.118/32;
!2001:630:212:12::d:fff3/128;
"any";
};
zone "1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "../zone/1.2.0.0.3.6.0.1.0.0.2.ip6.arpa";
masters {
"master-ipreg";
};
};
zone "10.in-addr.arpa" {
type slave;
file "../zone/10.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "111.131.in-addr.arpa" {
type slave;
file "../zone/111.131.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "145.111.131.in-addr.arpa" {
type slave;
file "../zone/145.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "16.111.131.in-addr.arpa" {
type slave;
file "../zone/16.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "16.172.in-addr.arpa" {
type slave;
file "../zone/16.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "169.129.in-addr.arpa" {
type slave;
file "../zone/169.129.in-addr.arpa";
masters {
"master-eng";
};
};
zone "17.111.131.in-addr.arpa" {
type slave;
file "../zone/17.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "17.172.in-addr.arpa" {
type slave;
file "../zone/17.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "18.111.131.in-addr.arpa" {
type slave;
file "../zone/18.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "18.172.in-addr.arpa" {
type slave;
file "../zone/18.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "19.172.in-addr.arpa" {
type slave;
file "../zone/19.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "195.18.192.in-addr.arpa" {
type slave;
file "../zone/195.18.192.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "../zone/2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa";
masters {
"master-cl";
};
};
zone "20.111.131.in-addr.arpa" {
type slave;
file "../zone/20.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "20.172.in-addr.arpa" {
type slave;
file "../zone/20.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "21.172.in-addr.arpa" {
type slave;
file "../zone/21.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "213.153.192.in-addr.arpa" {
type slave;
file "../zone/213.153.192.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "22.172.in-addr.arpa" {
type slave;
file "../zone/22.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "23.172.in-addr.arpa" {
type slave;
file "../zone/23.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "232.128.in-addr.arpa" {
type slave;
file "../zone/232.128.in-addr.arpa";
masters {
"master-cl";
};
};
zone "24.111.131.in-addr.arpa" {
type slave;
file "../zone/24.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "24.172.in-addr.arpa" {
type slave;
file "../zone/24.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "25.172.in-addr.arpa" {
type slave;
file "../zone/25.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "252.63.193.in-addr.arpa" {
type slave;
file "../zone/252.63.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "253.63.193.in-addr.arpa" {
type slave;
file "../zone/253.63.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "26.172.in-addr.arpa" {
type slave;
file "../zone/26.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "27.172.in-addr.arpa" {
type slave;
file "../zone/27.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "28.172.in-addr.arpa" {
type slave;
file "../zone/28.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "29.172.in-addr.arpa" {
type slave;
file "../zone/29.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "30.172.in-addr.arpa" {
type slave;
file "../zone/30.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "5.0.0.0.8.9.0.1.0.0.a.2.ip6.arpa" {
type slave;
file "../zone/5.0.0.0.8.9.0.1.0.0.a.2.ip6.arpa";
masters {
"master-ipreg";
};
};
zone "5.84.192.in-addr.arpa" {
type slave;
file "../zone/5.84.192.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "80.60.193.in-addr.arpa" {
type slave;
file "../zone/80.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "81.60.193.in-addr.arpa" {
type slave;
file "../zone/81.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "82.60.193.in-addr.arpa" {
type slave;
file "../zone/82.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "83.60.193.in-addr.arpa" {
type slave;
file "../zone/83.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "84.60.193.in-addr.arpa" {
type slave;
file "../zone/84.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "85.60.193.in-addr.arpa" {
type slave;
file "../zone/85.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "86.60.193.in-addr.arpa" {
type slave;
file "../zone/86.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "87.60.193.in-addr.arpa" {
type slave;
file "../zone/87.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "88.60.193.in-addr.arpa" {
type slave;
file "../zone/88.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "89.60.193.in-addr.arpa" {
type slave;
file "../zone/89.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "90.60.193.in-addr.arpa" {
type slave;
file "../zone/90.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "91.60.193.in-addr.arpa" {
type slave;
file "../zone/91.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "92.60.193.in-addr.arpa" {
type slave;
file "../zone/92.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "93.60.193.in-addr.arpa" {
type slave;
file "../zone/93.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "94.60.193.in-addr.arpa" {
type slave;
file "../zone/94.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "95.60.193.in-addr.arpa" {
type slave;
file "../zone/95.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "block.arpa.cam.ac.uk" {
type slave;
file "../zone/block.arpa.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "botnetcc.rpz.spamhaus.org" {
type slave;
file "../zone/botnetcc.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "cam.ac.uk" {
type slave;
file "../zone/cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "cl.cam.ac.uk" {
type slave;
file "../zone/cl.cam.ac.uk";
masters {
"master-cl";
};
};
zone "cst.cam.ac.uk" {
type slave;
file "../zone/cst.cam.ac.uk";
masters {
"master-cl";
};
};
zone "damtp.cam.ac.uk" {
type slave;
file "../zone/damtp.cam.ac.uk";
masters {
"master-maths";
};
};
zone "dbl.rpz.spamhaus.org" {
type slave;
file "../zone/dbl.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "dpmms.cam.ac.uk" {
type slave;
file "../zone/dpmms.cam.ac.uk";
masters {
"master-maths";
};
};
zone "drop.rpz.spamhaus.org" {
type slave;
file "../zone/drop.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "eng.cam.ac.uk" {
type slave;
file "../zone/eng.cam.ac.uk";
masters {
"master-eng";
};
};
zone "in-addr.arpa.cam.ac.uk" {
type slave;
file "../zone/in-addr.arpa.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "in-addr.arpa.private.cam.ac.uk" {
type slave;
file "../zone/in-addr.arpa.private.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "malware-aggressive.rpz.spamhaus.org" {
type slave;
file "../zone/malware-aggressive.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "malware.rpz.spamhaus.org" {
type slave;
file "../zone/malware.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "maths.cam.ac.uk" {
type slave;
file "../zone/maths.cam.ac.uk";
masters {
"master-maths";
};
};
zone "newton.cam.ac.uk" {
type slave;
file "../zone/newton.cam.ac.uk";
masters {
"master-maths";
};
};
zone "passthru.arpa.cam.ac.uk" {
type slave;
file "../zone/passthru.arpa.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "private.cam.ac.uk" {
type slave;
file "../zone/private.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "srcf.net" {
type slave;
file "../zone/srcf.net";
masters {
"master-srcf";
};
};
zone "srcf.ucam.org" {
type slave;
file "../zone/srcf.ucam.org";
masters {
"master-srcf";
};
};
zone "statslab.cam.ac.uk" {
type slave;
file "../zone/statslab.cam.ac.uk";
masters {
"master-maths";
};
};
zone "ucam.org" {
type slave;
file "../zone/ucam.org";
masters {
"master-chiark";
};
};
response-policy {
zone "passthru.arpa.cam.ac.uk" policy passthru;
zone "block.arpa.cam.ac.uk" policy cname "block.dns.cam.ac.uk";
} break-dnssec yes max-policy-ttl 300 qname-wait-recurse no;
};
view "unfiltered" {
zone "1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
in-view "main";
};
zone "10.in-addr.arpa" {
in-view "main";
};
zone "111.131.in-addr.arpa" {
in-view "main";
};
zone "145.111.131.in-addr.arpa" {
in-view "main";
};
zone "16.111.131.in-addr.arpa" {
in-view "main";
};
zone "16.172.in-addr.arpa" {
in-view "main";
};
zone "169.129.in-addr.arpa" {
in-view "main";
};
zone "17.111.131.in-addr.arpa" {
in-view "main";
};
zone "17.172.in-addr.arpa" {
in-view "main";
};
zone "18.111.131.in-addr.arpa" {
in-view "main";
};
zone "18.172.in-addr.arpa" {
in-view "main";
};
zone "19.172.in-addr.arpa" {
in-view "main";
};
zone "195.18.192.in-addr.arpa" {
in-view "main";
};
zone "2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
in-view "main";
};
zone "20.111.131.in-addr.arpa" {
in-view "main";
};
zone "20.172.in-addr.arpa" {
in-view "main";
};
zone "21.172.in-addr.arpa" {
in-view "main";
};
zone "213.153.192.in-addr.arpa" {
in-view "main";
};
zone "22.172.in-addr.arpa" {
in-view "main";
};
zone "23.172.in-addr.arpa" {
in-view "main";
};
zone "232.128.in-addr.arpa" {
in-view "main";
};
zone "24.111.131.in-addr.arpa" {
in-view "main";
};
zone "24.172.in-addr.arpa" {
in-view "main";
};
zone "25.172.in-addr.arpa" {
in-view "main";
};
zone "252.63.193.in-addr.arpa" {
in-view "main";
};
zone "253.63.193.in-addr.arpa" {
in-view "main";
};
zone "26.172.in-addr.arpa" {
in-view "main";
};
zone "27.172.in-addr.arpa" {
in-view "main";
};
zone "28.172.in-addr.arpa" {
in-view "main";
};
zone "29.172.in-addr.arpa" {
in-view "main";
};
zone "30.172.in-addr.arpa" {
in-view "main";
};
zone "5.0.0.0.8.9.0.1.0.0.a.2.ip6.arpa" {
in-view "main";
};
zone "5.84.192.in-addr.arpa" {
in-view "main";
};
zone "80.60.193.in-addr.arpa" {
in-view "main";
};
zone "81.60.193.in-addr.arpa" {
in-view "main";
};
zone "82.60.193.in-addr.arpa" {
in-view "main";
};
zone "83.60.193.in-addr.arpa" {
in-view "main";
};
zone "84.60.193.in-addr.arpa" {
in-view "main";
};
zone "85.60.193.in-addr.arpa" {
in-view "main";
};
zone "86.60.193.in-addr.arpa" {
in-view "main";
};
zone "87.60.193.in-addr.arpa" {
in-view "main";
};
zone "88.60.193.in-addr.arpa" {
in-view "main";
};
zone "89.60.193.in-addr.arpa" {
in-view "main";
};
zone "90.60.193.in-addr.arpa" {
in-view "main";
};
zone "91.60.193.in-addr.arpa" {
in-view "main";
};
zone "92.60.193.in-addr.arpa" {
in-view "main";
};
zone "93.60.193.in-addr.arpa" {
in-view "main";
};
zone "94.60.193.in-addr.arpa" {
in-view "main";
};
zone "95.60.193.in-addr.arpa" {
in-view "main";
};
zone "block.arpa.cam.ac.uk" {
in-view "main";
};
zone "botnetcc.rpz.spamhaus.org" {
in-view "main";
};
zone "cam.ac.uk" {
in-view "main";
};
zone "cl.cam.ac.uk" {
in-view "main";
};
zone "cst.cam.ac.uk" {
in-view "main";
};
zone "damtp.cam.ac.uk" {
in-view "main";
};
zone "dbl.rpz.spamhaus.org" {
in-view "main";
};
zone "dpmms.cam.ac.uk" {
in-view "main";
};
zone "drop.rpz.spamhaus.org" {
in-view "main";
};
zone "eng.cam.ac.uk" {
in-view "main";
};
zone "in-addr.arpa.cam.ac.uk" {
in-view "main";
};
zone "in-addr.arpa.private.cam.ac.uk" {
in-view "main";
};
zone "malware-aggressive.rpz.spamhaus.org" {
in-view "main";
};
zone "malware.rpz.spamhaus.org" {
in-view "main";
};
zone "maths.cam.ac.uk" {
in-view "main";
};
zone "newton.cam.ac.uk" {
in-view "main";
};
zone "passthru.arpa.cam.ac.uk" {
in-view "main";
};
zone "private.cam.ac.uk" {
in-view "main";
};
zone "srcf.net" {
in-view "main";
};
zone "srcf.ucam.org" {
in-view "main";
};
zone "statslab.cam.ac.uk" {
in-view "main";
};
zone "ucam.org" {
in-view "main";
};
attach-cache "main";
};
key "cam.ac.uk.feb2016.tsig.ic.ac.uk" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "tsig-ipreg" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "university_of_cambridge-a1ec5f18.sns-pba.isc.org" {
algorithm "hmac-sha512";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
key "tsig-cam-maths" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "tsig-cam-exim" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "tsig-fanf" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
server 157.83.102.245/32 {
send-cookie no;
};
server 157.83.102.246/32 {
send-cookie no;
};
server 157.83.126.245/32 {
send-cookie no;
};
server 157.83.126.246/32 {
send-cookie no;
};
server 43.242.49.158/32 {
send-cookie no;
};
server 113.209.232.218/32 {
send-cookie no;
};
server 63.150.72.5/32 {
send-cookie no;
};
server 2001:428::7/128 {
send-cookie no;
};
server 208.44.130.121/32 {
send-cookie no;
};
server 2001:428::8/128 {
send-cookie no;
};
server 172.16.3.0/24 {
bogus no;
};
server 0.0.0.0/8 {
bogus yes;
};
server 10.0.0.0/8 {
bogus yes;
};
server 100.64.0.0/10 {
bogus yes;
};
server 127.0.0.0/8 {
bogus yes;
};
server 169.254.0.0/16 {
bogus yes;
};
server 172.16.0.0/12 {
bogus yes;
};
server 192.0.0.0/24 {
bogus yes;
};
server 192.0.2.0/24 {
bogus yes;
};
server 192.88.99.0/24 {
bogus yes;
};
server 192.168.0.0/16 {
bogus yes;
};
server 198.18.0.0/15 {
bogus yes;
};
server 198.51.100.0/24 {
bogus yes;
};
server 203.0.113.0/24 {
bogus yes;
};
server 224.0.0.0/3 {
bogus yes;
};
server ::/3 {
bogus yes;
};
server 2001::/32 {
bogus yes;
};
server 2001:2::/48 {
bogus yes;
};
server 2001:10::/28 {
bogus yes;
};
server 2001:db8::/32 {
bogus yes;
};
server 2002::/16 {
bogus yes;
};
server 3000::/4 {
bogus yes;
};
server 4000::/2 {
bogus yes;
};
server 8000::/1 {
bogus yes;
};
```https://gitlab.isc.org/isc-projects/kea/-/issues/1725Sanity checks for Kea 1.9.5 rc12021-03-30T20:40:28ZjenkinsSanity checks for Kea 1.9.5 rc1```We are now at step SANITY CHECKS of Kea 1.9.5 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. ple...```We are now at step SANITY CHECKS of Kea 1.9.5 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. please, state in Sanity Checks issue in GitLab
what check you are doing in a thread/discussion (not as comment).
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/1.9.5-rc1
/data/shared/sweng/kea/releases/premium-1.9.5-rc1
/data/shared/sweng/kea/releases/subscription-1.9.5-rc1
SHA256 (kea-1.9.5.tar.gz) = 324a06f488645bee587e49a45d491b525f53417c56b219f1cb37461fdefd9d91
SHA256 (kea-premium-1.9.5.tar.gz) = 375c3ed27ec2511ab09af36b698248d9bae2c4f1178f49808be6b45130ad39c0
SHA256 (kea-subscription-1.9.5.tar.gz) = 3dd6ba61f9bc3604f40d13966a67bf6a95b6b22b622514be5d830312311230c1
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.isc.org/job/kea-dev/job/pkg/225/
Release version is 1.9.5-isc0019920210223075916 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```https://gitlab.isc.org/isc-projects/kea/-/issues/1691lib "bump" breaks build on git master (commit 6fea0912d4f0)2021-03-30T14:11:33ZGene Clib "bump" breaks build on git master (commit 6fea0912d4f0)Deleted comment - as seems to be a build error with nightly build of master.Deleted comment - as seems to be a build error with nightly build of master.https://gitlab.isc.org/isc-projects/kea/-/issues/1775distcheck fail: no module named 'kea_conn'2021-03-29T17:19:15ZAndrei Pavelandrei@isc.orgdistcheck fail: no module named 'kea_conn'https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/324/
```
14:57:28 Executing kea-shell (echo | /tmp/workspace/kea-dev/distcheck/kea-1.9.6-git/_build/sub/src/bin/shell/kea-shell --port 8443 > /tmp/workspace/kea-dev/distcheck/k...https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/324/
```
14:57:28 Executing kea-shell (echo | /tmp/workspace/kea-dev/distcheck/kea-1.9.6-git/_build/sub/src/bin/shell/kea-shell --port 8443 > /tmp/workspace/kea-dev/distcheck/kea-1.9.6-git/_build/sub/src/bin/agent/tests/shell-stdout.txt)
14:57:28 Traceback (most recent call last):
14:57:28 File "/tmp/workspace/kea-dev/distcheck/kea-1.9.6-git/_build/sub/src/bin/shell/kea-shell", line 27, in <module>
14:57:28 from kea_conn import CARequest # CAResponse
14:57:28 ModuleNotFoundError: No module named 'kea_conn'
14:57:28 [ FAILED ] NoTLS (exit code: 1)
```kea1.9.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2597Make calling generic rdata methods consistent2021-03-29T14:02:33ZMark AndrewsMake calling generic rdata methods consistentApril 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2416tlsdns_test gets stuck on FreeBSDs intermittently2021-03-29T13:23:28ZOndřej Surýtlsdns_test gets stuck on FreeBSDs intermittentlyThe `tlsdns_test` gets stuck on the FreeBSD 11 and 12 intermittently. It's not related to the OpenSSL version and it happens only occasionally. When it happens all the threads are waiting in either yield or kevent. We might be missing...The `tlsdns_test` gets stuck on the FreeBSD 11 and 12 intermittently. It's not related to the OpenSSL version and it happens only occasionally. When it happens all the threads are waiting in either yield or kevent. We might be missing some `tls_cycle()` invocation on some rare edge condition that happens only on FreeBSD.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/stork/-/issues/487Add missing TLS tests2021-03-29T13:20:20ZTomek MrugalskiAdd missing TLS testsWhile working on #483, a number of test gaps have been identified. Due to @godfryd's unexpected unavailability and approaching release date, @marcin and @tomek decided that the best way forward is to make an exception to the requirement ...While working on #483, a number of test gaps have been identified. Due to @godfryd's unexpected unavailability and approaching release date, @marcin and @tomek decided that the best way forward is to make an exception to the requirement for unit tests, merge #483 and implement the tests soon afterward. Hence this ticket.
The following tests are needed:
* [ ] extensions to PingMachine code in backend/server/restservice/machines.go:437, see https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_194921
* [ ] extensions to UpdateMachine code in backend/server/restservice/machines.go:536, see https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_194922
* [ ] better testing for DEB/RPM packages download, as suggested in https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_194941
* [ ] machines-page component received substantial updates, but there are no unit tests to cover this functionality, see https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_1949440.16Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1315HA + MT design - redesign of HA connection to control channel and Kea server2021-03-29T13:17:33ZRazvan BecheriuHA + MT design - redesign of HA connection to control channel and Kea serverthe ST async implementation of HA does not benefit from Kea MT without some core and lib changes
this ticket handles the design phase by creating the design document:
- old design: https://gitlab.isc.org/isc-projects/kea/-/wikis/high%2...the ST async implementation of HA does not benefit from Kea MT without some core and lib changes
this ticket handles the design phase by creating the design document:
- old design: https://gitlab.isc.org/isc-projects/kea/-/wikis/high%20availability%20with%20multi%20threading
- new design (as implemented): https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/HA-MT-Design-for-Multi-threaded-Http-HA-traffickea1.9.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2581"INSIST(oldsize == size);" assertion fails (down the call stack) for tls_writ...2021-03-29T13:16:03ZMichał Kępień"INSIST(oldsize == size);" assertion fails (down the call stack) for tls_write_cb()This is a new crash which was first observed on FreeBSD VMs in [pipeline
#66473][1]:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575006
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575007
However, it looks like somet...This is a new crash which was first observed on FreeBSD VMs in [pipeline
#66473][1]:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575006
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575007
However, it looks like something that was introduced earlier than in
commit 24c796942f53aefcd5929d820ee09b01f28ee827:
```
I:doth:ns1 died before a SIGTERM was sent
I:doth:stopping servers failed
I:doth:Core dump(s) found: doth/ns1/core.46383
D:doth:backtrace from doth/ns1/core.46383:
D:doth:--------------------------------------------------------------------------------
D:doth:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D doth-ns1 -X named.lock -m re'.
D:doth:Program terminated with signal SIGABRT, Aborted.
D:doth:#0 0x000000080100cc2a in thr_kill () from /lib/libc.so.7
D:doth:[Current thread is 1 (LWP 100126)]
D:doth:#0 0x000000080100cc2a in thr_kill () from /lib/libc.so.7
D:doth:#1 0x000000080100b084 in raise () from /lib/libc.so.7
D:doth:#2 0x0000000800f81279 in abort () from /lib/libc.so.7
D:doth:#3 0x000000000023b122 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=<optimized out>) at main.c:259
D:doth:#4 0x000000080032e6ca in isc_assertion_failed (file=0x1871e <error: Cannot access memory at address 0x1871e>, line=6, type=isc_assertiontype_require, cond=0x80100cc4a <thr_self+10> "\017\202\264G") at assertions.c:46
D:doth:#5 0x000000080033ca98 in isc__mem_put (ctx=0x801a05000, ptr=0x804c60010, size=6453, file=<optimized out>, line=0) at mem.c:775
D:doth:#6 0x00000008003179c6 in free_senddata (sock=<optimized out>) at netmgr/tlsdns.c:1295
D:doth:#7 0x0000000800317a50 in tls_write_cb (req=<optimized out>, status=0) at netmgr/tlsdns.c:1307
D:doth:#8 0x0000000800c1b065 in ?? () from /usr/local/lib/libuv.so.1
D:doth:#9 0x0000000800c1a92a in ?? () from /usr/local/lib/libuv.so.1
D:doth:#10 0x0000000800c2112b in uv.io_poll () from /usr/local/lib/libuv.so.1
D:doth:#11 0x0000000800c10551 in uv_run () from /usr/local/lib/libuv.so.1
D:doth:#12 0x000000080030771b in nm_thread (worker0=0x8013b0010) at netmgr/netmgr.c:553
D:doth:#13 0x000000080034dde5 in isc__trampoline_run (arg=0x8013f4d60) at trampoline.c:184
D:doth:#14 0x0000000800e37fac in ?? () from /lib/libthr.so.3
D:doth:#15 0x0000000000000000 in ?? ()
D:doth:Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
D:doth:--------------------------------------------------------------------------------
D:doth:full backtrace from doth/ns1/core.46383 saved in doth/ns1/core.46383-backtrace.txt
D:doth:core dump doth/ns1/core.46383 archived as doth/ns1/core.46383.gz
R:doth:FAIL
```
The `INSIST` that fails is: `INSIST(oldsize == size);`
@artem, any ideas?
[1]: https://gitlab.isc.org/isc-projects/bind9/-/pipelines/66473April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2580Does not compile without deprecated OpenSSL APIs2021-03-29T12:37:05ZRosen PenevDoes not compile without deprecated OpenSSL APIsSince it seems I can't make merge requests, here's a patch:
```
--- a/lib/isc/tls.c
+++ b/lib/isc/tls.c
@@ -9,8 +9,10 @@
* information regarding copyright ownership.
*/
+#include <openssl/bn.h>
#include <openssl/err.h>
#include <...Since it seems I can't make merge requests, here's a patch:
```
--- a/lib/isc/tls.c
+++ b/lib/isc/tls.c
@@ -9,8 +9,10 @@
* information regarding copyright ownership.
*/
+#include <openssl/bn.h>
#include <openssl/err.h>
#include <openssl/opensslv.h>
+#include <openssl/rsa.h>
#include <isc/atomic.h>
#include <isc/log.h>
@@ -220,11 +222,11 @@ isc_tlsctx_createserver(const char *keyfile, const char *certfile,
rsa = NULL;
ASN1_INTEGER_set(X509_get_serialNumber(cert), 1);
- X509_gmtime_adj(X509_get_notBefore(cert), 0);
+ X509_gmtime_adj(X509_getm_notBefore(cert), 0);
/*
* We set the vailidy for 10 years.
*/
- X509_gmtime_adj(X509_get_notAfter(cert), 3650 * 24 * 3600);
+ X509_gmtime_adj(X509_getm_notAfter(cert), 3650 * 24 * 3600);
X509_set_pubkey(cert, pkey);
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2514Windows 10 Insider Dev fails to resolve DoH queries against BIND2021-03-29T12:31:49ZtriaticWindows 10 Insider Dev fails to resolve DoH queries against BIND<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
I cannot get DNS over HTTPS in BIND to work with Windows 10 Insider Dev, whereas I have no problems with Unbound. Unbound returns the full chain for my letsencrypt tls certificate whereas BIND does not, which may explain it.
### BIND version used
BIND 9.17.10-1+ubuntu20.10.1+isc+1-Ubuntu (Development Release) <id:>
### Steps to reproduce
Install Windows 10 Insider (Dev channel) and attempt to resolve queries against a BIND DoH server configured with a letsencrypt (or similar) certificate.
### What is the current *bug* behavior?
DNS resolution fails.
### What is the expected *correct* behavior?
DNS resolution should succeed.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldariev