GitLab

Link all dependent libraries to libisc

See merge request !3323

It would fail to link -lisc without additional libraries, which should
not be required.

Add missing CHANGES notes from v9_16 branch

See merge request !3356

CHANGES notes 5379. should have been placeholder

See merge request !3355

Add missing CHANGES notes from v9_11 branch

See merge request !3352

Work around an MSVC bug

Closes #1742

See merge request !3347

The assembly code generated by MSVC for at least some signed comparisons
involving atomic variables incorrectly uses unsigned conditional jumps
instead of signed ones.  In particular, the checks in isc_log_wouldlog()
are affected in a way which breaks logging on Windows and thus also all
system tests involving a named instance.  Work around the issue by
assigning the values returned by atomic_load_acquire() calls in
isc_log_wouldlog() to local variables before performing comparisons.

Add placeholder

See merge request !3348

Merge branch '1574-confidential-issue-rebinding-protection-fail-in-forwarding-mode-master' into 'master'

Resolve "DNS rebinding protection is ineffective when BIND is configured as a forwarding DNS server"

Closes #1574

See merge request !3342

This test asserts that option "deny-answer-aliases" works correctly
when forwarding requests.

As a matter of example, the behavior expected for a forwarder BIND
instance, having an option such as deny-answer-aliases { "domain"; }
is that when forwarding a request for *.anything-but-domain, it is
expected that it will return SERVFAIL if any answer received has a CNAME
for "*.domain".

(cherry picked from commit 9bdb960a)

BIND wasn't honoring option "deny-answer-aliases" when configured to
forward queries.

Before the fix it was possible for nameservers listed in "forwarders"
option to return CNAME answers pointing to unrelated domains of the
original query, which could be used as a vector for rebinding attacks.

The fix ensures that BIND apply filters even if configured as a forwarder
instance.

(cherry picked from commit af6a4de3)

Fix kasp timing issue on Windows

Closes #1669

See merge request !3337

Increate the DNSKEY TTL of the migrate.kasp zone for the following
reason:  The key states are initialized depending on the timing
metadata. If a key is present long enough in the zone it will be
initialized to OMNIPRESENT.  Long enough here is the time when it
was published (when the setup script was run) plus DNSKEY TTL.
Otherwise it is set to RUMOURED, or to HIDDEN if no timing metadata
is set or the time is still in the future.

Since the TTL is "only" 5 minutes, the DNSKEY state may be
initialized to OMNIPRESENT if the test is slow, but we expect it
to be in RUMOURED state.  If we increase the TTL to a couple of
hours it is very unlikely that it will be initialized to something
else than RUMOURED.

The template zone file for server ns6 should have the ns6 domain
name, not ns3.

Now that the timing issue is fixed, we can enable the kasp test
again on Windows.

This fixes another intermittent failure in the kasp system test.
It does not happen often, except for in the Windows platform tests
where it takes a long time to run the tests.

In the "kasp" system test, there is an "rndc reconfig" call which
triggers a new rekey event.  check_next_key_event() verifies the time
remaining from the moment "rndc reconfig" is called until the next key
event.  However, the next key event time is calculated from the key
times provided during key creation (i.e. during test setup).  Given
this, if "rndc reconfig" is called a significant amount of time after
the test is started, some check_next_key_event() checks will fail.

Fix by calculating the time passed since the start of the test and
when 'rndc reconfig' happens.  Substract this time from the
calculated next key event.

This only needs to be done after an "rndc reconfig" on zones where
the keymgr needs to wait for a period of time (for example for keys
to become OMNIPRESENT, or HIDDEN). This is on step 2 and step 5 of
the algorithm rollover.  In step 2 there is a waiting period before
the DNSKEY is OMNIPRESENT, in step 5 there is a waiting period
before the DNSKEY is HIDDEN.

In step 1 new keys are created, in step 3 and 4 key states just
entered OMNIPRESENT, and in step 6 we no longer care because the
key lifetime is unlimited and we default to checking once per hour.

Regardless of our indifference about the next key event after step 6,
change some of the key timings in the setup script to better
reflect reality: DNSKEY is in HIDDEN after step 5, DS times have
changed when the new DS became active.

Resolve "kasp system test timing issue with view zones"

Closes #1715

See merge request !3334

Resolve "kasp system test timing issue with view zones"

See merge request !3333

Fix the some of the underflowing statistics

See merge request !3299

In case of normal fetch, the .recursionquota is attached and
ns_statscounter_recursclients is incremented when the fetch is created.  Then
the .recursionquota is detached and the counter decremented in the
fetch_callback().

In case of prefetch or rpzfetch, the quota is attached, but the counter is not
incremented.  When we reach the soft-quota, the function returns early but don't
detach from the quota, and it gets destroyed during the ns_client_endrequest(),
so no memory was leaked.

But because the ns_statscounter_recursclients is only incremented during the
normal fetch the counter would be incorrectly decremented on two occassions:

1) When we reached the softquota, because the quota was not properly detached
2) When the prefetch or rpzfetch was cancelled mid-flight and the callback
   function was never called.

Resolve "OOM issue after upgrade from 9.14.3 to 9.14.4"

Closes #1179

See merge request !3304

Key tags are not unique across algorithms.

Rather than group key ids together, group key id with its
corresponding counters. This should make growing / shrinking easier
than having keyids then counters.

Add a statschannel test case for DNSSEC sign metrics that has more
keys than there are allocated stats counters for.  This will produce
gibberish, but at least it should not crash.

The first attempt to add DNSSEC sign statistics was naive: for each
zone we allocated 64K counters, twice.  In reality each zone has at
most four keys, so the new approach only has room for four keys per
zone. If after a rollover more keys have signed the zone, existing
keys are rotated out.

The DNSSEC sign statistics has three counters per key, so twelve
counters per zone. First counter is actually a key id, so it is
clear what key contributed to the metrics.  The second counter
tracks the number of generated signatures, and the third tracks
how many of those are refreshes.

This means that in the zone structure we no longer need two separate
references to DNSSEC sign metrics: both the resign and refresh stats
are kept in a single dns_stats structure.

Incrementing dnssecsignstats:

Whenever a dnssecsignstat is incremented, we look up the key id
to see if we already are counting metrics for this key.  If so,
we update the corresponding operation counter (resign or
refresh).

If the key is new, store the value in a new counter and increment
corresponding counter.

If all slots are full, we rotate the keys and overwrite the last
slot with the new key.

Dumping dnssecsignstats:

Dumping dnssecsignstats is no longer a simple wrapper around
isc_stats_dump, but uses the same principle.  The difference is that
rather than dumping the index (key tag) and counter, we have to look
up the corresponding counter.