When a staleonly lookup doesn't find a satisfying answer, it should
not try to respond to the client.
This is not true when the initial lookup is staleonly (that is when
'stale-answer-client-timeout' is set to 0), because no resolver fetch
has been created at this point. In this case continue with the lookup
normally.
(cherry picked from commit f8b7b597e9)
Fix a crash that can happen in the following scenario:
A client request is received. There is no data for it in the cache,
(not even stale data). A resolver fetch is created as part of
recursion.
Some time later, the fetch still hasn't completed, and
stale-answer-client-timeout is triggered. A staleonly lookup is
started. It will also find no data in the cache.
So 'query_lookup()' will call 'query_gotanswer()' with ISC_R_NOTFOUND,
so this will call 'query_notfound()' and this will start recursion.
We will eventually end up in 'ns_query_recurse()' and that requires
the client query fetch to be NULL:
REQUIRE(client->query.fetch == NULL);
If the previously started fetch is still running this assertion
fails.
The crash is easily prevented by not requiring recursion for
staleonly lookups.
Also remove a redundant setting of the staleonly flag at the end of
'query_lookup_staleonly()' before destroying the query context.
Add a system test to catch this case.
(cherry picked from commit 9e061faaae)
When applying dnssec-policy on a dynamic zone (e.g. that allows Dynamic
Updates), the NSEC3 parameters were put on the queue, but they were
not being processed (until a reload of the zone or reconfiguration).
Process the NSEC3PARAM queue on zone postload when handling a
dynamic zone.
(cherry picked from commit 4b176c850b)
GitLab issue #2498 is a bug report on NSEC3 with dynamic zones. Tests
for it in the nsec3 system test directory were missing.
(cherry picked from commit 0c0f10b53f)
The 'checknames' field wasn't initialized in dns_view_create(), but it
should otherwise AddressSanitizer identifies the following runtime error
in query_test.c.
runtime error: load of value 190, which is not a valid value for type '_Bool'
(cherry picked from commit 0c6fa16477)
Removing stderr from the pict tool serves no purpose and drops valuable
information, we might use when debugging failed pairwise CI job, such
as:
Input Error: A parameter names must be unique
(cherry picked from commit 079debaa10)
*** CID 320481: Null pointer dereferences (REVERSE_INULL)
/bin/tests/wire_test.c: 261 in main()
255 process_message(input);
256 }
257 } else {
258 process_message(input);
259 }
260
CID 320481: Null pointer dereferences (REVERSE_INULL)
Null-checking "input" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
261 if (input != NULL) {
262 isc_buffer_free(&input);
263 }
264
265 if (printmemstats) {
266 isc_mem_stats(mctx, stdout);
(cherry picked from commit 658c950d7b)
Two minor fixes in the kasp system test:
1. A wrong comment in ns3/setup.sh (we are subtracting 2 hours, not
adding them).
2. 'get_keyids' used bad parameters "$1" "$2" when 'check_numkeys'
failed. Also, 'check_numkeys' can use $DIR, $ZONE, and $NUMKEYS
directly, no need to pass them.
(cherry picked from commit 5be26898c0)
Add some more zones to the kasp system test to test the 'purge-keys'
option. Three zones test that the predecessor key files are removed
after the purge keys interval, one test checks that the key files
are retained if 'purge-keys' is disabled. For that, we change the
times to 90 days in the past (the default value for 'purge-keys').
(cherry picked from commit 6333ff15f0)
On each keymgr run, we now also check if key files can be removed.
The 'purge-keys' interval determines how long keys should be retained
after they have become completely hidden.
Key files should not be removed if it has a state that is set to
something else then HIDDEN, if purge-keys is 0 (disabled), if
the key goal is set to OMNIPRESENT, or if the key is unused (a key is
unused if no timing metadata set, and no states are set or if set,
they are set to HIDDEN).
If the last changed timing metadata plus the purge-keys interval is
in the past, the key files may be removed.
Add a dst_key_t variable 'purge' to signal that the key file should
not be written to file again.
(cherry picked from commit 8c526cb67f)
Add a new option 'purge-keys' to 'dnssec-policy' that will purge key
files for deleted keys. The option determines how long key files
should be retained prior to removing the corresponding files from
disk.
If set to 0, the option is disabled and 'named' will not remove key
files from disk.
(cherry picked from commit 313de3a7e2)
dns_dt_open() is not currently called with mode dns_dtmode_unix.
*** CID 281489: Resource leaks (RESOURCE_LEAK)
/lib/dns/dnstap.c: 983 in dns_dt_open()
977
978 if (!dnstap_file(handle->reader)) {
979 CHECK(DNS_R_BADDNSTAP);
980 }
981 break;
982 case dns_dtmode_unix:
CID 281489: Resource leaks (RESOURCE_LEAK)
Variable "handle" going out of scope leaks the storage it points to.
983 return (ISC_R_NOTIMPLEMENTED);
984 default:
985 INSIST(0);
986 ISC_UNREACHABLE();
987 }
988
(cherry picked from commit 003dd8cc70)
feature-test tool location needs to be determined by its associated
variable; otherwise, the tool is not found on Windows:
setup.sh: line 22: ../feature-test: No such file or directory
(cherry picked from commit 102f012631)
"kyua report-html" command in CI generates more than two pages of output
to stdout, which is nothing but which HTML pages Kyua generated, e.g.:
Generating kyua_html/context.html
Generating kyua_html/lib_dns_tests_acl_test_main.html
...
Generating kyua_html/lib_ns_tests_query_test_main.html
Generating kyua_html/report.css
Generating kyua_html/index.html
This is seldomly useful and requires the user to scroll three pages
upwards to get to unit test results.
Any CI job:
- I:dnssec:file dnssec/ns1/trusted.keys not removed
- I:rpzrecurse:file rpzrecurse/ns3/named.run.prev not removed
system:gcc:sid:amd64:
- I:mirror:file mirror/ns3/_default.nzf not removed
system:gcc:xenial:amd64:
- I:shutdown:file shutdown/.cache/v/cache/lastfailed not removed
(cherry picked from commit 14a104d121)
Run this check only when in Git repository, because run.sh produces the
"file not removed" warnings only when in Git repository.
(cherry picked from commit 4a2778abdf)
The ISC SPNEGO implementation is based on mod_auth_kerb code. When
CVE-2006-5989 was disclosed, the relevant fix was not applied to the
BIND 9 codebase, making the latter vulnerable to the aforementioned flaw
when "tkey-gssapi-keytab" or "tkey-gssapi-credential" is set in
named.conf.
The original description of CVE-2006-5989 was:
Off-by-one error in the der_get_oid function in mod_auth_kerb 5.0
allows remote attackers to cause a denial of service (crash) via a
crafted Kerberos message that triggers a heap-based buffer overflow
in the component array.
Later research revealed that this flaw also theoretically enables remote
code execution, though achieving the latter in real-world conditions is
currently deemed very difficult.
This vulnerability was responsibly reported as ZDI-CAN-12302 ("ISC BIND
TKEY Query Heap-based Buffer Overflow Remote Code Execution
Vulnerability") by Trend Micro Zero Day Initiative.
