ISC Open Source Projects issues
https://gitlab.isc.org/groups/isc-projects/-/issues
2018-09-21T23:32:34Z
https://gitlab.isc.org/isc-projects/bind9/-/issues/321
Without libcap, named tries to acquire new Linux capabilities (and fails)
2018-09-21T23:32:34Z
Ghost User
Without libcap, named tries to acquire new Linux capabilities (and fails)
On Linux, without libcap, named may try to expand its permitted capabilities at startup, fail, and give a misleading error message.
When named starts, it immediatly drops capabilities to a restricted set. Once a
number of initialization...
On Linux, without libcap, named may try to expand its permitted capabilities at startup, fail, and give a misleading error message.
When named starts, it immediatly drops capabilities to a restricted set. Once a
number of initialization tasks have been performed, it drops even more
capabilities, before running the server. These operations happen in
[bin/name/unix/os.c](https://gitlab.isc.org/isc-projects/bind9/blob/master/bin/named/unix/os.c), where the first set of permission is called
`initialprivs`, and the second one `minprivs`.
**Note:** Since it is impossible for a process to add a capability to its own
permitted set, `minprivs` is a subset of `initialprivs`.
When compiled with libcap, dropping capabilities entails:
+ computing the intersection of the current permitted capability set, and the
desired set
+ setting the permitted and effective capability set to that intersection
In particular, when named starts, if one of the capabilities in `initialprivs`
is missing from the permitted set, named will not try to acquire that
capability. It makes sense, since it would not be allowed to (see Note
above). named keeps running without the missing capability, and if that
capability ends up not being used, the server functions properly.
On the other hand, when compiled without libcap, named does not lookup the
permitted capability set, and attempts to set the permitted and
effective capability sets to `initialprivs`. If any of the capabilities are
missing from the permitted set, the `capset` system call fails, as expected,
and named gives the partially misleading error message:
```
named: syscall(capset) failed: Operation not permitted: please ensure that the capset kernel module is loaded. see insmod(8)
```
This issue is encountered when trying to run named in docker. The
CAP_DAC_READ_SEARCH, and CAP_SYS_RESOURCE capabilities are not present in docker
by default, but are part of the `initialprivs` set. For example, see the bug
report at https://bugs.alpinelinux.org/issues/4513.
The capabilities in `initialprivs` represent all the potential capabilities required by named to perform initialization. Not every run of named uses all of them. For example, CAP_DAC_READ_SEARCH, mentioned above, is only required when trying to read a configuration file owned by a non-root user and non-world-readable on startup.
The behaviour without libcap should replicate the correct behaviour implemented with libcap. This way, the capset system call would not try to expand its permitted capabilities set and fail. As a result, the error message would be displayed in fewer cases, and the information about the likely missing capset kernel module would be relevant.
It looks like the issue ended up in the code base as follows:
1. In the initial version available on gitlab (https://gitlab.isc.org/isc-projects/bind9/commit/9b2267b5ba9d0640512a41e139a4a36caa43730d), without libcap, the capabilities are dropped at start up to CAP_NET_BIND_SERVICE. If that capability is not present in the permitted set, the user receives the error message:
```
named: syscall(capset) failed: Operation not permitted
```
2. A few years later, the error message on failure of the `capset` system call is expanded to its current form (https://gitlab.isc.org/isc-projects/bind9/commit/c93003b0a6c063c15495f66300a1822481728fca). It likely reflected a common issue at the time. That error message was shared by the libcap version when it was later added (https://gitlab.isc.org/isc-projects/bind9/commit/0415ca35ada2cac6a86127eaca64f3a997aea121).
3. Over time, more capabilities are added to the `initialprivs` required set, and the problem of trying to acquire capabilities not in the permitted set gets noticed. It is fixed only in the libcap version (https://gitlab.isc.org/isc-projects/bind9/commit/88674be66567d3c7db91e717cd5972655e2e2488).
Michał Kępień
Michał Kępień
https://gitlab.isc.org/isc-projects/bind9/-/issues/322
add support for marking options as deprecated.
2023-03-16T11:03:02Z
Mark Andrews
add support for marking options as deprecated.
Mark Andrews
Mark Andrews
https://gitlab.isc.org/isc-projects/bind9/-/issues/323
cleanup cfg_parse_buffer*
2019-01-24T20:26:18Z
Mark Andrews
cleanup cfg_parse_buffer*
https://gitlab.isc.org/isc-projects/bind9/-/issues/324
add obsolete answer-cookie to master.
2020-12-17T16:10:12Z
Mark Andrews
add obsolete answer-cookie to master.
BIND-9.13.2
https://gitlab.isc.org/isc-projects/bind9/-/issues/325
add cfg_parse_buffer4
2018-06-08T07:44:25Z
Mark Andrews
add cfg_parse_buffer4
Mark Andrews
Mark Andrews
https://gitlab.isc.org/isc-projects/bind9/-/issues/326
xfer system test passes even if there's a TSIG failure
2019-01-21T23:02:29Z
Ghost User
xfer system test passes even if there's a TSIG failure
`dig` doesn't seem to return an error status if there's a TSIG failure. E.g., apply this patch:
```patch
diff --git a/bin/dig/dig.c b/bin/dig/dig.c
index ee891b4e36..15f24f6677 100644
--- a/bin/dig/dig.c
+++ b/bin/dig/dig.c
@@ -1766,7 ...
`dig` doesn't seem to return an error status if there's a TSIG failure. E.g., apply this patch:
```patch
diff --git a/bin/dig/dig.c b/bin/dig/dig.c
index ee891b4e36..15f24f6677 100644
--- a/bin/dig/dig.c
+++ b/bin/dig/dig.c
@@ -1766,7 +1766,7 @@ dash_option(char *option, char *next, dig_lookup_t **lookup,
ptr2 = ptr3;
} else {
#ifndef PK11_MD5_DISABLE
- hmacname = DNS_TSIG_HMACMD5_NAME;
+ hmacname = DNS_TSIG_HMACSHA256_NAME;
#else
hmacname = DNS_TSIG_HMACSHA256_NAME;
#endif
diff --git a/bin/tests/system/xfer/tests.sh b/bin/tests/system/xfer/tests.sh
index 91b23b3edb..004bf43ab6 100755
--- a/bin/tests/system/xfer/tests.sh
+++ b/bin/tests/system/xfer/tests.sh
@@ -46,7 +46,7 @@ digcomp dig1.good dig.out.ns3 || status=1
n=`expr $n + 1`
echo_i "testing TSIG signed zone transfers"
-$DIG $DIGOPTS tsigzone. @10.53.0.2 axfr -y tsigzone.:1234abcd8765 > dig.out.ns2 || status=1
+$DIG $DIGOPTS tsigzone. @10.53.0.2 axfr -y tsigzone.:1234abcd8765 > dig.out.ns2 || exit 1
grep "^;" dig.out.ns2 | cat_i
#
```
and run the `xfer` system test. See the early failures, but it doesn't exit after the dig failure above.
This was noticed about a year back, but it got missed. The regular passing tests don't exercise the failure.
https://gitlab.isc.org/isc-projects/bind9/-/issues/327
Make the Windows builds parallel
2019-10-02T12:21:53Z
Ondřej Surý
Make the Windows builds parallel
Apparently the nmake has capability to run builds in parallel, we just haven't enable such option. Unfortunately, my knowledge of VS build system is at the "random monkeys smashing keyboard buttons", so unless the search engine results ...
Apparently the nmake has capability to run builds in parallel, we just haven't enable such option. Unfortunately, my knowledge of VS build system is at the "random monkeys smashing keyboard buttons", so unless the search engine results help, somebody will need to look into this in more detail.
The parametrized win64 build now has something like `set CL=/MP`, so we'll see.
October 2019 (9.11.12, 9.14.7, 9.15.5)
Michał Kępień
Michał Kępień
https://gitlab.isc.org/isc-projects/bind9/-/issues/328
Refactor crypto to use OpenSSL for everything but Public-Key Cryptography
2018-07-20T03:29:02Z
Ondřej Surý
Refactor crypto to use OpenSSL for everything but Public-Key Cryptography
Based on Twitter, mailing list, our forum and other people, more than 2/3 of respondents thinks that people just need to use HSMs for Public-Key cryptography (e.g. storing private keys and operations that involve public and private keys ...
Based on Twitter, mailing list, our forum and other people, more than 2/3 of respondents thinks that people just need to use HSMs for Public-Key cryptography (e.g. storing private keys and operations that involve public and private keys on the HSM).
This is an issue that aims to simplify the cryptography to use OpenSSL for everything but Public-Key cryptography, where we will keep the choice. This will also make OpenSSL mandatory.
Ondřej Surý
Ondřej Surý
https://gitlab.isc.org/isc-projects/bind9/-/issues/329
masterformat system test fails from time to time
2019-01-21T08:27:21Z
Ghost User
masterformat system test fails from time to time
It fails to find any one of these two files it's testing from time to time, and the `israw` code following it fails:
```patch
diff --git a/bin/tests/system/masterformat/tests.sh b/bin/tests/system/masterformat/tests.sh
index 14d90d5517....
It fails to find any one of these two files it's testing from time to time, and the `israw` code following it fails:
```patch
diff --git a/bin/tests/system/masterformat/tests.sh b/bin/tests/system/masterformat/tests.sh
index 14d90d5517..257299fd58 100755
--- a/bin/tests/system/masterformat/tests.sh
+++ b/bin/tests/system/masterformat/tests.sh
@@ -121,7 +121,7 @@ ret=0
status=`expr $status + $ret`
echo_i "waiting for transfers to complete"
-for i in 0 1 2 3 4 5 6 7 8 9
+for i in 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
do
test -f ns2/transfer.db.raw -a -f ns2/transfer.db.txt && break
sleep 1
```
https://gitlab.isc.org/isc-projects/bind9/-/issues/331
Further refactoring of functions in lib/dns/zoneverify.c
2021-08-31T13:33:10Z
Michał Kępień
Further refactoring of functions in lib/dns/zoneverify.c
Certain review comments in !291 were related to code which was not introduced by that MR, but rather just moved around. The following comments should thus be addressed:
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-pr...
Certain review comments in !291 were related to code which was not introduced by that MR, but rather just moved around. The following comments should thus be addressed:
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12167): (+1 comment)
> This block is little bit confusing (triggering warning condition on ISC_R_SUCCESS), is there a reason why not to move the whole block before the `break` where it really logically belongs?
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12176): (+1 comment)
> Also this sort of calls for a helper static functions similar to `innsec3params()`.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12178): (+1 comment)
> Perhaps use `= { 0 };` and remove memset?
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12180): (+1 comment)
> Use `sizeof(set_algorithms)` instead of arbitrary number.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12181): (+1 comment)
> `= { 0 };`
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12182): (+3 comments)
> `goto done;` as in previous functions instead of cut© code?
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12184): (+1 comment)
> This seems awfully similar to just calling `!chain_equal()`.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12185): (+1 comment)
> This is so fragile.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12186): (+1 comment)
> Perhaps `255` should be a constant with a descriptive name?
September 2021 (9.16.21, 9.16.21-S1, 9.17.18)
https://gitlab.isc.org/isc-projects/bind9/-/issues/332
v9_9 move lib/irs to lib/export/irs
2018-06-26T03:50:06Z
Mark Andrews
v9_9 move lib/irs to lib/export/irs
Mark Andrews
Mark Andrews
https://gitlab.isc.org/isc-projects/bind9/-/issues/333
We're sending unnecessary queries during qname minimization.
2018-11-14T18:28:23Z
Witold Krecicki
We're sending unnecessary queries during qname minimization.
Two separate cases when we issue unnecessary queries:
1. If we're looking for (e.g.) both A and AAAA for a foo.bar.baz we will issue separate queries for NS bar.baz
2. If we have a series of labels under one zone cut we don't 'remember' ...
Two separate cases when we issue unnecessary queries:
1. If we're looking for (e.g.) both A and AAAA for a foo.bar.baz we will issue separate queries for NS bar.baz
2. If we have a series of labels under one zone cut we don't 'remember' that those are under the same zone cut and query every single label every time.
Witold Krecicki
Witold Krecicki
https://gitlab.isc.org/isc-projects/bind9/-/issues/334
Extract common parts of bin/tests/system/conf.sh.{in,win32} to a separate file
2019-01-21T23:04:45Z
Michał Kępień
Extract common parts of bin/tests/system/conf.sh.{in,win32} to a separate file
While reviewing !312, @ondrej rightly [mentioned](https://gitlab.isc.org/isc-projects/bind9/merge_requests/312#note_12357) that we should extract the common parts of `bin/tests/system/conf.sh.in` and `bin/tests/system/conf.sh.win32` to a...
While reviewing !312, @ondrej rightly [mentioned](https://gitlab.isc.org/isc-projects/bind9/merge_requests/312#note_12357) that we should extract the common parts of `bin/tests/system/conf.sh.in` and `bin/tests/system/conf.sh.win32` to a separate file which would then be included by these two.
BIND 9.13.x
Michał Kępień
Michał Kępień
https://gitlab.isc.org/isc-projects/bind9/-/issues/335
tagging bind9 and https://sources.isc.org/ is out of date
2018-07-11T13:26:46Z
reedjc
tagging bind9 and https://sources.isc.org/ is out of date
I still have a .git/config pointing to
url = https://source.isc.org/git/bind9.git
I noticed it was missing some tags.
Then I went to the web interface https://sources.isc.org/ which still
links to your
https://source.isc.org/cg...
I still have a .git/config pointing to
url = https://source.isc.org/git/bind9.git
I noticed it was missing some tags.
Then I went to the web interface https://sources.isc.org/ which still
links to your
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=summary
which has:
last change Thu, 15 Feb 2018 19:56:13 +0000 (11:56 -0800)
Please consider getting rid of sources.isc.org/git/ repos. (Or if
keeping it, please keep up to date with your public releases.)
Please consider updating your https://sources.isc.org/ webpage so top
links point to github or gitlab. (I do see instructions were updated.)
So I looked at your github and gitlab pages. I don't see a tag for
v9_12_1_P2 (assuming your standard tag naming).
Please consider adding tags for all the releases. I understand a new
release is imminent. I can wait for it, but please do tag it! Thanks!
(By the way I first sent this to bind9-bugs. The autoresponse had typo "meail" and confusing sentence "Any ticket that seems like may have been create". I have not idea if that ticket submission was seen or not. Please consider stating if the email will be seen or not in the autoresponse.)
Brian Conry
Brian Conry
https://gitlab.isc.org/isc-projects/bind9/-/issues/336
Default of rrset-order silently changed to be sorted (rather than random)
2023-03-16T11:03:02Z
Ghost User
Default 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.2
https://gitlab.isc.org/isc-projects/bind9/-/issues/337
Remove copyright information from generated configure file
2018-06-15T09:41:14Z
Ondřej Surý
Remove copyright information from generated configure file
The 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.2
Ondřej Surý
Ondřej Surý
https://gitlab.isc.org/isc-projects/bind9/-/issues/338
unchecked dns_name_dup calls.
2023-10-31T09:45:54Z
Mark Andrews
unchecked dns_name_dup calls.
There are a number of dns_name_dup calls where the result is not checked. These all need to be checked.
There are a number of dns_name_dup calls where the result is not checked. These all need to be checked.
https://gitlab.isc.org/isc-projects/bind9/-/issues/339
BIND crash processing .jnl file for outbound IXFR
2018-07-05T04:38:03Z
Cathy Almond
BIND crash processing .jnl file for outbound IXFR
BIND 9.12.1-P2
### Summary
Three authoritative servers all crashed at around the same time with:
```
13-Jun-2018 06:16:37.710 general: critical: journal.c:1663: INSIST(j->offset <= j->it.epos.offset) failed
13-Jun-2018 06:16:37.710 gen...
BIND 9.12.1-P2
### Summary
Three authoritative servers all crashed at around the same time with:
```
13-Jun-2018 06:16:37.710 general: critical: journal.c:1663: INSIST(j->offset <= j->it.epos.offset) failed
13-Jun-2018 06:16:37.710 general: critical: exiting (due to assertion failure)
```
When trying to restart BIND, it fails to launch and logs the same lines as above.
### Steps to reproduce
Restarting BIND reproduces the problem.
Removing the zone .jnl file and restarting resolves the problem.
It would appear that named is attempting to process an outbound IXFR request at the time of the crash, after having recently received a significantly-sized inbound update:
```
13-Jun-2018 05:40:30.552 xfer-in: info: transfer of 'XXXXXXXX/IN' from XX.XX.XX.XX#53: Transfer status: success
13-Jun-2018 05:40:30.552 xfer-in: info: transfer of 'XXXXXXXX/IN' from XX.XX.XX.XX#53: Transfer completed: 113359 messages, 27271720 records, 1800453680 bytes, 669.247 secs (2690267 bytes/sec)
13-Jun-2018 05:40:30.569 xfer-out: info: client @0xXXXXXXXXXX XX.XX.XX.XX#36227/key XXXX (XXXXXXXX): transfer of 'XXXXXXXX/IN': IXFR started: TSIG XXXX (serial 2018061320 -> 2018061321)
```
### What is the current *bug* behavior?
named crashes
### What is the expected *correct* behavior?
named doesn't crash
### Relevant configuration files
Not yet available
### Relevant logs and/or screenshots
See above
### Possible fixes
I am wondering if the size of the .jnl file might be significant - ~4Gb
https://gitlab.isc.org/isc-projects/bind9/-/issues/340
unchecked returns in xoshiro128starstar.c
2018-08-25T12:08:14Z
Mark Andrews
unchecked returns in xoshiro128starstar.c
In next() the lock and unlock are not checked for failures.
In next() the lock and unlock are not checked for failures.
https://gitlab.isc.org/isc-projects/bind9/-/issues/341
constify dns_rdata_tostruct
2018-06-15T09:41:06Z
Mark Andrews
constify dns_rdata_tostruct
BIND-9.13.2
Mark Andrews
Mark Andrews