Add missing DNS results from 9.16. We only care about
DNS_R_NSEC3ITERRANGE but better to sync and use the same numbers than
use a different number for this result code than what is used in 9.16.
* The location of the digest type field has changed to where the
reserved field was.
* The reserved field is now called scheme and is where the digest
type field was.
* Digest type 2 has been defined (SHA256).
(cherry picked from commit 8510ccaa54)
5625. [func] Reduce the supported maximum number of iterations
that can be configured in an NSEC3 zones to 150.
[GL #2642]
(cherry picked from commit e04f06873f)
dnstap_test produces TSAN errors which originate in libfstrm.so. Unless
libfstrm is TSAN clean or a workaround is placed in libfstrm sources,
suppressing TSAN coming from libfstrm is necessary to test DNSTAP under
TSAN.
(cherry picked from commit c97c6fbfea)
All platforms but OpenBSD have dnstap dependencies readily in their
respective repositories, and dnstap thus can be tested there. Given that
majority of images have dnstap dependencies available, it seems fitting
to make dnstap enabled by default.
Also dnstap is disabled for TSAN jobs configured with --disable-atomic
as it's known to produce TSAN errors (#2664) and for the gcc:noatomics
job because it has threads disabled, which is a requirement for dnstap.
(cherry picked from commit deff0ae317)
[CVE-2021-25215] [v9_11] Properly answer queries for DNAME records that require the DNAME to be processed to resolve itself
See merge request isc-private/bind9!282
When answering a query, named should never attempt to add the same RRset
to the ANSWER section more than once. However, such a situation may
arise when chasing DNAME records: one of the DNAME records placed in the
ANSWER section may turn out to be the final answer to a client query,
but there is no way to know that in advance. Tweak the relevant INSIST
assertion in query_find() so that it handles this case properly. The
rdataset is freed later anyway, so there is no need to clean it up
immediately.
If a zone transfer results in a zone not having any NS records, named
stops serving it because such a zone is broken. Do the same if an
incoming zone transfer results in a zone lacking an SOA record at the
apex or containing more than one SOA record.
An IXFR containing SOA records with owner names different than the
transferred zone's origin can result in named serving a version of that
zone without an SOA record at the apex. This causes a RUNTIME_CHECK
assertion failure the next time such a zone is refreshed. Fix by
immediately rejecting a zone transfer (either an incremental or
non-incremental one) upon detecting an SOA record not placed at the apex
of the transferred zone.
GitLab CI pipelines do not currently include a Linux job that would have
GSSAPI support disabled. Add the "--without-gssapi" option to the
./configure invocation on Debian 9 to address that deficiency and also
to continuously test that build-time switch.
(cherry picked from commit a3957af864)
If "tkey-gssapi-credential" is set in the configuration and GSSAPI
support is not available, named will refuse to start. As the test
system framework does not support starting named instances
conditionally, ensure that "tkey-gssapi-credential" is only present in
named.conf if GSSAPI support is available.
(cherry picked from commit 6feac68b50)
Mark AndrewsandMatthijs Mekking
Michal Nowak
Michał Kępień
Tinderbox UserandMichał Kępień