ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2018-07-11T06:24:48Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/397BIND 9.12.2 Release2018-07-11T06:24:48ZOndřej SurýBIND 9.12.2 Release1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view...1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_release_notes_are_cor)
4. [x] [Ensure the metainformation is correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_metainformation_is_co)
3. [x] Make sure the tests are passing
4. [x] Create a tag (name `vX_Y_Z[-alphatag]`, content `BIND X.Y.Z[-alphatag]`, signed with a developer's GPG key): `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z`
5. [x] Push the changes and tag
6. [x] [Create the tarball](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Create_the_tar_ball_using_a_util)
7. [x] [Create the Windows zips](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Creating_Windows_zips)
7. [x] Have QA sanity check the tarball and zips
9. [x] Request the signature on the tarballs
10. [x] Make tarballs and signatures available to download
10. [x] Communication
1. [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
2. [x] Update the website(?), public release notes(?)
3. [x] Write release e-mail to bind9-announce
4. [x] Post short note to Twitter
5. [x] Update http://en.wikipedia.org/wiki/BIND
11. [ ] Update DEB and RPM packagesBIND-9.12.2Evan HuntEvan Hunt2018-07-10https://gitlab.isc.org/isc-projects/bind9/-/issues/396BIND 9.11.4 Release2018-07-11T06:24:30ZOndřej SurýBIND 9.11.4 Release1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view...1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_release_notes_are_cor)
4. [x] [Ensure the metainformation is correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_metainformation_is_co)
3. [x] Make sure the tests are passing
4. [x] Create a tag (name `vX_Y_Z[-alphatag]`, content `BIND X.Y.Z[-alphatag]`, signed with a developer's GPG key): `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z`
5. [x] Push the changes and tag
6. [x] [Create the tarball](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Create_the_tar_ball_using_a_util)
7. [x] [Create the Windows zips](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Creating_Windows_zips)
7. [x] Have QA sanity check the tarball and zips
9. [x] Request the signature on the tarballs
10. [x] Make tarballs and signatures available to download
10. [x] Communication
1. [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
2. [x] Update the website(?), public release notes(?)
3. [x] Write release e-mail to bind9-announce
4. [x] Post short note to Twitter
5. [x] Update http://en.wikipedia.org/wiki/BIND
11. [ ] Update DEB and RPM packagesBIND-9.11.4Evan HuntEvan Hunt2018-07-10https://gitlab.isc.org/isc-projects/bind9/-/issues/395BIND 9.10.8 Release2018-07-11T06:24:12ZOndřej SurýBIND 9.10.8 Release1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view...1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_release_notes_are_cor)
4. [x] [Ensure the metainformation is correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_metainformation_is_co)
3. [x] Make sure the tests are passing
4. [x] Create a tag (name `vX_Y_Z[-alphatag]`, content `BIND X.Y.Z[-alphatag]`, signed with a developer's GPG key): `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z`
5. [x] Push the changes and tag
6. [x] [Create the tarball](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Create_the_tar_ball_using_a_util)
7. [x] [Create the Windows zips](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Creating_Windows_zips)
7. [x] Have QA sanity check the tarball and zips
9. [x] Request the signature on the tarballs
10. [x] Make tarballs and signatures available to download
10. [x] Communication
1. [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
2. [x] Update the website(?), public release notes(?)
3. [x] Write release e-mail to bind9-announce
4. [x] Post short note to Twitter
5. [x] Update http://en.wikipedia.org/wiki/BIND
11. [ ] Update DEB and RPM packagesBIND-9.10.8Evan HuntEvan Hunt2018-07-10https://gitlab.isc.org/isc-projects/bind9/-/issues/394BIND 9.9.13 Release2018-07-11T06:24:01ZOndřej SurýBIND 9.9.13 Release1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view...1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_release_notes_are_cor)
4. [x] [Ensure the metainformation is correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_metainformation_is_co)
3. [x] Make sure the tests are passing
4. [x] Create a tag (name `vX_Y_Z[-alphatag]`, content `BIND X.Y.Z[-alphatag]`, signed with a developer's GPG key): `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z`
5. [x] Push the changes and tag
6. [x] [Create the tarball](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Create_the_tar_ball_using_a_util)
7. [x] [Create the Windows zips](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Creating_Windows_zips)
7. [x] Have QA sanity check the tarball and zips
9. [x] Request the signature on the tarballs
10. [x] Make tarballs and signatures available to download
10. [x] Communication
1. [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
2. [x] Update the website(?), public release notes(?)
3. [x] Write release e-mail to bind9-announce
4. [x] Post short note to Twitter
5. [x] Update http://en.wikipedia.org/wiki/BIND
11. [ ] Update DEB and RPM packagesBIND-9.9.13Evan HuntEvan Hunt2018-07-10https://gitlab.isc.org/isc-projects/bind9/-/issues/367dnssec system test failing2018-06-27T11:35:33ZMark Andrewsdnssec system test failing<pre>I:dnssec:check dnskey-sig-validity sets longer expiry for DNSKEY (201)
I:dnssec:failed
SRCID=f553dac1b0
dnssec/python.out.201:
0</pre><pre>I:dnssec:check dnskey-sig-validity sets longer expiry for DNSKEY (201)
I:dnssec:failed
SRCID=f553dac1b0
dnssec/python.out.201:
0</pre>BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/366Missing dereference in REQUIRE statement?2018-06-27T08:20:48ZStephen MorrisMissing dereference in REQUIRE statement?Caught by cppcheck:
File lib/isccfg/parser.c:
```
isc_result_t
cfg_parse_boolean(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret)
{
isc_result_t result;
isc_boolean_t value;
cfg_obj_t *obj = NULL;
REQUIRE(pctx != NULL)...Caught by cppcheck:
File lib/isccfg/parser.c:
```
isc_result_t
cfg_parse_boolean(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret)
{
isc_result_t result;
isc_boolean_t value;
cfg_obj_t *obj = NULL;
REQUIRE(pctx != NULL);
REQUIRE(ret != NULL && ret != NULL);
```
The check on ret in the last line is repeated. Should that read:
```
REQUIRE(ret != NULL && *ret != NULL);
```
?BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/341constify dns_rdata_tostruct2018-06-15T09:41:06ZMark Andrewsconstify dns_rdata_tostructBIND-9.13.2Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/337Remove copyright information from generated configure file2018-06-15T09:41:14ZOndřej SurýRemove copyright information from generated configure fileThe copyright information in the generated `configure` file serves no purpose and has no value - it just produces warnings when running `autoreconf -fi`.The copyright information in the generated `configure` file serves no purpose and has no value - it just produces warnings when running `autoreconf -fi`.BIND-9.13.2Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/324add obsolete answer-cookie to master.2020-12-17T16:10:12ZMark Andrewsadd obsolete answer-cookie to master.BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/309Recursion improperly allowed by default2018-06-14T12:51:56ZMichael McNallyRecursion improperly allowed by default<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
As reported to security-officer by Andrew Skalski:
>>>
I am submitting this bug report privately because it concerns ACL behavior, and I do not know whether the impact is limited to allowing recursion by default, or if it extends further than that.
I recently upgraded a VPS of mine from Ubuntu 16.04 (BIND 9.10.3) to Ubuntu 18.04 (BIND 9.11.3). Since that upgrade, I noticed an increase in network usage, and discovered that my BIND instance was being abused for DNS amplification attacks.
Given that open recursion has been disabled by default for over 10 years (https://kb.isc.org/article/AA-00269/0/What-has-changed-in-the-behavior-of-allow-recursion-and-allow-query-cache.html), I did a git-bisect to find the commit that introduced the regression:
```
commit 89636d8f305956ad42e95a988502c7345e85ffe1
Author: Evan Hunt <each@isc.org>
Date: Mon Oct 23 11:11:19 2017 -0700
[master] clean up a redundancy
4777. [cleanup] Removed a redundant call to configure_view_acl().
[RT #46369]
```
>>>
### Steps to reproduce
> Start BIND with an empty, default configuration. From a second machine, make a recursive query to the BIND server.
### What is the current *bug* behavior?
(as of commit 89636d8f305956ad42e95a988502c7345e85ffe1):
```
$ host google.com 45.33.85.152
Using domain server:
Name: 45.33.85.152
Address: 45.33.85.152#53
Aliases:
google.com has address 216.58.219.238
google.com has IPv6 address 2607:f8b0:4006:80f::200e
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
```
### What is the expected *correct* behavior?
```
$ host google.com 45.33.85.152
Using domain server:
Name: 45.33.85.152
Address: 45.33.85.152#53
Aliases:
Host google.com not found: 5(REFUSED)BIND-9.13.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/298Fix DNAME handling in DNSSEC tools2018-06-15T09:41:18ZMichał KępieńFix DNAME handling in DNSSEC toolsWhile reviewing !291, @marka noted that [`verifyzone()`](https://gitlab.isc.org/isc-projects/bind9/blob/1a9a1b48d7e409514f18f31972291506be00dd35/bin/dnssec/dnssectool.c#L1424-1818)...
> needs to check for DNAME records as these indicate...While reviewing !291, @marka noted that [`verifyzone()`](https://gitlab.isc.org/isc-projects/bind9/blob/1a9a1b48d7e409514f18f31972291506be00dd35/bin/dnssec/dnssectool.c#L1424-1818)...
> needs to check for DNAME records as these indicate bottom of zone like is_delegation() indicates bottom of zone. DNAME can appear at the zone apex and if is_delegation() returns true the DNAME test should not be made. zonecut needs to be set if the DNAME test is true so that check_no_nsec() is called for obscured records.BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/295Remove ECC-GOST (GOST R 34.11-94) support2018-06-05T19:41:19ZOndřej SurýRemove ECC-GOST (GOST R 34.11-94) supportFrom https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/?include_text=1
> ECC-GOST (GOST R 34.11-94) has been superseded by GOST R 34.11-2012
> in [RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use
>...From https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/?include_text=1
> ECC-GOST (GOST R 34.11-94) has been superseded by GOST R 34.11-2012
> in [RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use
> in DNSSEC.
From RFC6986:
> GOST R 34.11-94 is superseded by GOST R 34.11-2012 from 1st January
> 2013. That means that all new systems that are presented for
> certification MUST use GOST R 34.11-2012 and MAY use GOST R 34.11-94
> also for maintaining compatibility with existing systems. Usage of
> GOST R 34.11-94 in current systems is allowed at least for a 5-year
> period.
From OpenSSL 1.1.0 ChangeLog:
> *) The GOST engine was out of date and therefore it has been removed. An up
> to date GOST engine is now being maintained in an external repository.
> See: https://wiki.openssl.org/index.php/Binaries. Libssl still retains
> support for GOST ciphersuites (these are only activated if a GOST engine
> is present).
Given the very low deployment numbers (SecSpider reports 119 keys and that's less than DSA), I propose to remove this ciphersuite from BIND.BIND-9.13.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/289random_test is very slow since isc_random change2018-05-29T21:08:53ZEvan Huntrandom_test is very slow since isc_random changeBefore change 4947:
```
$ kyua test random_test
random_test:isc_rng_binarymatrixrank_16 -> passed [1.503s]
random_test:isc_rng_binarymatrixrank_bytes -> passed [0.918s]
random_test:isc_rng_blockfrequency_16 -> passed [0.718s]
r...Before change 4947:
```
$ kyua test random_test
random_test:isc_rng_binarymatrixrank_16 -> passed [1.503s]
random_test:isc_rng_binarymatrixrank_bytes -> passed [0.918s]
random_test:isc_rng_blockfrequency_16 -> passed [0.718s]
random_test:isc_rng_blockfrequency_bytes -> passed [0.134s]
random_test:isc_rng_monobit_16 -> passed [0.706s]
random_test:isc_rng_monobit_bytes -> passed [0.130s]
random_test:isc_rng_runs_16 -> passed [1.151s]
random_test:isc_rng_runs_bytes -> passed [0.580s]
```
After change 4947:
```
$ kyua test random_test
random_test:isc_random_binarymatrixrank_16 -> passed [57.969s]
random_test:isc_random_binarymatrixrank_bytes -> passed [4.127s]
random_test:isc_random_blockfrequency_16 -> passed [58.222s]
random_test:isc_random_blockfrequency_bytes -> passed [3.374s]
random_test:isc_random_monobit_16 -> passed [59.008s]
random_test:isc_random_monobit_bytes -> passed [3.351s]
random_test:isc_random_runs_16 -> passed [59.605s]
random_test:isc_random_runs_bytes -> passed [3.649s]
```
Even worse, when running a full "make unit" with other unit tests being run in parallel, these are the grepped-out lines for random_test:
```
random_test:isc_random_binarymatrixrank_bytes -> passed [16.648s]
random_test:isc_random_monobit_bytes -> passed [15.136s]
random_test:isc_random_blockfrequency_bytes -> passed [25.718s]
random_test:isc_random_runs_bytes -> passed [18.061s]
random_test:isc_random_monobit_16 -> passed [171.179s]
random_test:isc_random_binarymatrixrank_16 -> passed [177.380s]
random_test:isc_random_blockfrequency_16 -> passed [176.568s]
random_test:isc_random_runs_16 -> passed [166.775s]
```
Of greatest concern: the unit test doesn't appear to have been significantly changed, other than switching to the new `isc_random` API. It isn't running more iterations or anything. This suggests that `isc_random` performs less than a tenth as well as `isc_rng` did, which is alarming. If true, I'd expect it to impact on resolver performance.BIND-9.13.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/284Unify keyfile-to-configuration conversions in system tests2018-06-15T09:41:30ZMichał KępieńUnify keyfile-to-configuration conversions in system testsThe following code snippet is repeated (with slight variations) 29 times throughout `bin/tests/system/`:
```shell
cat $keyname.key | grep -v '^; ' | $PERL -n -e '
local ($dn, $class, $type, $flags, $proto, $alg, @rest) = split;
local $k...The following code snippet is repeated (with slight variations) 29 times throughout `bin/tests/system/`:
```shell
cat $keyname.key | grep -v '^; ' | $PERL -n -e '
local ($dn, $class, $type, $flags, $proto, $alg, @rest) = split;
local $key = join("", @rest);
print <<EOF
trusted-keys {
"$dn" $flags $proto $alg "$key";
};
EOF
' > trusted.conf
```
To reduce code duplication and make future changes easier, this snippet should be replaced with a helper function in `bin/tests/system/conf.sh.{in,win32}`.BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/275Provide a mechanism (build or runtime) to turn off server-side support for RF...2018-06-27T08:20:54ZCathy AlmondProvide a mechanism (build or runtime) to turn off server-side support for RFC7873There is a corner case scenario that affects operators running anycast (or load-balanced) authoritative servers in a heterogenous environment with a mixture of levels of support for RFC7873.
The RFC does reasonably consider operating in...There is a corner case scenario that affects operators running anycast (or load-balanced) authoritative servers in a heterogenous environment with a mixture of levels of support for RFC7873.
The RFC does reasonably consider operating in an anycast environment, and points out:
> For servers accessed via anycast, to successfully support
> DNS Cookies, either (1) the server clones must all use the same
> Server Secret or (2) the mechanism that distributes requests to the
> server clones must cause the requests from a particular client to go
> to a particular server for a sufficiently long period of time that
> extra requests due to changes in Server Cookies resulting from
> accessing different server machines are not unduly burdensome. (When
> such anycast-accessed servers act as recursive servers or otherwise
> act as clients, they normally use a different unique address to
> source their requests, to avoid confusion in the delivery of
> responses.)
The reason why this consideration is documented in the RFC is this:
> A DNS client where DNS Cookies are implemented and enabled examines
> the response for DNS Cookies and MUST discard the response if it
> contains an illegal COOKIE option length or an incorrect
> Client Cookie value. If the client is expecting the response to
> contain a COOKIE option and it is missing, the response MUST be
> discarded. If the COOKIE option Client Cookie is correct, the client
> caches the Server Cookie provided, even if the response is an error
> response (RCODE non-zero).
This effectively means that there are 3 viable scenarios to prevent clients (whose behaviour is unknown) from dropping query responses when their queries go to a new server than the one they had been communicating with:
a) None of the servers offer server-side cookies
b) All of the servers offer server-side cookies and in addition share the same server secret
c) The mechanism that distributes request to the server clones ensure that clients only reach the same server for as long as possible
BIND 9.11.3 (the ESV version of BIND which replaces BIND 9.9's position as our current ESV) implements server-side RFC7873, enabled by default, with no mechanism for switching it off.
Operators of load-balanced/anycast clusters populated by servers from other DNS source code providers that don't offer server-side cookie support, or which do, but which can't be configured to share the server secret, are put in a difficult position, as they'll be required to do one of:
- Deploy option c)
- Remove other servers that don't support b) from their cluster/balanced environment
- Deploy alternative addressing schemes so that the servers supporting RFC7873 are on one set of IP addresses, and the others that don't (or which have different server secrets) are on another set of IP addresses.
This seems an unreasonable constraint to put on server operators who just want to upgrade the version of BIND that they're running.
Therefore I'm strongly suggesting that while it is good that by default BIND 9.11 supports and provides server-side support for RFC7873, that we also need a fallback option to disable it for server operators who need to be able to do this in the short term, until other DNS software providers have caught up and implemented RFC7873.BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/269Refactor zone logging functions2018-06-15T09:34:17ZMichał KępieńRefactor zone logging functions`lib/dns/zone.c` contains a set of logging functions:
* `dns_zone_log()`
* `dns_zone_logc()`
* `notify_log()`
* `zone_debuglog()`
Implementations of all these functions are similar enough that the common bits can be extracted to a sepa...`lib/dns/zone.c` contains a set of logging functions:
* `dns_zone_log()`
* `dns_zone_logc()`
* `notify_log()`
* `zone_debuglog()`
Implementations of all these functions are similar enough that the common bits can be extracted to a separate function, which would improve clarity and decrease code duplication.BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/266Convert verifyzone() to a libdns function2018-06-15T09:41:01ZMichał KępieńConvert verifyzone() to a libdns functionIn preparation for [implementing mirror zones](#33), the `verifyzone()` function from `bin/dnssec/dnssectool.c` should first be converted to a libdns routine which does not call `exit()` under any circumstances. The reworked function wi...In preparation for [implementing mirror zones](#33), the `verifyzone()` function from `bin/dnssec/dnssectool.c` should first be converted to a libdns routine which does not call `exit()` under any circumstances. The reworked function will later be employed for verifying mirror zones. `dnssec-signzone` and `dnssec-verifyzone` should also use the reworked function to prevent code duplication.BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/260Queries with empty question section (and otherwise query message of undetermi...2019-04-25T15:49:05ZGhost UserQueries with empty question section (and otherwise query message of undetermined RDCLASS) return NOERROR instead of FORMERR [ISC-support #12856]Per customer, it looks like the corresponding RFC 7873 (cookie) handling code is broken for this case.
The same code seems to exist in both `v9_11_sub` and `master` branches.
```
As of 9.11.3-S1, 'named' returns a noerror response to a...Per customer, it looks like the corresponding RFC 7873 (cookie) handling code is broken for this case.
The same code seems to exist in both `v9_11_sub` and `master` branches.
```
As of 9.11.3-S1, 'named' returns a noerror response to a query without
an empty question section (and no EDNS for that matter). Previously
it returned FORMERR in this case. Is that intentional?
This is because of the following code in client.c:client_request():
if ((client->attributes & NS_CLIENTATTR_WANTCOOKIE) != 0 ||
(client->message->opcode == dns_opcode_query &&
client->message->counts[DNS_SECTION_QUESTION] == 0U)) {
result = dns_message_reply(client->message, ISC_TRUE);
if (result != ISC_R_SUCCESS) {
ns_client_error(client, result);
return;
}
if (notimp)
client->message->rcode = dns_rcode_notimp;
ns_client_send(client);
return;
}
which in the public repo version was introduced at commit ce67023ae:
4152. [func] Implement DNS COOKIE option. This replaces the
experimental SIT option of BIND 9.10. [...]
RFC7873 certainly talks about a special case of an empty query, but it
adds a condition of the existence of the cookie option:
For servers with DNS Cookies enabled, the QUERY opcode behavior is
extended to support queries with an empty Question Section (a QDCOUNT
of zero (0)), provided that an OPT record is present with a COOKIE
option.
So the above code doesn't seem to be fully compliant with the RFC. Is
there other reason for this behavior, or perhaps the first '||'
should have been '&&'?
```
See: https://support.isc.org/Ticket/Display.html?id=12856 for the details.BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/180Intermittent recursive resolver issues [socket.c:2135]2018-09-05T15:03:29ZGhost UserIntermittent recursive resolver issues [socket.c:2135]<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Intermittent recursive resolver issues on an internal view. Introduced with 9.11.3.
### Steps to reproduce
n/a. Random queries seem to trigger, unable to reproduce manually for now.
### What is the current *bug* behavior?
Error log sees Unexpected Errors and Invalid Arguments.
### What is the expected *correct* behavior?
-
### Relevant configuration files
```
view "internal" {
match-clients { internal_hosts; trusted_hosts; };
minimal-responses yes;
recursion yes;
allow-recursion { internal_hosts; trusted_hosts; };
allow-query-cache { internal_hosts; trusted_hosts; };
include "/etc/bind/named.conf.default-zones";
query-source address 1.2.3.4;
query-source-v6 address 2001:aaaa::::2;
};
```
### Relevant logs and/or screenshots
```
Mar 26 11:36:22 edi named[726]: ../../../../lib/isc/unix/socket.c:2135: unexpected error:
Mar 26 11:36:22 edi named[726]: internal_send: 127.0.0.1#39187: Invalid argument
Mar 26 11:36:22 edi named[726]: client @0x7fd748027af0 127.0.0.1#39187 (mail.dovecot.fi): view internal: error sending response: invalid file
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/90remove "I:check flushtree clears adb correctly" from cacheclean in BIND 9.92018-02-22T13:06:41ZMark Andrewsremove "I:check flushtree clears adb correctly" from cacheclean in BIND 9.9The functionality to support this was only added in 9.10.0The functionality to support this was only added in 9.10.0BIND-9.9.13Mark AndrewsMark Andrews