BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-07-17T20:29:24Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/398BIND 9.13.2 Release2018-07-17T20:29:24ZOndřej SurýBIND 9.13.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. [ ] Update http://en.wikipedia.org/wiki/BIND
11. [ ] Update DEB and RPM packagesBIND-9.13.2Evan 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/336Default of rrset-order silently changed to be sorted (rather than random)2023-03-16T11:03:02ZGhost UserDefault of rrset-order silently changed to be sorted (rather than random)<!--
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
The default rrset-order changed in bind 9.12 to sort returned results in an rrset rather than to randomize them. This is not listed in the change notes and is an operationally dangerous change. For example, this breaks services relying on DNS round-robin load balancing by overloading the machine with the lowest IP address. Even when the authority returns round-robin rrsets, bind 9.12 still sorts them by default.
This silent default change may be a critical issue in bind 9.12 that could cause major service incidents. It may be necessary to broadly communicate this broken/changed behavior and recommend fixes.
### Steps to reproduce
Resolve a name with multiple records in the rrset. With bind versions prior to 9.12, each lookup returns results in a different order. In bind 9.12, results are returned sorted. (As an example, doing an "ssh" or "curl" with a bind 9.12 resolver will always try the first IP, whereas with previous versions of bind9 different IPs will be tried.)
For example these are sorted (while the authority ns1.google.com even permutes with each lookup):
```
$ dig +short www.youtube.com @127.0.0.1
youtube-ui.l.google.com.
172.217.3.110
172.217.6.206
172.217.7.14
172.217.10.46
172.217.10.78
172.217.10.142
172.217.10.238
172.217.11.14
172.217.11.46
172.217.12.142
172.217.12.174
```
With the above, many clients using the stock Linux system libraries will always connect to "172.217.3.110".
### What is the current *bug* behavior?
rrsets with the default configuration are sorted.
### What is the expected *correct* behavior?
rrset responses should be randomized by default.
### Relevant configuration files
Behavior with the default configuration.
### Relevant logs and/or screenshots
### Possible fixes
I suspect this commit changed the behavior:
https://gitlab.isc.org/isc-projects/bind9/commit/03be5a6b4e6311b14a12dec5b15a62f55586aaf4
The issue is fixed by adding back in:
rrset-order { order random; };
If this is an intentional change, it should be discussed much more widely in the community as this has potentially operational implications.BIND-9.13.2https://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/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/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/33Root Zone local copy, similar to RFC 77062018-06-28T11:53:57ZVicky Riskvicky@isc.orgRoot Zone local copy, similar to RFC 7706Enable a resolver to download, validate, cache and update the entire root zone, obviating the need for queries to the root zone.
ICANN is sponsoring ISC to add this feature.
* [x] Refactor zone logging functions #269
* [x] constify dn...Enable a resolver to download, validate, cache and update the entire root zone, obviating the need for queries to the root zone.
ICANN is sponsoring ISC to add this feature.
* [x] Refactor zone logging functions #269
* [x] constify dns_rdata_tostruct #341
* [x] Convert verifyzone() to a libdns function #266
* [x] Unify keyfile-to-configuration conversions in system tests #284
* [x] Implement mirror zones #33BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/16QNAME Minimization2023-12-22T10:28:30ZOndřej SurýQNAME MinimizationImplement QNAME minimization and enable it by default.
Ensure that nothing breaks, by:
* [x] Have a proper fallbacks when QNAME minimization fails
* [ ] Introduce inter-resolver comparison testing
* [ ] Add a workarounds module that wo...Implement QNAME minimization and enable it by default.
Ensure that nothing breaks, by:
* [x] Have a proper fallbacks when QNAME minimization fails
* [ ] Introduce inter-resolver comparison testing
* [ ] Add a workarounds module that would allow disabling various features for DNS subtreesBIND-9.13.2Witold KrecickiWitold Krecicki2018-12-19