BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-09-09T19:36:12Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2897rndc thaw does not process manually made changes to a dynamic zone2021-09-09T19:36:12ZJakob Dhondtrndc thaw does not process manually made changes to a dynamic zone### Summary
When freezing a dynamic zone with `rndc freeze <zone>`, manually editing the zone file and then unfreezing the zone with `rndc thaw <zone>` the manual changes do not seem to be processed. E.g. when manually adding an entry i...### Summary
When freezing a dynamic zone with `rndc freeze <zone>`, manually editing the zone file and then unfreezing the zone with `rndc thaw <zone>` the manual changes do not seem to be processed. E.g. when manually adding an entry it won't be returned after unfreezing the zone, when querying it with dig. If I am not misunderstanding the [documentation](https://bind9.readthedocs.io/en/latest/advanced.html#the-journal-file) the following paragraph seems to suggest that manual changes to a dynamic zone should be immediately processed as described.
> To make changes to a dynamic zone manually, follow these steps: first, disable dynamic updates to the zone using rndc freeze zone. This updates the zone file with the changes stored in its .jnl file. Then, edit the zone file. Finally, run rndc thaw zone to reload the changed zone and re-enable dynamic updates.
This seems to be related to issue #2186.
### BIND version used
```
BIND 9.16.20 (Extended Support Version) <id:26db37f>
running on Linux x86_64 3.10.0-1160.25.1.el7.x86_64 #1 SMP Tue Apr 13 18:55:45 EDT 2021
built by make with '--build=x86_64-koji-linux-gnu' '--host=x86_64-koji-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/named' '--bindir=/opt/named/bin' '--sbindir=/opt/named/sbin' '--sysconfdir=/etc' '--datadir=/opt/named/share' '--includedir=/opt/named/include' '--libdir=/opt/named/lib64' '--libexecdir=/opt/named/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/opt/named/share/man' '--infodir=/opt/named/share/info' '--exec-prefix=/opt/named' '--disable-static' '--enable-dnstap' '--disable-openssl-version-check' '--with-randomdev=/dev/urandom' '--with-pic' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-tuning=large' '--with-python' '--with-python-install-dir=/opt/named/usr/lib/python2.7/site-packages' '--with-docbook-xsl=/opt/named/share/sgml/docbook/xsl-stylesheets' '--includedir=/opt/named/include/bind9' 'build_alias=x86_64-koji-linux-gnu' 'host_alias=x86_64-koji-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/opt/named/lib64/pkgconfig:/opt/named/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.0.2
linked to protobuf-c version: 1.0.2
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
```
### Steps to reproduce
1. Have a dynamic zone with the following config and content.
```
zone "zone.dyn-test.rpz.switch.ch" {
type master;
file "dynamic/zone.dyn-test.rpz.switch.ch";
update-policy {
grant "zone.dyn-test.rpz.switch.ch.tsig" subdomain "zone.dyn-test.rpz.switch.ch" "ANY";
};
dnssec-policy "none";
};
```
```
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073347 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
```
2. Check that dynamic updates work
* on a different machine that is allowed to do dynamic updates:
```
nsupdate -k <tsig-key>
> server pepsi.switch.ch
> zone zone.dyn-test.rpz.switch.ch
> update add test.zone.dyn-test.rpz.switch.ch 300 a 127.0.0.1
> send
```
* check for the record on the nameserver:
```
$ dig test.zone.dyn-test.rpz.switch.ch @localhost +norec
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.zone.dyn-test.rpz.switch.ch @localhost +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23411
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.zone.dyn-test.rpz.switch.ch. IN A
;; ANSWER SECTION:
test.zone.dyn-test.rpz.switch.ch. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
zone.dyn-test.rpz.switch.ch. 300 IN NS bona.switch.ch.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 09 11:44:51 CEST 2021
;; MSG SIZE rcvd: 105
```
3. Freeze the zone, manually add a record and unfreeze the zone.
* `$ rndc freeze zone.dyn-test.rpz.switch.ch`
* Zone file correctly shows the dynamically added record.
```
$ cat zone.dyn-test.rpz.switch.ch
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073348 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
$ORIGIN zone.dyn-test.rpz.switch.ch.
test A 127.0.0.1
```
* Add another record e.g.
```
$ cat zone.dyn-test.rpz.switch.ch
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073348 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
$ORIGIN zone.dyn-test.rpz.switch.ch.
test A 127.0.0.1
A 127.0.0.2
```
* `$ rndc thaw zone.dyn-test.rpz.switch.ch`
* Logs:
```
09-Sep-2021 11:49:50.536 general: info: received control channel command 'freeze zone.dyn-test.rpz.switch.ch'
09-Sep-2021 11:49:52.203 general: info: freezing zone 'zone.dyn-test.rpz.switch.ch/IN': success
09-Sep-2021 11:53:06.670 general: info: received control channel command 'thaw zone.dyn-test.rpz.switch.ch'
09-Sep-2021 11:53:06.671 general: info: thawing zone 'zone.dyn-test.rpz.switch.ch/IN': success
```
4. Query the record again.
```
$ dig test.zone.dyn-test.rpz.switch.ch @localhost +norec
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.zone.dyn-test.rpz.switch.ch @localhost +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19316
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.zone.dyn-test.rpz.switch.ch. IN A
;; ANSWER SECTION:
test.zone.dyn-test.rpz.switch.ch. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
zone.dyn-test.rpz.switch.ch. 300 IN NS bona.switch.ch.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 09 11:54:39 CEST 2021
;; MSG SIZE rcvd: 105
```
### What is the current *bug* behavior?
After executing the 4 steps above only one A record is returned.
### What is the expected *correct* behavior?
After executing the 4 steps above I'd expect there to be two A records.
### Relevant configuration files
named.conf
```
...
some acls
...
controls {
inet 127.0.0.1 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
inet ::1 allow {
::1/128;
} keys {
"rndc-key";
};
};
dnssec-policy "test" {
dnskey-ttl 3600;
keys {
csk key-directory lifetime unlimited algorithm 13;
};
max-zone-ttl 3600;
parent-ds-ttl 3600;
parent-propagation-delay 3600;
publish-safety 3600;
retire-safety 3600;
signatures-refresh P1D;
zone-propagation-delay 300;
};
logging {
channel "switch_local" {
file "/var/log/named/named" versions 10 size 6291456;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "switch_other" {
file "/var/log/named/other" versions 10 size 6291456;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category "general" {
"switch_local";
};
category "notify" {
"switch_local";
};
category "xfer-in" {
"switch_local";
};
category "xfer-out" {
"switch_local";
};
category "network" {
"switch_local";
};
category "dnssec" {
"switch_local";
};
category "default" {
"switch_other";
};
};
options {
directory "/etc/bind/zones";
listen-on port 53 {
"any";
};
listen-on-v6 port 53 {
"any";
};
pid-file "/var/run/named/named.pid";
server-id hostname;
transfers-in 100;
transfers-out 100;
transfers-per-ns 10;
version "contact dns-operation@switch.ch";
allow-query-cache {
"none";
};
check-names master warn;
dnssec-validation no;
ixfr-from-differences yes;
query-source address 130.59.117.36 port 0;
query-source-v6 address 2001:620:0:1005:21a:4aff:fede:5a port 0;
recursion no;
allow-transfer {
"XFR-SWITCH";
};
check-integrity no;
check-sibling no;
notify explicit;
notify-source 130.59.117.36;
notify-source-v6 2001:620:0:1005:21a:4aff:fede:5a;
transfer-source 130.59.117.36;
transfer-source-v6 2001:620:0:1005:21a:4aff:fede:5a;
use-alt-transfer-source no;
};
statistics-channels {
inet 127.0.0.1 port 8053 allow {
127.0.0.1/32;
};
inet ::1 port 8053 allow {
::1/128;
};
};
key "rndc-key" {
algorithm "hmac-md5";
secret "????????????????????????";
};
...
more keys
...
key "zone.dyn-test.rpz.switch.ch.tsig" {
algorithm "HMAC-SHA512";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
...
more zones
...
zone "zone.dyn-test.rpz.switch.ch" {
type master;
file "dynamic/zone.dyn-test.rpz.switch.ch";
update-policy {
grant "zone.dyn-test.rpz.switch.ch.tsig" subdomain "zone.dyn-test.rpz.switch.ch" "ANY";
};
dnssec-policy "none";
};
```
I removed some parts of the config. I hope they're not relevant.
### Relevant logs and/or screenshots
See above.
### Possible fixeshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2896TXT record parsing interop issue in named-compilezone2021-09-08T11:23:35ZGavin BrownTXT record parsing interop issue in named-compilezone<!--
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
I have an interoperability issue where `named-compilezone` and `ldns-read-zone` handle the following TXT record differently:
```
example.com. 3600 IN TXT "foo""bar"
```
Note the lack of space between `"foo"` and `"bar"`. From reading RFC 1035 it's not clear whether the space between the two text segments is required or optional:
> ```
> 3.3.14. TXT RDATA format
>
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> / TXT-DATA /
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
> where:
>
> TXT-DATA One or more <character-string>s.
> ```
A `<character-string>` is defined in Section 5 as follows:
> ```
> <character-string> is expressed in one or two ways: as a contiguous set
> of characters without interior spaces, or as a string beginning with a "
> and ending with a ". Inside a " delimited string any character can
> occur, except for a " itself, which must be quoted using \ (back slash).
> ```
RFC 1035 says nothing about how consecutive `<character-string>`s are delimited from each other.
`named-compilezone` parses the above TXT record without issue, and in its output, re-emits the TXT record with a space between each segment:
```
example.com. 3600 IN TXT "foo" "bar"
```
My question is whether or `named-compilezone` should reject the input above because it's malformed.
`ldns-read-zone` parses the record incorrectly and produces a mangled record, which I've already reported [here](https://github.com/NLnetLabs/ldns/issues/139).
### BIND version used
```
$ named-compilezone -v
9.16.7
```
Installed using Homebrew on macOS Big Sur, but this behaviour has also been reported on other versions/OSes.
### Steps to reproduce
`named-compilezone -i none -o /dev/stdout example.com example.com.txt`
[example.com.txt](/uploads/6f3e9f50560dbc932d1336da202a322c/example.com.txt)
### What is the current *bug* behavior?
```
$ named-compilezone -i none -o /dev/stdout example.com example.com.txt
zone example.com/IN: loaded serial 2021090201
example.com. 900 IN SOA ns.icann.org. noc.dns.icann.org. 2021090201 7200 3600 1209600 3600
example.com. 900 IN NS a.iana-servers.net.
example.com. 900 IN NS b.iana-servers.net.
example.com. 900 IN TXT "foo" "bar"
OK
```
### What is the expected *correct* behavior?
The existing behaviour *or* `named-compilezone` should reject the RR as malformed.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
N/Ahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2895named can create unrecoverable managed-keys.jnl file2022-11-01T11:20:24ZOndřej Surýnamed can create unrecoverable managed-keys.jnl file1. Run `named` in a way it can't reach the internet (f.e. set the query-source port to the listening port).
```
options {
query-source address 10.10.10.20 port 53054;
port 53;
listen-on port 53053 { 10.10.10.20; };
};
```
2. Stop it a...1. Run `named` in a way it can't reach the internet (f.e. set the query-source port to the listening port).
```
options {
query-source address 10.10.10.20 port 53054;
port 53;
listen-on port 53053 { 10.10.10.20; };
};
```
2. Stop it after you see `running` in the log immediately, but before `resolver priming query complete` is printed
3. Verify that managed-keys.jnl is bogus with `$ bin/tools/named-journalprint managed-keys.bind.jnl`
```
del . 0 IN SOA . . 0 0 0 0 0
add . 0 IN SOA . . 1 0 0 0 0
add . 0 IN TYPE65533 \# 16 00000000000000000000000000000000
```
4. Now fix your config:
```
options {
query-source address 10.10.10.20 port 0;
port 53;
listen-on port 53053 { 10.10.10.20; };
};
```
5. Run `named` again and it will not recover from the broken `managed-keys.bind.jnl` file:
```
08-Sep-2021 09:50:48.172 running
08-Sep-2021 09:50:49.784 managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
08-Sep-2021 09:50:49.788 validating ./NS: no valid signature found
08-Sep-2021 09:50:49.788 no valid RRSIG resolving './NS/IN': 198.97.190.53#53
08-Sep-2021 09:50:49.796 validating ./NS: no valid signature found
08-Sep-2021 09:50:49.796 no valid RRSIG resolving './NS/IN': 199.7.83.42#53
08-Sep-2021 09:50:49.804 validating ./NS: no valid signature found
08-Sep-2021 09:50:49.804 no valid RRSIG resolving './NS/IN': 193.0.14.129#53
08-Sep-2021 09:50:53.028 validating ./NS: no valid signature found
08-Sep-2021 09:50:53.028 no valid RRSIG resolving './NS/IN': 198.41.0.4#53
08-Sep-2021 09:50:53.040 validating ./NS: no valid signature found
08-Sep-2021 09:50:53.040 no valid RRSIG resolving './NS/IN': 192.33.4.12#53
08-Sep-2021 09:50:58.168 resolver priming query complete
08-Sep-2021 09:51:13.172 managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
```
This is low-priority issue, but it should be recorded somewhere.November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2894Windows Service Error 1067 for v. 9.16.202021-09-06T15:28:42ZmikeksWindows Service Error 1067 for v. 9.16.20### Summary
Unable to start ISC Bind v. 9.16.20 as Windows Service. It works with ISC Bind v. 9.11.35.
### BIND version used
The problem only occurs with ISC Bind 9.16.20, but not in 9.11.35
### Steps to reproduce
1. Download Windo...### Summary
Unable to start ISC Bind v. 9.16.20 as Windows Service. It works with ISC Bind v. 9.11.35.
### BIND version used
The problem only occurs with ISC Bind 9.16.20, but not in 9.11.35
### Steps to reproduce
1. Download Windows x64 binaries for ISC Bind 9.16.20
2. Run BINDInstall.exe as administrator, install the Bind.
3. Put your configs into ./etc folder
4. Allow full access to bind service account
5. Successfully run the Bind from command line: named -f
6. Attempt to run as service causes Windows error 1067
### What is the current *bug* behavior?
Attempt to run Windows service causes error 1067.
### What is the expected *correct* behavior?
Service should be able to start. The same configuration works with Bind 9.11.35.
### Relevant logs and/or screenshots
The Windows Application Events log doesn't reveal any error(s).https://gitlab.isc.org/isc-projects/bind9/-/issues/2893Release Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.182021-09-20T16:11:26ZMichał KępieńRelease Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.18## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, Septemb...## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, September 1st, 2021
**Tagging Deadline:** Monday, September 6th, 2021
**Public Release:** Wednesday, September 15th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=v9_16)
## 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.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### 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)*** Announce (on Mattermost) that the code freeze is over.
- [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 (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [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 confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [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.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Michał KępieńMichał Kępień2021-09-15https://gitlab.isc.org/isc-projects/bind9/-/issues/2892The Umbrella EDNS option has been published by IANA2021-09-13T20:37:12ZMark AndrewsThe Umbrella EDNS option has been published by IANA```
20292 Umbrella Ident Optional [https://developer.cisco.com/docs/cloud-security/#!integrating-network-devices/rdata-description][Cisco_CIE_DNS_team]
```
- Add the ability to check and display the option contents
- Add support to +edn...```
20292 Umbrella Ident Optional [https://developer.cisco.com/docs/cloud-security/#!integrating-network-devices/rdata-description][Cisco_CIE_DNS_team]
```
- Add the ability to check and display the option contents
- Add support to +ednsopt in dig.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2891Missing parenthesis in the `atomic_load_explicit` macro2021-09-01T10:18:23ZArаm SаrgsyаnMissing parenthesis in the `atomic_load_explicit` macroThere are missing parenthesis in the definition of `atomic_load_explicit` macro in `lib/isc/win32/include/isc/stdatomic.h` which results of always evaluating to `sizeof(bool)` instead of getting the size of the actual expression.There are missing parenthesis in the definition of `atomic_load_explicit` macro in `lib/isc/win32/include/isc/stdatomic.h` which results of always evaluating to `sizeof(bool)` instead of getting the size of the actual expression.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2890Update documentation with respect to sig-validity-interval and UPDATE2021-09-03T03:19:52ZMark AndrewsUpdate documentation with respect to sig-validity-interval and UPDATEWhen processing UPDATE requests validity interval of the RRSIGs is randomly chosen to be between the maximum and minimum values of the sig-validity-interval. The ARM needs to be updated to reflect this.When processing UPDATE requests validity interval of the RRSIGs is randomly chosen to be between the maximum and minimum values of the sig-validity-interval. The ARM needs to be updated to reflect this.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2889LMDB should flush to disk2021-08-30T21:11:00ZPetr MenšíkLMDB should flush to disk### Description
When LMDB support adds new zone, no change occurs immediately in its view_name.nzd file. Unlike plain file view_name.nzf, changes are not stored immediately to permanent storage. I admit it would have much better perform...### Description
When LMDB support adds new zone, no change occurs immediately in its view_name.nzd file. Unlike plain file view_name.nzf, changes are not stored immediately to permanent storage. I admit it would have much better performance, but I think save to disk should be possible without restarting named.
### Request
named should allow automatic flushing to disk on some events. Be it periodic timer maintenance after some time or manual rndc call, for example during sync without zone name or for zone added via rndc addzone, ``mdb_env_sync`` should be called sometime. It is never used in current implementation, on any event. I think data safety is important too, not only performance.
It is especially problematic on distributions, because LMDB support cannot be disabled once its support is built-in. NZF files were much slower, but were more safe.
### Links / references
- https://bugzilla.redhat.com/show_bug.cgi?id=1975775
- http://www.lmdb.tech/doc/group__mdb.html#ga85e61f05aa68b520cc6c3b981dba5037https://gitlab.isc.org/isc-projects/bind9/-/issues/2888log error when using common address:port for listen-on and transfer-source/no...2022-01-19T11:20:48ZChris Caputolog error when using common address:port for listen-on and transfer-source/notify-source### Summary
With a linux kernel (epoll-capable up to linux-5.14-rc4 and likely beyond), previously one could configure:
```
listen-on { 192.0.2.9; };
transfer-source 192.0.2.9 port 53;
notify-source 192.0.2.9 port 53;
```
or
```
list...### Summary
With a linux kernel (epoll-capable up to linux-5.14-rc4 and likely beyond), previously one could configure:
```
listen-on { 192.0.2.9; };
transfer-source 192.0.2.9 port 53;
notify-source 192.0.2.9 port 53;
```
or
```
listen-on-v6 { 2001:db8::9; };
transfer-source-v6 2001:db8::9 port 53;
notify-source-v6 2001:db8::9 port 53;
```
and things would work fine.
Since https://gitlab.isc.org/isc-projects/bind9/-/commit/53f0b6c34d3fe01c885d8020d155061d55c19477 the above no longer works on linux. The issue has to do with multiple UDP sockets on the same port being opened, one serviced by epoll and then other not. As a result, incoming packets get wedged, ala:
```
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
[...]
udp 768 0 192.0.2.9:53 0.0.0.0:*
udp 0 0 192.0.2.9:53 0.0.0.0:*
```
This results in a portion of the queries being dropped unanswered.
I believe the bug is that with the use of netmgr/libuv, bind should no longer allow transfer-source and notify-source, or their IPv6 counterparts, to use the same address:port being listened on, or alternatively, things need to be fixed in order to allow coexistence.
### BIND version used
```
BIND 9.16.19 (Stable Release) <id:df0e751>
running on Linux x86_64 5.14.0-rc4 #60 SMP Fri Aug 27 01:06:50 UTC 2021
built by make with '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--docdir=/usr/share/doc/bind-9.16.19' '--htmldir=/usr/share/doc/bind-9.16.19/html' '--with-sysroot=/' '--libdir=/usr/lib64' 'AR=/usr/bin/x86_64-pc-linux-gnu-ar' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--without-readline' '--with-openssl=/usr' '--without-cmocka' '--enable-linux-caps' '--disable-dnsrps' '--disable-dnstap' '--disable-fixed-rrset' '--without-dlz-bdb' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--without-gssapi' '--without-json-c' '--without-dlz-ldap' '--without-dlz-mysql' '--without-dlz-odbc' '--without-dlz-postgres' '--without-lmdb' '--without-libxml2' '--with-zlib' '--without-python' '--enable-symtable' '--without-maxminddb' '--disable-geoip' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=native -O2 -pipe -ggdb' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'
compiled by GCC 10.3.0
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.41.1
linked to libuv version: 1.42.1-dev
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
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: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Configure:
```
listen-on { 192.0.2.9; };
transfer-source 192.0.2.9 port 53;
notify-source 192.0.2.9 port 53;
```
and attempt to run multiple queries against 192.0.2.9:53.
### What is the current *bug* behavior?
Unanswered DNS queries.
### What is the expected *correct* behavior?
Answered DNS queries or don't allow the above configuration.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2887respdiff is really slow on Bullseyes2021-11-02T15:59:53ZMichal Nowakrespdiff is really slow on Bullseyes[respdiff on Bullseyes](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1945178) takes 91 minutes and identifies 1.5 % query disagreements (80 % of that are timeouts). On Buster the [test](https://gitlab.isc.org/isc-projects/bind9/-/job...[respdiff on Bullseyes](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1945178) takes 91 minutes and identifies 1.5 % query disagreements (80 % of that are timeouts). On Buster the [test](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1946373) takes 27 minutes and identifies just 0.34 % query disagreements (8 % of that are timeouts).
Locally I am able to identify something similar but instead of timeouts I get 15 % of SERVFAILs from the 100,000 query set. I can make it more stable by setting `jobs = 2` instead of the default `jobs = 16` in `respdiff.cfg`. When running `dig` manually for known working query, I get SERVFAIL in 99 % of attempts as if the query was over some limit. I don't know what might be the difference between Buster and Bullseye (I checked `./configure` and `sysctl` and there are not significant differences). Though, it might an unrelated problem on my system.
This needs to be fixed for the base image being switched to Bullseye.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2886cppcheck fails on Bullseye2022-01-11T14:25:35ZMichal Nowakcppcheck fails on BullseyeJob [#1947020](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947020) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with the following warnings:
| lib/dns/ttl.c || | | | ...Job [#1947020](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947020) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with the following warnings:
| lib/dns/ttl.c || | | |
|---------------|-------------|-----|---------|---------------------------------------------------------------------------------------|
| 76 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 76. |
| 77 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 77. |
| 78 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 78. |
| 80 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 80. |
| 82 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 82. |
The `cppcheck` tool should be the same, something else changed in Bullseye.
This needs to be fixed for the base image being switched to Bullseye.
[Cppcheck_-_HTML_report_-_BIND_9__24813ab4__Cppcheck_Report.html](/uploads/d2e514933310f66ffeb02f9df9c2367b/Cppcheck_-_HTML_report_-_BIND_9__24813ab4__Cppcheck_Report.html)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2885Pylint "no-member" check fails on Bullseye2022-01-11T15:15:06ZMichal NowakPylint "no-member" check fails on BullseyeJob [#1947023](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947023) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with:
```
$ PYTHONPATH="$PYTHONPATH:$CI_PROJECT_DIR/bin/python"
$ pylint --rcfile $CI_PROJ...Job [#1947023](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947023) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with:
```
$ PYTHONPATH="$PYTHONPATH:$CI_PROJECT_DIR/bin/python"
$ pylint --rcfile $CI_PROJECT_DIR/.pylintrc $(git ls-files '*.py' | grep -vE '(ans\.py|dangerfile\.py)')
************* Module tests-checkds
bin/tests/system/checkds/tests-checkds.py:98:27: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/checkds/tests-checkds.py:101:50: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/checkds/tests-checkds.py:102:24: E1101: Module 'dns.rdatatype' has no 'DS' member (no-member)
bin/tests/system/checkds/tests-checkds.py:102:42: E1101: Module 'dns.rdatatype' has no 'NONE' member (no-member)
bin/tests/system/checkds/tests-checkds.py:143:33: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/checkds/tests-checkds.py:161:29: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
************* Module helper
bin/tests/system/statschannel/helper.py:98:26: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/statschannel/helper.py:106:26: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
************* Module tests-tcp
bin/tests/system/timeouts/tests-tcp.py:149:33: E1101: Module 'dns.message' has no 'ANSWER' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:150:33: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:150:52: E1101: Module 'dns.rdatatype' has no 'SOA' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:157:37: E1101: Module 'dns.message' has no 'ANSWER' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:158:37: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:158:56: E1101: Module 'dns.rdatatype' has no 'SOA' member (no-member)
-----------------------------------
Your code has been rated at 9.40/10
```
This needs to be fixed for the base image being switched to Bullseye.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2884Sometimes dig aborts on an AXFR query over TLS2021-11-04T13:43:09ZCesar KuroiwaSometimes dig aborts on an AXFR query over TLS<!--
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
Sometimes (not always) `dig` crashes with a core dump on a AXFR query over TLS
### BIND version used
DiG 9.17.17
### Steps to reproduce
Using dig to make successive AXFR requests over TLS, using a HMAC-SHA256 TSIG key
```
% dig @<server> -p 853 +tls bom axfr -y hmac-sha256:<tsig-key>:<secret>
```
### Relevant logs and/or screenshots
```
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
bom. 21600 IN DNSKEY 256 3 13 fBrEkmLy0X3ANfdXKdkj8fNPAUbwhpC5VvlBaQMzi+8h63iePUcM/dcT aJVVpWgas+HgkKlA3wCTAAFuJJ1uCA==
bom. 21600 IN DNSKEY 257 3 13 jBWA/GVSitmW8erjfZc6plKFXq2j8OOR5FR+3qgAz8nM8yW4+8egKfNO fV1ynbGKAzOzyiC3xuGm7x3RfPXmNg==
bom. 172800 IN NSEC3PARAM 1 0 10 D5193D4EFD6031FF646F
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 xcJBeqP007hmCBgx9MXXGbN1m6MieWJJUJzQOGhPhrE= 9519 NOERROR 0
nic.bom. 3600 IN NS ns.dns.br.
nic.bom. 3600 IN NS ns2.dns.br.
nic.bom. 3600 IN DS 40126 13 2 2B666C945F28C2ADA55279798382CC1BCA19DED7A32E3E0B1680FE84 4B1C154F
nic.bom. 3600 IN RRSIG DS 13 2 3600 20210903143501 20210819133501 16861 bom. az4R7y6/rjAQia9lTlcjcISj182zosM35mIlSlub108MrMXVbOZUsrzZ 3rHNKGch4j23G0ljP8ELgo5+L3AGNw==
bom. 172800 IN NS a.dns.br.
bom. 172800 IN NS b.dns.br.
bom. 172800 IN NS c.dns.br.
bom. 172800 IN NS d.dns.br.
bom. 172800 IN NS e.dns.br.
bom. 172800 IN NS f.dns.br.
bom. 21600 IN RRSIG DNSKEY 13 1 21600 20210915000000 20210611000000 14600 bom. a8Tag5dWGGgKNF0nbZfIO+ODDnaDstPjrE7BG7rRojU+KUw8uewTN/Yd 5PrgjC4wUBVbaDTNkG0evhO9dGmVXA==
bom. 172800 IN RRSIG SOA 13 1 172800 20210910221001 20210826211001 16861 bom. 23yXB1pgr7N+SdI1MtDKELA7Vrjt7/rWT1wx5AXPbNXNBFiEPBRE30Fo vJE4fBT0l5ZLbffEfJKm65XmBGBtjw==
bom. 172800 IN RRSIG NSEC3PARAM 13 1 172800 20210910221001 20210826211001 16861 bom. LzCugkc0fnBsssqz7zkj/gasbnjKy5zkSWRrfgFI2c5HW6KpQ2ImXfSG xFtJgaVWl5+QjDWNzaMVublFHe/A5A==
bom. 172800 IN RRSIG NS 13 1 172800 20210910221001 20210826211001 16861 bom. kMcSAe8somkybKerjoCV8WG0WfnUXLAO88b0sutOrAVFJR1X4655hw9R CQZKqsC3RpqnDPcbN2QSVT91wcU5jg==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN RRSIG NSEC3 13 2 900 20210903143501 20210819133501 16861 bom. zSfR9WRP+xHbBflvdOpTQDleukg+sTaTB62FvPNC15pxroPkRdTlIOLW jg54yxwye+bBcnHH+HWRtzF0QbfxOA==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F SD3KLP44SLP2IB3IRND61I31V6ROG2PE NS DS RRSIG
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN RRSIG NSEC3 13 2 900 20210910221001 20210826211001 16861 bom. NL2n5iahzZF59faktxT+x22UA8548NwIoDZc/WHub8wdQ02F134kq0Uo 8NbEzvKJdB0/FQNWf222+l5HWYJzOw==
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F 6MOM8BVSN8OG38K5J20NUBCLK3L258VI NS SOA RRSIG DNSKEY NSEC3PARAM
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 Y1j1OjfZqqmzPHeTvNvVrEIfiK4UbMLiWntNw/Vo5A4= 9519 NOERROR 0
;; Query time: 1 msec
;; WHEN: Thu Aug 26 19:11:27 -03 2021
;; XFR size: 23 records (messages 2, bytes 1777)
netmgr/netmgr.c:1703: REQUIRE(((__builtin_expect(!!((handle) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)) && __c11_atomic_load(&(handle)->references, memory_order_seq_cst) > 0)) failed, back trace
0x8002ba7a0 <isc_assertion_setcallback+0x50> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ba74a <isc_assertion_failed+0xa> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002aae6b <isc__nm_get_read_req+0x11b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5295 <isc__nm_tlsdns_processbuffer+0x95> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ab338 <isc__nm_process_sock_buffer+0x48> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b4926 <isc__nm_async_tlsdnsshutdown+0x366> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5565 <isc__nm_tlsdns_read_cb+0xb5> at /home/cesar/named/lib/libisc-9.17.17.so
0x8007c5590 <uv__stream_init+0x500> at /usr/local/lib/libuv.so.1
0x8007cc12b <uv__io_poll+0x82b> at /usr/local/lib/libuv.so.1
0x8007bb551 <uv_run+0x1b1> at /usr/local/lib/libuv.so.1
0x8002a4deb <isc__netmgr_create+0x71b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002e9914 <isc__trampoline_run+0x54> at /home/cesar/named/lib/libisc-9.17.17.so
Abort (core dumped)
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2883Let name of inline-signed zone file be configured2023-11-02T16:26:08ZMagnus HolmgrenLet name of inline-signed zone file be configured### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://g...### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://gitlab.isc.org/isc-projects/bind9/-/blob/2872d6a12efe578360a641c1ba90884ea9a7dd01/bin/named/zoneconf.c#L1116
It's not a huge deal, but I'd like to separate manually edited configuration from software managed data per the FHS, and thus keep non-dynamic master zones in /etc (which is also what the Debian package recommends) but the inline-signed zone data in /var/lib. (It appears that the Debian BIND maintainers didn't consider inline signing, because the included AppArmor profile prevents `named` from writing to /etc/bind.)
### Request
Define a new option `signed-file` or similar. Could something like [signed-file.patch](/uploads/ec5f66b98f5c986d867ea76ccc4a89d9/signed-file.patch) work?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2882Remove the "map" zone file format from 9.17+2022-01-19T11:20:48ZPetr Špačekpspacek@isc.orgRemove the "map" zone file format from 9.17+Configuration option `masterfile-format map` is complex and thus fragile (e.g. #2872, #2878).
Currently benchmarks do not show significant benefit when compared to `masterfile-format raw`.
Tests on real `net.` zone
--------------------...Configuration option `masterfile-format map` is complex and thus fragile (e.g. #2872, #2878).
Currently benchmarks do not show significant benefit when compared to `masterfile-format raw`.
Tests on real `net.` zone
-------------------------
Zone serial 1629331223, obtained from czds.icann.org.
| format | load time [s] | % of text time |
|--------|---------------|----------------|
| map | 17,4 | 25 % |
| raw | 28,4 | 40 % |
| text | 70,8 | 100 % |
File size comparison:
| format | size | N- of text size |
|--------|------------|-----------------|
| map | 4880695376 | 5,1 |
| raw | 1509720581 | 1,6 |
| text | 960525608 | 1,0 |
Tests on an artificial flat zone
---------------------------------
Zone generated by:
```bash
perl bin/tests/startperf/mkzonefile.pl test 34674952 > /tmp/text
```
| format | load time [s] | % of text time |
|--------|---------------|----------------|
| map | 36 | 25 % |
| raw | 48 | 34 % |
| text | 144 | 100 % |
File size comparison:
| format | size | N- of text size |
|--------|------------|-----------------|
| map | 9430522392 | 9,8 |
| raw | 1386860577 | 1,4 |
| text | 960521110 | 1,0 |
Summary
-------
Speedup provided by the `map` format does not seem significant enough to warrant the complexity of map format, especially when we take into account that the difference measured in terms of "real time" is in order of 10s of seconds.
Maybe we should mark it as deprecated in ~v9.17 & ~v9.18 and remove remove it in v9.19 timeframe.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2881bind 9 can not balance load with mode order cyclic2021-08-26T07:07:39Zqimangebind 9 can not balance load with mode order cyclicI configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
...I configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
@ IN NS master.test.com.
@ IN NS slave.test.com.
slave IN A 100.100.5.21
master IN A 100.100.5.22
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.10.245
www IN A 101.101.10.246
www IN A 101.101.10.247
www IN A 101.101.10.248
www IN A 101.101.10.249
```
the Subnet Mask of ip in resource records above is all 16 bits,when i ping www.test.com from client for 10 times,the ip it allocates is 101.101.5.21 for 6 times and 101.101.5.22~25,it can not allocate the ip of 101.101.10.x,is it any limit for the ip in resource records?
and then I modified the resource records in zone file as follow:
```
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.5.26
www IN A 101.101.5.27
www IN A 101.101.5.28
www IN A 101.101.5.29
www IN A 101.101.5.30
```
and I also ping www.test.com from client for 10 times,when the clients' operarte system is centos 8,it can Poll all the ip(101.101.5.21~30) correctly,but when the clients' operarte system is centos 7,the ip it allocates is 101.101.5.21 for 5 times and 101.101.5.22~26,why does it happen?https://gitlab.isc.org/isc-projects/bind9/-/issues/2880timing issues with rndc system test2021-08-31T13:34:11ZMark Andrewstiming issues with rndc system testJob [#1940981](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1940981) failed for aae53e215678690df2fc857f05c9d409b6276104:
The test does not wait for the post freeze zone writes to complete.
```
I:rndc:checking update (68)
I:rndc:rn...Job [#1940981](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1940981) failed for aae53e215678690df2fc857f05c9d409b6276104:
The test does not wait for the post freeze zone writes to complete.
```
I:rndc:checking update (68)
I:rndc:rndc freeze
I:rndc:edit zone files
I:rndc:rndc thaw
I:rndc:rndc reload
I:rndc:ns7 server reload successful
I:rndc:checking zone file edits are loaded (69)
I:rndc:failed
I:rndc:exit status: 1
```
```
grep '\(test/IN\|'"'"'\(reload\|freeze\|thaw\)'"'"'\|all zones loaded\)' ns7/named.run
...
25-Aug-2021 00:27:36.398 received control channel command 'freeze'
25-Aug-2021 00:27:36.398 zone_dump: zone test/IN/internal: enter
25-Aug-2021 00:27:36.398 freezing zone 'test/IN' internal: success
25-Aug-2021 00:27:36.398 zone_gotwritehandle: zone test/IN/internal: enter
25-Aug-2021 00:27:36.430 received control channel command 'thaw'
25-Aug-2021 00:27:36.434 zone test/IN/internal: starting load
25-Aug-2021 00:27:36.434 zone_startload: zone test/IN/internal: enter
25-Aug-2021 00:27:36.434 thawing zone 'test/IN' internal: success
25-Aug-2021 00:27:36.442 dump_done: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone_journal_compact: zone test/IN/internal: target journal size 336
25-Aug-2021 00:27:36.442 zone test/IN/internal: dns_journal_compact: success
25-Aug-2021 00:27:36.442 zone_loaddone: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone test/IN/internal: number of nodes in database: 4
25-Aug-2021 00:27:36.442 zone test/IN/internal: loaded; checking validity
25-Aug-2021 00:27:36.442 dns_zone_verifydb: zone test/IN/internal: enter
25-Aug-2021 00:27:36.442 zone test/IN/internal: ixfr-from-differences: unchanged
25-Aug-2021 00:27:36.442 zone_postload: zone test/IN/internal: done
25-Aug-2021 00:27:36.466 received control channel command 'reload'
...
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2879Add --disable-doh to a CI build?2023-11-02T16:26:08ZMark AndrewsAdd --disable-doh to a CI build?The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet ano...The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet another system with --disable-doh to CI?"
- [ ] Also should we have a CI build that does not have libnghttp2 installed.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2878zonefiles in map format larger than 2 GiB cannot be read but can be written (...2021-09-15T21:06:34ZPetr Špačekpspacek@isc.orgzonefiles in map format larger than 2 GiB cannot be read but can be written (data loss)### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_1...### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_16 713ded2cc37037a5c63b61c00cc41b7de0328996
- v9_11 0480e212bf4b70f52e5a24e8ef3849a94c627a84
### Steps to reproduce
1. Generate a zone file which results in map file larger than 2 GiB:
```bash
perl bin/tests/startperf/mkzonefile.pl test 8000000 > /tmp/text
```
2. Convert text zone file into `map` format:
```bash
named-compilezone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f text -F map -o /tmp/map test /tmp/text
```
3. Attempt to read the zone:
```bash
named-checkzone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f map test /tmp/map
```
### What is the current *bug* behavior?
```
zone test/IN: loading from master file /tmp/map failed: invalid file
zone test/IN: not loaded due to errors.
```
### What is the expected *correct* behavior?
Zone can be read and the data are intact, obviously.
### Possible fixes
The main question is how much we want to invest into the `map` format. If we decide to remove RBTDB map format in favor of a different data structure, we might consider a low-cost option: Limit file size to make it "safe" and remove the format a bit later.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)