GitLab

Run GDB for crashed named servers

See merge request !4848

When a core file was generated after named crashed during a system test
on 9.16, it wasn't processed by GDB, and no backtrace report was
created. This is now fixed. There are also a few white-space changes.

[v9_16] Move fromhex.pl script to bin/tests/system/

See merge request !4877

The fromhex.pl script needs to be copied from the source directory to
the build directory before any test is run, otherwise the out-of-tree
fails to find it. Given that the script is used only in system test,
move it to bin/tests/system/.

(cherry picked from commit cd0a34df)

[v9_16] Free resources when gss_accept_sec_context() fails

See merge request !4874

(cherry picked from commit 7eb87270)

Even if a call to gss_accept_sec_context() fails, it might still cause a
GSS-API response token to be allocated and left for the caller to
release.  Make sure the token is released before an early return from
dst_gssapi_acceptctx().

(cherry picked from commit d954e152)

Fix triggering rules for the "tarball-create" job

See merge request !4871

Commit fd8ce681 (a backport of commit
4d5d3b75) did not account for the fact
that the "tarball-create" GitLab CI job is not created for manually
triggered pipelines.  This prevents manual pipeline creation from
succeeding as it causes the "gcc:tarball" job to have unsatisfied
dependencies.  Make sure the "tarball-create" job is created for
manually triggered pipelines to allow such pipelines to be started
again.

Merge branch '2600-general-error-managed-keys-zone-dns_journal_compact-failed-no-more-v9_16' into 'v9_16'

Resolve "general: error: managed-keys-zone: dns_journal_compact failed: no more" (v9.16)

See merge request !4870

(cherry picked from commit 0174098a)

Update the system to include a recoverable managed.keys journal created
with <size,serial0,serial1,0> transactions and test that it has been
updated as part of the start up process.

(cherry picked from commit bb6f0fae)

Both managed keys and regular zone journals need to be updated
immediately when a recoverable error is discovered.

(cherry picked from commit 0fbdf189)

Previously, dns_journal_begin_transaction() could reserve the wrong
amount of space.  We now check that the transaction is internally
consistent when upgrading / downgrading a journal and we also handle the
bad transaction headers.

(cherry picked from commit 83310ffd)

previously the code assumed that it was a new transaction.

(cherry picked from commit 520509ac)

Instead of journal_write(), use correct format call journal_write_xhdr()
to write the dummy transaction header which looks at j->header_ver1 to
determine which transaction header to write instead of always writing a
zero filled journal_rawxhdr_t header.

(cherry picked from commit 5a6112ec)

Merge branch '2582-threadsanitizer-data-race-lib-dns-zone-c-10272-7-in-zone_maintenance-v9_16' into 'v9_16'

Resolve TSAN data race in zone_maintenance

See merge request !4866

Fix race between zone_maintenance and dns_zone_notifyreceive functions,
zone_maintenance was attempting to read a zone flag calling
DNS_ZONE_FLAG(zone, flag) while dns_zone_notifyreceive was updating
a flag in the same zone calling DNS_ZONE_SETFLAG(zone, ...).

The code reading the flag in zone_maintenance was not protected by the
zone's lock, to avoid a race the zone's lock is now being acquired
before an attempt to read the zone flag is made.

Change default stale-answer-client-timeout to off (9.16)

See merge request !4867

Using "stale-answer-client-timeout" turns out to have unforeseen
negative consequences, and thus it is better to disable the feature
by default for the time being.

(cherry picked from commit e443279b)

Serve-stale "staleonly" recursion race condition

See merge request !4860

When we are recursing, RPZ processing is not allowed. But when we are
performing a lookup due to "stale-answer-client-timeout", we are still
recursing. This effectively means that RPZ processing is disabled on
such a lookup.

In this case, bail the "stale-answer-client-timeout" lookup and wait
for recursion to complete, as we we can't perform the RPZ rewrite
rules reliably.

(cherry picked from commit 3d3a6415)

The dboption DNS_DBFIND_STALEONLY caused confusion because it implies
we are looking for stale data **only** and ignore any active RRsets in
the cache. Rename it to DNS_DBFIND_STALETIMEOUT as it is more clear
the option is related to a lookup due to "stale-answer-client-timeout".

Rename other usages of "staleonly", instead use "lookup due to...".
Also rename related function and variable names.

(cherry picked from commit 839df941)

When doing a staleonly lookup we don't want to fallback to recursion.
After all, there are obviously problems with recursion, otherwise we
wouldn't do a staleonly lookup.

When resuming from recursion however, we should restore the
RECURSIONOK flag, allowing future required lookups for this client
to recurse.

(cherry picked from commit 3f81d79f)

When implementing "stale-answer-client-timeout", we decided that
we should only return positive answers prematurely to clients. A
negative response is not useful, and in that case it is better to
wait for the recursion to complete.

To do so, we check the result and if it is not ISC_R_SUCCESS, we
decide that it is not good enough. However, there are more return
codes that could lead to a positive answer (e.g. CNAME chains).

This commit removes the exception and now uses the same logic that
other stale lookups use to determine if we found a useful stale
answer (stale_found == true).

This means we can simplify two test cases in the serve-stale system
test: nodata.example is no longer treated differently than data.example.

(cherry picked from commit aaed7f9d)

Pretty newsworthy.

(cherry picked from commit e44bcc6f)

The NS_QUERYATTR_ANSWERED attribute is to prevent sending a response
twice. Without the attribute, this may happen if a staleonly lookup
found a useful answer and sends a response to the client, and later
recursion ends and also tries to send a response.

The attribute was also used to mask adding a duplicate RRset. This is
considered harmful. When we created a response to the client with a
stale only lookup (regardless if we actually have send the response),
we should clear the rdatasets that were added during that lookup.

Mark such rdatasets with the a new attribute,
DNS_RDATASETATTR_STALE_ADDED. Set a query attribute
NS_QUERYATTR_STALEOK if we may have added rdatasets during a stale
only lookup. Before creating a response on a normal lookup, check if
we can expect rdatasets to have been added during a staleonly lookup.
If so, clear the rdatasets from the message with the attribute
DNS_RDATASETATTR_STALE_ADDED set.

(cherry picked from commit 3d5429f6)

With stale-answer-client-timeout, we may send a response to the client,
but we may want to hold on to the network manager handle, because
recursion is going on in the background, or we need to refresh a
stale RRset.

Simplify the setting of 'nodetach':
* During a staleonly lookup we should not detach the nmhandle, so just
  set it prior to 'query_lookup()'.
* During a staleonly "stalefirst" lookup set the 'nodetach' to true
  if we are going to refresh the RRset.

Now there is no longer the need to clear the 'nodetach' if we go
through the "dbfind_stale", "stale_refresh_window", or "stale_only"
paths.

(cherry picked from commit 48b0dc15)

When doing a staleonly lookup, ignore active RRsets from cache. If we
don't, we may add a duplicate RRset to the message, and hit an
assertion failure in query.c because adding the duplicate RRset to the
ANSWER section failed.

This can happen on a race condition. When a client query is received,
the recursion is started. When 'stale-answer-client-timeout' triggers
around the same time the recursion completes, the following sequence
of events may happen:
1. Queue the "try stale" fetch_callback() event to the client task.
2. Add the RRsets from the authoritative response to the cache.
3. Queue the "fetch complete" fetch_callback() event to the client task.
4. Execute the "try stale" fetch_callback(), which retrieves the
   just-inserted RRset from the database.
5. In "ns_query_done()" we are still recursing, but the "staleonly"
   query attribute has already been cleared. In other words, the
   query will resume when recursion ends (it already has ended but is
   still on the task queue).
6. Execute the "fetch complete" fetch_callback(). It finds the answer
   from recursion in the cache again and tries to add the duplicate to
   the answer section.

This commit changes the logic for finding stale answers in the cache,
such that on "stale_only" lookups actually only stale RRsets are
considered. It refactors the code so that code paths for "dbfind_stale",
"stale_refresh_window", and "stale_only" are more clear.

First we call some generic code that applies in all three cases,
formatting the domain name for logging purposes, increment the
trystale stats, and check if we actually found stale data that we can
use.

The "dbfind_stale" lookup will return SERVFAIL if we didn't found a
usable answer, otherwise we will continue with the lookup
(query_gotanswer()). This is no different as before the introduction of
"stale-answer-client-timeout" and "stale-refresh-time".

The "stale_refresh_window" lookup is similar to the "dbfind_stale"
lookup: return SERVFAIL if we didn't found a usable answer, otherwise
continue with the lookup (query_gotanswer()).

Finally the "stale_only" lookup.

If the "stale_only" lookup was triggered because of an actual client
timeout (stale-answer-client-timeout > 0), and if database lookup
returned a stale usable RRset, trigger a response to the client.
Otherwise return and wait until the recursion completes (or the
resolver query times out).

If the "stale_only" lookup is a "stale-anwer-client-timeout 0" lookup,
preferring stale data over a lookup. In this case if there was no stale
data, or the data was not a positive answer, retry the lookup with the
stale options cleared, a.k.a. a normal lookup. Otherwise, continue
with the lookup (query_gotanswer()) and refresh the stale RRset. This
will trigger a response to the client, but will not detach the handle
because a fetch will be created to refresh the RRset.

(cherry picked from commit 92f7a678)

The stale-answer-client-timeout feature introduced a dependancy on
when a client may be detached from the handle. The dboption
DNS_DBFIND_STALEONLY was reused to track this attribute. This overloads
the meaning of this database option, and actually introduced a bug
because the option was checked in other places. In particular, in
'ns_query_done()' there is a check for 'RECURSING(qctx->client) &&
(!QUERY_STALEONLY(&qctx->client->query) || ...' and the condition is
satisfied because recursion has not completed yet and
DNS_DBFIND_STALEONLY is already cleared by that time (in
query_lookup()), because we found a useful answer and we should detach
the client from the handle after sending the response.

Add a new boolean to the client structure to keep track of client
detach from handle is allowed or not. It is only disallowed if we are
in a staleonly lookup and we didn't found a useful answer.

(cherry picked from commit fee16424)

Remove custom ISC SPNEGO implementation (v9.16)

See merge request !4855

Previously, every function had it's own #ifdef GSSAPI #else #endif block
that defined shim function in case GSSAPI was not being used.  Now the
dummy shim functions have be split out into a single #else #endif block
at the end of the file.

This makes the gssapictx.c similar to 9.17.x code, making the backports
and reviews easier.

The Heimdal Kerberos library handles the OID sets in a different manner.
Unify the handling of the OID sets between MIT and Heimdal
implementations by dynamically creating the OID sets instead of using
static predefined set.  This is how upstream recommends to handle the
OID sets.

The GSSAPI now needs both gssapi and krb5 libraries, so we need to
request both CFLAGS and LIBS from the configure script.

The custom ISC SPNEGO mechanism implementation is no longer needed on
the basis that all major Kerberos 5/GSSAPI (mit-krb5, heimdal and
Windows) implementations support SPNEGO mechanism since 2006.

This commit removes the custom ISC SPNEGO implementation, and removes
the option from both autoconf and win32 Configure script.  Unknown
options are being ignored, so this doesn't require any special handling.

When the authsock.pl script would be terminated with a signal,
it would leave the pidfile around.  This commit adds a signal
handler that cleanups the pidfile on signals that are expected.

[v9_16] Run gcc:tarball CI job in web-triggered pipelines

See merge request !4852

The gcc:tarball CI job may identify problems with tarballs created by
"make dist" of the tarball-create CI job. Enabling the gcc:tarball CI
job in web-triggered pipelines provides developers with a test vector.

(cherry picked from commit 4d5d3b75)

Do not require config.h to use isc/util.h (v9.16)

See merge request !4842