ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-02-08T13:17:14Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1697isc_rwlock_init can no longer fail in master, clean up calls.2021-02-08T13:17:14ZMark Andrewsisc_rwlock_init can no longer fail in master, clean up calls.Coverity is complaining about unchecked returns from isc_rwlock_init. Silence by removing return value which is always ISC_R_SUCCESS.
Check earlier active branches to see if similar is appropriate for them.Coverity is complaining about unchecked returns from isc_rwlock_init. Silence by removing return value which is always ISC_R_SUCCESS.
Check earlier active branches to see if similar is appropriate for them.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2383kasp confuses signatures-validity with signatures-validity-dnskey2021-01-29T14:16:15ZMatthijs Mekkingmatthijs@isc.orgkasp confuses signatures-validity with signatures-validity-dnskeyFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2404Bind 9.16.8 reuses old keys2021-03-15T13:16:47ZMarc Dequènes (Duck)Bind 9.16.8 reuses old keys
### Summary
I switched from 9.11.5.P4 to 9.16.8 and from dnssec-keymgr to dnssec-policy. dnssec-keymgr did not remove old keys and Bind now just revived them all without caring for the old state.
### BIND version used
```
BIND 9.16.8...
### Summary
I switched from 9.11.5.P4 to 9.16.8 and from dnssec-keymgr to dnssec-policy. dnssec-keymgr did not remove old keys and Bind now just revived them all without caring for the old state.
### BIND version used
```
BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-Pv1hAF/bind9-9.16.8=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libuv version: 1.24.1
linked to libuv version: 1.24.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Switch from dnssec-keymgr based management to dnssec-policy. You also need to have old keys around. dnssec-keymgr lacked cleanup management so they stayed around.
### What is the current *bug* behavior?
Here is an example zone: https://dnsviz.net/d/_kage.duckcorp.org/dnssec/
You can have a look at the previous state. As you can see that's a bit of a mess. I also wonder if Bind is gonna inactive old keys again by itself or if I have to do that myself.
### What is the expected *correct* behavior?
IMHO it would help to have a proper upgrade path from dnssec-keymgr to dnssec-policy. That means reading the .key files (created by dnssec-keymgr) and at least the Inactive field in order to ignore keys that are not relevant.
### Relevant configuration files
The configuration with dnssec-keymgr:
```
zone "hq.duckcorp.org" IN {
type master;
allow-transfer { key duckcorp-internal; };
also-notify { duckland_ns2; };
file "/var/cache/bind/masters/hq.duckcorp.org.zone";
inline-signing yes;
auto-dnssec maintain;
}
```
with /etc/bind/dnssec-policy.conf:
```
policy default {
algorithm RSASHA512;
keyttl 3600;
key-size ksk 4096;
key-size zsk 2048;
roll-period ksk 1y;
roll-period zsk 3mo;
pre-publish ksk 1mo;
pre-publish zsk 1mo;
post-publish ksk 1mo;
post-publish zsk 1mo;
standby ksk 0;
standby zsk 0;
coverage 1y;
};
```
And now:
```
zone "hq.duckcorp.org" IN {
type master;
allow-transfer { key duckcorp-internal; };
also-notify { duckland_ns2; };
file "/var/cache/bind/masters/hq.duckcorp.org.zone";
dnssec-policy "generated";
}
dnssec-policy "generated" {
keys {
ksk key-directory lifetime P1Y algorithm rsasha512 4096;
zsk key-directory lifetime 30d algorithm rsasha512 2048;
};
max-zone-ttl PT1H;
};
```
Example of key header for one of the obsolete keys K_kage.hq.duckcorp.org.+010+57716.key:
```
; This is a zone-signing key, keyid 57716, for _kage.hq.duckcorp.org.
; Created: 20190927153144 (Sat Sep 28 00:31:44 2019)
; Publish: 20200224153144 (Tue Feb 25 00:31:44 2020)
; Activate: 20200325153144 (Thu Mar 26 00:31:44 2020)
; Inactive: 20200623153144 (Wed Jun 24 00:31:44 2020)
; Delete: 20200723153144 (Fri Jul 24 00:31:44 2020)
```
And the corresponding `rndc dnssec -status` for it:
```
key: 57716 (RSASHA512), ZSK
published: yes - since Tue Feb 25 00:31:44 2020
zone signing: yes - since Thu Mar 26 00:31:44 2020
Rollover is due since Wed Jun 24 00:31:44 2020
- dnskey: omnipresent
- zone rrsig: omnipresent
```
Interestingly some are in other states like:
```
key: 36878 (RSASHA512), ZSK
published: no - scheduled Fri Feb 19 00:31:44 2021
zone signing: no - scheduled Sun Mar 21 00:31:44 2021
Key will retire on Sat Jun 19 00:31:44 2021
- dnskey: hidden
- zone rrsig: hidden
```
or
```
key: 49415 (RSASHA512), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- zone rrsig: unretentive
```
Regards.
\\_o<March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2349Should we back-port max-ixfr-ratio from 9.17 to earlier versions of BIND?2021-05-10T16:49:36ZCathy AlmondShould we back-port max-ixfr-ratio from 9.17 to earlier versions of BIND?I can't see any other elegant option currently that could be used to 'protect' a zone hosting set-up from receipt and onward propagation of a massive IXFR to the service-providing authoritatives.
This happens sometimes accidentally (see...I can't see any other elegant option currently that could be used to 'protect' a zone hosting set-up from receipt and onward propagation of a massive IXFR to the service-providing authoritatives.
This happens sometimes accidentally (see [Support Ticket #17366](https://support.isc.org/Ticket/Display.html?id=17366)) and I would rather provide a solid solution in named, than encourage scripting that spots when something like this happens, and then goes off to delete .jnl or zone files on disk to prevent the same IXFR heading out to Internet-facing servers, where the effects of applying it can be seriously detrimental to server performance.
!3113
#1515February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2350Dead code guarded by PK11_RSA_PKCS_REPLACE in pkcs11rsa_link.c2021-11-02T15:46:20ZMichal NowakDead code guarded by PK11_RSA_PKCS_REPLACE in pkcs11rsa_link.c`PK11_RSA_PKCS_REPLACE` is not defined in `configure` or described in documentation and is therefore invisible for the user on `main` and `v9_16`.
In `v9_11` one might set it via `./configure --enable-native-pkcs11 --with-pkcs11=/opt/Ke...`PK11_RSA_PKCS_REPLACE` is not defined in `configure` or described in documentation and is therefore invisible for the user on `main` and `v9_16`.
In `v9_11` one might set it via `./configure --enable-native-pkcs11 --with-pkcs11=/opt/Keyper/PKCS11Provider/pkcs11.so` (see `configure.ac`, line 2324), which sets `-DPK11_FLAVOR=PK11_AEP_FLAVOR`, which in `lib/isc/include/pk11/site.h` via `#if PK11_FLAVOR == PK11_AEP_FLAVOR` defines `PK11_RSA_PKCS_REPLACE`.
`#else /* ifndef PK11_RSA_PKCS_REPLACE */` blocks in `lib/dns/pkcs11rsa_link.c` are either dead code forgotten when OpenSSL was made mandatory with c3b8130fe8267185e786e9c12527df7c53b37589 in `v9_13_3` and thus should be dropped, made available by `configure`, or the least documented in e.g. `OPTIONS.md`.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2351catgets crashes on openWRT2020-12-17T11:32:15ZThomas Markwaldercatgets crashes on openWRTAs reported by an ISC DCHP user, a segfault occurs in the call to catgets() on openWRT in this issue:
https://gitlab.isc.org/isc-projects/dhcp/-/issues/156
It seems that catopen() returns -1 as the catalogs are not present. Subsequent...As reported by an ISC DCHP user, a segfault occurs in the call to catgets() on openWRT in this issue:
https://gitlab.isc.org/isc-projects/dhcp/-/issues/156
It seems that catopen() returns -1 as the catalogs are not present. Subsequent calls to catgets() with an invalid pointer value of -1 cause it to segfault. Preliminary testing under Ubuntu 18.04 shows the catopen() returns 0 (contrary to the man page) but that catgets() handles a null pointer value safely.
This is present in 9.1.14.https://gitlab.isc.org/isc-projects/bind9/-/issues/2352Issues with cppcheck 2.32021-08-30T12:57:43ZMichał KępieńIssues with cppcheck 2.3cppcheck 2.3 is now available, but, as usually, it comes with a set of
problems. IMHO we should skip updating to this version for the time
being and here is why.
[Upstream commit bd7e915c208219d6a5e3efca40168d31f9c0248c][1] is the
prim...cppcheck 2.3 is now available, but, as usually, it comes with a set of
problems. IMHO we should skip updating to this version for the time
being and here is why.
[Upstream commit bd7e915c208219d6a5e3efca40168d31f9c0248c][1] is the
primary culprit this time around. It causes two types of problems:
---
```
lib/dns/ttl.c:76:13: warning: Either the condition 'weeks!=0' is redundant or there is division by zero at line 76. [zerodivcond]
secs = src % 60;
^
lib/dns/ttl.c:89:12: note: Assuming that condition 'weeks!=0' is not redundant
if (weeks != 0) {
^
lib/dns/ttl.c:84:10: note: Assignment to 'weeks=src'
weeks = src;
^
lib/dns/ttl.c:83:2: note: Compound assignment '/=', assigned value is 0
src /= 7;
^
lib/dns/ttl.c:81:2: note: Compound assignment '/=', assigned value is 0
src /= 24;
^
lib/dns/ttl.c:79:2: note: Compound assignment '/=', assigned value is 0
src /= 60;
^
lib/dns/ttl.c:79:9: note: Assignment to 'src/=60'
src /= 60;
^
lib/dns/ttl.c:76:13: note: Division by zero
secs = src % 60;
^
```
This is pretty obvious nonsense. I [reported it upstream][2] because it
is still not addressed in cppcheck's development branch. Working around
this would involve adding inline suppressions or reworking 20-year code.
Neither of these options sounds reasonable to me at this point.
---
```
lib/dns/spnego.c:1591:52: warning: Either the condition 'if(buf)' is redundant or there is pointer arithmetic with NULL pointer. [nullPointerArithmeticRedundantCheck]
ret = gssapi_spnego_encapsulate(minor_status, buf + buf_size - len, len,
^
lib/dns/spnego.c:1606:5: note: Assuming that condition 'if(buf)' is not redundant
if (buf) {
^
lib/dns/spnego.c:1591:52: note: Null pointer addition
ret = gssapi_spnego_encapsulate(minor_status, buf + buf_size - len, len,
^
```
This seems to only be reported for ~"v9.16" / ~"v9.16-S". This report
is also wrong because a quick look at the `goto` statements above the
flagged piece of code clearly tells that `buf` cannot be `NULL` where
cppcheck things it might be.
[Upstream commit da1375c9a3f3a3b7eae7aece5e2ba03e59973aa0][3] from
cppcheck's development branch addresses this, so it will not be flagged
by future cppcheck releases.
---
cppcheck 2.3 also started reporting the following false positive for
~"v9.11" / ~"v9.11-S":
```
lib/isc/mem.c:697:43: warning: Either the condition 'ret!=NULL' is redundant or there is possible null pointer dereference: ctx->freelists[new_size]. [nullPointerRedundantCheck]
ctx->freelists[new_size] = ctx->freelists[new_size]->next;
^
lib/isc/mem.c:714:10: note: Assuming that condition 'ret!=NULL' is not redundant
if (ret != NULL)
^
lib/isc/mem.c:696:22: note: Assignment to 'ret=ctx->freelists[new_size]'
ret = ctx->freelists[new_size];
^
lib/isc/mem.c:697:43: note: Null pointer dereference
ctx->freelists[new_size] = ctx->freelists[new_size]->next;
^
```
This report was already triggered for other branches before (#1969), the
relevant fix (commit 0cf25d7f3820b3cbe266998f8e11ceb21b28908c) was
simply not backported to ~"v9.11" / ~"v9.11-S".
All in all, I would wait for cppcheck 2.4, hoping that it will be able
to properly process `lib/dns/ttl.c`.
[1]: https://github.com/danmar/cppcheck/commit/bd7e915c208219d6a5e3efca40168d31f9c0248c
[2]: https://sourceforge.net/p/cppcheck/discussion/general/thread/f4a81c33d5/
[3]: https://github.com/danmar/cppcheck/commit/da1375c9a3f3a3b7eae7aece5e2ba03e59973aa0BIND 9.17 BackburnerMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2353Release Checklist for BIND 9.11.27, BIND 9.11.27-S1, BIND 9.16.11, BIND 9.16....2021-01-26T07:13:52ZMichał KępieńRelease Checklist for BIND 9.11.27, BIND 9.11.27-S1, BIND 9.16.11, BIND 9.16.11-S1, BIND 9.17.9## Release Schedule
**Code Freeze:** Wednesday, January 6th, 2021
**Tagging Deadline:** Monday, January 11th, 2021
**Public Release:** Wednesday, January 20th, 2021
## Documentation Review Links
**Closed issues assigned to the miles...## Release Schedule
**Code Freeze:** Wednesday, January 6th, 2021
**Tagging Deadline:** Monday, January 11th, 2021
**Public Release:** Wednesday, January 20th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.9](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.11](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.27](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.9](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.11](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.27](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.9](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.11](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.27](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=January%202021%20(9.11.27%2C%209.11.27-S1%2C%209.16.11%2C%209.16.11-S1%2C%209.17.9)&label_name[]=No%20CHANGES&target_branch=v9_11)
## Other Links
**QA Report:** *(not yet available)*
**Signing Ticket:** *(not yet available)*
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition.
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)Michał KępieńMichał Kępień2021-01-20https://gitlab.isc.org/isc-projects/bind9/-/issues/2354[CVE-2020-8625] ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow...2023-06-19T09:07:00ZCathy Almond[CVE-2020-8625] ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow Remote Code Execution Vulnerability### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exist...### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exists
- [x] Prepare a detailed description of the problem which should include the following by default:
- instructions for reproducing the problem (a system test is good enough)
- explanation of code flow which triggers the problem (a system test is *not* good enough)
- [x] Prepare a private merge request containing the following items in separate commits:
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle: isc-private/bind9#34
- [x] Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
---
As reported to ISC Security Officer:
ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow Remote Code Execution Vulnerability
-- CVSS -----------------------------------------
8.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
-- ABSTRACT -------------------------------------
Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products:
ISC - BIND
-- VULNERABILITY DETAILS ------------------------
* Version tested:9.16.9
* Installer file:bind-9.16.9.tar.xz
* Platform tested:ubuntu 20.04.1 desktop edition
---
### Analysis
```
the bug is CVE-2006-5989, ISC did not merge the patch
https://bugzilla.redhat.com/show_bug.cgi?id=206736
it leads to heap overflow off-by-4
it affected the latest Current-Stable, 9.16.9
it require the tkey-gssapi-keytab config in named.conf
```
~~~C++
static int
der_get_oid(const unsigned char *p, size_t len, oid *data, size_t *size) {
...
data->components = malloc(len * sizeof(*data->components));
if (data->components == NULL) {
return (ENOMEM);
}
data->components[0] = (*p) / 40;
data->components[1] = (*p) % 40; <--- (1) two element is written
--len; <--- (2) but len is plus one only
++p;
for (n = 2; len > 0U; ++n) {
unsigned u = 0;
do {
--len;
u = u * 128 + (*p++ % 128);
} while (len > 0U && p[-1] & 0x80);
data->components[n] = u; <--- (3) off-by-4
}
...
return (0);
}
~~~
debug log
```
(gdb) b *0x18E27E+0x7fb83fd83000
Breakpoint 1 at 0x7fb83ff1127e
(gdb) b *0x18E309+0x7fb83fd83000
Breakpoint 2 at 0x7fb83ff11309
(gdb) c
Continuing.
[Switching to Thread 0x7fb83d1f8700 (LWP 77138)]
Thread 2 "isc-net-0000" hit Breakpoint 1, 0x00007fb83ff1127e in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/i $pc
=> 0x7fb83ff1127e: call 0x7fb83fdab5d0 <malloc@plt>
(gdb) i r $rdi
rdi 0x28 40
(gdb) ni
0x00007fb83ff11283 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/30xg $rax-0x10
0x7fb82c0164b0: 0x0000000000000000 0x0000000000000035
0x7fb82c0164c0: 0x00007fb82c016650 0x0000000000000000
0x7fb82c0164d0: 0x0000000000000000 0x0000000000000000
0x7fb82c0164e0: 0x0000000000000000 0x0000000000000025
0x7fb82c0164f0: 0x00007fb82c016230 0x00007fb83f55fc20
0x7fb82c016500: 0x0000000000000000 0x0000000000000025
0x7fb82c016510: 0x00007fb82c016530 0x00007fb82c0008d0
0x7fb82c016520: 0x0000000000000000 0x0000000000000025
0x7fb82c016530: 0x0000000000000000 0x00007fb82c0008d0
0x7fb82c016540: 0x0000000000000000 0x00000000000000b5
0x7fb82c016550: 0x00007fb82c015120 0x00007fb82c0008d0
0x7fb82c016560: 0x0000000000000000 0x00000000ffffffff
0x7fb82c016570: 0x0000000000000000 0x0000000000000000
0x7fb82c016580: 0x0000000000000000 0x0000000000000000
0x7fb82c016590: 0x0000000000000000 0x0000000000000000
(gdb) c
Continuing.
Thread 2 "isc-net-0000" hit Breakpoint 2, 0x00007fb83ff11309 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/i $pc
=> 0x7fb83ff11309: mov DWORD PTR [rax+rcx*4],edi // overwrite next chunk header
(gdb) x/xg $rax+$rcx*4
0x7fb82c0164e8: 0x0000000000000025
(gdb) bt
#0 0x00007fb83ff11309 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
#1 0x00007fb83ff1144a in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
#2 0x00007fb83ff11a2d in gss_accept_sec_context_spnego () from /lib/x86_64-linux-gnu/libdns.so.1601
#3 0x00007fb83ff1d083 in dst_gssapi_acceptctx () from /lib/x86_64-linux-gnu/libdns.so.1601
#4 0x00007fb83feb65cd in dns_tkey_processquery () from /lib/x86_64-linux-gnu/libdns.so.1601
#5 0x00007fb83ffcf27f in ns_query_start () from /lib/x86_64-linux-gnu/libns.so.1601
#6 0x00007fb83ffb2131 in ns.client_request () from /lib/x86_64-linux-gnu/libns.so.1601
#7 0x00007fb83fce2b26 in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#8 0x00007fb83fce33cd in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#9 0x00007fb83fcdf74c in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#10 0x00007fb83f470b01 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#11 0x00007fb83f471638 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x00007fb83f476ae0 in uv.io_poll () from /lib/x86_64-linux-gnu/libuv.so.1
#13 0x00007fb83f4667ac in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#14 0x00007fb83fcdec2d in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#15 0x00007fb83f7b4609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#16 0x00007fb83f6d5293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.
Thread 3 "isc-net-0001" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fb83c8b6700 (LWP 77139)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)
```
-- CREDIT ---------------------------------------
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day InitiativeFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2355Incorrect increment of inactive in rbtdb.c:maybe_free_rbtdb()2021-01-08T13:29:07ZMark AndrewsIncorrect increment of inactive in rbtdb.c:maybe_free_rbtdb()It is possible to have two threads destroying an rbtdb at the same time when detachnode() executes and removes the last reference to a node between exiting being set to true for the node and testing if the references are zero in maybe_fr...It is possible to have two threads destroying an rbtdb at the same time when detachnode() executes and removes the last reference to a node between exiting being set to true for the node and testing if the references are zero in maybe_free_rbtdb().
```
Thread 18 (Thread 80113ef00 (LWP 100776/<unknown>)):
#0 0x0000000800d5843a in _umtx_op () from /home/support/XXXXXXX/lib/libc.so.7
#1 0x0000000800c7e9dd in pthread_mutex_unlock () from /home/support/XXXXXXX/lib/libthr.so.3
#2 0x00000000006c31ba in task_ready (task=0x805272c80) at task.c:424
#3 0x00000000006c3412 in isc_task_sendto (task0=0x805272c80, eventp=0x7fffdfdfc208, c=1) at task.c:570
#4 0x00000000006c3232 in isc_task_send (task0=0x805272c80, eventp=0x7fffdfdfc208) at task.c:517
#5 0x0000000000491e72 in free_rbtdb (rbtdb=0x827229aa0, log=true, event=0x0) at rbtdb.c:1122
#6 0x000000000049760f in detachnode (db=0x827229aa0, targetp=0x7fffdfdfcaa0) at rbtdb.c:5477
#7 0x00000000004a0cdf in rdataset_disassociate (rdataset=0x82f4d2f48) at rbtdb.c:8816
#8 0x00000000005452bd in dns_rdataset_disassociate (rdataset=0x82f4d2f48) at rdataset.c:111
#9 0x0000000000441c40 in msgresetnames (msg=0x82f4c74a0, first_section=0) at message.c:465
#10 0x000000000043b95d in msgreset (msg=0x82f4c74a0, everything=false) at message.c:551
#11 0x000000000043b907 in dns_message_reset (msg=0x82f4c74a0, intent=1) at message.c:779
#12 0x000000000036a02d in ns_client_endrequest (client=0x82ecd8b60) at client.c:229
#13 0x0000000000369a2c in ns__client_reset_cb (client0=0x82ecd8b60) at client.c:1536
#14 0x00000000006a67a6 in isc_nmhandle_detach (handlep=0x7fffdfdfcc58) at netmgr.c:1261
#15 0x00000000006a7552 in isc__nm_uvreq_put (req0=0x7fffdfdfcc98, sock=0x83b1e1a00) at netmgr.c:1393
#16 0x00000000006b073f in tcpdnssend_cb (handle=0x83b98aa00, result=54, cbarg=0x83e174800) at tcpdns.c:539
#17 0x00000000006adbc9 in tcp_send_cb (req=0x82fbaf278, status=-32) at tcp.c:1024
#18 0x0000000800c3edcc in uv__stream_destroy () from /home/support/XXXXXXX/usr/local/lib/libuv.so.1
#19 0x0000000800c3e717 in uv__stream_init () from /home/support/XXXXXXX/usr/local/lib/libuv.so.1
#20 0x0000000800c341eb in uv_run () from /home/support/XXXXXXX/usr/local/lib/libuv.so.1
#21 0x00000000006a28df in nm_thread (worker0=0x8011e93a8) at netmgr.c:488
#22 0x0000000800c76736 in pthread_create () from /home/support/XXXXXXX/lib/libthr.so.3
#23 0x0000000000000000 in ?? ()
Thread 12 (Thread 801140d00 (LWP 100782/<unknown>)):
#0 0x0000000800e4f1ba in thr_kill () from /home/support/XXXXXXX/lib/libc.so.7
#1 0x0000000800e4d5e4 in raise () from /home/support/XXXXXXX/lib/libc.so.7
#2 0x0000000800dc17e9 in abort () from /home/support/XXXXXXX/lib/libc.so.7
#3 0x0000000000300f21 in assertion_failed (file=0x252469 "rbtdb.c", line=1146, type=isc_assertiontype_require, cond=0x28ef26 "isc_refcount_current(&rbtdb->node_locks[i].references) == 0") at main.c:261
#4 0x000000000067dd18 in isc_assertion_failed (file=0x252469 "rbtdb.c", line=1146, type=isc_assertiontype_require, cond=0x28ef26 "isc_refcount_current(&rbtdb->node_locks[i].references) == 0") at assertions.c:46
#5 0x000000000049207c in free_rbtdb (rbtdb=0x827229aa0, log=true, event=0x0) at rbtdb.c:1146
#6 0x00000000004b16de in free_rbtdb_callback (task=0x805272c80, event=0x836d08768) at rbtdb.c:843
#7 0x00000000006ca483 in dispatch (manager=0x801d5c780, threadid=1) at task.c:1152
#8 0x00000000006c5ed1 in run (queuep=0x801d5d7c8) at task.c:1344
#9 0x0000000800c76736 in pthread_create () from /home/support/XXXXXXX/lib/libthr.so.3
#10 0x0000000000000000 in ?? ()
```January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/2356no dnstap messages with unix socket2021-01-06T06:37:23ZDenis MACHARDno dnstap messages with unix socket### Summary
Hello, I try to use the dnstap feature but no dnstap messages are generated with a unix socket.
if a use the dnstap-output file then dnstap messages are generated.
### BIND version used
Bind 9.16 on CentOS8 - https://copr....### Summary
Hello, I try to use the dnstap feature but no dnstap messages are generated with a unix socket.
if a use the dnstap-output file then dnstap messages are generated.
### BIND version used
Bind 9.16 on CentOS8 - https://copr.fedorainfracloud.org/coprs/isc/bind/
/opt/isc/isc-bind/root/usr/sbin/named -v
BIND 9.16.10 (Stable Release) <id:fac8def>
I have also tested with bind 9.11 and it's work fine so I don't know what i'm doing wrong.
### Steps to reproduce
install the dnstap receiver and start-it in unix mode
```
python3 -m pip install dnstap_receiver
su - named -s /bin/bash -c "dnstap_receiver -u /var/opt/isc/scls/isc-bind/named/data/dnstap.out -v"
```
Configure named with dnstap and restart-it
```
options {
directory "/var/opt/isc/scls/isc-bind/named/data";
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
dnssec-validation auto;
dnstap-identity "bind";
dnstap-version "xxx";
dnstap-output unix "dnstap.out";
dnstap { all; };
}
```
When I make a "dig", no dnstap messages are received, nothing happened. I have also tested with the dnstap in go and it's the same thing.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2357Cannot compile current versions on macOS "Catalina"2021-03-04T12:22:26ZJP MensCannot compile current versions on macOS "Catalina"Compiling on macOS Catalina 10.15.7 is failing for current versions:
- 9.16.10
- 9.17.8
- git checkout
I believe this is _supposed_ to be possible, at least it used to be: going back to `9.11.26` shows it was: that version builds tools ...Compiling on macOS Catalina 10.15.7 is failing for current versions:
- 9.16.10
- 9.17.8
- git checkout
I believe this is _supposed_ to be possible, at least it used to be: going back to `9.11.26` shows it was: that version builds tools and _named_ (but fails at the end on tests on my machine because of missing Python2).
I've got output of `make -k` [at this gist](https://gist.github.com/jpmens/291a7a2013ed17623cc4b44e63e3dbce).March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2359missing newlines in log messages dnssec-signzone/dnssec-verify2021-01-08T11:40:29ZMark Andrewsmissing newlines in log messages dnssec-signzone/dnssec-verifyChange 664b8f04f5f2322086138f5eda5899a62bcc019b needs to be reimplemented. The newlines need to be added by report not the caller to ensure that named's logs don't have spurious new lines. Perhaps use flockfile/funlockfile to prevent l...Change 664b8f04f5f2322086138f5eda5899a62bcc019b needs to be reimplemented. The newlines need to be added by report not the caller to ensure that named's logs don't have spurious new lines. Perhaps use flockfile/funlockfile to prevent log messages being mangled.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/2360dnstap-read: please modify to print query/response timestamps with milliseconds2023-05-05T10:34:18Zssbertilsondnstap-read: please modify to print query/response timestamps with milliseconds### Description
Desire to be able to use dnstap-read to track latency - milliseconds not just by seconds. Simple function call change in print_yaml from using existing libisc function isc_time_formatISO8601 to existing isc_time_formatI...### Description
Desire to be able to use dnstap-read to track latency - milliseconds not just by seconds. Simple function call change in print_yaml from using existing libisc function isc_time_formatISO8601 to existing isc_time_formatISO8601ms in 2 places. Am using this in a version modified from 9.16.6.
### Request
```
diff --git a/bin/tools/dnstap-read.c b/bin/tools/dnstap-read.c
index 5b15fa8153..2663668c08 100644
--- a/bin/tools/dnstap-read.c
+++ b/bin/tools/dnstap-read.c
@@ -230,13 +230,13 @@ print_yaml(dns_dtdata_t *dt) {
if (!isc_time_isepoch(&dt->qtime)) {
char buf[100];
- isc_time_formatISO8601(&dt->qtime, buf, sizeof(buf));
+ isc_time_formatISO8601ms(&dt->qtime, buf, sizeof(buf));
printf(" query_time: !!timestamp %s\n", buf);
}
if (!isc_time_isepoch(&dt->rtime)) {
char buf[100];
- isc_time_formatISO8601(&dt->rtime, buf, sizeof(buf));
+ isc_time_formatISO8601ms(&dt->rtime, buf, sizeof(buf));
printf(" response_time: !!timestamp %s\n", buf);
}
```
### Links / referencesMay 2023 (9.16.41, 9.16.41-S1, 9.18.15, 9.18.15-S1, 9.19.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2361The additional system test fails on system:gcc:mutexatomics2021-01-07T13:38:37ZMatthijs Mekkingmatthijs@isc.orgThe additional system test fails on system:gcc:mutexatomicshttps://gitlab.isc.org/isc-projects/bind9/-/jobs/1377090https://gitlab.isc.org/isc-projects/bind9/-/jobs/1377090January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/2362named-checkzone not failing check for a zone file that fails to load in named2020-12-23T17:40:29ZNathan Neulingernamed-checkzone not failing check for a zone file that fails to load in named### Summary
named erroring on hostname with underscore (correct)
named-checkzone says same zone file is fine (not correct)
### BIND version used
9.16.7
### Steps to reproduce
Create zone file with a underscore in middle of name:
fo...### Summary
named erroring on hostname with underscore (correct)
named-checkzone says same zone file is fine (not correct)
### BIND version used
9.16.7
### Steps to reproduce
Create zone file with a underscore in middle of name:
foo_bar.example.com. IN A 1.2.3.4
### What is the current *bug* behavior?
named-checkzone says zone is fine
named refuses to load the zone saying it's got a bad owner name
### What is the expected *correct* behavior?
named-checkzone should have reported the same error as named - not allowed the file through sanity checks and then have it refuse to load in named.https://gitlab.isc.org/isc-projects/bind9/-/issues/2363update rejected: post update name server sanity check failed2021-01-05T15:17:54Ztpickle-pyupdate rejected: post update name server sanity check failed
### Summary
When creating subed subdomain txt records for certbot changellenges, nsupdate utility fails to update record.
### BIND version used
```
BIND 9.11.20-RedHat-9.11.20-5.el8 (Extended Support Version) <id:f3d1d66>
running on ...
### Summary
When creating subed subdomain txt records for certbot changellenges, nsupdate utility fails to update record.
### BIND version used
```
BIND 9.11.20-RedHat-9.11.20-5.el8 (Extended Support Version) <id:f3d1d66>
running on Linux x86_64 4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19 17:20:08 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/libexec/platform-python' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--enable-openssl-hash' '--with-geoip2' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=no' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 8.3.1 20191121 (Red Hat 8.3.1-5)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.2.0
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
```
nsupdate -y hmac-sha512:**letsencrypt.***:**privatekey**
> server 212.x.x.63
> update add _acme-challenge.test.ddns.flex-sys.us.ip6tunnel.tk 3600 txt "8YVbEhYivK2XhImgfDEvNOEv9gs5MKpfOLYUjwgyoXM"
> send
update failed: REFUSED
```
### What is the current *bug* behavior?
Throws error in logs and says REFUSED
```
Dec 24 21:55:35 ns2 named[2865777]: client @0x7f44980e2d90 154.x.x.122#52119/key letsencrypt: view external: signer "letsencrypt" approved
Dec 24 21:55:35 ns2 named[2865777]: client @0x7f44980e2d90 154.x.x.122#52119/key letsencrypt: view external: updating zone 'ip6tunnel.tk/IN': adding an RR at '_acme-challenge.test.ddns.flex-sys.us.ip6tunnel.tk' TXT "8YVbEhYivK2XhImgfDEvNOEv9gs5MKpfOLYUjwgyoXM"
Dec 24 21:55:35 ns2 named[2865777]: client @0x7f44980e2d90 154.x.x.122#52119/key letsencrypt: view external: updating zone 'ip6tunnel.tk/IN': update rejected: post update name server sanity check failed
```
### What is the expected *correct* behavior?
```
Dec 24 21:01:21 ns2 named[2865777]: client @0x7f449aefe0d0 154.x.x.122#40284/key letsencrypt: view external: updating zone 'ip6tunnel.tk/IN': adding an RR at '_acme-challenge.test.ddns.flex-sys.us.ip6tunnel.tk' TXT "8YVbEhYivK2XhImgfDEvNOEv9gs5MKpfOLYUjwgyo>
```
### Relevant configuration files
Configs are working for nsupdate for shorter (sub)domain names, no policies are being enforected
### Relevant logs and/or screenshots
```
[root@ddns ~]# dig -t txt _acme-challenge.test.ddns.flex-sys.us.ip6tunnel.tk
; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8 <<>> -t txt _acme-challenge.test.ddns.flex-sys.us.ip6tunnel.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34443
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_acme-challenge.test.ddns.flex-sys.us.ip6tunnel.tk. IN TXT
;; AUTHORITY SECTION:
ip6tunnel.tk. 1799 IN SOA ns1.ddns.flex-sys.us. admin.flex-sys.us.ip6tunnel.tk. 2020122435 3600 600 1209600 3600
;; Query time: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Dec 24 21:02:58 EST 2020
;; MSG SIZE rcvd: 141
```
Wildcard exists
```
[root@ddns ~]# dig -t txt _acme-challenge.*.ip6tunnel.tk
; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8 <<>> -t txt _acme-challenge.*.ip6tunnel.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46582
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_acme-challenge.*.ip6tunnel.tk. IN TXT
;; ANSWER SECTION:
_acme-challenge.*.ip6tunnel.tk. 119 IN TXT "8YVbEhYivK2XhImgfDEvNOEv9gs5MKpfOLYUjwgyoXM"
```
### Possible fixes
No fixes tried, tried to use wild cards for long subdomains, however it will not resolve specifiedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2364CID 314969: Control flow issues (DEADCODE) in zoneconf.c2021-01-18T12:35:31ZMichal NowakCID 314969: Control flow issues (DEADCODE) in zoneconf.cCoverity Scan identified the following issue in `bin/named/zoneconf.c` on Sunday December 27 on `v9_16` and `main`:
```
*** CID 314969: Control flow issues (DEADCODE)
/bin/named/zoneconf.c: 2212 in named_zone_inlinesigning()
2206 ...Coverity Scan identified the following issue in `bin/named/zoneconf.c` on Sunday December 27 on `v9_16` and `main`:
```
*** CID 314969: Control flow issues (DEADCODE)
/bin/named/zoneconf.c: 2212 in named_zone_inlinesigning()
2206 if (!inline_signing && !zone_is_dynamic &&
2207 cfg_map_get(zoptions, "dnssec-policy", &signing) == ISC_R_SUCCESS &&
2208 signing != NULL)
2209 {
2210 if (strcmp(cfg_obj_asstring(signing), "none") != 0) {
2211 inline_signing = true;
>>> CID 314969: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression ""no"" inside this statement: "dns_zone_log(zone, 1, "inli...".
2212 dns_zone_log(
2213 zone, ISC_LOG_DEBUG(1), "inline-signing: %s",
2214 inline_signing
2215 ? "implicitly through dnssec-policy"
2216 : "no");
2217 } else {
```
The culprit likely lies in cf420b2af0d45693d0f5f34d9113ea411b5f2225 as it's the only change in that file between last two Coverity Scan runs.
Coverity Scan link: https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=38520332&defectInstanceId=11383777&mergedDefectId=314969.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2365Use of "statistics-channel" appears to cause a memory leak.2023-04-04T14:17:01ZBunny EvansUse of "statistics-channel" appears to cause a memory leak.### Summary
Telegraf pointing at bind 9.11 (or 9.16) observes a continuous memory increase.
### BIND version used
BIND 9.11.26 (Extended Support Version) <id:3ff8620>
running on FreeBSD amd64 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GE...### Summary
Telegraf pointing at bind 9.11 (or 9.16) observes a continuous memory increase.
### BIND version used
BIND 9.11.26 (Extended Support Version) <id:3ff8620>
running on FreeBSD amd64 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC
The same applies with 9.16.9/10
### Steps to reproduce
Enable statistics channels. In this case:
statistics-channels {
inet 10.0.0.8 port 8053 allow { 10.0.0.0/24; };
inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
};
Add telegraf to the mix (as per https://github.com/influxdata/telegraf/blob/release-1.14/plugins/inputs/bind/README.md )
[inputs.bind]
urls = ["http://localhost:8053/xml/v3"]
gather_memory_contexts = false
gather_views = true
(this leak appears independent of /xml/v3 or /json/v1 )
### What is the current *bug* behavior?
Memory grows at about 230 kB / minute with 9.11
I think it was around 2 MB / minute with 9.16
9.16.9, 6 days, grew to 19 GB.
9.16.9, 7 days, grew to 22 GB.
9.16.10, 4 days, grew to 11 GB.
9.11.26, 4 days, grew to 2 GB.
It has not yet run to the point of crashing.
Accessing the web interface version causes an approximate 2MB jump in "Total Memory" But that goes
away after a minute or so.
### What is the expected *correct* behavior?
To be able to run for weeks without growing endlessly.
### Relevant configuration files
### Relevant logs and/or screenshots
when run with "-m report" memstats file contains:
Dump of all outstanding memory allocations:
None.
![Screenshot_2020-12-29_161432](/uploads/020d4cc4db08943152b716f9493601b2/Screenshot_2020-12-29_161432.png)
![Screenshot_2020-12-29_163417](/uploads/efbbcc9eb19322d408834d4a1ff535eb/Screenshot_2020-12-29_163417.png)
### Possible fixes
The code, while awesome, is beyond my ability to grok.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2366BIND 9.16.10 build fails with libmaxminddb-1.4.32021-01-08T11:54:20ZGreg RabilBIND 9.16.10 build fails with libmaxminddb-1.4.3Having compile problems when building BIND 9.16.10 on CentOS 7 with support for GeoIP using MaxMindDB 1.4.3:
```
./configure --with-openssl=/opt/bind916/openssl --with-maxminddb=/opt/bind916/maxminddb
make
<...snip...>
gcc -std=gnu99 -g...Having compile problems when building BIND 9.16.10 on CentOS 7 with support for GeoIP using MaxMindDB 1.4.3:
```
./configure --with-openssl=/opt/bind916/openssl --with-maxminddb=/opt/bind916/maxminddb
make
<...snip...>
gcc -std=gnu99 -g -O2 -pthread -fPIC -Wl,--export-dynamic -o resolve \
resolve.o ../irs/libirs.a ../dns/libdns.a -L/opt/bind916/maxminddb/lib ../isccfg/libisccfg.a ../isc/libisc.a -L/opt/bind916/openssl/lib -lcrypto -lxml2 -lz -L/opt/bind916/libuv/lib -luv -ldl -ldl
../dns/libdns.a(geoip2.o): In function `get_entry_for':
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:96: undefined reference to `MMDB_lookup_sockaddr'
../dns/libdns.a(geoip2.o): In function `dns_geoip_match':
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:368: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:345: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:328: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:304: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:296: undefined reference to `MMDB_get_value'
collect2: error: ld returned 1 exit status
make[2]: *** [resolve] Error 1
make[2]: Leaving directory `/opt/work3/bind-9.16.10/lib/samples'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/opt/work3/bind-9.16.10/lib'
make: *** [subdirs] Error 1
```January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)