The draft says that the NSEC(3) TTL must have the same TTL value
as the minimum of the SOA MINIMUM field and the SOA TTL. This was
always the intended behaviour.
Update the zone structure to also track the SOA TTL. Whenever we
use the MINIMUM value to determine the NSEC(3) TTL, use the minimum
of MINIMUM and SOA TTL instead.
There is no specific test for this, however two tests need adjusting
because otherwise they failed: They were testing for NSEC3 records
including the TTL. Update these checks to use 600 (the SOA TTL),
rather than 3600 (the SOA MINIMUM).
(cherry picked from commit 9af8caa733)
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)
Check that resign interval is actually in days rather than hours
by checking that RRSIGs are all within the allowed day range.
(cherry picked from commit 11ecf7901b)
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.
(cherry picked from commit c6345fffe9)
as the update triggers by the rndc command to clear the signing records
may not have completed by the time the subsequent rndc command to test
that the records have been removed is commenced. Loop several times to
prevent false negative.
(cherry picked from commit 353018c0e5)
There is a failure mode which gets triggered on heavily loaded
systems. A key change is scheduled in 5 seconds to make ZSK2 inactive
and ZSK3 active, but `named` takes more than 5 seconds to progress
from `rndc loadkeys` to the query check. At this time the SOA RRset
is already signed by the new ZSK which is not expected to be active
at that point yet.
Split up the checks to test the case where RRsets are signed
correctly with the offline KSK (maintained the signature) and
the active ZSK. First run, RRsets should be signed with the still
active ZSK2, second run RRsets should be signed with the new active
ZSK3.
(cherry picked from commit aebb2aaa0f)
the internal keytable structure has not yet been changed, but
insertion of DS anchors is the only method now available.
NOTE: the keytable unit test is currently failing because of tests
that expect individual keynode objects to contain single DST key
objects.
Before this change, there was a missing blank line between the
negative trust anchors for one view, and the heading line for the next
view. This is because dns_ntatable_totext() omits the last newline.
There is an example of the incorrect output below; the fixed output
has a blank line before "Start view auth".
secure roots as of 21-Oct-2019 12:03:23.500:
Start view rec
Secure roots:
./RSASHA256/20326 ; managed
Negative trust anchors:
example.com: expiry 21-Oct-2019 13:03:15.000
Start view auth
Secure roots:
./RSASHA256/20326 ; managed
Negative trust anchors:
example.com: expiry 21-Oct-2019 13:03:07.000
When trying to extract the key ID from a key file name, some test code
incorrectly attempts to strip all leading zeros. This breaks tests when
keys with ID 0 are generated. Add a new helper shell function,
keyfile_to_key_id(), which properly handles keys with ID 0 and use it in
test code whenever a key ID needs to be extracted from a key file name.
- trusted-keys is now flagged as deprecated, but still works
- managed-keys can be used to configure permanent trust anchors by
using the "static-key" keyword in place of "initial-key"
- parser now uses an enum for static-key and initial-key keywords
If named is configured to perform DNSSEC validation and also forwards
all queries ("forward only;") to validating resolvers, negative trust
anchors do not work properly because the CD bit is not set in queries
sent to the forwarders. As a result, instead of retrieving bogus DNSSEC
material and making validation decisions based on its configuration,
named is only receiving SERVFAIL responses to queries for bogus data.
Fix by ensuring the CD bit is always set in queries sent to forwarders
if the query name is covered by an NTA.
This affects two cases:
* When writing a `dsset` file for this zone, to be used by its
parent, only write a SHA-256 DS record.
* When reading a `keyset` file for a child, to generate DS records
to include in this zone, generate SHA-256 DS records only.
This change does not affect digests used in CDS records.
This is for conformance with the DS/CDS algorithm requirements in
https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update
This makes the `-12a` options to `dnssec-dsfromkey` work more like
`dnssec-cds`, in that you can specify more than one digest and you
will get multiple records. (Previously you could only get one
non-default digest type at a time.)
The default is now `-2`. You can get the old behaviour with `-12`.
Tests and tools that use `dnssec-dsfromkey` have been updated to use
`-12` where necessary.
This is for conformance with the DS/CDS algorithm requirements in
https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update
Key IDs may accidentally match dig output that is not the key ID (for
example the RRSIG inception or expiration time, the query ID, ...).
Search for key ID + signer name should prevent that, as that is what
only should occur in the RRSIG record, and signer name always follows
the key ID.
Remove sleep calls from test, rely on wait_for_log(). Make
wait_for_log() and dnssec_loadkeys_on() fail the test if the
appropriate log line is not found.
Slightly adjust the echo_i() lines to print only the key ID (not the
key name).
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.
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.
Simply looking for the key ID surrounded by spaces in the tested
dnssec-signzone output file is not a precise enough method of checking
for signatures prepared using a given key ID: it can be tripped up by
cross-algorithm key ID collisions and certain low key IDs (e.g. 60, the
TTL specified in bin/tests/system/dnssec/signer/example.db.in), which
triggers false positives for the "dnssec" system test. Make key ID
extraction precise by using an awk script which operates on specific
fields.
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.
For checks querying a named instance with "dnssec-accept-expired yes;"
set, authoritative responses have a TTL of 300 seconds. Assuming empty
resolver cache, TTLs of RRsets in the ANSWER section of the first
response to a given query will always match their authoritative
counterparts. Also note that for a DNSSEC-validating named resolver,
validated RRsets replace any existing non-validated RRsets with the same
owner name and type, e.g. cached from responses received while resolving
CD=1 queries. Since TTL capping happens before a validated RRset is
inserted into the cache and RRSIG expiry time does not impose an upper
TTL bound when "dnssec-accept-expired yes;" is set and, as pointed out
above, the original TTLs of the relevant RRsets equal 300 seconds, the
RRsets in the ANSWER section of the responses to expiring.example/SOA
and expired.example/SOA queries sent with CD=0 should always be exactly
120 seconds, never a lower value. Make the relevant TTL checks stricter
to reflect that.
Always expecting a TTL of exactly 300 seconds for RRsets found in the
ADDITIONAL section of responses received for CD=1 queries sent during
TTL capping checks is too strict since these responses will contain
records cached from multiple DNS messages received during the resolution
process.
In responses to queries sent with CD=1, ns.expiring.example/A in the
ADDITIONAL section will come from a delegation returned by ns2 while the
ANSWER section will come from an authoritative answer returned by ns3.
If the queries to ns2 and ns3 happen at different Unix timestamps,
RRsets cached from the older response will have a different TTL by the
time they are returned to dig, triggering a false positive.
Allow a safety margin of 60 seconds for checks inspecting the ADDITIONAL
section of responses to queries sent with CD=1 to fix the issue. A
safety margin this large is likely overkill, but it is used nevertheless
for consistency with similar safety margins used in other TTL capping
checks.
Commit c032c54dda inadvertently changed
the DNS message section inspected by one of the TTL capping checks from
ADDITIONAL to ANSWER, introducing a discrepancy between that check's
description and its actual meaning. Revert to inspecting the ADDITIONAL
section in the aforementioned check.
Changes introduced by commit 6b8e4d6e69
were incomplete as not all time-sensitive checks were updated to match
revised "nta-lifetime" and "nta-recheck" values. Prevent rare false
positives by updating all NTA-related checks so that they work reliably
with "nta-lifetime 12s;" and "nta-recheck 9s;". Update comments as well
to prevent confusion.
