In the "allow-query" system test, ns3 uses a root hints file which
contains a single entry for a.root-servers.nil (10.53.0.1). This name
is not present in the root zone served by ns1, which means querying it
for that name and any type will yield an NXDOMAIN response. When
combined with unfavorable thread scheduling, this can lead to ns3
caching an NXDOMAIN response for the only root server it is aware of and
thus to false positives for the "allow-query" system test caused by ns3
returning unexpected SERVFAIL responses. Fix by modifying the root zone
served by ns1 so that authoritative responses to a.root-servers.nil
queries match the root hints file used by ns3.
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).
One second may not be enough for an NSEC3 chain change triggered by an
UPDATE message to complete. Wait up to 10 seconds when checking whether
a given NSEC3 chain change is complete in the "nsupdate" system test.
In the "nsupdate" system test, do not sleep before checking results of
changes which are expected to be processed synchronously, i.e. before
nsupdate returns.
Make bin/tests/system/ifconfig.bat also configure addresses ending with
9 and 10, so that the script is in sync with its Unix counterpart.
Update comments listing the interfaces created by ifconfig.{bat,sh} so
that they do not include addresses whose last octet is zero (since an
address like 10.53.1.0/24 is not a valid host address and thus the
aforementioned scripts do not even attempt configuring them).
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.
As signals are currently not handled by named on Windows, instances
terminated using signals are not able to perform a clean shutdown, which
involves e.g. removing the lock file. Thus, waiting for a given
instance's lock file to be removed beforing assuming it is shut down
is pointless on Windows, so do not even attempt it.
When a Windows service receives a request to stop, it should not set its
state to SERVICE_STOPPED until it is completely shut down as doing that
allows the operating system to kill that service prematurely, which in
the case of named may e.g. prevent the PID file and/or the lock file
from being cleaned up.
Set service state to SERVICE_STOP_PENDING when named begins its shutdown
and only report the SERVICE_STOPPED state immediately before exiting.
this restores functionality that was removed in commit 03be5a6b4e,
allowing named to search in authoritative zone databases outside the
current zone for additional data, if and only if recursion is allowed
and minimal-responses is disabled.
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.
Some system tests assume dig's default setings are in effect. While
these defaults may only be silently overridden (because of specific
options set in /etc/resolv.conf) for BIND releases using liblwres for
parsing /etc/resolv.conf (i.e. BIND 9.11 and older), it is arguably
prudent to make sure that tests relying on specific +timeout and +tries
settings specify these explicitly in their dig invocations, in order to
prevent test failures from being triggered by any potential changes to
current defaults.
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.
The "mirror" system test expects all dig queries (including recursive
ones) to be responded to within 1 second, which turns out to be overly
optimistic in certain cases and leads to false positives being
triggered. Increase dig query timeout used throughout the "mirror"
system test to 2 seconds in order to alleviate the issue.
Currently, ns3 in the "mirror" system test sends trust anchor telemetry
queries every second as it is started with "-T tat=1". Given the number
of trust anchors configured on ns3 (9), TAT-related traffic clutters up
log files, hindering troubleshooting efforts. Increase TAT query
interval to 3 seconds in order to alleviate the issue.
Note that the interval chosen cannot be much higher if intermittent test
failures are to be avoided: TAT queries are only sent after the
configured number of seconds passes since resolver startup. Quick
experiments show that even on contemporary hardware, ns3 should be
running for at least 5 seconds before it is first shut down, so a
3-second TAT query interval seems to be a reasonable, future-proof
compromise. Ensure the relevant check is performed before ns3 is first
shut down to emphasize this trade-off and make it more clear by what
time TAT queries are expected to be sent.
"rndc dumpdb" works asynchronously, i.e. the requested dump may not yet
be fully written to disk by the time "rndc" returns. Prevent false
positives for the "serve-stale" system test by only checking dump
contents after the line indicating that it is complete is written.
This tests both the cases when the DLV trust anchor is of an
unsupported or disabled algorithm, as well as if the DLV zone
contains a key with an unsupported or disabled algorithm.
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.
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.
bin/tests/system/stop.pl only waits for the PID file to be cleaned up
while named cleans up the lock file after the PID file. Thus, the
aforementioned script may consider a named instance to be fully shut
down when in fact it is not.
Fix by also checking whether the lock file exists when determining a
given instance's shutdown status. This change assumes that if a named
instance uses a lock file, it is called "named.lock".
Also rename clean_pid_file() to pid_file_exists(), so that it is called
more appropriately (it does not clean up the PID file itself, it only
returns the server's identifier if its PID file is not yet cleaned up).
MR !1141 broke the way stop.pl is invoked when start.pl fails:
- start.pl changes the working directory to $testdir/$server before
attempting to start $server,
- commit 27ee629e6b causes the $testdir
variable in stop.pl to be determined using the $SYSTEMTESTTOP
environment variable, which is set to ".." by all tests.sh scripts,
- commit e227815af5 makes start.pl pass
$test (the test's name) rather than $testdir (the path to the test's
directory) to stop.pl when a given server fails to start.
Thus, when a server is restarted from within a tests.sh script and such
a restart fails, stop.pl attempts to look for the server directory in a
nonexistent location ($testdir/$server/../$test, i.e. $testdir/$test,
instead of $testdir/../$test). Fix the issue by changing the working
directory before stop.pl is invoked in the scenario described above.
Remove another remnant of shared secret HMAC-MD5 support.
Explain that with currently recommended setups DNSKEY records are
inserted automatically, but you can still use $INCLUDE in other cases.
On Unix systems, the CYGWIN environment variable is not set at all when
BIND system tests are run. If a named instance crashes on shutdown or
otherwise fails to clean up its pidfile and the CYGWIN environment
variable is not set, stop.pl will print an uninitialized value warning
on standard error. Prevent this by using defined().
ifconfig.sh depends on config.guess for platform guessing. It uses it to
choose between ifconfig or ip tools to configure interfaces. If
system-wide automake script is installed and local was not found, use
platform guess. It should work well on mostly any sane platform. Still
prefers local guess, but passes when if cannot find it.
When a zone is converted from NSEC to NSEC3, the private record at zone
apex indicating that NSEC3 chain creation is in progress may be removed
during a different (later) zone_nsec3chain() call than the one which
adds the NSEC3PARAM record. The "delzsk.example" zone check only waits
for the NSEC3PARAM record to start appearing in dig output while private
records at zone apex directly affect "rndc signing -list" output. This
may trigger false positives for the "autosign" system test as the output
of the "rndc signing -list" command used for checking ZSK deletion
progress may contain extra lines which are not accounted for. Ensure
the private record is removed from zone apex before triggering ZSK
deletion in the aforementioned check.
Also future-proof the ZSK deletion progress check by making it only look
at lines it should care about.
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.
During "dlv" system test setup, the "sed" regex used for mangling the
DNSKEY RRset for the "druz" zone does not include the plus sign ("+"),
which may:
- cause the replacement to happen near the end of DNSKEY RDATA, which
can cause the latter to become an invalid Base64 string,
- prevent the replacement from being performed altogether.
Both cases prevent the "dlv" system test from behaving as intended and
may trigger false positives. Add the missing character to the
aforementioned regex to ensure the replacement is always performed on
bytes 10-25 of DNSKEY RDATA.
Use them in structs for various rdata types where they are missing.
This doesn't change the structs since we are replacing explicit
uint8_t field types with aliases for uint8_t.
Use dns_dsdigest_t in library function arguments.
Improve dnssec-cds with these more specific types.
Alphabetize options and synopsis; remove spurious -z from synopsis;
remove remnants of deprecated -k option; remove mention of long-gone
TSIG support; refer to -T KEY in options that are only relevant to
pre-RFC3755 DNSSEC; remove unnecessary -n ZONE from the example, and
add a -f KSK example.
When the "library" part of a "plugin" configuration stanza does not
contain at least one path separator, treat it as a filename and assume
it is a name of a shared object present in the named plugin installation
directory. Absolute and relative paths can still be used and will be
used verbatim. Get the full path to a plugin before attempting to
check/register it so that all relevant log messages include the same
plugin path (apart from the one logged when the full path cannot be
determined).
Installing named plugins into ${libdir} clutters the latter and is not
in line with common filesystem conventions. Instead, install named
plugins into a separate directory, ${libdir}/named.
The "check key refreshes are resumed after root servers become
available" check may trigger a false positive for the "mkeys" system
test if the second example/TXT query sent by dig is received by ns5 less
than a second after it receives a REFUSED response to the upstream query
it sends to ns1 in order to resolve the first example/TXT query sent by
dig. Since that REFUSED response from ns1 causes ns5 to return a
SERVFAIL answer to dig, example/TXT is added to the SERVFAIL cache,
which is enabled by default with a TTL of 1 second. This in turn may
cause ns5 to return a cached SERVFAIL response to the second example/TXT
query sent by dig, i.e. make ns5 not perform full query processing as
expected by the check.
Since the primary purpose of the check in question is to ensure that key
refreshes are resumed once initially unavailable root servers become
available, the optimal solution appears to be disabling SERVFAIL cache
for ns5 as doing that still allows the check to fulfill its purpose and
it is arguably more prudent than always sleeping for 1 second.
For consistency between all system tests, add missing setup.sh scripts
for tests which do not have one yet and ensure every setup.sh script
calls its respective clean.sh script.
Temporary files created by a given system test should be removed by its
clean.sh script, not its setup.sh script. Remove redundant "rm"
invocations from setup.sh scripts. Move required "rm" invocations from
setup.sh scripts to their corresponding clean.sh scripts.
If dots are not escaped in the "1.2.3.4" regular expressions used for
checking whether IP address 1.2.3.4 is present in the tested resolver's
answers, a COOKIE that matches such a regular expression will trigger a
false positive for the "resolver" system test. Properly escape dots in
the aforementioned regular expressions to prevent that from happening.
Including $SYSTEMTESTTOP/conf.sh from a system test's clean.sh script is
not needed for anything while it causes an error message to be printed
out when "./configure" is run, as "make clean" is invoked at the end.
Remove the offending line to prevent the error from occurring.
For all system tests utilizing named instances, call clean.sh from each
test's setup.sh script in a consistent way to make sure running the same
system test multiple times using run.sh does not trigger false positives
caused by stale files created by previous runs.
Ideally we would just call clean.sh from run.sh, but that would break
some quirky system tests like "rpz" or "rpzrecurse" and being consistent
for the time being does not hurt.
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.
Illustrate the syntax for the policy options, with semicolons.
Explicitly mention the "default" policy.
Fix a few typos and remove some redundant wording.
When a mirror zone is verified, the 'ignore_kskflag' argument passed to
dns_zoneverify_dnssec() is set to false. This means that in order for
its verification to succeed, a mirror zone needs to have at least one
key with the SEP bit set configured as a trust anchor. This brings no
security benefit and prevents zones signed only using keys without the
SEP bit set from being mirrored, so change the value of the
'ignore_kskflag' argument passed to dns_zoneverify_dnssec() to true.
The "mirror" system test checks whether log messages announcing a mirror
zone coming into effect are emitted properly. However, the helper
functions responsible for waiting for zone transfers and zone loading to
complete do not wait for these exact log messages, but rather for other
ones preceding them, which introduces a possibility of false positives.
This problem cannot be addressed by just changing the log message to
look for because the test still needs to discern between transferring a
zone and loading a zone.
Add two new log messages at debug level 99 (which is what named
instances used in system tests are configured with) that are to be
emitted after the log messages announcing a mirror zone coming into
effect. Tweak the aforementioned helper functions to only return once
the log messages they originally looked for are followed by the newly
added log messages. This reliably prevents races when looking for
"mirror zone is now in use" log messages and also enables a workaround
previously put into place in the "mirror" system test to be reverted.
In the "mirror" system test, ns3 periodically sends trust anchor
telemetry queries to ns1 and ns2. It may thus happen that for some
non-recursive queries for names inside mirror zones which are not yet
loaded, ns3 will be able to synthesize a negative answer from the cached
records it obtained from trust anchor telemetry responses. In such
cases, NXDOMAIN responses will be sent with the root zone SOA in the
AUTHORITY section. Since the root zone used in the "mirror" system test
has the same serial number as ns2/verify.db.in and zone verification
checks look for the specified serial numbers anywhere in the answer, the
test could be broken if different zone names were used.
The +noauth dig option could be used to address this weakness, but that
would prevent entire responses from being stored for later inspection,
which in turn would hamper troubleshooting test failures. Instead, use
a different serial number for ns2/verify.db.in than for any other zone
used in the "mirror" system test and check the number of records in the
ANSWER section of each response.
Due to the way the "mirror" system test is set up, it is impossible for
the "verify-unsigned" and "verify-untrusted" zones to contain any serial
number other than the original one present in ns2/verify.db.in. Thus,
using presence of a different serial number in the SOA records of these
zones as an indicator of problems with mirror zone verification is
wrong. Look for the original zone serial number instead as that is the
one that will be returned by ns3 if one of the aforementioned zones is
successfully verified.
* Alphabetize the option lists in the man page and help text
* Make the synopses more consistent between the man page and help
text, in particular the number of different modes
* Group mutually exclusive options in the man page synopses, and order
options so that it is more clear which are available in every mode
* Expand the DESCRIPTION to provide an overview of the output modes
and input modes
* Improve cross-references between options
* Leave RFC citations to the SEE ALSO section, and clarify which RFC
specifies what
* Clarify list of digest algorithms in dnssec-dsfromkey and dnssec-cds
man pages
Ensure IXFR statistics are calculated correctly by dig and named, both
for incoming and outgoing transfers. Disable EDNS when using dig to
request an IXFR so that the same reference file can be used for testing
statistics calculated by both dig and named (dig uses EDNS by default
when sending transfer requests, which affects the number of bytes
transferred).
Ensure AXFR statistics are calculated correctly by dig and named, both
for incoming and outgoing transfers. Rather than employing a zone which
is already used in the "xfer" system test, create a new one whose AXFR
form spans multiple TCP messages. Disable EDNS when using dig to
request an AXFR so that the same reference file can be used for testing
statistics calculated by both dig and named (dig uses EDNS by default
when sending transfer requests, which affects the number of bytes
transferred).
the occluded-key test creates both a KEY and a DNSKEY. the second
call to dnssec-keygen calls dns_dnssec_findmatchingkeys(), which causes
a spurious warning to be printed when it sees the type KEY record.
this should be fixed in dnssec.c, but the meantime this change silences
the warning by reversing the order in which the keys are created.
- options that were flagged as obsolete or not implemented in 9.0.0
are now flagged as "ancient", and are a fatal error
- the ARM has been updated to remove these, along with other
obsolete descriptions of BIND 8 behavior
- the log message for obsolete options explicitly recommends removal
This adds a test for rndc dumpdb to ensure the correct "stale
comment" is printed. It also adds a test for non-stale data to
ensure no "stale comment" is printed for active RRsets.
In addition, the serve-stale tests are hardened with more accurate
grep calls.
The introduced grep call checks whether there was a
response that has an answer and an additional record.
There should be only one in the nsupdate output that is
for the TKEY response.
The introduced grep call checks whether there was a
response that has an answer and an additional record.
There should be only one in the nsupdate output that is
for the TKEY response.
use a lame server configuration to force SERVFAILs instead of killing ns2.
this prevents test failures that occurred due to a different behavior of
the netowrking stack in windows.
test the average delay between notifies instead of the minimum delay;
this helps avoid unnecessary test failures on systems with bursty
network performance.
dig retries a TCP query when a server closes the connection prematurely.
However, dig's exit code remains unaffected even if the second attempt
to get a response also fails with the same error for the same lookup,
which should not be the case. Ensure the exit code is updated
appropriately when a retry triggered by a TCP EOF condition fails.
- mishandling of trailing dots caused bad behavior with the
root zone or names like "example.com."
- fixing this exposed an error in dnssec-coverage caused the
wrong return value if there were KSK errors but no ZSK errors
- incidentally silenced the dnssec-keygen output in the coverage
system test
- dig command had the @ parameter in the wrong place
- private-dnskey and private-cdnskey are queried in a separate
loop, which strips 'private-' from the name to determine the qtype
If we try to fetch a record from cache and need to look into
hints database we assume that the resolver is not primed and
start dns_resolver_prime(). Priming query is supposed to return
NSes for "." in ANSWER section and glue records for them in
ADDITIONAL section, so that we can fill that info in 'regular'
cache and not use hints db anymore.
However, if we're using a forwarder the priming query goes through
it, and if it's configured to return minimal answers we won't get
the addresses of root servers in ADDITIONAL section. Since the
only records for root servers we have are in hints database we'll
try to prime the resolver with every single query.
This patch adds a DNS_FETCHOPT_NOFORWARD flag which avoids using
forwarders if possible (that is if we have forward-first policy).
Using this flag on priming fetch fixes the problem as we get the
proper glue. With forward-only policy the problem is non-existent,
as we'll never ask for root server addresses because we'll never
have a need to query them.
Also added a test to confirm priming queries are not forwarded.
Log a message if a mirror zone becomes unusable for the resolver (most
usually due to the zone's expiration timer firing). Ensure that
verification failures do not cause a mirror zone to be unloaded
(instead, its last successfully verified version should be served if it
is available).
Log a message when a mirror zone is successfully loaded from disk and
subsequently verified.
This could have been implemented in a simpler manner, e.g. by modifying
an earlier code branch inside zone_postload() which checks whether the
zone already has a database attached and calls attachdb() if it does
not, but that would cause the resulting logs to indicate that a mirror
zone comes into effect before the "loaded serial ..." message is logged,
which would be confusing.
Tweak some existing sed commands used in the "mirror" system test to
ensure that separate test cases comprising it do not break each other.
Log a message when a mirror zone is successfully transferred and
verified, but only if no database for that zone was yet loaded at the
time the transfer was initiated.
This could have been implemented in a simpler manner, e.g. by modifying
zone_replacedb(), but (due to the calling order of the functions
involved in finalizing a zone transfer) that would cause the resulting
logs to suggest that a mirror zone comes into effect before its transfer
is finished, which would be confusing given the nature of mirror zones
and the fact that no message is logged upon successful mirror zone
verification.
Once the dns_zone_replacedb() call in axfr_finalize() is made, it
becomes impossible to determine whether the transferred zone had a
database attached before the transfer was started. Thus, that check is
instead performed when the transfer context is first created and the
result of this check is passed around in a field of the transfer context
structure. If it turns out to be desired, the relevant log message is
then emitted just before the transfer context is freed.
Taking this approach means that the log message added by this commit is
not timed precisely, i.e. mirror zone data may be used before this
message is logged. However, that can only be fixed by logging the
message inside zone_replacedb(), which causes arguably more dire issues
discussed above.
dns_zone_isloaded() is not used to double-check that transferred zone
data was correctly loaded since the 'shutdown_result' field of the zone
transfer context will not be set to ISC_R_SUCCESS unless axfr_finalize()
succeeds (and that in turn will not happen unless dns_zone_replacedb()
succeeds).
The handling of class and view arguments was broken, because the code
didn't realise that next_token() would overwrite the class name when
it parsed the view name. The code was trying to implement a syntax
like `refresh [[class] view]`, but it was documented to have a syntax
like `refresh [class [view]]`. The latter is consistent with other rndc
commands, so that is how I have fixed it.
Before:
$ rndc managed-keys refresh in rec
rndc: 'managed-keys' failed: unknown class/type
unknown class 'rec'
After:
$ rndc managed-keys refresh in rec
refreshing managed keys for 'rec'
There were missing newlines in the output from `rndc managed-keys
refresh` and `rndc managed-keys destroy`.
Before:
$ rndc managed-keys refresh
refreshing managed keys for 'rec'refreshing managed keys for 'auth'
After:
$ rndc managed-keys refresh
refreshing managed keys for 'rec'
refreshing managed keys for 'auth'
- the checkprivate function in the dnssec test set ret=0, erasing
results from previous tests and making the test appear to have passed
when it shouldn't have
- checkprivate needed a delay loop to ensure there was time for all
private signing records to be updated before the test
When a query times out after a socket is created and associated with a
given dig_query_t structure, calling isc_socket_cancel() causes
connect_done() to be run, which in turn takes care of all necessary
cleanups. However, certain errors (e.g. get_address() returning
ISC_R_FAMILYNOSUPPORT) may prevent a TCP socket from being created in
the first place. Since force_timeout() may be used in code handling
such errors, connect_timeout() needs to properly clean up a TCP query
which is not associated with any socket. Call clear_query() from
connect_timeout() after attempting to send a TCP query to the next
available server if the timed out query does not have a socket
associated with it, in order to prevent dig from hanging indefinitely
due to the dig_query_t structure not being detached from its parent
dig_lookup_t structure.
When a query times out and another server is available for querying
within the same lookup, the timeout handler - connect_timeout() - is
responsible for sending the query to the next server. Extract the
relevant part of connect_timeout() to a separate function in order to
improve code readability.
Before commit c2ec022f57, using the "-b"
command line switch for dig did not disable use of the other address
family than the one to which the address supplied to that option
belonged to. Thus, bind9_getaddresses() could e.g. prepare an
isc_sockaddr_t structure for an IPv6 address when an IPv4 address has
been passed to the "-b" command line option. To avoid attempting the
impossible (e.g. querying an IPv6 address from a socket bound to an IPv4
address), a certain code block in send_tcp_connect() checked whether the
address family of the server to be queried was the same as the address
family of the socket set up for sending that query; if there was a
mismatch, that particular server address was skipped.
Commit c2ec022f57 made
bind9_getaddresses() fail upon an address family mismatch between the
address the hostname passed to it resolved to and the address supplied
to the "-b" command line option. Such failures were fatal to dig back
then.
Commit 7f65860391 made
bind9_getaddresses() failures non-fatal, but also ensured that a
get_address() failure in send_tcp_connect() still causes the given query
address to be skipped (and also made such failures trigger an early
return from send_tcp_connect()).
Summing up, the code block handling address family mismatches in
send_tcp_connect() has been redundant since commit
c2ec022f57. Remove it.
Since following a delegation resets most fetch context state, address
marks (FCTX_ADDRINFO_MARK) set inside lib/dns/resolver.c are not
preserved when a delegation is followed. This is fine for full
recursive resolution but when named is configured with "forward first;"
and one of the specified forwarders times out, triggering a fallback to
full recursive resolution, that forwarder should no longer be consulted
at each delegation point subsequently reached within a given fetch
context.
Add a new badnstype_t enum value, badns_forwarder, and use it to mark a
forwarder as bad when it times out in a "forward first;" configuration.
Since the bad server list is not cleaned when a fetch context follows a
delegation, this prevents a forwarder from being queried again after
falling back to full recursive resolution. Yet, as each fetch context
maintains its own list of bad servers, this change does not cause a
forwarder timeout to prevent that forwarder from being used by other
fetch contexts.
Add a new libisccfg function, cfg_pluginlist_foreach(), which allows an
arbitrary callback to be invoked for every "plugin" stanza present in a
configuration object. Use this function for both loading plugins and
checking their configuration in order to reduce duplication of
configuration processing code present in bin/named/server.c and
lib/bind9/check.c.
- "hook" is now used only for hook points and hook actions
- the "hook" statement in named.conf is now "plugin"
- ns_module and ns_modlist are now ns_plugin and ns_plugins
- ns_module_load is renamed ns_plugin_register
- the mandatory functions in plugin modules (hook_register,
hook_check, hook_version, hook_destroy) have been renamed
- use a per-view module list instead of global hook_modules
- create an 'instance' pointer when registering modules, store it in
the module structure, and use it as action_data when calling
hook functions - this enables multiple module instances to be set
up in parallel
- also some nomenclature changes and cleanup
- this is necessary because adding the same hook to multiple views
causes the ISC_LIST link value to become inconsistent; it isn't
noticeable when only one hook action is ever registered at a
given hook point, but it will break things when there are two.
- eliminate qctx->hookdata and client->hookflags.
- use a memory pool to allocate data blobs in the filter-aaaa module,
and associate them with the client address in a hash table
- instead of detaching the client in query_done(), mark it for deletion
and then call ns_client_detach() from qctx_destroy(); this ensures
that it will still exist when the QCTX_DESTROYED hook point is
reached.
- use a get_hooktab() function to determine the hook table.
- PROCESS_HOOK now jumps to a cleanup tag on failure
- add PROCESS_ALL_HOOKS in query.c, to run all hook functions at
a specified hook point without stopping. this is to be used for
intiialization and destruction functions that must run in every
module.
- 'result' is set in PROCESS_HOOK only when a hook function
interrupts processing.
- revised terminology: a "callback" is now a "hook action"
- remove unused NS_PROCESS_HOOK and NS_PROCESS_HOOK_VOID macros.
- added a 'hookdata' array to qctx to store pointers to up to
16 blobs of data which are allocated by modules as needed.
each module is assigned an ID number as it's loaded, and this
is the index into the hook data array. this is to be used for
holding persistent state between calls to a hook module for a
specific query.
- instead of using qctx->filter_aaaa, we now use qctx->hookdata.
(this was the last piece of filter-aaaa specific code outside the
module.)
- added hook points for qctx initialization and destruction. we get
a filter-aaaa data pointer from the mempool when initializing and
store it in the qctx->hookdata table; return to to the mempool
when destroying the qctx.
- link the view to the qctx so that detaching the client doesn't cause
hooks to fail
- added a qctx_destroy() function which must be called after qctx_init;
this calls the QCTX_DESTROY hook and detaches the view
- general cleanup and comments
- make some cfg-parsing functions global so they can be run
from filter-aaaa.so
- add filter-aaaa options to the hook module's parser
- mark filter-aaaa options in named.conf as obsolete, remove
from named and checkconf, and update the filter-aaaa test not to
use checkconf anymore
- remove filter-aaaa-related struct members from dns_view
- allow multiple "hook" statements at global or view level
- add "optional bracketed text" type for optional parameter list
- load hook module from specified path rather than hardcoded path
- add a hooktable pointer (and a callback for freeing it) to the
view structure
- change the hooktable functions so they no longer update ns__hook_table
by default, and modify PROCESS_HOOK so it uses the view hooktable, if
set, rather than ns__hook_table. (ns__hook_table is retained for
use by unit tests.)
- update the filter-aaaa system test to load filter-aaaa.so
- add a prereq script to check for dlopen support before running
the filter-aaaa system test
not yet done:
- configuration parameters are not being passed to the filter-aaaa
module; the filter-aaaa ACL and filter-aaaa-on-{v4,v6} settings are
still stored in dns_view
- temporary kluge! in this version, for testing purposes,
named always searches for a filter-aaaa module at /tmp/filter-aaaa.so.
this enables the filter-aaaa system test to run even though the
code to configure hooks in named.conf hasn't been written yet.
- filter-aaaa-on-v4, filter-aaaa-on-v6 and the filter-aaaa ACL are
still configured in the view as they were before, not in the hook.
- these formerly static helper functions have been moved into client.c
and made external so that they can be used in hook modules as well as
internally in libns: query_newrdataset, query_putrdataset,
query_newnamebuf, query_newname, query_getnamebuf, query_keepname,
query_releasename, query_newdbversion, query_findversion
- made query_recurse() and query_done() into public functions
ns_query_recurse() and ns_query_done() so they can be called from
modules.
- the goal of this change is for AAAA filtering to be fully contained
in the query logic, and implemented at discrete points that can be
replaced with hook callouts later on.
- the new code may be slightly less efficient than the old filter-aaaa
implementation, but maximum efficiency was never a priority for AAAA
filtering anyway.
- we now use the rdataset RENDERED attribute to indicate that an AAAA
rdataset should not be included when rendering the message. (this
flag was originally meant to indicate that an rdataset has already
been rendered and should not be repeated, but it can also be used to
prevent rendering in the first place.)
- the DNS_MESSAGERENDER_FILTER_AAAA, NS_CLIENTATTR_FILTER_AAAA,
and DNS_RDATASETGLUE_FILTERAAAA flags are all now unnecessary and
have been removed.
- move hooks.h to public include directory
- ns_hooktable_init() initializes a hook table. if NULL is passed in, it
initializes the global hook table
- ns_hooktable_save() saves a pointer to the current global hook table.
- ns_hooktable_reset() replaces the global hook table with different
one
- ns_hook_add() adds hooks at specified hook points in a hook table (or
the global hook table if the specified table is NULL)
- load and unload functions support dlopen() of hook modules (this is
adapted from dyndb and not yet functional)
- began adding new hook points to query.c
We can remove this, because it is used in `strtodsdigest` but that
already no longer covers the algorithm name "GOST".
There is one more GOST reference in `bin/python/isc/checkds.py.in`
but that is used for presentation format and probably should stay.
(cherry picked from commit 57d44fbc628d3c7dafdd545f6b83dbdcdc39a986)
