In certain situations (e.g. a named instance crashing upon shutdown in a
system test which involves shutting down a server and restarting it
afterwards), a system test may succeed despite a named crash being
triggered. This must never be the case. Extend run.sh to mark a test
as failed if core dumps or log lines indicating assertion failures are
detected (the latter is only an extra measure aimed at test environments
in which core dumps are not generated; note that some types of crashes,
e.g. segmentation faults, will not be detected using this method alone).
Make the get_named_xfer_stats() helper shell function more precise in
order to prevent it from matching the wrong lines as that may trigger
false positives for the "ixfr" and "xfer" system tests. As an example,
the regular expression responsible for extracting the number of bytes
transmitted throughout an entire zone transfer could also match a line
containing the following string:
transfer of '<zone-name>/IN': sending TCP message of <integer> bytes
However, such a line is not one summarizing a zone transfer.
Also simplify both get_dig_xfer_stats() and get_named_xfer_stats() by
eliminating the need for "echo" statements in them.
If ns1/setup.sh generates a key with ID 0, the "KEYID" token in
ns1/named.conf.in will be replaced with an empty string, causing the
following broken statement to appear in ns1/named.conf:
tkey-dhkey "server" ;
Such a statement triggers false positives for the "tkey" system test due
to ns1 being unable to start with a broken configuration file. Fix by
tweaking the regular expression used for removing leading zeros from the
key ID, so that it removes at most 4 leading zeros.
Compiling with -O3 triggers the following warning with GCC 8.3:
driver.c: In function ‘dlz_findzonedb’:
driver.c:191:29: warning: ‘%u’ directive output may be truncated writing between 1 and 5 bytes into a region of size between 0 and 99 [-Wformat-truncation=]
snprintf(buffer, size, "%s#%u", addr_buf, port);
^~
driver.c:191:25: note: directive argument in the range [0, 65535]
snprintf(buffer, size, "%s#%u", addr_buf, port);
^~~~~~~
driver.c:191:2: note: ‘snprintf’ output between 3 and 106 bytes into a destination of size 100
snprintf(buffer, size, "%s#%u", addr_buf, port);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Increase the size of the relevant array to prevent this warning from
being triggered.
- change references to trusted-keys to dnssec-keys with static-key
- rebuild doc/misc/options and other generated grammar doc
- add a "see MANAGED-KEYS" note when building named.conf.docbook
- managed-keys is now deprecated as well as trusted-keys, though
it continues to work as a synonym for dnssec-keys
- references to managed-keys have been updated throughout the code.
- tests have been updated to use dnssec-keys format
- also the trusted-keys entries have been removed from the generated
bind.keys.h file and are no longer generated by bindkeys.pl.
- any use of trusted or static keys for the root zone will now
elicit a warning, regardless of what the keys may be
- ditto for any use of a key for dlv.isc.org, static or managed
- 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
Since 2008, the cleaning-interval timer has been documented as
"effectively obsolete" and disabled in the default configuration with
a comment saying "now meaningless".
This change deletes all the code that implements the cleaning-interval
timer, except for the config parser in whcih it is now explicitly
marked as obsolete.
I have verified (using the deletelru and deletettl cache stats) that
named still cleans the cache after this change.
Replace grep calls with awk scripts to more precisely detect presence of
CDS and CDNSKEY records in a signed zone file, in order to prevent rare
false positives for the "smartsign" system test triggered by the strings
"CDS" and/or "CDNSKEY" being accidentally present in the Base64 form of
DNSSEC-related data in the zone file being checked.
qname minimization, even in relaxed mode, can fail on
some very broken domains. In relaxed mode, instead of
asking for "foo.bar NS" ask for "_.foo.bar A" to either
get a delegation or NXDOMAIN. It will require more queries
than regular mode for proper NXDOMAINs.
Performing server setup checks using "+tries=3 +time=5" is redundant as
a single query is arguably good enough for determining whether a given
named instance was set up properly. Only use multiple queries with a
long timeout for resolution checks in the "legacy" system test, in order
to significantly reduce its run time (on a contemporary machine, from
about 1m45s to 0m40s).
In the "legacy" system test, in order to make server setup checks more
consistent with each other, add further checks for either presence or
absence of the EDNS OPT pseudo-RR in the responses returned by the
tested named instances.
Extract repeated dig and grep calls into two helper shell functions,
resolution_succeeds() and resolution_fails(), in order to reduce code
duplication in the "legacy" system test, emphasize the similarity
between all the resolution checks in that test, and make the conditions
for success and failure uniform for all resolution checks in that test.
When testing named instances which are configured to drop outgoing UDP
responses larger than 512 bytes, querying with DO=1 may be used instead
of querying for large TXT records as the effect achieved will be
identical: an unsigned response for a SOA query will be below 512 bytes
in size while a signed response for the same query will be over 512
bytes in size. Doing this makes all resolution checks in the "legacy"
system test more similar. Add checks for the TC flag being set in UDP
responses which are expected to be truncated to further make sure that
tested named instances behave as expected.
Sending TCP queries to test named instances with TCP support disabled
should cause dig output to contain the phrase "connection refused", not
"connection timed out", as such instances never open the relevant
sockets. Make sure that the "legacy" system test fails if the expected
phrase is not found in any of the relevant files containing dig output.
This work cleans up the API which includes couple of things:
1. Make the isc_appctx_t type fully opaque
2. Protect all access to the isc_app_t members via stdatomics
3. sigwait() is part of POSIX.1, remove dead non-sigwait code
4. Remove unused code: isc_appctx_set{taskmgr,sockmgr,timermgr}
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 changes the behaviour so that it explicitly lists DS records that
are present in the parent but do not have keys in the child. Any
inconsistency is reported as an error, which is somewhat stricter than
before.
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