Cloning to a stable location allows clearer handling of paths when
calling scripts from CI jobs.
`unit:gcc:tarball` and `system:gcc:tarball` do `cd bind-*` in
`before_script` which lead to the `bind9-qa` directory ending up in
a different place in exactly these two jobs and that made reasoning
about paths in `.system_test_common` and `.unit_test_common` tricky.
(cherry picked from commit 482c1cc72f)
Use `python -m` for running the custom servers.
This allows the use of relative imports in the server modules and in
turn linting the modules.
(cherry picked from commit 407df9599c)
A stale answer could have been served in case of multiple upstream
failures when following the CNAME chains. This has been fixed.
Closes#5751
Backport of MR !11558
Merge branch 'backport-5751-clear-staleflags-in-CNAME-chains-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11583
A stale answer or SERVFAIL could have been served in case of multiple
upstream failures when following the CNAME chains. This has been fixed.
(cherry picked from commit d46277b398)
Three variants of YWH-PGM40640-56: Stale/Wrong DNS Data Served via
CNAME Flag Leak (DNS_DBFIND_STALEOK persistence) are presented in
GitLab issue #5751. All these variants have been converted to system
tests.
Variant 1 forwards source.stale to another server, that provides a
CNAME record, while the resolver is authoritative for target.stale.
The CNAME points to a non-existing name. A stale CNAME record should
result in a stale NXDOMAIN (instead of SERVFAIL).
Variant 2 forwards both source.stale and target.stale to other servers.
This time the CNAME points to an A RRset. If the source.stale server
is not available (and stale-answer-client-timeout is off), the cached
CNAME should be followed and pick up the fresh RRset (instead of the
stale A RRset).
Variant 3 is similar to variant 2, but this time the CNAME points to
a non-existing name again. After flushing the target, BIND should
return a stale NXDOMAIN (instead of SERVFAIL).
(cherry picked from commit c32de7df95)
When selecting nameserver addresses to be looked up we where
always selecting them in dnssec name order from the start of
the nameserver rrset. This could lead to resolution failure
despite there being address that could be resolved for the
other names. Use a random starting point when selecting which
names to lookup.
Closes#5695Closes#5745
Backport of MR !11395
Merge branch 'backport-5695-add-random-server-selection-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11600
Add randomizens system test which ensures that NS are randomly selected.
The test relies of the fact that `getaddresses_allowed()` logic won't
allow to query more than 3 NS at the top-level. The `example.` zone has
4 NS and the 3 formers are lame. As a result, if the resolved doesn't
randomize the NS selection, it will only quiery the 3 formers, which
won't give an answer, and fails. With randomization enabled, there is a
chance that the resolver queries the fourth NS, and gets the result.
(cherry picked from commit c67b52684f)
When selecting nameserver addresses to be looked up we where
always selecting them in dnssec name order from the start of
the nameserver rrset. This could lead to resolution failure
despite there being address that could be resolved for the
other names. Use a random starting point when selecting which
names to lookup.
(cherry picked from commit b78052119a)
If an BIND 9 administrator imports an invalid SKR file, local stack
in the import function might overflow. This could lead to
a memory corruption on the stack and ultimately server crash.
This has been fixed.
ISC would like to thank mcsky23 for bringing this bug to our attention.
Closes#5758
Backport of MR !11578
Merge branch 'backport-5758-fix-stack-overflow-via-rndc-skr-import-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11598
Try to import invalid SKR file and observe whether the named is still
alive. This test only triggers under ASAN.
(cherry picked from commit a82773ea89)
If an invalid SKR file is imported, reading the time from the token
buffer might overflow the buffer on the local stack. This has been
fixed by removing the intermediate buffer and parsing the lexer token
directly.
(cherry picked from commit 8ab4827a0c)
When .next_length is longer than NSEC3_MAX_HASH_LENGTH, it causes a
harmless out-of-bound read of the isdelegation() stack. This has been
fixed.
Closes#5749
Backport of MR !11553
Merge branch 'backport-5749-fix-OOB-read-in-isdelegation-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11594
Adds text and wire format unit tests to verify the newly enforced
maximum NSEC3 hash length constraints. These tests ensure that hash
lengths up to the 39-byte maximum are accepted, while larger sizes
correctly fail.
(cherry picked from commit e83a182056)
Adds a static system test that fails to load an NSEC3 record with an
invalid next part length. Additionally, introduces a dynamic test using
a crafted authoritative DNS proxy to inject invalid NSEC3 records on the
fly to test runtime behavior.
(cherry picked from commit 7b737bc1c4)
NSEC3 hashes are required to fit within a single DNS label. Since there
are 5 bits per label byte without pad characters, the maximum hash size
is floor(63*5/8) (39 bytes).
This patch enforces this maximum length for unknown algorithms, while
strictly enforcing the exact expected digest length for known algorithms
like SHA-1.
(cherry picked from commit 3801d0ebbf)
When .next_length is longer than NSEC3_MAX_HASH_LENGTH, it causes a
harmless out-of-bound read of the isdelegation() stack. This patch
fixes the issue by skipping NSEC3 records with an oversized hash length
during validation.
(cherry picked from commit 67b4fb56e4)
Fix assertion failure on unchanged rdataset during IXFR.
Closes#5759
Merge branch '5759-do-not-set-case-on-unchanged' into 'bind-9.20'
See merge request isc-projects/bind9!11587
A regression was introduced when adding the EDE code for unsupported
DNSKEY and DS algorithms. When the parent has both supported and
unsupported algorithm in the DS record, the validator would treat the
supported DS algorithm as insecure when validating DNSKEY records
instead of BOGUS. This has not security impact as the rest of the child
zone correctly ends with BOGUS status, but it is incorrect and thus the
regression has been fixed.
Closes#5757
Backport of MR !11580
Merge branch 'backport-5757-fix-mixed-algorithm-DS-handling-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11590
Add a system test that has one invalid DS record with supported
algorithm and one unsupported DS record. Both DNSKEY and A queries must
fail with SERVFAIL.
(cherry picked from commit 46f15f4f9d)
A regression was introduced when adding the EDE code for unsupported
DNSKEY and DS algorithms. When the parent has both supported and
unsupported algorithm in the DS record, the validator would treat the
supported DS algorithm as insecure when validating DNSKEY records
instead of BOGUS. This has not security impact as the rest of the child
zone correctly ends with BOGUS status, but it is incorrect and thus the
regression has been fixed.
(cherry picked from commit f983a64152)
In the last few years, the capabilities of coding tools have exploded.
As those capabilities have expanded, contributors and maintainers have
more and more questions about how and when to apply those capabilities.
Add new documentation to guide contributors on how to best use BIND 9
development tools, new and old.
In short: Please show your work and make sure your contribution is
easy to review.
This has been adopted from the Linux Kernel guidelines.
Backport of MR !11447
Merge branch 'backport-ondrej/clarify-the-use-of-tools-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11581
In the last few years, the capabilities of coding tools have exploded.
As those capabilities have expanded, contributors and maintainers have
more and more questions about how and when to apply those capabilities.
Add new documentation to guide contributors on how to best use BIND 9
development tools, new and old.
In short: Please show your work and make sure your contribution is
easy to review.
This has been adopted from the Linux Kernel guidelines.
(cherry picked from commit 3fe2215afb)
Add a set of short examples at the end of the dig manual page to help new or infrequent users figure out the most basic ways to use dig.
Backport of MR !11577
Merge branch 'backport-examples-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11579
The goal here is to help new or infrequent users figure out the most
basic ways to use dig.
Notes on the choice of examples:
* I wrote examples that users can copy and paste exactly as is, without
having to come up with an appropriate IP address or domain name to use.
The one exception is the `dig -x` example which uses an IP from the
example range.
* `dig +noall +answer` here is because learning about `+noall +answer`
was lifechanging for me when I learned about it, I've heard from
others that they find it helpful too, and it's pretty hard to infer
from the man page as is that it might be useful
* I thought about adding `+trace` but left it out because 5 examples was
already starting to feel like a lot.
(cherry picked from commit 8972ed9424)
An attacker controlling a malicious DNS server returns a DNAME record,
and the we stores a pointer to resp->foundname, frees the response
structure, then uses the dangling pointer in dns_name_fullcompare()
possibly causing invalid match. Only the `delv`is affected. This has
been fixed.
Closes#5728
Backport of MR !11570
Merge branch 'backport-5728-heap-uaf-in-bind9-dns_client_resolve-via-dname-response-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11571
An attacker controlling a malicious DNS server returns a DNAME record,
and the we stores a pointer to resp->foundname, frees the response
structure, then uses the dangling pointer in dns_name_fullcompare()
possibly causing invalid match. Only the `delv`is affected. This has
been fixed.
(cherry picked from commit 9135b71a7a)
Fixes a case where an in-domain NS with an expired glue would fail to resolve.
Let's consider the following parent-side delegation (both for `foo.example.` and `dnshost.example.`
```
foo.example. 3600 NS ns.dnshost.example.
dnshost.example. 3600 NS ns.dnshost.example.
ns.dnshost.example. 3600 A 1.2.3.4
```
Then the child-side of `dnshost.example.`:
```
dnshost.example. 300 NS ns.dnshost.example.
ns.dnshost.example. 300 A 1.2.3.4
```
And then the child-side of `foo.example.`:
```
foo.example 3600 NS ns.dnshost.example.
a.foo.example 300 A 5.6.7.8
```
While there is a zone misconfiguration (the TTL of the delegation and glue doesn't match in the parent and the child), it is possible to resolve `a.foo.example` on a cold-cache resolver. However, after the `ns.dnshost.example.` glue expires, the resolution would have failed with a "fetch loop detected" error. This is now fixed.
Closes#5588
Backport of MR !11535
Merge branch 'backport-5588-loopfetches-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11547
The fetch loop detection occured in two places: when
`dns_resolver_createfetch()` is invoked (looking up through the parent
fetches chain and stops the fetch if a parent fetch is the same qname and
qtype) and right after calling `dns_adb_findname()` in the resolver
(stops the fetch if the current fetch is the same name from the ADB
lookup, and ADB lookup needs to fetch it).
Regarding fetch loop detection at the `dns_resulver_createfetch()`
entry, there are case where both qname and qtype are similar but the
zonecut is different. This will then query different name servers and
get different responses. For instance, the following delegation
parent-side (both for `foo.example.` and `dnshost.example.`):
foo.example. 3600 NS ns.dnshost.example.
dnshost.example. 3600 NS ns.dnshost.example.
ns.dnshost.example. 3600 A 1.2.3.4
Then the child-side of `dnshost.example.`:
dnshost.example. 300 NS ns.dnshost.example.
ns.dnshost.example. 300 A 1.2.3.4
Then the child-side of `foo.example.`:
foo.example 3600 NS ns.dnshost.example.
a.foo.example 300 A 5.6.7.8
Obviously, there is a misconfiguration between the parent-side and the
child-side of `dnshost.example` (the mismatch of the TTL), but, this
happens...
Because the resolver is currently child-centric, the parent-side
delegation's glue of `dnshost.example.` will be overriden by the
child-side of the delegation. Once both A records will expires, the
resolver will attempt to find out the A RRs but will start from the
`foo.example.` zonecut, as the delegation itself is still valid.
Then the resolver will attempt to resolve `ns.dnshost.example.`, still
using the `foo.example.` zonecut, which will immediately trigger another
attempt to resolve `ns.foo.example.` (because the A RR is expired). This
is, however _not_ a loop, because the second attempt will have
`dnshost.example.` zonecut. And this changes everything, because the
resolver detects the A name is in-domain, and pass a flag to ADB so
`dns_view_find()` won't use the cache. As a result, the zonecut will be
`.`, and the hints (root servers) will be queried instead.
From that point, they'll return the parent-side delegation, which
includes the glue for `ns.dnshost.example/A`, and the resolution can
continue. Previously, this wouldn't be possible because a loop would be
detected from the second attempt to looking `ns.foo.example/A` and would
result in a SERVFAIL.
Now, the loop detection is relaxed as the loop is detected if the qname,
qtype _and_ zonecut are equals.
This commit also changes the way the loop detection post
`dns_adb_createfind()` works. From the same example above, there would
be two ADB fetches with the same name, but with two different ADB flags
(the first one without DNS_ADB_STARTATZONE, the second one with that
flag). It means that there will be two fetches out of those two ADB
lookups, both legit, and not a loop (i.e. it won't be stuck). To
differenciate between a find which has a pending fetch (which could be
from another find the current find has been attached to), a new find
option `DNS_ADBFIND_STARTEDFETCH` is introduced, which tells that the
current has did started a fetch.
That way, if a find doesn't have `DNS_ADBFIND_STARTEDFETCH` option but
has pending fetches, we know this is a find attached to a similar find
so this is a loop. Otherwise, with `DNS_ADBFIND_STARTEDFETCH`, we know
that even if there is a pending fetch, this is not a loop as the fetch
has just been started
(cherry picked from commit f623ab1fb3)
ADB entry window and ADB min cache time can be tweaked using `named -T
adbentrywindow=<unsigned int>` and `named -T adbmincache=<unsigned
int>`.
While those values doesn't needs to be exposed to the operator, this can
be needed to be able to system test ADB behaviors without having to wait
as long as those values are by default.
(cherry picked from commit e5f963262a)
Enable a socket option on the outgoing TCP sockets to allow faster selection of the source <address,port> tuple for different destination <address,port> tuples when nearing over 70-80% of the source port utilization.
Backport of MR !11569
Merge branch 'backport-improve-selection-of-outgoing-TCP-port-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!11573
