BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-10-05T07:14:03Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3054"External" memory leaks are not detected by GitLab CI2022-10-05T07:14:03ZMichał Kępień"External" memory leaks are not detected by GitLab CIIf `named`'s memory use grows over time, but that growth is reflected in
the "in use" statistics of libisc memory contexts, tracking down the
source of such growth is a matter of time. However, not all memory that
`named` uses is contai...If `named`'s memory use grows over time, but that growth is reflected in
the "in use" statistics of libisc memory contexts, tracking down the
source of such growth is a matter of time. However, not all memory that
`named` uses is contained in libisc memory contexts: every linked shared
library might also perform its own memory allocations. If those are not
cleaned up properly, core dump examination is no good for tracking them
down unless the "needle" (i.e. what we are looking for) is known
beforehand, which is rarely the case.
The most notable example of this type of problem are memory leaks which
are specific to FreeBSD - these are usually caused by the fact that
libthr (the POSIX Threads implementation FreeBSD currently uses)
allocates memory on the heap for most of its objects upon their
creation. If such an object is a part of an often-recycled data
structure used by `named` (e.g. a socket), missing destructors can lead
to memory exhaustion issues over time, but only on specific operating
systems. This has already happened at least twice so far.
Finding a method of detecting "external" memory leaks in GitLab CI
should prevent such problems from reoccurring in the future.
See #3051August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3053named crash after reconfiguration when "allow-recursion" changed2022-04-05T16:02:29ZMichal Nowaknamed crash after reconfiguration when "allow-recursion" changedWith BIND 9.17.20 on Fedora 35 from my [Copr fork](https://copr.fedorainfracloud.org/coprs/mnohime/bind-dev/packages/) I get a reproducible `named` segfault few seconds after I add IP entry to `allow-recursion` list, save `named.conf` (a...With BIND 9.17.20 on Fedora 35 from my [Copr fork](https://copr.fedorainfracloud.org/coprs/mnohime/bind-dev/packages/) I get a reproducible `named` segfault few seconds after I add IP entry to `allow-recursion` list, save `named.conf` (attached), and reconfigure `named` with `rndc reconfig` (if I restart `named` service instead of reconfiguration in the last step, no crash happens).
Also happens with Fedora 34 BIND 9.17.20 packages on Fedora 35 from the official Copr repo (we don't provide official Fedora 35 packages yet).
backtrace:
```
Core was generated by `/opt/isc/isc-bind/root/usr/sbin/named -u named'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:476
476 VMOVU -VEC_SIZE(%rsi, %rdx), %VEC(5)
[Current thread is 1 (Thread 0x7f0479b7f640 (LWP 1360))]
(gdb) bt
#0 __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:476
#1 0x00007f047b342de2 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:29
#2 OPENSSL_sk_dup (sk=0x7f04740138f0) at crypto/stack/stack.c:66
#3 0x00007f047ad25111 in sk_SSL_CIPHER_dup (sk=<optimized out>) at include/openssl/ssl.h:963
#4 SSL_new (ctx=ctx@entry=0x7f04740161a0) at ssl/ssl_lib.c:717
#5 0x00007f047b7d1a23 in isc_tls_create (ctx=0x7f04740161a0) at /usr/src/debug/isc-bind-bind-9.17.20-1.1.fc35.x86_64/lib/isc/tls.c:607
#6 0x00007f047b7df109 in tlslisten_acceptcb (handle=0x7f04789ee280, result=<optimized out>, cbarg=0x7f0478976800) at netmgr/tlsstream.c:595
#7 0x00007f047b7a062e in accept_connection (ssock=ssock@entry=0x7f0478977c00, quota=<optimized out>) at netmgr/tcp.c:1018
#8 0x00007f047b7a137e in tcp_connection_cb (server=<optimized out>, status=<optimized out>) at netmgr/tcp.c:632
#9 0x00007f047b1892f7 in uv__server_io (loop=0x7f047a231010, w=0x7f04789781b8, events=<optimized out>) at src/unix/stream.c:570
#10 0x00007f047b18ed3d in uv__io_poll (loop=0x7f047a231010, timeout=<optimized out>) at src/unix/linux-core.c:462
#11 0x00007f047b17e8e4 in uv_run (loop=loop@entry=0x7f047a231010, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:385
#12 0x00007f047b7a201e in nm_thread (worker0=0x7f047a231000) at netmgr/netmgr.c:688
#13 0x00007f047b7d517a in isc__trampoline_run (arg=0x561a73df6500) at /usr/src/debug/isc-bind-bind-9.17.20-1.1.fc35.x86_64/lib/isc/trampoline.c:185
#14 0x00007f047ae0bad7 in start_thread (arg=<optimized out>) at pthread_create.c:435
#15 0x00007f047ae90770 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
```
[full backtrace](/uploads/f32799c1cd4ec7910ca867060a4cc82b/coredump.txt)
<details><summary>named.conf</summary>
```
tls local-tls {
key-file "/etc/letsencrypt/live/dns.mnowak.cz/privkey.pem";
cert-file "/etc/letsencrypt/live/dns.mnowak.cz/fullchain.pem";
};
options {
directory "/var/opt/isc/scls/isc-bind/named/data";
listen-on port 443 tls local-tls http default { any; };
listen-on-v6 port 443 tls local-tls http default { any; };
listen-on { any; };
listen-on-v6 { any; };
listen-on tls ephemeral { any; };
listen-on-v6 tls ephemeral { any; };
dnssec-validation auto;
recursion yes;
allow-recursion { 2a02:8308:a007:f700::0/64; 86.49/16; localhost; };
querylog yes;
max-cache-size 90%;
};
statistics-channels {
inet * port 666 allow { 2a02:8308:a007:f700::0/64; 86.49/16; localhost; };
};
logging {
channel default_debug {
file "named.run";
print-time yes;
severity dynamic;
};
};
key "rndc-key" {
algorithm hmac-sha256;
secret "5BLhJni/LLWlg8Lo09iTqhvJgvLmViEmcf60b+XX07o=";
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
```
</details>
[core.gz](/uploads/b1e7ef5c910e925f1a8392237f3408ad/core.gz)
[named.gz](/uploads/b1ce3ea46b71e50fa430e4be0838a5a4/named.gz)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/3051Missing destroy(s) for rwlocks, mutexes and conditions2022-01-11T14:13:40ZOndřej SurýMissing destroy(s) for rwlocks, mutexes and conditionsIt was reported to us that there's a runaway memory leak on FreeBSD which was identified as missing dtor for pthread primitives:
1. `sock->cond` in netmgr - the one causing runaway memory use
2. `worker->lock` - one per worker
3. rwlock...It was reported to us that there's a runaway memory leak on FreeBSD which was identified as missing dtor for pthread primitives:
1. `sock->cond` in netmgr - the one causing runaway memory use
2. `worker->lock` - one per worker
3. rwlocks in db.c and dlz.c - initialized once per `named` (fixing would require dtor at library unload, not worth fixing)
4. rwlock in `lib/*/result.c` - initialized once per `named` (fixing would require dtor at library unload, not worth fixing)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3050Post load checking of missing delegations2023-11-02T16:26:08ZMark AndrewsPost load checking of missing delegationsIs it worth while to perform a post load DS lookup for each primary / slave zone against the other loaded zone looking for a NXDOMAIN response which would indicate a missing delegation? This would catch cases like bhutan.gov.bt where b...Is it worth while to perform a post load DS lookup for each primary / slave zone against the other loaded zone looking for a NXDOMAIN response which would indicate a missing delegation? This would catch cases like bhutan.gov.bt where both it and the parent zone are served by the same servers but there isn't a delegation for bhutan.gov.bt in the gov.bt zone.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3049Expired zone signatures are not replaced with KSK signatures2022-01-12T10:08:42ZMatthijs Mekkingmatthijs@isc.orgExpired zone signatures are not replaced with KSK signaturesWe fixed #763 to make sure not to sign the DNSKEY RRset with the ZSK if the KSK was offline (even if the signatures were expired).
The change caused the definition of "having both keys": if one key is offline, we still consider having b...We fixed #763 to make sure not to sign the DNSKEY RRset with the ZSK if the KSK was offline (even if the signatures were expired).
The change caused the definition of "having both keys": if one key is offline, we still consider having both keys, so we don't fallback signing with the ZSK if KSK is offline.
That change also works the other way, if the ZSK is offline, we don't fallback signing with the KSK. But in this case the fallback could actually help preventing the zone from going bogus.
Update the fix for #763 to allow fallback of signing zone RRsets with the KSK in case the ZSK is offline.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3048The hp_max_threads initial value is maximum value2022-01-20T10:21:45ZOndřej SurýThe hp_max_threads initial value is maximum valueIn a011d422117, the `isc_hp_init()` was changed, so the maximum number of threads cannot ever go down, only up. At the same time the initial value of `isc__hp_max_threads` is set to the maximum, so in the end, it's always the maximum (`...In a011d422117, the `isc_hp_init()` was changed, so the maximum number of threads cannot ever go down, only up. At the same time the initial value of `isc__hp_max_threads` is set to the maximum, so in the end, it's always the maximum (`128` threads).
Related issue: #2398January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3047Change reject-000-label default to false in BIND 9.192021-12-08T07:05:44ZMark AndrewsChange reject-000-label default to false in BIND 9.19As per documented road map for reject-000-label.
- [ ] change default
- [ ] update documentation
- [ ] update synthfromdnssec system test
- [ ] update release notes
- [ ] create future issue to remove reject-000-label (9.21.x)As per documented road map for reject-000-label.
- [ ] change default
- [ ] update documentation
- [ ] update synthfromdnssec system test
- [ ] update release notes
- [ ] create future issue to remove reject-000-label (9.21.x)BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3046TCP client not being identified in log message2023-11-02T17:02:21ZMark AndrewsTCP client not being identified in log messageI was trying to match expected log messages in a system test (!5616) and switching from UDP to TCP to force a SERVFAIL rather than timeout response resulted in `<unknown>` for the client being logged instead of IP address and port.
`06-...I was trying to match expected log messages in a system test (!5616) and switching from UDP to TCP to force a SERVFAIL rather than timeout response resulted in `<unknown>` for the client being logged instead of IP address and port.
`06-Dec-2021 16:26:06.430 DNS format error from 10.53.0.8#5300 resolving tcpalso.no-questions/A for <unknown>: empty question section, accepting it anyway as TC=1`
The string I was expecting to match against was
`resolving tcpalso.no-questions/A for 10.53.0.5#[0-9]*: empty question section, accepting it anyway as TC=1`
I haven't checked 9.16 yet.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3045DiG removes underscores from queries2021-12-03T14:35:32ZtriaticDiG removes underscores from queries<!--
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
When performing a dig query on a host with an underscore in it, the underscore is unexpectedly removed.
### BIND version used
DiG 9.17.20-1+ubuntu21.10.1+isc+2-Ubuntu
### Steps to reproduce
```
dig _spf-a.microsoft.com txt
; <<>> DiG 9.17.20-1+ubuntu21.10.1+isc+2-Ubuntu <<>> _spf-a.microsoft.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 981
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;spf-a.microsoft.com. IN TXT
;; AUTHORITY SECTION:
microsoft.com. 167 IN SOA ns1-205.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Dec 03 13:22:46 GMT 2021
;; MSG SIZE rcvd: 122
```
### What is the current *bug* behavior?
DiG removes the underscore from the host prior to the query.
### What is the expected *correct* behavior?
The query should be performed with the underscore still within the host.
nslookup for comparison:
```
nslookup -type=txt _spf-a.microsoft.com
Server: dsldevice.lan
Address: 192.168.1.254
Non-authoritative answer:
_spf-a.microsoft.com text =
"v=spf1 ip4:216.99.5.67 ip4:216.99.5.68 ip4:202.177.148.100 ip4:203.122.32.250 ip4:202.177.148.110 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 ip4:65.55.42.224/28 ip4:13.78.233.182 include:spf.protection.outlook.com ~all"
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3044'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S12021-12-07T11:47:20ZCathy Almond'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S1As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND ...As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND (#1078, #1719), but it is definitely still a problem.
There was one hypothesis that this might be related to DNS64 - however, no sign of DNS64 in this named.conf.
I would like to suggest that it might be due to one (or all) of:
- prefetch (it'd be easy to turn this off to confirm?)
- RPZ (yes, they have all of `nsip-wait-recurse no` and `qname-wait-recurse no` but whether or not additional recursion takes place is determined also by the actual policies in the policy zones themselves)
- Something awry with TCP socket handling?
- Something whacky with the interaction with serve-stale? (Although this is a default config., so `stale-cache-enable yes;`, `stale-answer-enable no;`.
No fetch-limits in this configuration, but if it was purely fetch-limits related, I think we'd have found and fixed it by now.https://gitlab.isc.org/isc-projects/bind9/-/issues/3042TCP dispatch can still hang with non-matching response2022-01-11T14:14:49ZEvan HuntTCP dispatch can still hang with non-matching responseWhile testing a fix for #3040 @michal observed another shutdown hang, which turned out to be a missed case from #3026. A TCP dispatch resumes listening after receiving a response by calling `dispatch_getnext()`, and then the response cal...While testing a fix for #3040 @michal observed another shutdown hang, which turned out to be a missed case from #3026. A TCP dispatch resumes listening after receiving a response by calling `dispatch_getnext()`, and then the response callback sees that the response didn't match the question and calls `dns_dispatch_getnext()`, which uselessly calls `dispatch_getnext()` again, bumping the dispatch reference count.
This can currently be observed with the query:
`dig @localhost -x 74.213.100.99`
The delegation to 74.in-addr.arpa is lame, all servers are responding with REFUSED. This leads to the following being logged:
```
02-Dec-2021 10:45:37.815 received packet from 24.138.252.19#53
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 19192
;; flags: qr; QUESTION: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
02-Dec-2021 10:45:37.815 DNS format error from 24.138.252.19#53 resolving 99.100.213.74.in-addr.arpa/PTR for 127.0.0.1#41988: empty question section
02-Dec-2021 10:45:37.815 fctx 0x7f30ed826000(99.100.213.74.in-addr.arpa/PTR): [result: FORMERR] response did not match question
02-Dec-2021 10:45:37.815 fctx 0x7f30ed826000(99.100.213.74.in-addr.arpa/PTR): [result: FORMERR] query canceled in rctx_done(); responding
```
It looks to me like the best fix is to make `dispatch_getnext()` idempotent.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3041Decide what to do with reject-000 and other obscure options for synth-from-dn...2021-12-23T05:14:57ZPetr Špačekpspacek@isc.orgDecide what to do with reject-000 and other obscure options for synth-from-dnssec featureThe following discussions from !5446 should be addressed:
Should we have obscure options like `reject-000` and company? They were merged into 9.18.0rc1 in interest of time, so now we can discuss calmly with more time.
- [ ] @pspacek st...The following discussions from !5446 should be addressed:
Should we have obscure options like `reject-000` and company? They were merged into 9.18.0rc1 in interest of time, so now we can discuss calmly with more time.
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5446#note_251408): (+17 comments)
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5446#note_251760): (+4 comments)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/3040Removing the fetch context expiry timer uncovered latent bugs2022-01-26T11:33:40ZMichał KępieńRemoving the fetch context expiry timer uncovered latent bugsAfter the dispatch code was reworked to use netmgr, the lifetime expiry
timer for the fetch context was replaced with in-band netmgr timeouts.
Unfortunately, it turned out that the lifetime expiry timer served as a
last-resort measure fo...After the dispatch code was reworked to use netmgr, the lifetime expiry
timer for the fetch context was replaced with in-band netmgr timeouts.
Unfortunately, it turned out that the lifetime expiry timer served as a
last-resort measure for breaking various deadlocks and hangs which could
be triggered in pathological resolution scenarios (#3033 and #3037 are
examples of these).
Now that the fetches are never cleaned up after in some scenarios,
`named` may not respond at all to certain queries and hang on shutdown,
which is not acceptable for a stable release.
Since the bugs uncovered are neither new nor easy to fix, it was decided
that the lifetime expiry timer should be revived until we figure out all
known preexisting glitches in resolver code. The current plan is for
the lifetime expiry timer to be present in BIND 9.18, with the hope of
removing it before the release of BIND 9.20.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/3039update forward logging2024-03-27T13:21:26ZPeter Daviesupdate forward loggingupdate forward logging:
In installations where dynamic updates are forwarded from a secondary server to a stealth master server.
It could be helpful to be able to configure the forwarding server to log the originating source of the u...update forward logging:
In installations where dynamic updates are forwarded from a secondary server to a stealth master server.
It could be helpful to be able to configure the forwarding server to log the originating source of the update and the RRs being updated or enough sufficient to identify the client requesting the update.
[RT #19907](https://support.isc.org/Ticket/Display.html?id=19907 )Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3038refactor peer.c to reduce copy-and-paste needed for new options.2021-12-02T02:05:21ZMark Andrewsrefactor peer.c to reduce copy-and-paste needed for new options.This should reduce copy-paste-replace errors.This should reduce copy-paste-replace errors.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3036clang-format-13 leads to weird layout formatting of function parameters2021-12-01T08:52:54ZMatthijs Mekkingmatthijs@isc.orgclang-format-13 leads to weird layout formatting of function parametersThe following discussion from !5602 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5602#note_251399): (+1 comment)
> Off topic, but is this really the preferr...The following discussion from !5602 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5602#note_251399): (+1 comment)
> Off topic, but is this really the preferred format? Maybe we want to adjust the `clang-format`? @ondrejhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3035BIND with dnssec-policy stops signing when removing the ZSK key files2022-01-06T08:52:05ZThomas AmgartenBIND with dnssec-policy stops signing when removing the ZSK key files### Summary
When removing the ZSK key files from the key-directory and removing also the journal files (.signed.jnl, .jnl, .jbk), then - under certain circumstandes - BIND does create a new ZSK (after restart) but is no more able to sig...### Summary
When removing the ZSK key files from the key-directory and removing also the journal files (.signed.jnl, .jnl, .jbk), then - under certain circumstandes - BIND does create a new ZSK (after restart) but is no more able to sign the RR (neither DNSKEY-RR with the KSK nor TXT-RR with the ZSK).
### BIND version used
9.16.22, self-compiled
### Steps to reproduce
Perhaps this behavior has something to do with "**timings**" or "**timers**", because I needed to wait about one night (for ex. 8h), before I was able to reproduce the issue this morning again.
With this quick-and-dirty helperscript, I can reproduce this issue (after the mentioned timing) always:
```
#!/bin/bash
KEY_ROOT="/chroot/bind/etc/named/keys"
MASTER_DIR="/var/named/master"
[[ $# -lt 1 ]] && { echo -e "specify a zone"; exit 1; }
ZONE=$1
[[ ! -d ${KEY_ROOT}/${ZONE} ]] && { echo -e "key-dir does not exist"; exit 1; }
cd $KEY_ROOT/${ZONE}/
ZSK=$(grep -l "ZSK: yes" * | sed 's,\(.*\)\.state,\1,'g)
echo -e "ZSK found: $ZSK"
systemctl stop named
rm -f $KEY_ROOT/${ZONE}/$ZSK.*
rm -rf $MASTER_DIR/${ZONE}.hosts.*
systemctl start named
```
### What is the current *bug* behavior?
dnssec-policy is no more signing the zone, even if I run "rndc sign example.ch":
```
# No RRSIG for the DNSKEY-RR
$ dig @127.0.0.1 +short +norec +dnssec dnskey example.ch
256 3 13 yzEu6qim1W01nMHAPGhB8nXM2Qb+PTJH0c5+muyy1QjVy4+dldge0Tw6 H0rckR/sNyQOAPzpsChOqqHZhSF32w==
257 3 13 f2m47DhSRftPS7dbCw8u/C2Gnek3XJyf+FpD1gJg1dl2ZXpVVtx7RsJS ML1bq3WHrWz2IRQvW/0rsvB1f3z2WQ==
# Also no RRSIG for the TXT-Record
$ dig @127.0.0.1 +short +norec +dnssec txt example.ch
"v=spf1 -all"
```
#### rndc dnssec -status example.ch
```
$ rndc dnssec -status example.ch
dnssec-policy: thewaytogo-faster
current time: Tue Nov 30 10:09:13 2021
key: 54591 (ECDSAP256SHA256), ZSK
published: yes - since Tue Nov 30 09:59:00 2021
zone signing: no
Next rollover scheduled on Tue Dec 7 07:54:00 2021
- goal: omnipresent
- dnskey: rumoured
- zone rrsig: hidden
key: 56340 (ECDSAP256SHA256), KSK
published: yes - since Mon Nov 29 20:54:22 2021
key signing: yes - since Mon Nov 29 20:54:22 2021
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
```
#### reloading
Reloading the zone shows (in debug-level 3) the following messages:
```
30-Nov-2021 10:05:26.927 general: info: received control channel command 'reload example.ch'
30-Nov-2021 10:05:26.927 zoneload: debug 1: zone example.ch/IN (unsigned): skipping load: master file older than last load
```
#### restarting
##### The key-files are existing (before and after restart)
```
$ ls -lahF
total 340K
drwxr-xr-x. 2 named named 4.0K 30. Nov 09:59 ./
drwxr-xr-x. 7 named named 308K 29. Nov 16:31 ../
-rw-r--r--. 1 named named 443 30. Nov 10:10 Kexample.ch.+013+54591.key
-rw-------. 1 named named 235 30. Nov 10:10 Kexample.ch.+013+54591.private
-rw-r--r--. 1 named named 541 30. Nov 10:10 Kexample.ch.+013+54591.state
-rw-r--r--. 1 named named 388 30. Nov 10:10 Kexample.ch.+013+56340.key
-rw-------. 1 named named 241 30. Nov 10:10 Kexample.ch.+013+56340.private
-rw-r--r--. 1 named named 675 30. Nov 10:10 Kexample.ch.+013+56340.state
```
```
# ZSK
$ cat Kexample.ch.+013+54591.key Kexample.ch.+013+54591.state
; This is a zone-signing key, keyid 54591, for example.ch.
; Created: 20211130085900 (Tue Nov 30 09:59:00 2021)
; Publish: 20211130085900 (Tue Nov 30 09:59:00 2021)
; Activate: 20211130085900 (Tue Nov 30 09:59:00 2021)
; Inactive: 20211207085900 (Tue Dec 7 09:59:00 2021)
; Delete: 20211217100400 (Fri Dec 17 11:04:00 2021)
example.ch. 3600 IN DNSKEY 256 3 13 yzEu6qim1W01nMHAPGhB8nXM2Qb+PTJH0c5+muyy1QjVy4+dldge0Tw6 H0rckR/sNyQOAPzpsChOqqHZhSF32w==
; This is the state of key 54591, for example.ch.
Algorithm: 13
Length: 256
Lifetime: 604800
KSK: no
ZSK: yes
Generated: 20211130085900 (Tue Nov 30 09:59:00 2021)
Published: 20211130085900 (Tue Nov 30 09:59:00 2021)
Active: 20211130085900 (Tue Nov 30 09:59:00 2021)
Retired: 20211207085900 (Tue Dec 7 09:59:00 2021)
Removed: 20211217100400 (Fri Dec 17 11:04:00 2021)
DNSKEYChange: 20211130085900 (Tue Nov 30 09:59:00 2021)
ZRRSIGChange: 20211130085900 (Tue Nov 30 09:59:00 2021)
DNSKEYState: rumoured
ZRRSIGState: hidden
GoalState: omnipresent
# KSK
$ cat Kexample.ch.+013+56340.key Kexample.ch.+013+56340.state
; This is a key-signing key, keyid 56340, for example.ch.
; Created: 20211129195422 (Mon Nov 29 20:54:22 2021)
; Publish: 20211129195422 (Mon Nov 29 20:54:22 2021)
; Activate: 20211129195422 (Mon Nov 29 20:54:22 2021)
; SyncPublish: 20211129195422 (Mon Nov 29 20:54:22 2021)
example.ch. IN DNSKEY 257 3 13 f2m47DhSRftPS7dbCw8u/C2Gnek3XJyf+FpD1gJg1dl2ZXpVVtx7RsJS ML1bq3WHrWz2IRQvW/0rsvB1f3z2WQ==
; This is the state of key 56340, for example.ch.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: no
Generated: 20211129195422 (Mon Nov 29 20:54:22 2021)
Published: 20211129195422 (Mon Nov 29 20:54:22 2021)
Active: 20211129195422 (Mon Nov 29 20:54:22 2021)
DSPublish: 20211129195759 (Mon Nov 29 20:57:59 2021)
DSRemoved: 20211129195739 (Mon Nov 29 20:57:39 2021)
PublishCDS: 20211129195422 (Mon Nov 29 20:54:22 2021)
DNSKEYChange: 20211129205955 (Mon Nov 29 21:59:55 2021)
KRRSIGChange: 20211129205955 (Mon Nov 29 21:59:55 2021)
DSChange: 20211129225759 (Mon Nov 29 23:57:59 2021)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: omnipresent
```
##### Doing the restart shows the following output:
```
30-Nov-2021 10:07:04.657 general: debug 1: zone_dump: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.657 general: debug 1: zone_gotwritehandle: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.659 general: debug 3: zone_shutdown: zone example.ch/IN (signed): shutting down
30-Nov-2021 10:07:04.664 general: debug 3: zone_shutdown: zone example.ch/IN (unsigned): shutting down
30-Nov-2021 10:07:04.664 database: debug 1: calling free_rbtdb(example.ch)
30-Nov-2021 10:07:04.664 database: debug 1: done free_rbtdb(example.ch)
30-Nov-2021 10:07:04.665 general: debug 1: dump_done: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.665 general: debug 1: zone_journal_compact: zone example.ch/IN (signed): target journal size 2358
30-Nov-2021 10:07:04.665 general: debug 3: zone example.ch/IN (signed): dns_journal_compact: success
30-Nov-2021 10:07:04.669 database: debug 1: calling free_rbtdb(example.ch)
30-Nov-2021 10:07:04.669 database: debug 1: done free_rbtdb(example.ch)
30-Nov-2021 10:07:04.743 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.743 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.745 zoneload: debug 1: zone example.ch/IN (unsigned): starting load
30-Nov-2021 10:07:04.745 general: debug 1: zone_startload: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.746 zoneload: debug 2: zone example.ch/IN (unsigned): number of nodes in database: 1
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (unsigned): journal empty
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (unsigned): loaded; checking validity
30-Nov-2021 10:07:04.746 general: debug 1: dns_zone_verifydb: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.746 general: debug 1: zone_settimer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.746 zoneload: info: zone example.ch/IN (unsigned): loaded serial 2021113001
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (signed): starting load
30-Nov-2021 10:07:04.746 general: debug 1: zone_startload: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 zoneload: debug 2: zone example.ch/IN (signed): number of nodes in database: 1
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (signed): journal rollforward completed successfully: up to date
30-Nov-2021 10:07:04.746 zoneload: debug 1: zone example.ch/IN (signed): loaded; checking validity
30-Nov-2021 10:07:04.746 general: debug 1: dns_zone_verifydb: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.746 zoneload: info: zone example.ch/IN (signed): loaded serial 2021113003
30-Nov-2021 10:07:04.758 general: debug 1: dns_zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.758 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.758 general: debug 1: dns_zone_maintenance: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.758 general: debug 1: zone_settimer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.761 general: debug 1: setnsec3param: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.761 general: debug 1: rss_post: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.761 general: debug 1: receive_secure_serial: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.764 general: error: zone example.ch/IN (signed): found no active private keys, unable to generate any signatures
30-Nov-2021 10:07:04.764 general: debug 1: zone_journal: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.769 general: debug 1: zone_needdump: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.769 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.769 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.770 general: debug 1: zone_timer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.770 general: debug 1: zone_maintenance: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.770 general: debug 1: zone_settimer: zone example.ch/IN (unsigned): enter
30-Nov-2021 10:07:04.771 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.771 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.771 notify: info: zone example.ch/IN (signed): sending notifies (serial 2021113004)
30-Nov-2021 10:07:04.771 dnssec: info: zone example.ch/IN (signed): reconfiguring zone keys
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:07:04.777 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) matches policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) is active in policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) (policy thewaytogo-faster) in 2656704072 seconds
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) matches policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) is active in policy thewaytogo-faster
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) (policy thewaytogo-faster) in 596816 seconds
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY in state RUMOURED
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT?
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: dnssec evaluation of ZSK example.ch/ECDSAP256SHA256/54591 record DNSKEY: rule1=(~true or true) rule2=(~true or true) rule3=(~false or false)
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: time says no to ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT (wait 7016 seconds)
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG in state HIDDEN
30-Nov-2021 10:07:04.778 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED?
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: policy says no to ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in stable state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in stable state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DS in state OMNIPRESENT
30-Nov-2021 10:07:04.779 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DS in stable state OMNIPRESENT
30-Nov-2021 10:07:04.780 general: info: CDS for key example.ch/ECDSAP256SHA256/56340 is now published
30-Nov-2021 10:07:04.780 general: info: CDNSKEY for key example.ch/ECDSAP256SHA256/56340 is now published
30-Nov-2021 10:07:04.782 general: debug 1: zone_journal: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.784 general: debug 1: zone_needdump: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.784 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.784 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.785 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.785 dnssec: debug 3: zone example.ch/IN (signed): next key event in 7016 seconds
30-Nov-2021 10:07:04.785 dnssec: info: zone example.ch/IN (signed): next key event: 30-Nov-2021 12:04:00.771
30-Nov-2021 10:07:04.785 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 54591/ECDSAP256SHA256
30-Nov-2021 10:07:04.785 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 56340/ECDSAP256SHA256
30-Nov-2021 10:07:04.785 general: debug 1: zone_sign: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:04.787 dnssec: debug 3: zone example.ch/IN (signed): zone_sign:use kasp -> yes
30-Nov-2021 10:07:04.787 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:09.771 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:09.771 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:07:09.771 notify: info: zone example.ch/IN (signed): sending notifies (serial 2021113005)
30-Nov-2021 10:07:09.771 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
```
#### rndc sign example.ch
```
30-Nov-2021 10:10:56.477 general: info: received control channel command 'sign example.ch'
30-Nov-2021 10:10:56.478 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.478 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.478 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.478 dnssec: info: zone example.ch/IN (signed): reconfiguring zone keys
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: keyring: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/54591 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: dnskeys: example.ch/ECDSAP256SHA256/56340 (policy thewaytogo-faster)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) matches policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) is active in policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/56340 (KSK) (policy thewaytogo-faster) in 2656703840 seconds
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) matches policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) is active in policy thewaytogo-faster
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: new successor needed for DNSKEY example.ch/ECDSAP256SHA256/54591 (ZSK) (policy thewaytogo-faster) in 596584 seconds
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY in state RUMOURED
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT?
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: dnssec evaluation of ZSK example.ch/ECDSAP256SHA256/54591 record DNSKEY: rule1=(~true or true) rule2=(~true or true) rule3=(~false or false)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: time says no to ZSK example.ch/ECDSAP256SHA256/54591 type DNSKEY state RUMOURED to state OMNIPRESENT (wait 6784 seconds)
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: examine ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG in state HIDDEN
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: can we transition ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED?
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: policy says no to ZSK example.ch/ECDSAP256SHA256/54591 type ZRRSIG state HIDDEN to state RUMOURED
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in state OMNIPRESENT
30-Nov-2021 10:10:56.483 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DNSKEY in stable state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type KRRSIG in stable state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: examine KSK example.ch/ECDSAP256SHA256/56340 type DS in state OMNIPRESENT
30-Nov-2021 10:10:56.484 dnssec: debug 1: keymgr: KSK example.ch/ECDSAP256SHA256/56340 type DS in stable state OMNIPRESENT
30-Nov-2021 10:10:56.487 general: warning: zone example.ch/IN (signed): Key example.ch/ECDSAP256SHA256/56340 missing or inactive and has no replacement: retaining signatures.
30-Nov-2021 10:10:56.487 general: debug 1: zone_journal: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_needdump: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.490 dnssec: debug 3: zone example.ch/IN (signed): next key event in 6784 seconds
30-Nov-2021 10:10:56.490 dnssec: info: zone example.ch/IN (signed): next key event: 30-Nov-2021 12:04:00.478
30-Nov-2021 10:10:56.491 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 54591/ECDSAP256SHA256
30-Nov-2021 10:10:56.491 dnssec: debug 3: zone example.ch/IN (signed): zone_rekey done: key 56340/ECDSAP256SHA256
30-Nov-2021 10:10:56.491 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.491 general: debug 1: zone_timer: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.491 general: debug 1: zone_maintenance: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.491 general: debug 1: zone_sign: zone example.ch/IN (signed): enter
30-Nov-2021 10:10:56.493 dnssec: debug 3: zone example.ch/IN (signed): zone_sign:use kasp -> yes
30-Nov-2021 10:10:56.493 general: debug 1: zone_settimer: zone example.ch/IN (signed): enter
```
### What is the expected *correct* behavior?
Signed zone
### Relevant configuration files
```
# zone configuration
zone "example.ch" {
type master;
file "master/example.ch.hosts";
dnssec-policy thewaytogo-faster;
parental-agents { "ch"; };
key-directory "/etc/named/keys/example.ch";
};
```
```
# dnssec-policy
dnssec-policy "thewaytogo-faster" {
// Signatures
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
// Keys
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 30d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 7d algorithm ecdsap256sha256;
};
// Zone properties
zone-propagation-delay 300s;
max-zone-ttl 86400s;
// Parent properties
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
```January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3034UDP dispatch can reuse <srcip, srcport, dstip, dstport>2022-03-01T09:47:10ZOndřej SurýUDP dispatch can reuse <srcip, srcport, dstip, dstport>This could possibly lead to the wrong callback receiving the response and dropping it on the floor because of non-matching QID.This could possibly lead to the wrong callback receiving the response and dropping it on the floor because of non-matching QID.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3032make doc is missing isc-logo.pdf in released archive2022-01-11T14:56:02ZPetr Menšíkmake doc is missing isc-logo.pdf in released archive<!--
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
named 9.17 tarball is missing *doc/arm/isc-logo.pdf*
### BIND version used
```
BIND 9.17.20 (Development Release) <id:642abd5>
running on Linux x86_64 5.13.12-200.fc34.x86_64 #1 SMP Wed Aug 18 13:27:18 UTC 2021
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--with-gssapi=yes' '--with-lmdb=yes' '--with-json-c' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 11.2.1 20210728 (Red Hat 11.2.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1l FIPS 24 Aug 2021
linked to OpenSSL version: OpenSSL 1.1.1l FIPS 24 Aug 2021
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.14
linked to json-c version: 0.14
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
- Extract archive downloaded from pages
- find -name isc-logo.pdf
- ./configure && make && make doc
### What is the current *bug* behavior?
```
...
Making doc in arm
make[2]: Entering directory '/home/pemensik/fedora/bind/bind-9.17.20/build/doc/arm'
SPHINX html-local
SPHINX pdf-local
SPHINX singlehtml
SPHINX epub
Sphinx error:
logo file 'isc-logo.pdf' does not exist
make[2]: *** [Makefile:722: pdf-local] Error 2
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/pemensik/fedora/bind/bind-9.17.20/build/doc/arm'
make[1]: *** [Makefile:442: doc-recursive] Error 1
make[1]: Leaving directory '/home/pemensik/fedora/bind/bind-9.17.20/build/doc'
make: *** [Makefile:614: doc-recursive] Error 1
```
### What is the expected *correct* behavior?
Should pass.
### Relevant configuration files
(none needed)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
Fix release scripts to include isc-logo.pdf, just as in 9.16 branch.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3031Add support for caching parent and child NSEC and RRSIG at the same name2022-06-01T14:34:00ZMark AndrewsAdd support for caching parent and child NSEC and RRSIG at the same nameThis should improve synth-from-dnssec hit rates as we currently only keep the latest one we learn.
rbtdb will also need to become more selective about the covering NSEC returned. If we have a parental NSEC it is not valid for names tha...This should improve synth-from-dnssec hit rates as we currently only keep the latest one we learn.
rbtdb will also need to become more selective about the covering NSEC returned. If we have a parental NSEC it is not valid for names that are subdomains of the NSEC owner.Not planned