One second may not be enough for an NSEC3 chain change triggered by an
UPDATE message to complete. Wait up to 10 seconds when checking whether
a given NSEC3 chain change is complete in the "nsupdate" system test.
(cherry picked from commit f8746cddbc)
In the "nsupdate" system test, do not sleep before checking results of
changes which are expected to be processed synchronously, i.e. before
nsupdate returns.
(cherry picked from commit 1c8e5ea333)
Make bin/tests/system/ifconfig.bat also configure addresses ending with
9 and 10, so that the script is in sync with its Unix counterpart.
Update comments listing the interfaces created by ifconfig.{bat,sh} so
that they do not include addresses whose last octet is zero (since an
address like 10.53.1.0/24 is not a valid host address and thus the
aforementioned scripts do not even attempt configuring them).
(cherry picked from commit b6c1cdfffe)
On Windows, the bin/tests/system/dnssec/signer/example.db.signed file
contains carriage return characters at the end of each line. Remove
them before passing the aforementioned file to the awk script extracting
key IDs so that the latter can work properly.
(cherry picked from commit e4280ed9f5)
As signals are currently not handled by named on Windows, instances
terminated using signals are not able to perform a clean shutdown, which
involves e.g. removing the lock file. Thus, waiting for a given
instance's lock file to be removed beforing assuming it is shut down
is pointless on Windows, so do not even attempt it.
(cherry picked from commit 761ba4514f)
5213. [bug] win32: Eliminated a race which allowed named.exe running
as a service to be killed prematurely during shutdown.
[GL #978]
(cherry picked from commit e7332343ed)
When a Windows service receives a request to stop, it should not set its
state to SERVICE_STOPPED until it is completely shut down as doing that
allows the operating system to kill that service prematurely, which in
the case of named may e.g. prevent the PID file and/or the lock file
from being cleaned up.
Set service state to SERVICE_STOP_PENDING when named begins its shutdown
and only report the SERVICE_STOPPED state immediately before exiting.
(cherry picked from commit 964749dfdb)
This tests both the cases when the DLV trust anchor is of an
unsupported or disabled algorithm, as well as if the DLV zone
contains a key with an unsupported or disabled algorithm.
(cherry picked from commit 3b7c849a3f)
The following changes were needed:
* Remove dnskey-sig-validity option (added in 9.12)
* Replace rndccmd, dig_with_opts with export variables
* Remove tests for CDNSKEY and CDS (in 9.11 always signed with ZSK)
The option `update-check-ksk` will look if both KSK and ZSK are
available before signing records. It will make sure the keys are
active and available. However, for operational practices keys may
be offline. This commit relaxes the update-check-ksk check and will
mark a key that is offline to be available when adding signature
tasks.
(cherry picked from commit 3cb8c49c73)
(cherry picked from commit b508cffeee3bfb8bc7dcf39db59ec3782a5d9e4c)
This commit adds a lengthy test where the ZSK is rolled but the
KSK is offline (except for when the DNSKEY RRset is changed). The
specific scenario has the `dnskey-kskonly` configuration option set
meaning the DNSKEY RRset should only be signed with the KSK.
A new zone `updatecheck-kskonly.secure` is added to test against,
that can be dynamically updated, and that can be controlled with rndc
to load the DNSSEC keys.
There are some pre-checks for this test to make sure everything is
fine before the ZSK roll, after the new ZSK is published, and after
the old ZSK is deleted. Note there are actually two ZSK rolls in
quick succession.
When the latest added ZSK becomes active and its predecessor becomes
inactive, the KSK is offline. However, the DNSKEY RRset did not
change and it has a good signature that is valid for long enough.
The expected behavior is that the DNSKEY RRset stays signed with
the KSK only (signature does not need to change). However, the
test will fail because after reconfiguring the keys for the zone,
it wants to add re-sign tasks for the new active keys (in sign_apex).
Because the KSK is offline, named determines that the only other
active key, the latest ZSK, will be used to resign the DNSKEY RRset,
in addition to keeping the RRSIG of the KSK.
The question is: Why do we need to resign the DNSKEY RRset
immediately when a new key becomes active? This is not required,
only once the next resign task is triggered the new active key
should replace signatures that are in need of refreshing.
(cherry-picked from commit c48b85d0a3c34480179d44e736e3e535dbae1001)
Add dns_rdata_totext() and dns_rdata_fromtext() to fromwire for
valid inputs to ensure that what we accept in dns_rdata_fromwire()
can be written out and read back in.
(cherry picked from commit 36f30f5731)
Michał Kępień
Mark Andrews
Matthijs Mekking
Ondřej Surý
Ondřej Surý
Evan Hunt