GitLab

Some values returned by dstkey_fromconfig() indicate that key loading
should be interrupted, others do not.  There are also certain subsequent
checks to be made after parsing a key from configuration and the results
of these checks also affect the key loading process.  All of this
complicates the key loading logic.

In order to make the relevant parts of the code easier to follow, reduce
the body of the inner for loop in load_view_keys() to a single call to a
new function, process_key().  Move dstkey_fromconfig() error handling to
process_key() as well and add comments to clearly describe the effects
of various key loading errors.

These tests check if a key with an unsupported algorithm in
managed-keys is ignored and when seeing an algorithm rollover to
an unsupported algorithm, the new key will be ignored too.

The keyfile and key ID for the original managed key do not change
throughout the mkeys system test.  Keep them in helper variables to
prevent calling "cat" multiple times and improve code readability.

Reduce code duplication by replacing a code snippet repeated throughout
system tests using "trusted-keys" and/or "managed-keys" configuration
sections with calls to keyfile_to_{managed,trusted}_keys() helper
functions.

Update tests to not use '>&-' that closes file descriptor, but instead use correct redirection to '>/dev/null'

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

4812.	[bug]		Minor improvements to stability and consistency of code
			handling managed keys. [RT #46468]

4802.	[test]		Refactor mkeys system test to make it quicker and more
			reliable. [RT #45293]

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 560d8b83.

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]

This reverts commit 54d4737b.

                        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]

4065.	[test]		Additional RFC 5011 tests. [RT #38569]

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]