Calling nextpart() after reconfiguring ns1 is not safe, because the
expected log message may appear in ns5/named.run before nextpart() is
run. With the TTL for ./DNSKEY set to 20 seconds, ns5 will refresh it
after 10 seconds, by which time wait_for_log() will already have failed.
This results in a false negative.
However, just calling nextpart() before reconfiguring ns1 would
introduce a different problem: if ns5 refreshed ./DNSKEY between these
two steps, the subsequent wait_for_log() call would return immediately
as it would come across the log message about a failure while refreshing
./DNSKEY instead of the expected success. This in turn would result in
a different false negative as the root key would still be uninitialized
by the time "rndc secroots" is called.
Prevent both kinds of false negatives by:
- calling nextpart() before reconfiguring ns1, in order to prevent the
first case described above,
- looking for a more specific log message, in order to prevent the
second case described above.
Also look for a more specific log message in the first part of the
relevant check, not to fix any problem, but just to emphasize that a
different fetch result is expected in that case.
With these tweaks in place, if a (failed) ./DNSKEY refresh is scheduled
between nextpart() and reconfiguring ns1, wait_for_log() will just wait
for two more seconds (one "hour"), at which point another refresh
attempt will be made that will succeed.
- 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
4798. [func] Keys specified in "managed-keys" statements
are tagged as "initializing" until they have been
updated by a key refresh query. If initialization
fails it will be visible from "rndc secroots".
[RT #46267]
This reverts commit 560d8b833e.
This change created a potential race between key refresh queries and
root zone priming queries which could leave the root name servers in
the bad-server cache.
4773. [bug] Keys specified in "managed-keys" statements
can now only be used when validating key refresh
queries during initialization of RFC 5011 key
maintenance. If initialization fails, DNSSEC
validation of normal queries will also fail.
Previously, validation of normal queries could
succeed using the initializing key, potentially
masking problems with managed-keys. [RT #46077]
4750. [func] "rndc managed-keys destroy" shuts down RFC 5011 key
maintenance and deletes the managed-keys database.
If followed by "rndc reconfig" or a server restart,
key maintenance is reinitialized from scratch.
This is primarily intended for testing. [RT #32456]
4594. [func] dnssec-keygen no longer uses RSASHA1 by default;
the signing algorithm must be specified on
the command line with the "-a" option. Signing
scripts that rely on the existing default behavior
will break; use "dnssec-keygen -a RSASHA1" to
repair them. (The goal of this change is to make
it easier to find scripts using RSASHA1 so they
can be changed in the event of that algorithm
being deprecated in the future.) [RT #44755]
4642. [cleanup] Add more logging of RFC 5011 events affecting the
status of managed keys: newly observed keys,
deletion of revoked keys, etc. [RT #45354]
to provide feedback to the trust-anchor administrators
about how key rollovers are progressing as per
draft-ietf-dnsop-edns-key-tag-02. This can be
disabled using 'trust-anchor-telemetry no;'.
[RT #40583]
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]
Evan Hunt
Michał Kępień
Ondřej Surý
Tinderbox User
Mukund Sivaraman
Witold Krecicki
Mark Andrews