ans10 simulates a local anycast server which has both signed and
unsigned instances of a zone. 'A' queries get answered from the
signed instance. Everything else gets answered from the unsigned
instance. The resulting answer should be insecure.
(cherry picked from commit d7840f4b93)
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.
More specifically: ignore configured trusted and managed keys that
match a disabled algorithm. The behavioral change is that
associated responses no longer SERVFAIL, but return insecure.
- all tests with "recursion yes" now also specify "dnssec-validation yes",
and all tests with "recursion no" also specify "dnssec-validation no".
this must be maintained in all new tests, or else validation will fail
when we use local root zones for testing.
- clean.sh has been modified where necessary to remove managed-keys.bind
and viewname.mkeys files.
- added tests to the dnssec system test that duplicate the ones
from bin/tests/dnssec-signzone
- changed cleanall.sh so it doesn't automatically remove all
key files, because there are now some of those that are part of the
distribution
- add CHANGES note
- update copyrights and license headers
- add -j to the make commands in .gitlab-ci.yml to take
advantage of parallelization in the gitlab CI process
4721. [func] 'dnssec-signzone -x' and 'dnssec-dnskey-kskonly'
options now apply to CDNSKEY and DS records as well
as DNSKEY. Thanks to Tony Finch. [RT #45689]
4056. [bug] Expanded automatic testing of trust anchor
management and fixed several small bugs including
a memory leak and a possible loss of key state
information. [RT #38458]
4055. [func] "rndc managed-keys" can be used to check status
of trust anchors or to force keys to be refreshed,
Also, the managed keys data file has easier-to-read
comments. [RT #38458]
4034. [func] When added, negative trust anchors (NTA) are now
saved to files (viewname.nta), in order to
persist across restarts of the named server.
[RT #37087]
Conflicts:
bin/tests/system/conf.sh.in
lib/dns/win32/libdns.def.in
lib/isc/win32/file.c
The merge also needed to update files in legacy and tcp system tests
(newly introduced in master after branch was created) to introduce use
of lockfile.
