If the primary has been updated, but the secondary has not been
notified, the journal will go out of date. An 'rndc retransfer' causes
the zone to force an AXFR, removing and rebuilding zone and journal
files.
This test reproduces a bug that in such scenario, an NSEC3 signed zone
falls back to NSEC.
The "no root hints for view X" message must not be shown for the default
_bind/CH view. However, it is shown since 27c4f68dcc (part of effective
configuration changes).
The reason is that since 27c4f68dcc, `configure_views()` now processes
a single list of views, which contains both builtin and user views as
they are both part of the effective configuration. Those changes omitted
the `need_hints` bool that disabled the warning for the builtin view.
This commit silences the log message again.
now that the EDNS state is stored within dns_message_t, it's no longer
necessary to have a public API call to build an opt rdataset; we can
just have dns_message_setopt() build the opt record internally.
The new dns_message_ednsinit() and dns_message_ednsaddopt() functions
allow EDNS options to be added to a message one at a time; it is no
longer necessary to construct a full array of EDNS options and set
them all at once.
This allows us to simplify EDNS option handling code, and in the
future it wlil allow plugins to add EDNS options to existing
messages.
To check if the key managing for a zone is done, we check a log message.
On some machines, with many zones this may take some time.
Increate the timeout to a minute. Note that most zones will continue
their test case much faster, but with many zones there may be some
straggling.
When all zones are configured, regardless of whether the test module
actually uses them, it makes debugging the logs needlessly more
complicated, as there is a bunch of stuff going on that is completely
unrelated to the test.
Define a list of tested zones in each test module and only render the
named.conf with those zones defined.
This converts two test cases:
1. A zone that previously failed to load is now fixed. Make sure the
zone is signed correctly with the right NSEC3 parameters.
2. Test case to ensure the salt is the same after a restart, i.e. no
re-salting takes place. Previously we only tested with salt length
0, this commit adds a test case for salt length 8 as well.
This converts the nsec3 system test cases after to reconfiguring the
name server.
Two extra test for nsec3-change.kasp is updated. It depends on the
zone being updated, and a reconfig. This test code is moved to
tests_nsec3_reconfig.py.
Furthermore, an additional 'rndc signing -nsec3param' error test
case has been added.
Change the named.conf templating to make use of jinja template
rendering. The ns2 server is trivial. The ns3 server configuration
structure has changed:
The common configuration is moved out of named-fips.conf.
The main named.conf file is in named.conf.j2. It always includes the
common part, named-common.conf.j2, and the FIPS part,
named-fips.conf.j2.
The named-fips.conf.j2 and named-rsasha1.conf.j2 templates are
rendered differently depending on the reconfiged status. Mainly the
dnssec-policy for zones are different after reconfiguration, but there
are some other changes to, for example some zones change their
inline-signing setting.
Some zones only exist prior or after the configuration.
Finally, this is a bit hackish: If RSASHA1 is supported, named.conf
includes "named-rsasha1.conf", otherwise it includes the deliberately
empty "named-rsasha0.conf".
This converts all the nsec3 system test cases prior to reconfiguring the
name server. There are two main classes, one that tests the zone is
correctly signed with NSEC, the other with NSEC3.
Two extra tests for nsec3-dynamic-update-inline.kasp and
nsec3-change.kasp are also rewritten. For the former, we need to
change the 'nsupdate' definition to be able to set the expected RCODE.
when merging view objects into the effective configuration, add
allow-query-cache, allow-recursion, allow-query-cache-on and
allow-recursion-on ACLs as needed to reflect the way those
options inherit from each other.
this means the effective configuration is now correct for each
view. ACLs no longer need to be corrected when applying the
configuration, and the actual effective ACL values will be
displayed in "rndc showconf" and "named-checkconf -pe".
the merging of options and defaults into the effective configuration
broke the mutual inheritance of the allow-recursion, allow-query, and
allow-query-cache ACLs, and of the allow-recursion-on and
allow-query-cache-on ACLs.
this has been corrected by adding a 'cloned' flag to the cfg_obj
structure to indicate whether it was configured explicitly or
cloned from the defaults during parsing. we can then adjust the
ACLs while configuring a view, favoring user-configured values
when they're available over cloned defaults.
currently the adjustments to the ACLs are done in configure_view();
later they'll be moved into the effective configuration and this
special handling can be removed.
allow-recursion is set to "none" in the options block and to
"any" in the view. allow-query-cache in the view should inherit
the "any", not the "none". (currently this test does not pass.)
The dns_resolver mode of operation is to resolve all the domains as it
iterates the DNS tree to fill up the cache as quickly as possible.
This commit reduces the number of outgoing queries by reducing the
number of remote fetches started for the nameserver addresses resolution
via dns_adb_createfind() to a smaller number per depth of the recursion
since the delegation point (3 2 1 0) - where 0 means only create fetch
on demand if we don't have any addresses yet.
Because the asynchronous loading logic expected all jobs to be scheduled
then to be run (because it used to be scheduled during the exclusive
mode) and because all jobs are scheduled on various threads, there were
random situations where load_zones() would return after the scheduled
DB zone loading actually ran. In such cases, the zl->refs ref counter
in view_loaded() wouldn't go down to 0 and the remaining task to do
once all zones were loaded was never called. In particular,
server->reload_status kept the NAMED_RELOAD_PENDING state.
This problem is fixed by handling zoneload_t as a ref-counted object,
shared between load_zones() and each instance of scheduled zone DB
loading. Its destructor function is actually the content of
view_loaded() in the case the zt->refs went to 0. This ensures a
correct post-loading routine to be called once the last load is done.
The configloading system script attempts multiple `rndc
{reconfig,reload}` commands without ensuring the system left
exclusive mode; which normally raise an RNDC error as the server is
currently reloading already. This used to work because the request was
enqueued while the server was in exclusive mode, and was processed
after the server `reload_status` was reset to `NAMED_RELOAD_DONE`.
Due to the fact the exclusive mode is not retaken after
`apply_configuration()` by `load_zones()`, the scheduling of
pending tasks is changed and, regularly, the RNDC command sent by the
test is processed before `NAMED_RELOAD_DONE` is set. This is the same
kind of issue the views system tests had, solved by
`4b2dcb3128fbd5af4609a5a73aeeee1f93bde237`
Fix the problem by waiting for a log line matching the end of
the reloading phase.
The `reload_status` is set to `NAMED_RELOAD_FAILED` after the log line is
printed about this change. Update `reload_status` first, to avoid
(unlikely) case where a test waiting for this log line would attempt a
RNDC reload query but it would be processed by `named` before the status
is updated.
Remove the exclusive mode when scheduling the zone load right after
(re)loading `named` configuration, as there is no reason anymore to
schedule zone loading while the exclusive lock is held. Data which can
be read or written by multiple threads are locked or atomic.
The prefetch statement now enforces its bounds. The configuration
(including `named-checkconf`) now fails if the trigger (first value) is
above 10, or if the eligibility (second optional value) isn't at least
six seconds more than the trigger value.
Catalog-zones can't be used in view which are not from the IN class.
This is now enforced as the server won't load (instead of loading
without the catalog-zone). This configuration error is now also caught
by `named-checkconf`.
The `configure_view()` `need_hints` is removed as it this function was
always called with the value `true`.
The `need_hints` wasn't even used in the function. The only thing it was
actually used was to throw a warning which can be done simply in an
`else` condition branch.
Moreoever, in the case of catalog zones and response-policy, it fixes a
possible bug that would affect root zones, as those wouldn't be reverted
back to their previous version in case of the view fails to load
(during a server reconfiguration).
Do not save the textual version of the effective configuration when
`allow-new-zones` is enabled, as it can be printed on-demand. This
enable to reduce the memory footprint of ~70MB on huge configurations
(1M zones).
the effective configuration tree is now detached if allow-new-zones
or catalog-zones aren't enabled in any views. this reduces memory
consumption while still allowing "rndc showconf -effective" to work.
as previously mentioned in commit c65b2868ab, a cfg_obj_t
configuration tree structure takes up considerably more space than
the canonical text. since the zone configuration saved in the zone
object using dns_zone_setcfg() is only currently used for "rndc
showzone", it can be saved as text more efficiently than as an
object tree. (and, if a tree were needed, the text could be
re-parsed quickly; zone configuration text is generally small.)
The `display_rrcomments` is a tri-state (-1, 0, 1) which is (in some
cases) initialized with `state`, a boolean, through an implicit cast.
This was spot by Coccinelle. Remove the implcit cast by explicitly
assigning 0 or 1 to `display_rrcomments` based on `state` value.
Previously, hasattr("extended_errors") was used as a check to detect a
mimumum required dnspython version in order to only perform the EDE
check if a new-enough dnspython was present. This is now abstracted into
isctest.check.ede().
In order to support dnspython<2.2.0, use isctest.compat.EDECode rather
than using dns.edns.EDECode directly.
Add a utility function to check for EDE options present in the DNS
message. The primary benefit of this helper function is that it
handles the compatibility issues with different dnspython versions
and the actual test code doesn't have to deal with that any more.
Rather than using the convenience .extended_errors() method
introduced in dnspython 2.7.0, iterate over the options and find
EDEOption types, which is supported from 2.2.0 onwards.
To work around the issue of using dns.edns.EDECode to specify EDE codes
in our tests, create an isctest.compat.EDECode wrapper. This can be used
even with dnspython versions prior to 2.2.0 and will simply result in
no-op, since EDE isn't supported in the older dnspython anyway.
A part of the `views` system test attempts to add multiples zones in a
loop, and after each zone being added, reconfig the server.
However, the test didn't take into account the fact that the server
might take a bit more time to reload than the script to move to the next
iteration, and in some case the test was re-requesting the server reload
when it was still reloading.
Since `b49f83a3`, `named` explicitly fails to reload when a load/reload
is pending, which is (unless proved otherwise) the reason of the test
was now randomly failing.
That part of the test is now waiting for the server log message saying
the server has added the new zone and is running. Also, that part of the
test has been rewrote in Python.
Because ede24 system tests require stopping/restarting server, there is
always the risk that the test ends (with a failure) with server in an
wrong and impredictible state. This would make the other tests to fail
in a strange way as well.
To avoid this problem, split the test into different modules, so if a
module fails, the other module is not impacted as it uses separate
server instances.
There was a random failure of ede24 system test. While this is still a
bit speculative, the two reasons were:
- in the case of `test_ede24_noloaded` the test might attempt to early
(before the zone actually transfered on the secondary server) to query
ns2.
- still in the case of `test_ede24_noloaded`, even after waiting for
transfer succeed logs, if the CI machine is slow, the zone could be
expired before the request checking the secondary zone works because
the expiration time of the zone was very short (1s). Moving this
expiration time to 3 seconds should be enough (while not making the
test execution too much longer when waiting for the zone expiration).
- in the case of `test_ede24_expired`, the zone expired flag is flipped
and the log message is printed immediately after. However, it is
possible that because the flag is set using a relaxed atomic
operation, another thread process the query and gets the previous
(non-expired) value of the flag. In order to workaround this, the
test now also expects another log written after the zone expiration
(stop timers) on the next UV tick.
Maintaining compatibility with pre-2.0.0 dnspython became cumbersome
leading to failure in nightly CI jobs which are the only ones that run
with dnspython this old.
Abort all AsyncServer instances when running with old dnspython. Add an
importor skip for all system tests using isctest.asyncserver.
They can be used outside of test modules (like ans.py custom servers)
which leads to pytest.outcomes.Skipped being raised in weird places and
skipping of tests which don't need dnspython this new.
Remove pytest.importskip from top scope in isctest.name, only run the
check when ZoneAnalyzer is used.
`named-checkconf` now supports the command line switch `-b`, which
prints the default built-in configuration used by `named`.
When `-b` is in use, other options are ignored.
Check that dig doesn't exit with an assertion failure when a IPv4
source address is defined after defining a server address which has
both IPv4 and IPv6 addresses (in this case, @localhost).
Previously, if there's no more server to try in force_next,
it attempted to retry the current server similar to a query
timeout case. But, force_next() is called only when the
current server's address is unusable and the query was not
even sent, so recvcount was not incremented, causing an
assertion failure.
We might be able to fix it so the retry doesn't cause a crash,
but it doesn't make sense to retry the server when its address
is known to be unusable. So, simply avoiding the retry would be
the easiest and safest way to prevent the crash.
Without this, start_udp or start_tcp would trigger an assertion
failure. Detaching it at this point is also consistent with
other failure handling cases, such as in recv_done.
Add system test covering EDE 24 being added in the response in both
common cases: when the server has not loaded the DB of a zone and when
the zone has expired (secondary).
The built-in configuration is actually used in two cases: first, when
the server is loaded (or reloaded), and second when
'rndc showconf -builtin' is called.
Considering the parsing of the builtin configuration is quick and does
not occur during exclusive mode, but the configuration tree takes
considerable memory space, the built-in configuration is no longer kept
in memory once it has been used; instead it is re-parsed on demand.
