Adjust serve-stale test

The number of queries to use in the burst can be reduced, as we have
a very low fetch limit of 1.

The dig command in 'wait_for_fetchlimits()' should time out sooner as
we expect a SERVFAIL to be returned promptly.

Enabling serve-stale can be done before hitting fetch-limits. This
reduces the chance that the resolver queries time out and fetch count
is reset. The chance of that happening is already slim because
'resolver-query-timeout' is 10 seconds, but better to first let the
data become stale rather than doing that while attempting to resolve.

Use stale on error also when unable to recurse

The 'query_usestale()' function was only called when in
'query_gotanswer()' and an unexpected error occurred. This may have
been "quota reached", and thus we were in some cases returning
stale data on fetch-limits (and if serve-stale enabled of course).

But we can also hit fetch-limits when recursing because we are
following a referral (in 'query_notfound()' and
'query_delegation_recurse()'). Here we should also check for using
stale data in case an error occurred.

Specifically don't check for using stale data when refetching a
zero TTL RRset from cache.

Move the setting of DNS_DBFIND_STALESTART into the 'query_usestale()'
function to avoid code duplication.

Merge branch '2469-cid-281461-untrusted-loop-bound' into 'main'

Resolve "CID 281461: untrusted loop bound"

Closes #2469

See merge request isc-projects/bind9!4642

Attempt to silence untrusted loop bound

Assign hit_len + key_len to len and test the result
rather than recomputing and letting the compiler simplify.

    213        isc_region_consume(&region, 2); /* hit length + algorithm */
        9. tainted_return_value: Function uint16_fromregion returns tainted data. [show details]
        10. tainted_data_transitive: Call to function uint16_fromregion with tainted argument *region.base returns tainted data.
        11. tainted_return_value: Function uint16_fromregion returns tainted data.
        12. tainted_data_transitive: Call to function uint16_fromregion with tainted argument *region.base returns tainted data.
        13. var_assign: Assigning: key_len = uint16_fromregion(&region), which taints key_len.
    214        key_len = uint16_fromregion(&region);
        14. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
        15. Condition key_len == 0, taking false branch.
    215        if (key_len == 0) {
    216                RETERR(DNS_R_FORMERR);
    217        }
        16. Condition !!(_r->length >= _l), taking true branch.
        17. Condition !!(_r->length >= _l), taking true branch.
    218        isc_region_consume(&region, 2);
        18. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
        19. Condition region.length < (unsigned int)(hit_len + key_len), taking false branch.
    219        if (region.length < (unsigned)(hit_len + key_len)) {
    220                RETERR(DNS_R_FORMERR);
    221        }
    222
        20. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
        21. Condition _r != 0, taking false branch.
    223        RETERR(mem_tobuffer(target, rr.base, 4 + hit_len + key_len));
        22. lower_bounds: Casting narrower unsigned key_len to wider signed type int effectively tests its lower bound.
        23. var_assign_var: Compound assignment involving tainted variable 4 + hit_len + key_len to variable source->current taints source->current.
    224        isc_buffer_forward(source, 4 + hit_len + key_len);
    225
    226        dns_decompress_setmethods(dctx, DNS_COMPRESS_NONE);

    CID 281461 (#1 of 1): Untrusted loop bound (TAINTED_SCALAR)
        24. tainted_data: Using tainted variable source->active - source->current as a loop boundary.
    Ensure that tainted values are properly sanitized, by checking that their values are within a permissible range.
    227        while (isc_buffer_activelength(source) > 0) {
    228                dns_name_init(&name, NULL);
    229                RETERR(dns_name_fromwire(&name, source, dctx, options, target));
    230        }

Merge branch 'mnowak/check-arm-pdf-validity' into 'main'

Check PDF file structure with QPDF

See merge request isc-projects/bind9!4620

Check PDF file structure with QPDF

"qpdf --check" checks file structure of generated ARM PDF.

Merge branch '2377-allow-a-records-below-an-_spf-label-as-a-check-names-exception' into 'main'

Resolve "Allow A records below an '_spf' label as a check-names exception"

Closes #2377

See merge request isc-projects/bind9!4529

Add release note entry

Add CHANGES

Check that A record is accepted with _spf label present

Allow A records below '_spf' labels as recommend by RFC7208

Merge branch '2375-dnssec-policy-three-is-a-crowd-rollover-bug' into 'main'

Resolve "three is a crowd" dnssec-policy key rollover bug

Closes #2375

See merge request isc-projects/bind9!4541

Add kasp test todo for [#2375]

This bugfix has been manually verified but is missing a unit test.
Created GL #2471 to track this.

Use NUM_KEYSTATES constant where appropriate

We use the number 4 a lot when working on key states. Better to use
the NUM_KEYSTATES constant instead.

Add change and release note for [#2375]

News worthy.

Cleanup keymgr.c

Three small cleanups:

1. Remove an unused keystr/dst_key_format.
2. Initialize a dst_key_state_t state with NA.
3. Update false comment about local policy (local policy only adds
   barrier on transitions to the RUMOURED state, not the UNRETENTIVE
   state).

Fix DS/DNSKEY hidden or chained functions

There was a bug in function 'keymgr_ds_hidden_or_chained()'.

The funcion 'keymgr_ds_hidden_or_chained()' implements (3e) of rule2
as defined in the "Flexible and Robust Key Rollover" paper. The rules
says: All DS records need to be in the HIDDEN state, or if it is not
there must be a key with its DNSKEY and KRRSIG in OMNIPRESENT, and
its DS in the same state as the key in question. In human langauge,
if all keys have their DS in HIDDEN state you can do what you want,
but if a DS record is available to some validators, there must be
a chain of trust for it.

Note that the barriers on transitions first check if the current
state is valid, and then if the next state is valid too. But
here we falsely updated the 'dnskey_omnipresent' (now 'dnskey_chained')
with the next state. The next state applies to 'key' not to the state
to be checked. Updating the state here leads to (true) always, because
the key that will move its state will match the falsely updated
expected state. This could lead to the assumption that Key 2 would be
a valid chain of trust for Key 1, while clearly the presence of any
DS is uncertain.

The fix here is to check if the DNSKEY and KRRSIG are in OMNIPRESENT
state for the key that does not have its DS in the HIDDEN state, and
only if that is not the case, ensure that there is a key with the same
algorithm, that provides a valid chain of trust, that is, has its
DNSKEY, KRRSIG, and DS in OMNIPRESENT state.

The changes in 'keymgr_dnskey_hidden_or_chained()' are only cosmetical,
renaming 'rrsig_omnipresent' to 'rrsig_chained' and removing the
redundant initialization of the DST_KEY_DNSKEY expected state to NA.

Update keymgr_key_is_successor() calls

The previous commit changed the function definition of
'keymgr_key_is_successor()', this commit updates the code where
this function is called.

In 'keymgr_key_exists_with_state()' the logic is also updated slightly
to become more readable. First handle the easy cases:
- If the key does not match the state, continue with the next key.
- If we found a key with matching state, and there is no need to
  check the successor relationship, return (true).
- Otherwise check the successor relationship.

In 'keymgr_key_has_successor()' it is enough to check if a key has
a direct successor, so instead of calling 'keymgr_key_is_successor()',
we can just check 'keymgr_direct_dep()'.

In 'dns_keymgr_run()', we want to make sure that there is no
dependency on the keys before retiring excess keys, so replace
'keymgr_key_is_successor()' with 'keymgr_dep()'.

Implement Equation(2) of "Flexible Key Rollover"

So far the key manager could only deal with two keys in a rollover,
because it used a simplified version of the successor relationship
equation from "Flexible and Robust Key Rollover" paper. The simplified
version assumes only two keys take part in the key rollover and it
for that it is enough to check the direct relationship between two
keys (is key x the direct predecessor of key z and is key z the direct
successor of key x?).

But when a third key (or more keys) comes into the equation, the key
manager would assume that one key (or more) is redundant and removed
it from the zone prematurely.

Fix by implementing Equation(2) correctly, where we check for
dependencies on keys:

z ->T x: Dep(x, T) = ∅ ∧
         (x ∈ Dep(z, T) ∨
          ∃ y ∈ Dep(z, T)(y != z ∧ y ->T x ∧ DyKyRySy = DzKzRzSz))

This says: key z is a successor of key x if:
- key x depends on key z if z is a direct successor of x,
- or if there is another key y that depends on key z that has identical
  key states as key z and key y is a successor of key x.
- Also, key x may not have any other keys depending on it.

This is still a simplified version of Equation(2) (but at least much
better), because the paper allows for a set of keys to depend on a
key. This is defined as the set Dep(x, T). Keys in the set Dep(x, T)
have a dependency on key x for record type T. The BIND implementation
can only have one key in the set Dep(x, T). The function
'keymgr_dep()' stores this key in 'uint32_t *dep' if there is a
dependency.

There are two scenarios where multiple keys can depend on a single key:

1. Rolling keys is faster than the time required to finish the
   rollover procedure. This scenario is covered by the recursive
   implementation, and checking for a chain of direct dependencies
   will suffice.

2. Changing the policy, when a zone is requested to be signed with
   a different key length for example. BIND 9 will not mark successor
   relationships in this case, but tries to move towards the new
   policy. Since there is no successor relationship, the rules are
   even more strict, and the DNSSEC reconfiguration is actually slower
   than required.

Note: this commit breaks the build, because the function definition
of 'keymgr_key_is_successor' changed. This will be fixed in the
following commit.

Merge branch '2468-cid-318094-null-pointer-dereferences-reverse_inull' into 'main'

Resolve "CID 318094:  Null pointer dereferences  (REVERSE_INULL)"

Closes #2468

See merge request isc-projects/bind9!4641

Remove redundant 'version == NULL' check

    *** CID 318094:  Null pointer dereferences  (REVERSE_INULL)
    /lib/dns/rbtdb.c: 1389 in newversion()
    1383      version->xfrsize = rbtdb->current_version->xfrsize;
    1384      RWUNLOCK(&rbtdb->current_version->rwlock, isc_rwlocktype_read);
    1385      rbtdb->next_serial++;
    1386      rbtdb->future_version = version;
    1387      RBTDB_UNLOCK(&rbtdb->lock, isc_rwlocktype_write);
    1388
       CID 318094:  Null pointer dereferences  (REVERSE_INULL)
       Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
    1389      if (version == NULL) {
    1390      return (result);
    1391      }
    1392
    1393      *versionp = version;
    1394

Merge branch '1144-dns-over-https-server' into 'main'

Resolve "Encrypted DNS - RFC 8484, DNS over HTTPS, DOH (also DoT comments)"

Closes #1144

See merge request isc-projects/bind9!4644

CHANGES, release notes

Drop gcc:sid:i386 from GitLab CI

Building sid-i386 in Docker no longer works and we don't have a viable
alternative now, so dropping gcc:sid:i386 is our only option in this
very moment.

support "tls ephemeral" with https

tls and http configuration code was unnecessarily complex

removed the isc_cfg_http_t and isc_cfg_tls_t structures
and the functions that loaded and accessed them; this can
be done using normal config parser functions.

Unit-test fixes and manual page updates for DoH configuration

This commit contains fixes to unit tests to make them work well on
various platforms (in particular ones shipping old versions of
OpenSSL) and for different configurations.

It also updates the generated manpage to include DoH configuration
options.

Initial support for DNS-over-HTTP(S)

This commit completes the support for DNS-over-HTTP(S) built on top of
nghttp2 and plugs it into the BIND. Support for both GET and POST
requests is present, as required by RFC8484.

Both encrypted (via TLS) and unencrypted HTTP/2 connections are
supported. The latter are mostly there for debugging/troubleshooting
purposes and for the means of encryption offloading to third-party
software (as might be desirable in some environments to simplify TLS
certificates management).

nghttp2-based HTTP layer in netmgr

This commit includes work-in-progress implementation of
DNS-over-HTTP(S).

Server-side code remains mostly untested, and there is only support
for POST requests.

Add isc_mem_strndup() function

This commit adds an implementation of strndup() function which
allocates memory from the supplied isc_mem_t memory context.

update ARM with "http" grammar

add a link to the http statement grammar and explanations and examples
for configuring DoH listeners.

Add parser support for DoH configuration options

This commit adds stub parser support and tests for:
- an "http" global option for HTTP/2 endpoint configuration.
- command line options to set http or https port numbers by
  specifying -p http=PORT or -p https=PORT.  (NOTE: this change
  only affects syntax; specifying HTTP and HTTPS ports on the
  command line currently has no effect.)
- named.conf options "http-port" and "https-port"
- HTTPSPORT environment variable for use when running tests.

Resurrect old TLS code

This commit resurrects the old TLS code from
8f73c70d23e26954165fd44ce5617a95f112bcff.

It also includes numerous stability fixes and support for
isc_nm_cancelread() for the TLS layer.

The code was resurrected to be used for DoH.

Merge branch '2448-tweak-sphinx-build-invocations' into 'main'

Tweak sphinx-build invocations

Closes #2448

See merge request isc-projects/bind9!4640

Make sphinx-build warnings fatal

In order to prevent documentation building issues from being glossed
over, pass the -W command line switch to all sphinx-build invocations.
This causes the latter to return with a non-zero exit code whenever any
Sphinx warnings are triggered.

Address a Sphinx duplicate label warning

Both doc/man/ddns-confgen.rst and doc/man/tsig-keygen.rst include
bin/confgen/tsig-keygen.rst, which defines a "man_tsig-keygen" label.
This triggers the following warning when running sphinx-build with the
-W command line switch in the doc/man/ directory:

    ../../bin/confgen/tsig-keygen.rst:27: WARNING: duplicate label man_tsig-keygen, other instance in /tmp/bind9/doc/man/ddns-confgen.rst

Move the offending label from bin/confgen/tsig-keygen.rst to the proper
spot in doc/arm/manpages.rst to avoid effectively defining it twice in
different source documents while still allowing the relevant man page to
be referenced in the ARM.  Also rename that label so that it more
closely matches the content it points to.  As the label no longer
immediately precedes a section title in its new location, use
:ref:`Title <label>` syntax for the only reference to the
tsig-keygen/ddns-confgen man page in the ARM.

Use separate sphinx-build cache directories

Simultaneously starting multiple sphinx-build instances with the -d
command line switch set to a common value (which is what happens when
e.g. "make -j6 doc" is run) causes intermittent problems which we failed
to notice before because they only trigger Sphinx warnings, not errors,
e.g.:

    WARNING: toctree contains ref to nonexisting file 'reference'

The message above is not triggered because doc/arm/reference.rst is
actually missing from disk at any point, but rather because a temporary
file created by one sphinx-build instance gets truncated by another one
working in parallel (the confusing message quoted above is logged
because of an overly broad "except" statement in Sphinx code).

Prevent this problem from being triggered by making each sphinx-build
process use its own dedicated cache directory.

Merge branch '2406-kasp-init-inactive-delete-metadata' into 'main'

Resolve "kasp: look at Inactive/Delete when initializing state files"

Closes #2406

See merge request isc-projects/bind9!4599

Remove initialize goal code

Since keys now have their goals initialized in 'keymgr_key_init()',
remove this redundant piece of code in 'keymgr_key_run()'.

Correctly initialize old key with state file

The 'key_init()' function is used to initialize a state file for keys
that don't have one yet. This can happen if you are migrating from a
'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration.

It did not look at the "Inactive" and "Delete" timing metadata and so
old keys left behind in the key directory would also be considered as
a possible active key. This commit fixes this and now explicitly sets
the key goal to OMNIPRESENT for keys that have their "Active/Publish"
timing metadata in the past, but their "Inactive/Delete" timing
metadata in the future. If the "Inactive/Delete" timing metadata is
also in the past, the key goal is set to HIDDEN.

If the "Inactive/Delete" timing metadata is in the past, also the
key states are adjusted to either UNRETENTIVE or HIDDEN, depending on
how far in the past the metadata is set.

Update legacy-keys kasp test

The 'legacy-keys.kasp' test checks that a zone with key files but not
yet state files is signed correctly. This test is expanded to cover
the case where old key files still exist in the key directory. This
covers bug #2406 where keys with the "Delete" timing metadata are
picked up by the keymgr as active keys.

Fix the 'legacy-keys.kasp' test, by creating the right key files
(for zone 'legacy-keys.kasp', not 'legacy,kasp').

Use a unique policy for this zone, using shorter lifetimes.

Create two more keys for the zone, and use 'dnssec-settime' to set
the timing metadata in the past, long enough ago so that the keys
should not be considered by the keymgr.

Update the 'key_unused()' test function, and consider keys with
their "Delete" timing metadata in the past as unused.

Extend the test to ensure that the keys to be used are not the old
predecessor keys (with their "Delete" timing metadata in the past).

Update the test so that the checks performed are consistent with the
newly configured policy.

Merge branch '1697-isc_rwlock_init-can-no-longer-fail-in-master-clean-up-calls' into 'main'

Resolve "isc_rwlock_init can no longer fail in master, clean up calls."

Closes #2462 and #1697

See merge request isc-projects/bind9!4635

Cleanup redundant isc_rwlock_init() result checks

Merge branch '2444-call-freeaddrinfo-in-test_client' into 'main'

Fix addrinfo leak in test_client.c

Closes #2444

See merge request isc-projects/bind9!4629

Fix addrinfo leak in test_client.c

The addrinfo we got from getaddrinfo() was never freed.

Merge branch '2392-xot-xfrin' into 'main'

Add support for incoming tranfers via XoT

Closes #2392

See merge request isc-projects/bind9!4571

CHANGES and release notes

implement xfrin via XoT

Add support for a "tls" key/value pair for zone primaries, referencing
either a "tls" configuration statement or "ephemeral". If set to use
TLS, zones will send SOA and AXFR/IXFR queries over a TLS channel.

Merge branch '2442-tsan-error-lib-dns-rbtdb-c' into 'main'

Resolve "TSAN error: lib/dns/rbtdb.c"

Closes #2442

See merge request isc-projects/bind9!4609

Fix race condition on check_stale_header

This commit fix a race that could happen when two or more threads have
failed to refresh the same RRset, the threads could simultaneously
attempt to update the header->last_refresh_fail_ts field in
check_stale_header, a field used to implement stale-refresh-time.

By making this field atomic we avoid such race.

Merge branch '2434-fetch-limit-serve-stale' into 'main'

Resolve "Serve stale when fetch limits are hit"

Closes #2434

See merge request isc-projects/bind9!4607

Add notes and change entry for [#2434]

This concludes the serve-stale improvements.

Add test for serve-stale /w fetch-limits

Add a test case when fetch-limits are reached and we have stale data
in cache.

This test starts with a positive answer for 'data.example/TXT' in
cache.

1. Reload named.conf to set fetch limits.
2. Disable responses from the authoritative server.
3. Now send a batch of queries to the resolver, until hitting the
   fetch limits. We can detect this by looking at the response RCODE,
   at some point we will see SERVFAIL responses.
4. At that point we will turn on serve-stale.
5. Clients should see stale answers now.
6. An incoming query should not set the stale-refresh-time window,
   so a following query should still get a stale answer because of a
   resolver failure (and not because it was in the stale-refresh-time
   window).

Only start stale refresh window when resuming

If we did not attempt a fetch due to fetch-limits, we should not start
the stale-refresh-time window.

Introduce a new flag DNS_DBFIND_STALESTART to differentiate between
a resolver failure and unexpected error. If we are resuming, this
indicates a resolver failure, then start the stale-refresh-time window,
otherwise don't start the stale-refresh-time window, but still fall
back to using stale data.

(This commit also wraps some docstrings to 80 characters width)

Use stale data also if we are not resuming

Before this change, BIND will only fallback to using stale data if
there was an actual attempt to resolve the query. Then on a timeout,
the stale data from cache becomes eligible.

This commit changes this so that on any unexpected error stale data
becomes eligble (you would still have to have 'stale-answer-enable'
enabled of course).

If there is no stale data, this may return in an error again, so don't
loop on stale data lookup attempts. If the DNS_DBFIND_STALEOK flag is
set, this means we already tried to lookup stale data, so if that is
the case, don't use stale again.

Merge branch '2420-xmlfreetextwriter-could-be-called-twice' into 'main'

Resolve "CID 316510: Memory - corruptions (USE_AFTER_FREE)"

Closes #2420

See merge request isc-projects/bind9!4613

Add CHANGES entry for  [GL #2420]

Stop xmlFreeTextWriter being called twice

xmlFreeTextWriter could be called twice if xmlDocDumpFormatMemoryEnc
failed.

Merge branch 'marka-changes-line-length' into 'main'

Detect overly long CHANGES lines

See merge request isc-projects/bind9!4603

fix overly long line

Detect overly long CHANGES lines

Merge branch '2413-after-upgrade-to-bind9-9-16-11-named-is-killed-with-status-11-segv' into 'main'

Resolve "after upgrade to bind9 9.16.11 named is killed with status=11/SEGV"

Closes #2413

See merge request isc-projects/bind9!4592

Add release note for [GL #2413]

Add CHANGES for [GL #2413]

Add a named acl example

Require 'ctx' to be non-NULL in cfg_acl_fromconfig{,2}

Pass an afg_aclconfctx_t structure to cfg_acl_fromconfig

in named_zone_inlinesigning.  A NULL pointer does not work.

Merge branch '2391-check-nsupdate-y-for-all-hmac-algorithms' into 'main'

Resolve "Check 'nsupdate -y' for all hmac algorithms."

Closes #2391

See merge request isc-projects/bind9!4569

Check that 'nsupdate -y' works for all HMAC algorithms

Merge branch '2073-dnssec-verify-tries-all-keys-which-results-in-poor-performance' into 'main'

Resolve "dnssec-verify tries all keys which results in poor performance"

Closes #2073

See merge request isc-projects/bind9!4411

Add CHANGES note

Optimise dnssec-verify

dns_dnssec_keyfromrdata() only needs to be called once per DNSKEY
rather than once per verification attempt.

Merge branch '2342-rndc-retransfer-issues-misleading-diagnostic-on-primary-zone' into 'main'

Resolve "rndc retransfer issues misleading diagnostic on primary zone"

Closes #2342

See merge request isc-projects/bind9!4482

Add CHANGES

Check 'rndc retransfer' of primary error message

Improve the diagnostic 'rndc retransfer' error message

Merge branch '2178-dnssec-fromlabel-ec_crash' into 'main'

Resolve "dnssec-keyfromlabel  ECDSAP256SHA256 error on AEP Keypers HSM"

Closes #2178

See merge request isc-projects/bind9!4495

Make opensslecdsa_parse use fromlabel

When 'opensslecdsa_parse()' encounters a label tag in the private key
file, load the private key with 'opensslecdsa_fromlabel()'. Otherwise
load it from the private structure.

This was attempted before with 'load_privkey()' and 'uses_engine()',
but had the same flaw as 'opensslecdsa_fromlabel()' had previously,
that is getting the private and public key separately, juggling with
pointers between EC_KEY and EVP_PKEY, did not create a valid
cryptographic key that could be used for signing.

Simplify opensslecdsa_fromlabel

The 'opensslecdsa_fromlabel()' function does not need to get the
OpenSSL engine twice to load the private and public key. Also no need
to call 'dst_key_to_eckey()' as the EC_KEY can be derived from the
loaded EVP_PKEY's.

Add some extra checks to ensure the key has the same base id and curve
(group nid) as the dst key.

Since we already have the EVP_PKEY, no need to call 'finalize_eckey()',
instead just set the right values in the key structure.

Replace EVP_DigestFinal with EVP_DigestFinal_ex

The openssl docs claim that EVP_DigestFinal() is obsolete and that
one should use EVP_DigestFinal_ex() instead.

Add notes and changes for [#2178]

Don't set pubkey if eckey already has public key

The 'ecdsa_check()' function tries to correctly set the public key
on the eckey, but this should be skipped if the public key is
retrieved via the private key.

ECDSA code should not use RSA label

The 'opensslecdsa_tofile()' function tags the label as an RSA label,
that is a copy paste error and should be of course an ECDSA label.

Correctly update pointers to pubkey and privkey

The functions 'load_pubkey_from_engine()' and
'load_privkey_from_engine()' did not correctly store the pointers.

Update both functions to add 'EC_KEY_set_public_key()' and
'EC_KEY_set_private_key()' respectively, so that the pointers to
the public and private keys survive the "load from engine" functions.

load_pubkey_from_engine() should load public key

The 'function load_pubkey_from_engine()' made a call to the libssl
function 'ENGINE_load_private_key'.  This is a copy paste error and
should be 'ENGINE_load_public_key'.

Merge branch '2403-dig-has-a-fit-with-option-multi-typo-on-multi' into 'main'

Report unknown dash option during the pre-parse phase

Closes #2403

See merge request isc-projects/bind9!4590

Add CHANGES note for [GL #2403]

Report unknown dash option during the pre-parse phase

Merge branch 'mnowak/add-rsabigexponent-README' into 'main'

Add README.md file to rsabigexponent system test

See merge request isc-projects/bind9!4579

Add README.md file to rsabigexponent system test

This README.md describes why is bigkey needed.

Merge branch '2247-add-serve-stale-option-to-set-client-timeout' into 'main'

Resolve "Add serve-stale option to set client timeout"

Closes #2247

See merge request isc-projects/bind9!4514

Rewrap comments to 80 char width serve-stale test

Update code flow in query.c wrt stale data

First of all, there was a flaw in the code related to the
'stale-refresh-time' option. If stale answers are enabled, and we
returned stale data, then it was assumed that it was because we were
in the 'stale-refresh-time' window. But now we could also have returned
stale data because of a 'stale-answer-client-timeout'. To fix this,
introduce a rdataset attribute DNS_RDATASETATTR_STALE_WINDOW to
indicate whether the stale cache entry was returned because the
'stale-refresh-time' window is active.

Second, remove the special case handling when the result is
DNS_R_NCACHENXRRSET. This can be done more generic in the code block
when dealing with stale data.

Putting all stale case handling in the code block when dealing with
stale data makes the code more easy to follow.

Update documentation to be more verbose and to match then new code
flow.

Extracted common function from query_lookup and query_refresh_rrset

Both functions employed the same code lines to allocate query context
buffers, which are used to store query results, so this shared portion
of code was extracted out to a new function, qctx_prepare_buffers.

Also, this commit uses qctx_init to initialize the query context whitin
query_refresh_rrset function.

Small optimization in query_usestale

This commit makes the code in query_usestale easier to follow, it also
doesn't attach/detach to the database if stale answers are not enabled.

Add CHANGES note for [GL #2247]

Add documentation for stale-answer-client-timeout

Add system tests for stale-answer-client-timeout

This commit add 4 tests for the new option:
1. Test default configuration of stale-answer-client-timeout, a
   value of 1.8 seconds, with stale-refresh-time disabled.

2. Test disabling of stale-answer-client-timeout.

3. Test stale-answer-client-timeout with a value of zero, in this
   case we take advantage of a log entry which shows that a stale
   answer was promptly used before an attempt to refresh the RRset
   is made. We also check, by activating a disabled authoritative
   server, that the RRset was successfully refreshed after that.

4. Test stale-answer-client-timeout 0 with stale-refresh-time 4, in
   this test we want to ensure a couple things:

   - If we have a stale RRSet entry in cache, a request must be
 promptly answered with this data, while BIND must also attempt
 to refresh the RRSet in background.

   - If the attempt to refresh the RRSet times out, the RRSet must
 have its stale-refresh-time window activated.

   - If a new request for the same RRSet arrives, it must be
 promptly answered with stale data due to stale-refresh-time
 being active for this RRSet, in this case no attempt to refresh
 the RRSet is made.

   - Enable authoritative server, ensure that the RRSet was not
 refreshed, to honor stale-refresh-time.

   - Wait for stale-refresh-window time pass, send another request
 for the same RRSet, this time we expect the answer to be the
 stale entry in cache being hit due to
 stale-answer-client-timeout 0.

    - Send another request, this time we expect the answer to be an
  active RRSet, since it must have been refreshed during the
  previous request.

Allow stale data to be used before name resolution

This commit allows stale RRset to be used (if available) for responding
a query, before an attempt to refresh an expired, or otherwise resolve
an unavailable RRset in cache is made.

For that to work, a value of zero must be specified for
stale-answer-client-timeout statement.

To better understand the logic implemented, there are three flags being
used during database lookup and other parts of code that must be
understood:

. DNS_DBFIND_STALEOK: This flag is set when BIND fails to refresh a
  RRset due to timeout (resolver-query-timeout), its intent is to
  try to look for stale data in cache as a fallback, but only if
  stale answers are enabled in configuration.

  This flag is also used to activate stale-refresh-time window, since it
  is the only way the database knows that a resolution has failed.

. DNS_DBFIND_STALEENABLED: This flag is used as a hint to the database
  that it may use stale data. It is always set during query lookup if
  stale answers are enabled, but only effectively used during
  stale-refresh-time window. Also during this window, the resolver will
  not try to resolve the query, in other words no attempt to refresh the
  data in cache is made when the stale-refresh-time window is active.

. DNS_DBFIND_STALEONLY: This new introduced flag is used when we want
  stale data from the database, but not due to a failure in resolution,
  it also doesn't require stale-refresh-time window timer to be active.
  As long as there is a stale RRset available, it should be returned.
  It is mainly used in two situations:

    1. When stale-answer-client-timeout timer is triggered: in that case
       we want to know if there is stale data available to answer the
       client.
    2. When stale-answer-client-timeout value is set to zero: in that
       case, we also want to know if there is some stale RRset available
       to promptly answer the client.

We must also discern between three situations that may happen when
resolving a query after the addition of stale-answer-client-timeout
statement, and how to handle them:

1. Are we running query_lookup() due to stale-answer-client-timeout
       timer being triggered?

       In this case, we look for stale data, making use of
       DNS_DBFIND_STALEONLY flag. If a stale RRset is available then
       respond the client with the data found, mark this query as
       answered (query attribute NS_QUERYATTR_ANSWERED), so when the
       fetch completes the client won't be answered twice.

       We must also take care of not detaching from the client, as a
       fetch will still be running in background, this is handled by the
       following snippet:

       if (!QUERY_STALEONLY(&client->query)) {
           isc_nmhandle_detach(&client->reqhandle);
       }

       Which basically tests if DNS_DBFIND_STALEONLY flag is set, which
       means we are here due to a stale-answer-client-timeout timer
       expiration.

    2. Are we running query_lookup() due to resolver-query-timeout being
       triggered?

       In this case, DNS_DBFIND_STALEOK flag will be set and an attempt
       to look for stale data will be made.
       As already explained, this flag is algo used to activate
       stale-refresh-time window, as it means that we failed to refresh
       a RRset due to timeout.
       It is ok in this situation to detach from the client, as the
       fetch is already completed.

    3. Are we running query_lookup() during the first time, looking for
       a RRset in cache and stale-answer-client-timeout value is set to
       zero?

       In this case, if stale answers are enabled (probably), we must do
       an initial database lookup with DNS_DBFIND_STALEONLY flag set, to
       indicate to the database that we want stale data.

       If we find an active RRset, proceed as normal, answer the client
       and the query is done.

       If we find a stale RRset we respond to the client and mark the
       query as answered, but don't detach from the client yet as an
       attempt in refreshing the RRset will still be made by means of
       the new introduced function 'query_resolve'.

       If no active or stale RRset is available, begin resolution as
       usual.

Added option for disabling stale-answer-client-timeout

This commit allows to specify "disabled" or "off" in
stale-answer-client-timeout statement. The logic to support this
behavior will be added in the subsequent commits.

This commit also ensures an upper bound to stale-answer-client-timeout
which equals to one second less than 'resolver-query-timeout'.