Since October 2019 I have had complaints from `dnssec-cds` reporting
that the signatures on some of my test zones had expired. These were
zones signed by BIND 9.15 or 9.17, with a DNSKEY TTL of 24h and
`sig-validity-interval 10 8`.
This is the same setup we have used for our production zones since
2015, which is intended to re-sign the zones every 2 days, keeping
at least 8 days signature validity. The SOA expire interval is 7
days, so even in the presence of zone transfer problems, no-one
should ever see expired signatures. (These timers are a bit too
tight to be completely correct, because I should have increased
the expiry timers when I increased the DNSKEY TTLs from 1h to 24h.
But that should only matter when zone transfers are broken, which
was not the case for the error reports that led to this patch.)
For example, this morning my test zone contained:
dev.dns.cam.ac.uk. 86400 IN RRSIG DNSKEY 13 5 86400 (
20200701221418 20200621213022 ...)
But one of my resolvers had cached:
dev.dns.cam.ac.uk. 21424 IN RRSIG DNSKEY 13 5 86400 (
20200622063022 20200612061136 ...)
This TTL was captured at 20200622105807 so the resolver cached the
RRset 64976 seconds previously (18h02m56s), at 20200621165511
only about 12h before expiry.
The other symptom of this error was incorrect `resign` times in
the output from `rndc zonestatus`.
For example, I have configured a test zone
zone fast.dotat.at {
file "../u/z/fast.dotat.at";
type primary;
auto-dnssec maintain;
sig-validity-interval 500 499;
};
The zone is reset to a minimal zone containing only SOA and NS
records, and when `named` starts it loads and signs the zone. After
that, `rndc zonestatus` reports:
next resign node: fast.dotat.at/NS
next resign time: Fri, 28 May 2021 12:48:47 GMT
The resign time should be within the next 24h, but instead it is
near the signature expiry time, which the RRSIG(NS) says is
20210618074847. (Note 499 hours is a bit more than 20 days.)
May/June 2021 is less than 500 days from now because expiry time
jitter is applied to the NS records.
Using this test I bisected this bug to 09990672d which contained a
mistake leading to the resigning interval always being calculated in
hours, when days are expected.
This bug only occurs for configurations that use the two-argument form
of `sig-validity-interval`.
Resolve "BIND stops DNSKEY lookup in get_dst_key() when a key with unsupported algorithm is found first"
Closes#1689
See merge request isc-projects/bind9!3736
Add a note why we don't have a test case for the issue.
It is tricky to write a good test case for this if our tools are
not allowed to create signatures for unsupported algorithms.
Assign and then check node for NULL to address another thread
changing radix->head in the meantime.
Move 'node != NULL' check into while loop test to silence cppcheck
false positive.
Fix pointer != NULL style.
enough buffer space. Also change named_os_uname() prototype so
that it is now returning (const char *) rather than (char *). If
uname() is not supported on a UNIX build prepopulate unamebuf[]
with "unknown architecture".
The LT_INIT() call in configure.ac is effectively a no-op because it is
preceded by a call to AC_PROG_LIBTOOL(), which is the previous name of
LT_INIT() used in older libtool versions. Replace AC_PROG_LIBTOOL()
with AC_PATH_PROG() to look for libtool in PATH without initializing it,
which is the originally intended behavior.
Without this change, --enable-static is used by default, which causes a
plain ./configure invocation to fail because static linking is now
disallowed. Drop --disable-static from the ./configure invocations used
in GitLab CI to test this scenario continuously.
Linking BIND 9 programs and libraries statically disables several
important features:
* dlopen() - relied on by dynamic loading of modules, dlz, and dyndb,
* RELRO (read-only relocations) and ASLR (address space layout
randomization) - security features which are important for any
program interacting with the network and/or user input.
Disable and disallow linking BIND 9 binaries statically, thus enforcing
dlopen() support and allowing use of RELRO and ASLR by default.
The `rndc` argument was always overridden by the static configuration,
because the logic for handling the number of dnstap files to retain
was both backwards and a bit redundant.
When maintainer mode is enabled (./configure --enable-maintainer-mode)
it enables rebuild of documentation source files that require extra
tools to be installed or compiled. For a convenience, those files are
already committed into the repository and their rebuild is not required
to build BIND 9 from sources.
Similarly, the manpage sources will get rebuild only when in maintainer
mode because they require sphinx-build to be available locally and that
might not be always the case.
The files in doc/misc requires all the BIND 9 libraries to be built
before the documentation can be built. One of the extra automake
features is maintainer mode that allows to conditionally build and clean
files that require special tools. Make use of the automake maintainer
mode to not rebuild the files in doc/misc under normal circumstances.
if tests that take a particularly long time to complete
(serve-stale, dnssec, rpzrecurse) are run first, a parallel
run of the system tests can finish 1-2 minutes faster.
The doc/misc/options is used to generate a file describing all
configuration options. Currently, the file contents could differ
based on ./configure option which is kind of suboptimal.
We already removed the "// not configured" from the options.active, and
this time we remove generation of the string altogether.
these keywords were added to the parser as synonyms for "master"
and "slave" but were never hooked in to the configuration of named,
so they were ignored. this has been fixed and the option is now
checked for correctness.
The isc_nm_cancelread() function cancels reading on a connected
socket and calls its read callback function with a 'result'
parameter of ISC_R_CANCELED.
when isc_nm_destroy() is called, there's a loop that waits for
other references to be detached, pausing and unpausing the netmgr
to ensure that all the workers' events are run, followed by a
1-second sleep. this caused a delay on shutdown which will be
noticeable when netmgr is used in tools other than named itself,
so the delay has now been reduced to a hundredth of a second.