ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-02-21T07:56:10Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/11221.6.2 sanity checks2020-02-21T07:56:10ZWlodzimierz Wencel1.6.2 sanity checks```
@repo.isc.org /data/shared/sweng/kea/releases
SHA256 (1.6.2-rc1/kea-1.6.2.tar.gz) = d55802a117392a0ff42b2507de922598ed08e5ed08fa35cad260c76122360b80
SHA256 (subscription-1.6.2-rc1/kea-subscription-1.6.2.tar.gz) = 62f3ea5ee2af6b5c20a1...```
@repo.isc.org /data/shared/sweng/kea/releases
SHA256 (1.6.2-rc1/kea-1.6.2.tar.gz) = d55802a117392a0ff42b2507de922598ed08e5ed08fa35cad260c76122360b80
SHA256 (subscription-1.6.2-rc1/kea-subscription-1.6.2.tar.gz) = 62f3ea5ee2af6b5c20a11f9a4a57b70b9fa15514a6d5df5aec8f2543e1f32441
SHA256 (premium-1.6.2-rc1/kea-premium-1.6.2.tar.gz) = 046522f4f6800bc39307794a32759df452d9647b91a5963027ffe7c27f599784
SHA256 (1.6.2-rc1/doc/html) = e80fe1577a1e00e9659d5637cc3f0c42a8221f170fa7a77b4c804e48352754d0
SHA256 (1.6.2-rc1/doc/kea-arm.pdf) = f4da5af47eb77422e0938ce5e9d6c22e5d63c50ec4158ee7d02b37e4332f48ec
SHA256 (1.6.2-rc1/doc/kea-messages.pdf) = 3a6eb0d7db320f3bb0940a68b1cd8ad56a88cb175ccaa2c96d5038656140e52c
```kea1.6.2https://gitlab.isc.org/isc-projects/bind9/-/issues/1626Algorithm rollover is stuck on publishing DS2020-03-09T13:43:21ZMatthijs Mekkingmatthijs@isc.orgAlgorithm rollover is stuck on publishing DSThe keymgr logic prevents to introduce the DS record (move it to RUMOURED state) because it thinks that will move DNSSEC into an invalid state.The keymgr logic prevents to introduce the DS record (move it to RUMOURED state) because it thinks that will move DNSSEC into an invalid state.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1625Algorithm rollover takes too long to introduce2020-03-09T13:43:20ZMatthijs Mekkingmatthijs@isc.orgAlgorithm rollover takes too long to introduceAlgorithm rollover takes too long (but luckily not too short) because when introducing new zone signatures the time to wait before the signatures are omnipresent includes the sign delay. This is the delay that ensures all zone signature...Algorithm rollover takes too long (but luckily not too short) because when introducing new zone signatures the time to wait before the signatures are omnipresent includes the sign delay. This is the delay that ensures all zone signatures have been refreshed. Thus publishing the DS record is delayed. Since there is no predecessor key with the same algorithm, all signatures need to be resigned anyway and adding the sign delay is unnecessary.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1624dnssec-policy change does not retire keys2020-03-09T13:43:21ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy change does not retire keysWhen changing a policy for a zone (for example to perform an algorithm rollover), existing keys with no longer matching properties (for example that now have the wrong algorithm) are not being retired, thus are being kept in the zone and...When changing a policy for a zone (for example to perform an algorithm rollover), existing keys with no longer matching properties (for example that now have the wrong algorithm) are not being retired, thus are being kept in the zone and maintain active.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1623Assertion failure in ns_client_endrequest when shutting down2020-02-27T07:55:40ZWitold KrecickiAssertion failure in ns_client_endrequest when shutting downScenario:
1. We are shutting down, interface->clientmgr is gone
2. We receive a packet, it gets through ns__client_request
3. mgr == NULL, return
4. isc_nmhandle_detach calls ns_client_reset_cb
5. ns_client_reset_cb calls ns_client_endr...Scenario:
1. We are shutting down, interface->clientmgr is gone
2. We receive a packet, it gets through ns__client_request
3. mgr == NULL, return
4. isc_nmhandle_detach calls ns_client_reset_cb
5. ns_client_reset_cb calls ns_client_endrequest
6. INSIST(client->state == NS_CLIENTSTATE_WORKING || client->state == NS_CLIENTSTATE_RECURSING) is not met - we haven't started processing this packet so client->state == NS_CLIENTSTATE_READY.
Solution - don't call ns_client_endrequest if client->state == NS_CLIENTSTATE_READYMarch 2020 (9.11.17, 9.16.1, 9.17.0)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1621"statistics" system test is prone to races and does not preserve forensic data2024-02-24T07:58:28ZMichał Kępień"statistics" system test is prone to races and does not preserve forensic dataIt was hard to figure out what was happening in https://gitlab.isc.org/isc-private/bind9/-/jobs/674674 because the `statistics` system test does not preserve enough forensic data to troubleshoot this particular failure mode easily, but I...It was hard to figure out what was happening in https://gitlab.isc.org/isc-private/bind9/-/jobs/674674 because the `statistics` system test does not preserve enough forensic data to troubleshoot this particular failure mode easily, but I think I got to the bottom of what is happening. I believe the problem is that `ns3` retries the SOA query for the `a-slave` zone right *before* the first use of `rndc stats` but the response to that query is received *after* the first use of `rndc stats`. This retried SOA query is usually sent after the first use of `rndc stats` and replied to before the second use of `rndc stats`; if that is not the case, statistics get skewed. Here is how things look typically:
```
$ grep -E "(created socket| soa_query:|refresh:|'stats')" ns3/named.run | sed -E "/'stats'/{s|(.*)|---------- \1 ----------|}"
14-Feb-2020 13:39:51.279 dispatch 0x7faf54030ce0: created socket 0x7faf5ec9f600
14-Feb-2020 13:39:51.279 dispatch 0x7faf54030720: created socket 0x7faf5ec9f778
14-Feb-2020 13:39:51.279 dispatch 0x7faf54030160: created socket 0x7faf5ec9f8f0
14-Feb-2020 13:39:51.279 dispatch 0x7faf5402fba0: created socket 0x7faf5ec9fa68
14-Feb-2020 13:39:51.303 soa_query: zone a-slave/IN: enter
14-Feb-2020 13:39:51.303 dispatch 0x7faf54652fa0: created socket 0x7faf5a41e600
14-Feb-2020 13:39:51.304 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#5300 (source 10.53.0.3#0)
---------- 14-Feb-2020 13:39:51.537 received control channel command 'stats' ----------
14-Feb-2020 13:39:51.803 soa_query: zone a-slave/IN: enter
14-Feb-2020 13:39:51.803 dispatch 0x7faf54652fa0: created socket 0x7faf5a41ebe0
14-Feb-2020 13:39:51.807 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#5300 (source 0.0.0.0#0)
---------- 14-Feb-2020 13:39:53.564 received control channel command 'stats' ----------
```
while this is what happened in the job linked to above:
```
$ grep -E "(created socket| soa_query:|refresh:|'stats')" ns3/named.run | sed -E "/'stats'/{s|(.*)|---------- \1 ----------|}"
13-Feb-2020 14:47:44.500 dispatch 0x80545b000: created socket 0x80508d838
13-Feb-2020 14:47:44.500 dispatch 0x80545aa00: created socket 0x80508d990
13-Feb-2020 14:47:44.500 dispatch 0x80545a400: created socket 0x80508dae8
13-Feb-2020 14:47:44.500 dispatch 0x805459e00: created socket 0x80508dc40
13-Feb-2020 14:47:44.549 soa_query: zone a-slave/IN: enter
13-Feb-2020 14:47:44.550 dispatch 0x805743400: created socket 0x8054e0508
13-Feb-2020 14:47:44.552 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#12400 (source 10.53.0.3#0)
13-Feb-2020 14:47:45.048 soa_query: zone a-slave/IN: enter
13-Feb-2020 14:47:45.048 dispatch 0x805743400: created socket 0x80508d430
---------- 13-Feb-2020 14:47:45.058 received control channel command 'stats' ----------
13-Feb-2020 14:47:45.069 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#12400 (source 0.0.0.0#0)
---------- 13-Feb-2020 14:47:47.149 received control channel command 'stats' ----------
```
Thus, I *believe* that the active socket count was 1 less than the expected value in the second `ns3/named.stats` file being examined.
AFAICT, the `a-slave` zone is only relevant in the `checking bind9.xsl vs xml` check, it is not configured on `ns1`. If it was actually configured, the SOA query would not need to be retried due to an NXDOMAIN response, hopefully making the test more reliable.
Forensic data preservation should also be improved for this test.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/kea/-/issues/1121Remove use of IOAddress::lessThan() from comparison operators2020-02-14T16:22:20ZThomas MarkwalderRemove use of IOAddress::lessThan() from comparison operatorsThe IOAddress operators for < and <= use IOAddress::lessThan() rather than simply using the underlying data object, asio_address_'s operators as we already do for =. IOAddress::lessThan() adds an unnecessary layer of logic and uses a l...The IOAddress operators for < and <= use IOAddress::lessThan() rather than simply using the underlying data object, asio_address_'s operators as we already do for =. IOAddress::lessThan() adds an unnecessary layer of logic and uses a less efficient mechanism for comparison. Perflab testing demonstrated a modest improvement for v4 and a noticeable improvement for v6 (using memfile, persist, 1M clients no congestion).kea1.7.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1120Refine reverse proxy for kea2021-06-28T08:22:33ZRazvan BecheriuRefine reverse proxy for keaWhen we implemented Kea Control Agent we considered whether we should provide a built-in solution for https or not. At that time, it seemed reasonable to rely on third party HTTP servers, such as nginx to provide reverse proxy function b...When we implemented Kea Control Agent we considered whether we should provide a built-in solution for https or not. At that time, it seemed reasonable to rely on third party HTTP servers, such as nginx to provide reverse proxy function because we don't have the maintain the security critical code. The third party HTTP servers are trustworthy when it comes to security. However, we've had reports that installing such a third party software is not always possible, especially when talking about large installations.
This ticket resumes the discussion how we could possibly provide a viable alternative to third party reverse proxies and ship something with Kea that would provide similar function and would be easy to install, deploy and run.
A discussion/high level design page is here: https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent-discussionKea1.9-backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/167integrate stork with prometheus2020-03-02T13:46:24ZMichal Nowikowskiintegrate stork with prometheus0.5Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1620dnssec-policy NSEC3 support2021-01-04T12:47:31ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy NSEC3 supportDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1619RPZ wildcard passthru ignored2020-08-20T19:36:01ZDaniel StirnimannRPZ wildcard passthru ignored### Summary
I have two response-policy zones configured. The first zone is a local whitelist with the policy passthru. The second zone is a local blacklist with the policy given. If the blacklist rpz zone contains `www.example.com CNAME...### Summary
I have two response-policy zones configured. The first zone is a local whitelist with the policy passthru. The second zone is a local blacklist with the policy given. If the blacklist rpz zone contains `www.example.com CNAME .` (nxdomain) and the whitelist rpz zone contains a wildcard to whitelist *.example.com with `*.example.com CNAME rpz-passthru.` then this wildcard is ignored.
This has worked from 9.8 up to 9.14.5 and started not working in 9.14.6 and later (I tested up to 9.16.1)
### BIND version used
```
BIND 9.14.6 (Stable Release) <id:efd3496>
running on Linux x86_64 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020
built by make with '--build=x86_64-koji-linux-gnu' '--host=x86_64-koji-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/named' '--bindir=/opt/named/bin' '--sbindir=/opt/named/sbin' '--sysconfdir=/etc' '--datadir=/opt/named/share' '--includedir=/opt/named/include' '--libdir=/opt/named/lib64' '--libexecdir=/opt/named/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/opt/named/share/man' '--infodir=/opt/named/share/info' '--exec-prefix=/opt/named' '--disable-static' '--enable-threads' '--enable-ipv6' '--enable-dnstap' '--disable-openssl-version-check' '--enable-largefile' '--with-tuning=large' '--with-randomdev=/dev/urandom' '--with-pic' '--with-libjson' '--with-libtool' '--with-libxml2' '--with-python-install-dir=/opt/named/usr/lib/python2.7/site-packages' '--with-docbook-xsl=/opt/named/share/sgml/docbook/xsl-stylesheets' '--includedir=/opt/named/include/bind9' 'build_alias=x86_64-koji-linux-gnu' 'host_alias=x86_64-koji-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/opt/named/lib64/pkgconfig:/opt/named/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with libjson-c version: 0.11
linked to libjson-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
1. Install bind release 9.14.6
2. Use the `named.conf` and `whitelist.zone`, `blacklist.zone` listed in the configuration file section.
3. Start bind e.g. systemctl start named
4. Use dig to check the behavior and check the logs
```
dig @::1 www.example.com
```
### What is the current *bug* behavior?
The wildcard passthru entry in the `whitelist.zone` is ignored.
### What is the expected *correct* behavior?
The wildcard passthru entry in the `whitelist.zone` is used.
### Relevant configuration files
Used `named.conf`
```
logging {
channel "default_debug" {
file "named.log";
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
};
options {
directory "/var/named/data";
listen-on port 53 {
127.0.0.1/32;
};
listen-on-v6 port 53 {
::1/128;
};
dnssec-enable yes;
dnssec-validation auto;
empty-zones-enable yes;
recursion yes;
response-policy {
zone "whitelist.zone" policy passthru;
zone "blacklist.zone" policy given;
} break-dnssec yes;
allow-query {
"localhost";
};
allow-transfer {
"localhost";
};
};
zone "whitelist.zone" {
type master;
file "whitelist.zone";
allow-query {
"none";
};
};
zone "blacklist.zone" {
type master;
file "blacklist.zone";
allow-query {
"none";
};
};
```
Used `whitelist.zone`
```
$ORIGIN whitelist.zone.
$TTL 3600
@ IN SOA ns.whitelist.zone. hostmaster.whitelist.zone. 1 600 300 604800 3600
IN NS ns2.switch.ch.
example.com CNAME rpz-passthru.
*.example.com CNAME rpz-passthru.
```
Used `blacklist.zone`
```
$ORIGIN blacklist.zone.
$TTL 3600
@ IN SOA ns.blacklist.zone. hostmaster.blacklist.zone. 1 600 300 604800 3600
IN NS ns2.switch.ch.
www.example.com CNAME .
; test record
test.example.org CNAME .
```
### Relevant logs and/or screenshots
Log entry on 9.14.6 where it breaks wildcards for passthru:
```
12-Feb-2020 15:12:30.481 rpz: info: client @0x7fd7200a2cb0 ::1#58427 (www.example.com): rpz QNAME Local-Data rewrite www.example.com/A/IN via www.example.com.blacklist.zone
```
Log entry on 9.14.5 where wildcard passthru still works:
```
12-Feb-2020 15:14:36.229 rpz: info: client @0x7fd5440a2cb0 ::1#45028 (www.example.com): rpz QNAME PASSTHRU rewrite www.example.com/A/IN via www.example.com.whitelist.zone
```
### Possible fixes
It may has something to do with this change in 9.14.6
```
5282. [bug] Fixed a bug in searching for possible wildcard matches
for query names in the RPZ summary database. [GL #1146]
```
https://ftp.isc.org/isc/bind9/9.14.6/CHANGESAugust 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/1618Update Windows instructions for building with GeoIP support2021-10-05T11:00:11ZMichał KępieńUpdate Windows instructions for building with GeoIP supportThe GeoIP section of `win32utils/build.txt` is outdated and needs to be revised to reflect the current state of things:
```
Step 5: Download and build GeoIP
Geographic ("geoip") ACLs require libGeoIP. If you wish to build BIND 9
wi...The GeoIP section of `win32utils/build.txt` is outdated and needs to be revised to reflect the current state of things:
```
Step 5: Download and build GeoIP
Geographic ("geoip") ACLs require libGeoIP. If you wish to build BIND 9
without support for this feature, skip to step 6.
The libGeoIP source code is available from:
https://github.com/maxmind/geoip-api-c/releases.
As of this writing, the current version of libGeoIP is 1.6.0. There
is a known bug in this and all prior versions which prevents it from
building a suitable DLL with thread support on Windows. You can apply
the patch file bind9/win32utils/GeoIP.diff to address the problem.
This patch has been submitted upstream, and will be included in
future versions of libGeoIP.
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/stork/-/issues/166implement pulling kea lease stats periodically2020-02-24T07:41:26ZMichal Nowikowskiimplement pulling kea lease stats periodically0.5Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1617Remove dnssec-keymgr2021-10-05T11:00:01ZOndřej SurýRemove dnssec-keymgrThe `dnssec-keymgr` has been obsoleted by `dnssec-policy` in BIND 9.16. Remove it from the next development release. We should probably also add a warning to 9.16.x at some point, so people can migrate. I don't really want to maintain...The `dnssec-keymgr` has been obsoleted by `dnssec-policy` in BIND 9.16. Remove it from the next development release. We should probably also add a warning to 9.16.x at some point, so people can migrate. I don't really want to maintain `dnssec-keymgr` for next 6+ years.BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1616autosign not waiting long enough for zone to be signed v9_11 and maybe others2020-02-12T20:44:16ZMark Andrewsautosign not waiting long enough for zone to be signed v9_11 and maybe othersJob [#661978](https://gitlab.isc.org/isc-projects/bind9/-/jobs/661978) failed for 8d0b59a5f5fc13c11931b25a9f05dd2845bad854:
```
I:autosign:checking scheduled key activation (72)
I:autosign:waiting for changes to take effect
I:autosign:f...Job [#661978](https://gitlab.isc.org/isc-projects/bind9/-/jobs/661978) failed for 8d0b59a5f5fc13c11931b25a9f05dd2845bad854:
```
I:autosign:checking scheduled key activation (72)
I:autosign:waiting for changes to take effect
I:autosign:failed
```
```
echo_i "checking scheduled key activation ($n)"
ret=0
$SETTIME -K ns3 -A now+3s $zsk > settime.out.test$n.zsk || ret=1
$SETTIME -K ns3 -A now+3s $ksk > settime.out.test$n.ksk || ret=1
($RNDCCMD 10.53.0.3 loadkeys delay.example. 2>&1 | sed 's/^/ns2 /' | cat_i) || ret=1
echo_i "waiting for changes to take effect"
sleep 3
wait_for_notifies "delay.example" "ns3" || ret=1
$DIG $DIGOPTS +noall +answer dnskey delay.example. @10.53.0.3 > dig.out.ns3.1.test$n || ret=1
# DNSKEY expected:
awk 'BEGIN {r=1} $4=="DNSKEY" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
$DIG $DIGOPTS +noall +answer a a.delay.example. @10.53.0.3 > dig.out.ns3.2.test$n || ret=1
# A expected:
awk 'BEGIN {r=1} $4=="A" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
n=`expr $n + 1`
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret
```
```
head autosign/*test72*
==> autosign/dig.out.ns3.1.test72 <==
delay.example. 300 IN DNSKEY 256 3 7 AwEAAcpWc1D81h1jDWcL3DuvIgB9cqYNusfcPMyh0/GAypygpJHaOGlV dbPbEbwtgjv9Kj0LYGhswjesQcTjayJAgQfqFeh1QPcq5TpNGUvptybS F+iw3Vnc6QqZZ9uW0H9dcpmWrcSxp3z+FAqfqC+eEgp7jQog9DHcGrqS XKRDLuR/
delay.example. 300 IN DNSKEY 257 3 7 AwEAAc1i4SBAfPGkfKeVCHbhKsZ3zNPAvfWTZUQQ7jXu8APcv4/zFeyr IXs8e1itifPNpbZrOqT0lx/4sEH0eYOKaliWYDJd3A+gIpRhHcUTQQmM mQsSVkk/zXWCnJpTHxtiz8nT2cAwcKrUKdh8rSOfs/MfHjV657qCKgK4 UCWkl/H0vARcnKD0xE261GzKWq3YPu5+XnFOcXC5Bn7aceUjhrCmm7Lc DJBXjdg+t7kKH+AFZoN95qQnCKFnfg72nH4cITZz1Bca/W+PRKuCjsn5 TIkobYSZGlUU+8xgQToIZv7D544SfyOctvGL+J8SXL2zhHIcfKEdrWcy siWZDuMzAVc=
==> autosign/dig.out.ns3.2.test72 <==
a.delay.example. 300 IN A 10.0.0.1
==> autosign/settime.out.test72.ksk <==
ns3/Kdelay.example.+007+64764.key
ns3/Kdelay.example.+007+64764.private
==> autosign/settime.out.test72.zsk <==
ns3/Kdelay.example.+007+07832.key
ns3/Kdelay.example.+007+07832.private
```
```
11-Feb-2020 13:09:24.248 received control channel command 'loadkeys delay.example.'
11-Feb-2020 13:09:27.250 writing to journal
11-Feb-2020 13:09:27.250 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200312130927 20200211120927 7832 delay.example. WGIO8hlCkXJ+3U4yDLsdPI14suvhF/ATYA4ulGVjbwre0TLkXf7cmhf4 VaNGbRiFpYY/r9Lv0GXWjqjUbZET20raH4ngQmHz1lKrHdHqvXEkqZW4 DNIM9StLs1ylke5WNT4nT7SGkWibycBa+CAdcFOix1m4oK/WSbR+ihto zoU=
11-Feb-2020 13:09:27.250 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200312130927 20200211120927 64764 delay.example. vEIGbSFdYF5UNouyrnrGO3peuKkZYNqp1I8qeEsM1Lm5HTNWFPtndp4N 0uPkv1PN3yPqpNL74LuCU5fy8RnziVS+V5ggDzpOi3dio9yb0vh4PJdP 0W0ltY3IJXRmgTjpYxZRlvP2kT3Lozg+bg2gerQAUMY2A3YjKycG/sCl 2Im1dIEi/3o/+PUdgWRYB3UHVizMgpBWo/JEAF2lvEIeV7HQd1f/RnFc hUYaTicKSENkvwxzT/7bcNU3+w69Ot1zk5PYe8Xiwou2MyV3VoVufG2F 2tGxia0QqzHTSJe1mahnowhgGp8zAPTnHRWkd+mH+do66HBgEQdFgEYc SDFIvA==
11-Feb-2020 13:09:28.691 zone_needdump: zone delay.example/IN: enter
11-Feb-2020 13:09:28.692 zone delay.example/IN: sending notifies (serial 2009102724)
11-Feb-2020 13:09:28.694 writing to journal
11-Feb-2020 13:09:28.694 add re-sign a.delay.example. 300 IN RRSIG A 7 3 300 20200228153842 20200211120928 7832 delay.example. vn8NKJWewQk2d6ZyiRpeNb5uvnbRDOoFfY+7d2+IjWdtXAJp40EIItxn GnfQEv1XjsbhbM6NspiSE/p6tI2lz2pu/U/UNwSaOn5iFrhU4qE24Nvs kK3dJWBMF8vGL6U5bwDMwTBdtaQeh2JVUQj9oX2E3vlDOLQNmCPTLt7p bmA=
11-Feb-2020 13:09:29.473 client @0x7f261c1e4d90 10.53.0.1#54783 (delay.example): query 'delay.example/DNSKEY/IN' approved
11-Feb-2020 13:09:29.489 client @0x7f2630f8ddc0 10.53.0.1#59149 (a.delay.example): query 'a.delay.example/A/IN' approved
11-Feb-2020 13:09:31.874 zone_needdump: zone delay.example/IN: enter
11-Feb-2020 13:09:31.903 writing to journal
11-Feb-2020 13:09:31.904 add delay.example. 3600 IN NSEC a.delay.example. NS SOA RRSIG NSEC DNSKEY
11-Feb-2020 13:09:31.909 zone_needdump: zone delay.example/IN: enter
11-Feb-2020 13:09:33.692 zone delay.example/IN: sending notifies (serial 2009102726)
```February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1119add dhcp4 releases to perfdhcp2021-06-22T08:47:19ZWlodzimierz Wenceladd dhcp4 releases to perfdhcpAdd a new feature to perfdhcp to generate dhcpv4 release messages.Add a new feature to perfdhcp to generate dhcpv4 release messages.kea1.9.9Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/stork/-/issues/165Create database model for subnets and shared networks2020-02-27T09:03:20ZMarcin SiodelskiCreate database model for subnets and shared networksWe need to support the model in which the database holds a single instance of a given subnet and multiple servers can be associated with it, e.g. in a load balancing case. We should be able to edit this subnet and then deploy it to the s...We need to support the model in which the database holds a single instance of a given subnet and multiple servers can be associated with it, e.g. in a load balancing case. We should be able to edit this subnet and then deploy it to the selected DHCP servers. As a first step (with this ticket) we should be able to detect the subnets from the Kea servers` configurations and store them in the dedicated tables.0.5Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/164Fix webui unit-tests2020-10-27T14:42:34ZTomek MrugalskiFix webui unit-testsI've tried to run webui unit-tests. Here's what I did:
```
rake build_ui
export CHROME_BIN=chromium
cd webui
npx ng test
```
An example error in the first comment.
We should:
1. investigate why the tests are failing. If they're non-s...I've tried to run webui unit-tests. Here's what I did:
```
rake build_ui
export CHROME_BIN=chromium
cd webui
npx ng test
```
An example error in the first comment.
We should:
1. investigate why the tests are failing. If they're non-sense, mark them as such.
2. extend developer's guide with a description how to run webui tests. A single section or a list of steps will do.
3. look at running those tests as part of CI.
The last step can easily be moved to a separate ticket.0.13Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/163Shared networks need documentation2020-03-06T12:29:54ZTomek MrugalskiShared networks need documentation#151 introduced two views of the shared networks (per app and global). Those should be documented.#151 introduced two views of the shared networks (per app and global). Those should be documented.0.5https://gitlab.isc.org/isc-projects/bind9/-/issues/1613Signal DS submitting via rndc2020-08-31T12:08:46ZMatthijs Mekkingmatthijs@isc.orgSignal DS submitting via rndcWe need a way, via rndc or some other command, to signal that we have submitted the DS.We need a way, via rndc or some other command, to signal that we have submitted the DS.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org