ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-08-31T13:08:13Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2857inline-signing and auto-dnssec migration to dnssec-policy fails for zone with...2021-08-31T13:08:13ZDaniel Stirnimanninline-signing and auto-dnssec migration to dnssec-policy fails for zone with CSK### Summary
The zone `dyn-acme.switch.ch` was configured with "inline-signing" and "auto-dnssec" with a CSK. Changing to a "dnssec-policy" with the same algorithm and again a CSK failed to recognize the existing CSK. The existing CSK (K...### Summary
The zone `dyn-acme.switch.ch` was configured with "inline-signing" and "auto-dnssec" with a CSK. Changing to a "dnssec-policy" with the same algorithm and again a CSK failed to recognize the existing CSK. The existing CSK (KSK) was ignored and hidden and a new CSK was created after a reload of named. The published zone contained only the new CSK leading to DNSSEC validation errors.
### BIND version used
BIND 9.16.19
### Steps to reproduce
Old zone configuration:
```
zone "dyn-acme.switch.ch" {
type master;
file "dynamic/dyn-acme.switch.ch";
update-check-ksk no; // CSK
key-directory "/etc/bind/inline-signing-keys";
auto-dnssec maintain;
inline-signing yes;
};
```
New zone configuration:
```
zone "dyn-acme.switch.ch" {
type master;
file "dynamic/dyn-acme.switch.ch";
key-directory "/etc/bind/inline-signing-keys";
dnssec-policy "switch-default";
};
dnssec-policy "switch-default" {
keys { csk key-directory lifetime unlimited algorithm 13; };
};
```
After a reload of named the existing CSK got the following state file:
```
Kdyn-acme.switch.ch.+013+61215.state
; This is the state of key 61215, for dyn-acme.switch.ch.
Algorithm: 13
Length: 256
KSK: yes
ZSK: no
Generated: 20191211143721 (Wed Dec 11 15:37:21 2019)
Published: 20191211143721 (Wed Dec 11 15:37:21 2019)
Active: 20191211143721 (Wed Dec 11 15:37:21 2019)
Retired: 20210810090712 (Tue Aug 10 11:07:12 2021)
Removed: 20210811110712 (Wed Aug 11 13:07:12 2021)
DNSKEYChange: 20210810091212 (Tue Aug 10 11:12:12 2021)
KRRSIGChange: 20210810091212 (Tue Aug 10 11:12:12 2021)
DSChange: 20210810090712 (Tue Aug 10 11:07:12 2021)
DNSKEYState: hidden
KRRSIGState: hidden
DSState: hidden
GoalState: hidden
```
The zone was immediately resigned with a new CSK, this new CSK state file looked as follow:
```
Kdyn-acme.switch.ch.+013+25592.state
; This is the state of key 25592, for dyn-acme.switch.ch.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210810090712 (Tue Aug 10 11:07:12 2021)
Published: 20210810090712 (Tue Aug 10 11:07:12 2021)
Active: 20210810090712 (Tue Aug 10 11:07:12 2021)
PublishCDS: 20210811101212 (Wed Aug 11 12:12:12 2021)
DNSKEYChange: 20210810090712 (Tue Aug 10 11:07:12 2021)
ZRRSIGChange: 20210810090712 (Tue Aug 10 11:07:12 2021)
KRRSIGChange: 20210810090712 (Tue Aug 10 11:07:12 2021)
DSChange: 20210810090712 (Tue Aug 10 11:07:12 2021)
DNSKEYState: rumoured
ZRRSIGState: rumoured
KRRSIGState: rumoured
DSState: hidden
GoalState: omnipresent
```
### What is the current *bug* behavior?
The previous CSK was not recognized as a CSK and ignored.
### What is the expected *correct* behavior?
Given that I removed the zone configuration which hints that the zone was using a CSK I think there is no way named can know that the old KSK was being used as a CSK. Maybe document a migration scenario in https://kb.isc.org/docs/dnssec-key-and-signing-policy ?
### Relevant logs and/or screenshots
named log during reload
```
10-Aug-2021 11:07:11.843 general: info: received control channel command 'reload'
10-Aug-2021 11:07:11.843 general: info: loading configuration from '/etc/bind/named.conf'
10-Aug-2021 11:07:11.898 general: info: unable to open '/etc/bind.keys'; using built-in keys instead
10-Aug-2021 11:07:11.899 general: info: using default UDP/IPv4 port range: [32768, 60999]
10-Aug-2021 11:07:11.899 general: info: using default UDP/IPv6 port range: [32768, 60999]
10-Aug-2021 11:07:11.948 general: info: sizing zone task pool based on 129 zones
10-Aug-2021 11:07:11.958 general: info: zone dyn-acme.switch.ch/IN (signed): (primary) removed
10-Aug-2021 11:07:11.959 general: info: reloading configuration succeeded
10-Aug-2021 11:07:12.055 general: info: reloading zones succeeded
10-Aug-2021 11:07:12.075 notify: info: zone dyn-acme.switch.ch/IN: sending notifies (serial 1610010728)
10-Aug-2021 11:07:12.075 dnssec: info: zone dyn-acme.switch.ch/IN: reconfiguring zone keys
10-Aug-2021 11:07:12.077 dnssec: error: zone dyn-acme.switch.ch/IN: zone_rekey:dns_zone_getdnsseckeys failed: not found
10-Aug-2021 11:07:12.077 dnssec: info: keymgr: retire DNSKEY dyn-acme.switch.ch/ECDSAP256SHA256/61215 (KSK)
10-Aug-2021 11:07:12.077 dnssec: info: keymgr: DNSKEY dyn-acme.switch.ch/ECDSAP256SHA256/25592 (CSK) created for policy switch-default
10-Aug-2021 11:07:12.083 dnssec: info: Fetching dyn-acme.switch.ch/ECDSAP256SHA256/25592 (CSK) from key repository.
10-Aug-2021 11:07:12.084 dnssec: info: DNSKEY dyn-acme.switch.ch/ECDSAP256SHA256/25592 (CSK) is now published
10-Aug-2021 11:07:12.084 dnssec: info: DNSKEY dyn-acme.switch.ch/ECDSAP256SHA256/25592 (CSK) is now active
10-Aug-2021 11:07:12.087 dnssec: info: zone dyn-acme.switch.ch/IN: next key event: 10-Aug-2021 11:12:12.075
10-Aug-2021 11:07:12.092 general: notice: all zones loaded
10-Aug-2021 11:07:12.092 general: notice: running
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2856[CVE-2021-25218] named crashes when trying to send a UDP packet exceeding MTU...2022-04-26T20:51:36ZMichał Kępień[CVE-2021-25218] named crashes when trying to send a UDP packet exceeding MTU with RRL enabled### CVE-specific actions
- [x] [Assign a CVE identifier](https://gitlab.isc.org/isc-projects/bind9/-/issues/2839#note_227833)
- [x] [Determine CVSS score](#note_229297)
- [x] [Determine the range of BIND versions affected (includi...### CVE-specific actions
- [x] [Assign a CVE identifier](https://gitlab.isc.org/isc-projects/bind9/-/issues/2839#note_227833)
- [x] [Determine CVSS score](#note_229297)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_229299)
- [x] [Determine whether workarounds for the problem exists](#note_229301)
- [x] [Create a draft of the security advisory and put the information above in there](https://gitlab.isc.org/isc-private/bind9/-/wikis/CVE-2021-25218-Advisory-Draft)
- [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)](isc-private/bind9!315)
- [explanation of code flow which triggers the problem (a system test is *not* good enough)](#note_229306)
- [x] [Prepare a private merge request containing the following items in separate commits:](isc-private/bind9!313)
- 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#46)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5318)
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
---
Original report: #2839August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Brian ConryBrian Conryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2855Load time is not updated for unchanged inline-signed zones2021-08-10T08:13:01ZMichał KępieńLoad time is not updated for unchanged inline-signed zonesWhen a zone file of an inline-signed zone has a modification time newer
than the last `rndc reload` time, but its contents have not actually
changed since the last `rndc reload`, `named` queues a redundant zone
reload: `rndc reload <zone...When a zone file of an inline-signed zone has a modification time newer
than the last `rndc reload` time, but its contents have not actually
changed since the last `rndc reload`, `named` queues a redundant zone
reload: `rndc reload <zonename>` logs `zone reload queued` and `named`
produces (harmless, yet confusing) log messages like this one:
```
zone example/IN (unsigned): ixfr-from-differences: unchanged
```
The problem here is that the code branch logging `ixfr-from-differences:
unchanged` does not update `zone->loadtime`, which leads `named` to
believe that the zone has been changed since load time upon every
subsequent `rndc reload` (until the situation is rectified e.g. by
actually updating the contents of the unsigned zone, which causes
`zone_postload()` to be called in order to i.a. update
`zone->loadtime`).
See also #2542.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/2852BIND doesn't create server TCP sockets for new interfaces detected during nam...2021-10-04T09:19:36ZCathy AlmondBIND doesn't create server TCP sockets for new interfaces detected during named start-up processingMore detail noted in [Support ticket RT #18855](https://support.isc.org/Ticket/Display.html?id=18855)
The scenario is a recursive server that has a scripted start-up process. named is started first, without the server anycast IPs activ...More detail noted in [Support ticket RT #18855](https://support.isc.org/Ticket/Display.html?id=18855)
The scenario is a recursive server that has a scripted start-up process. named is started first, without the server anycast IPs active (this is to prevent client queries from reaching the server before it is ready to handle queries). The next step in the script is to add the anycast address to the lo interface.
It was observed (on both 9.11.33-S1 and 9.16.18) that named creates both UDP and TCP sockets for interfaces that are present when named is first starting up. These are logged as:
listening on IPv4 interface ... (interface IP address and port)
The interfaces that are missing the TCP server socket are logged as being added after named reports that the control channel socket has been created.
command channel listening on 127.0.0.1#953
And these newly added interfaces are logged thus:
additionally listening on IPv4 interface (interface, IP address and port)
This step takes place before named has finished its startup processing and has logged:
running
If a 5s delay is added to the start-up script, then the new interfaces, when added, have both TCP and UDP sockets created as expected.
Analysis of logs produced by named 9.11.33-S1 (options -g -d 255) show that named does not even attempt to create the second socket for the additional interfaces added at this point in its start up processing, whereas the ones that were already present and created earlier have two calls to open and bind to a socket.
Here's a snippet from the debug logs of named starting up and opening the server sockets on the 127.0.0.1 interface: (already present and detected at startup)
```
05-Aug-2021 09:49:13.322 listening on IPv4 interface lo, 127.0.0.1#53
05-Aug-2021 09:49:13.322 clientmgr @0x7f35b14f4010: create
05-Aug-2021 09:49:13.322 sendmsg: Invalid argument
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca270: created
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca270 127.0.0.1#53: bound << *** HERE ***
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 512
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402f7b0
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f7b0: created task 0x7f35b14f28a8
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f7b0: created socket 0x7f35b15ca270
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca4d0: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 513
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402f1e0
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f1e0: created task 0x7f35b14f2970
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f1e0: created socket 0x7f35b15ca4d0
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca730: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 514
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402ec10
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402ec10: created task 0x7f35b14f2a38
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402ec10: created socket 0x7f35b15ca730
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca990: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 515
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402e640
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e640: created task 0x7f35b14f2b00
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e640: created socket 0x7f35b15ca990
05-Aug-2021 09:49:13.330 socket 0x7f35b15cabf0: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 516
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402e070
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e070: created task 0x7f35b14f2bc8
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e070: created socket 0x7f35b15cabf0
05-Aug-2021 09:49:13.330 socket 0x7f35b14f8010: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 517
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402daa0
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402daa0: created task 0x7f35b14f2c90
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402daa0: created socket 0x7f35b14f8010
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: createclients
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.330 client @0x7f35a403a9a0 (no-peer): create
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.330 client @0x7f35a40408a0 (no-peer): create
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.330 client @0x7f35a40a2230 (no-peer): create
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40b0ae0 (no-peer): create
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40bf390 (no-peer): create
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40cdc40 (no-peer): create
05-Aug-2021 09:49:13.331 socket 0x7f35b14f8270: created
05-Aug-2021 09:49:13.331 socket 0x7f35b14f8270 127.0.0.1#53: bound << *** AND HERE ***
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: createclients
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40dc660 (no-peer): create
```
(named is started with -U 6)
The same logging for the additional interfaces is completely missing the second 'socket ... created' and 'socket ... bound' pair from the logs.
There are no obvious errors being logged - named simply doesn't create the second socket (that I assume is the TCP listener that we didn't get).
The same symptoms are present both in 9.11-S and 9.16, but it's not possible to obtain useful debug logging from 9.16 - likely because the libuv-based server socket code no longer has the logging that was available from the named-based server socket code.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/2850The list of fetches at the end of 'rndc recursing' output is very poorly expl...2021-12-01T09:08:04ZCathy AlmondThe list of fetches at the end of 'rndc recursing' output is very poorly explained in the ARM - what does 'allowed' mean?In the ARM, the output from rndc option recursing is described thus:
This command dumps the list of queries named is currently recursing on, and the list of domains to which
iterative queries are currently being sent. The second list in...In the ARM, the output from rndc option recursing is described thus:
This command dumps the list of queries named is currently recursing on, and the list of domains to which
iterative queries are currently being sent. The second list includes the number of fetches currently active for the
given domain, and how many have been passed or dropped because of the fetches-per-zone option.
This is an example of what is being output in the second list:
name.example.com.: 1 active (0 spilled, 1 allowed)
The counters here need a better explanation than the one given in the ARM. Specifically, the word 'allowed' is ambiguous. What it actually means is: "for the lifetime of this entry, 1 fetch has not been blocked by any per-domain fetch limits". What it does **not** mean (but could easily be misinterpreted thus) is 'only 1 concurrent fetch is permitted'. This is an alarming thing to see on a server that has fetch-limits entirely disabled.
The other two values are more easily understood - 'active' is the number of fetches currently in progress (that is, queries from a resolver to other servers); 'spilled' is a count of those that have been dropped (or SERVFAILed) because of fetches-per-zone.
Please could the author of this dump list provide some more information about the values, and what they represent (in relation to fetches and the structures around those for 'counting' for fetches-per-zone, which happens anyway, even if fetches-per-zone is disabled). An update to the ARM would be ideal, but also in the interim, we could add a small FAQ to kb.isc.org as well as update the main KB articles on fetch-limits.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/2845Automatic zone text file inlining replaces $INCLUDE file references with stal...2021-08-19T09:59:11ZAndrej PodzimekAutomatic zone text file inlining replaces $INCLUDE file references with stale data### Summary
My zone files use the `$INCLUDE` directive a lot. For example, TLSA checksums (generated by a toolchain unrelated to `named`) are propagated that way.
Unfortunately, `named` won’t reflect changes to the `$INCLUDE`’d files, ...### Summary
My zone files use the `$INCLUDE` directive a lot. For example, TLSA checksums (generated by a toolchain unrelated to `named`) are propagated that way.
Unfortunately, `named` won’t reflect changes to the `$INCLUDE`’d files, unless a hard reset with `.jnl` file deletion is carried out.
### BIND version used
```
BIND 9.17.16 (Development Release) <id:b33f621>
running on Linux x86_64 5.12.15-arch1-1-zen2 #1 SMP PREEMPT Sun, 11 Jul 2021 10:50:03 +0000
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--with-python=/usr/bin/python' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' '--with-libtool' 'CFLAGS=-march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
compiled by GCC 11.1.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.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.44.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.6.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
0. `rndc freeze`\
…edit `$INCLUDE`’d files…\
…increase all zones’ serials…\
`rndc thaw`
0. (0), and, on top of that:\
`rndc reload`
0. (1), and, on top of that:\
`systemctl restart named`
### What is the current *bug* behavior?
Changes to `$INCLUDE`’d files have **no effect**, the server just doesn’t know about the new data — even after a restart.
### What is the expected *correct* behavior?
All zones affected by changed `$INCLUDE`’d files should reflect the new state already after a simple `freeze` → edit → `thaw`, not to mention a `reload` or a `systemctl restart` of the whole server.
The only way I could make the zone update happen was:
```
systemctl stop named
rm /var/named/*.jnl # uh oh!
systemctl start named
```
After this^^^ the zones did get updated, but … well, I would expect `named` to be able to stay “online” during such an update, with just a simple `freeze` and `thaw`, or, in the worst case, a `reload`.
### Relevant configuration files
As mentioned in #2844, there are lots of them. I’ll be more than happy to post some relevant snippets upon request. (Not sure which one to pick.)
### Relevant logs and/or screenshots
Something surprising are the following messages for all zones:
```
Aug 02 10:30:46 named[3960]: zone tmpwireless4.domain.censored/IN/loopback: zone serial (2021072733) unchanged. zone may fail to transfer to slaves.
```
Unlike the repetitive freeze errors described in #2844, this^^^ message appears only **once** per zone and despite the fact that the zone serial **did** change. Not sure if it could be (also) `in-view`-related or not.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2844`rndc freeze` command always fails, perhaps due to `in-view`2021-09-15T21:06:34ZAndrej Podzimek`rndc freeze` command always fails, perhaps due to `in-view`### Summary
`rndc freeze` always fails:
```
rndc: 'freeze' failed: already frozen
```
### BIND version used
```
BIND 9.17.16 (Development Release) <id:b33f621>
running on Linux x86_64 5.12.15-arch1-1-zen2 #1 SMP PREEMPT Sun, 11 Jul 2...### Summary
`rndc freeze` always fails:
```
rndc: 'freeze' failed: already frozen
```
### BIND version used
```
BIND 9.17.16 (Development Release) <id:b33f621>
running on Linux x86_64 5.12.15-arch1-1-zen2 #1 SMP PREEMPT Sun, 11 Jul 2021 10:50:03 +0000
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--with-python=/usr/bin/python' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' '--with-libtool' 'CFLAGS=-march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
compiled by GCC 11.1.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.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.44.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.6.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
Set up a server with a few zones and views. (In particular, the `in-view` feature is used a lot. Could it be causing wrong zone freeze retries?) Then call `rndc freeze`.
### What is the current *bug* behavior?
`rndc freeze` always fails. (But then `thaw` always succeeds.)
### What is the expected *correct* behavior?
`rndc freeze` should succeed, definitely at least after a successful `rndc thaw`.
### Relevant configuration files
There are lots of them. Not sure which ones are relevant. Please feel free to ask for details.
The server has a number of views, `dnssec-policy`, zones shared among views with `in-view` as well as zones that differ between views (signed with `dnssec-policy` in only one view while other views reuse the same DNSSEC keys (but not the same zone file/data) via `auto-dnssec maintain; inline-signing yes;`).
### Relevant logs and/or screenshots
For `rndc freeze`, [the logs look like](/uploads/ffc2209077b1788a185702240779be0f/freeze.txt) repetitive attempts to freeze the same zones (all of which are defined in the `loopback` view mentioned in the log and reused in numerous views using `in-view`).
Thawing seems to work fine. Uneventful.
```
Aug 02 10:48:10 named[450242]: received control channel command 'thaw'
Aug 02 10:48:10 named[450242]: thawing all zones: success
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2842Clean up catalog journal2021-08-25T05:18:13ZMark AndrewsClean up catalog journalFrom bind-users
```
Hi
Using BIND-9.16.19: When removing a member zone from a catz (catalog zone), then the journal files are not removed on the slave:
Current situation before removing the zone "example.com" from catz:
$ ls -lahF
-r...From bind-users
```
Hi
Using BIND-9.16.19: When removing a member zone from a catz (catalog zone), then the journal files are not removed on the slave:
Current situation before removing the zone "example.com" from catz:
$ ls -lahF
-rw-r--r--. 1 named named 4.0K 28. Jul 15:21 __catz___default_catalog.123456.local_example.com.db
-rw-r--r--. 1 named named 1.2K 28. Jul 15:26 __catz___default_catalog.123456.local_example.com.db.jnl
After removing the zone on the master (catz), the slave removes the __catz___default_...-files for the corresponding zone, but not the journal-file:
28-Jul-2021 15:29:56.018 general: info: catz: updating catalog zone 'catalog.123456.local' with serial 2021072803
28-Jul-2021 15:29:56.018 xfer-in: info: zone catalog.123456.local/IN: transferred serial 2021072803: TSIG 'master-slave'
28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123456.local/IN' from 172.16.1.1#53: Transfer status: success
28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123546.local/IN' from 172.16.1.1#53: Transfer completed: 1 messages, 5 records, 343 bytes, 0.001 secs (343000 bytes/sec) (serial 2021072803)
28-Jul-2021 15:29:56.020 general: info: catz: deleting zone 'example.com' from catalog 'catalog.123456.local' - success
28-Jul-2021 15:29:56.021 general: warning: catz: catz_delzone_taskaction: zone 'example.com' deleted
$ ls -lahF
-rw-r--r--. 1 named named 1.2K 28. Jul 15:26 __catz___default_catalog.123456.local_example.com.db.jnl
Is this intentional or possibly a bug?
Many thanks.
Kind regards,
Tom
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2839bind 9.16.19 assertion failure2021-08-19T08:16:58ZAndrey Blokhintsevbind 9.16.19 assertion failure<!--
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
bind 9.16.19 assertion failure
### BIND version used
```
BIND 9.16.19 (Stable Release) <id:df0e751>
running on FreeBSD amd64 12.2-RELEASE-p7 FreeBSD 12.2-RELEASE-p7 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--enable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' '--enable-tcp-fastopen' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.2' 'build_alias=amd64-portbld-freebsd12.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -Wl,-rpath,/usr/local/lib -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
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.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
Bind was crashed after 2 days of runtine
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
```
25-Jul-2021 21:13:52.057 general: client.c:798: INSIST(rcode != ((dns_rcode_t)dns_rcode_noerror) && rcode != ((dns_rcode_t)dns_rcode_nxdomain)) failed, back trace
25-Jul-2021 21:13:52.057 general: #0 0x2d8a65 in ??
25-Jul-2021 21:13:52.057 general: #1 0x4c2f2a in ??
25-Jul-2021 21:13:52.057 general: #2 0x3135f3 in ??
25-Jul-2021 21:13:52.057 general: #3 0x317efd in ??
25-Jul-2021 21:13:52.057 general: #4 0x4de376 in ??
25-Jul-2021 21:13:52.057 general: #5 0x4dc3a1 in ??
25-Jul-2021 21:13:52.057 general: #6 0x800ae7d42 in ??
25-Jul-2021 21:13:52.057 general: #7 0x800ae92b2 in ??
25-Jul-2021 21:13:52.057 general: #8 0x800ada684 in ??
25-Jul-2021 21:13:52.057 general: #9 0x4d6fcb in ??
25-Jul-2021 21:13:52.057 general: #10 0x4f4b44 in ??
25-Jul-2021 21:13:52.057 general: exiting (due to assertion failure)
25-Jul-2021 21:13:52.057 general: client.c:798: INSIST(rcode != ((dns_rcode_t)dns_rcode_noerror) && rcode != ((dns_rcode_t)dns_rcode_nxdomain)) failed, back trace
25-Jul-2021 21:13:52.057 general: #0 0x2d8a65 in ??
25-Jul-2021 21:13:52.057 general: #1 0x4c2f2a in ??
25-Jul-2021 21:13:52.057 general: #2 0x3135f3 in ??
25-Jul-2021 21:13:52.057 general: #3 0x317efd in ??
25-Jul-2021 21:13:52.057 general: #4 0x4de376 in ??
25-Jul-2021 21:13:52.057 general: #5 0x4dc3a1 in ??
25-Jul-2021 21:13:52.057 general: #6 0x800ae7d42 in ??
25-Jul-2021 21:13:52.057 general: #7 0x800ae92b2 in ??
25-Jul-2021 21:13:52.057 general: #8 0x800ada684 in ??
25-Jul-2021 21:13:52.057 general: #9 0x4d6fcb in ??
25-Jul-2021 21:13:52.057 general: #10 0x4f4b44 in ??
25-Jul-2021 21:13:52.057 general: exiting (due to assertion failure)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)
See #2856August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Brian ConryBrian Conryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2838Update 9.16 branch release notes to clearly indicate that the branch has been...2021-08-09T07:55:43ZMichael McNallyUpdate 9.16 branch release notes to clearly indicate that the branch has been designated ESVIf this has not been done already, please update the release notes for the 9.16 branch to indicate that the branch (starting from 9.16.19) has been designated ESV.
Per customer request on [Support #18811](https://support.isc.org/Ticket/...If this has not been done already, please update the release notes for the 9.16 branch to indicate that the branch (starting from 9.16.19) has been designated ESV.
Per customer request on [Support #18811](https://support.isc.org/Ticket/Display.html?id=18811).August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2837BIND 9 doesn't run on Windows when then number of workers in 8 or 122021-09-15T21:06:34Zlegacy1BIND 9 doesn't run on Windows when then number of workers in 8 or 12So this is simple to test with bind 9.16.19 and a CPU with more then 7 cores/threads bind will not start older version like 9.16.15 or 9.17.12 works beyond 7 cores/threads.
Please fix thanksSo this is simple to test with bind 9.16.19 and a CPU with more then 7 cores/threads bind will not start older version like 9.16.15 or 9.17.12 works beyond 7 cores/threads.
Please fix thanksSeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2836Missing string "net" in parental-agents documentation2021-08-09T13:31:46ZMatthijs Mekkingmatthijs@isc.orgMissing string "net" in parental-agents documentationhttps://twitter.com/jpmens/status/1418464718956769281https://twitter.com/jpmens/status/1418464718956769281August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2833Documentation of notify-delay appears to be out of date2021-08-09T12:03:27Zpdw-mbDocumentation of notify-delay appears to be out of dateThe documentation for [notify-delay](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/arm/reference.rst#L3615) says:
> The overall rate at which NOTIFY messages are sent for all zones is controlled by ``serial-query-rate``.
Th...The documentation for [notify-delay](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/arm/reference.rst#L3615) says:
> The overall rate at which NOTIFY messages are sent for all zones is controlled by ``serial-query-rate``.
The documentation for `serial-query-rate` makes no mention of NOTIFY messages.
My understanding from https://kb.isc.org/docs/aa-01313 is that `serial-query-rate` used to control NOTIFY rates, but no longer does, so I assume that this is just an outdated reference, and it should now point to `notify-rate`
I'm also struggling to understand exactly what `notify-delay` does. The description says:
> This sets the delay, in seconds, between sending sets of NOTIFY messages for a zone. The default is 5 seconds.
Is this defining the maximum rate at which NOTIFY messages are sent for an individual zone? i.e. if a zone changes twice in 2s, the NOTIFY messages will be sent 5s apart?August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/2830statistics system tests needs to save named.stats files2021-08-03T00:55:06ZMark Andrewsstatistics system tests needs to save named.stats filesJob [#1878582](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1878582) failed for 5cccab83de1725f3b657b0951ae2c8142b29772f:
There where not enough forensics to diagnose the statistics test failure.Job [#1878582](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1878582) failed for 5cccab83de1725f3b657b0951ae2c8142b29772f:
There where not enough forensics to diagnose the statistics test failure.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2829Reduce the size of internal node tables2021-09-02T13:59:51ZOndřej SurýReduce the size of internal node tablesIn !3067 the `DEFAULT_NODE_LOCK_COUNT` was bumped from `7` to `53` that affects number of internal structures allocated (node locks, deadlists, rdatasets, heaps) supposedly to reduce contention in the rbtdb, but at the same time it would...In !3067 the `DEFAULT_NODE_LOCK_COUNT` was bumped from `7` to `53` that affects number of internal structures allocated (node locks, deadlists, rdatasets, heaps) supposedly to reduce contention in the rbtdb, but at the same time it would increase a per-zone memory consumption.
With better testing that we have available now, it was shown that the effect of increasing the count is negligible and it's not worth the memory increase that could be as much as double when many zones or many records are loaded into `named`.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2827resolving certain name fails with ICMP port unreachable2021-08-08T06:23:23ZRichard Laagerresolving certain name fails with ICMP port unreachable### Summary
bind9 fails to resolve www.aviatormastercard.com (or more specifically www.aviatormastercard.egslb.barclaycardus.com).
### BIND version used
This is reproducible with git master as of right now:
```
BIND 9.17.15 (Developm...### Summary
bind9 fails to resolve www.aviatormastercard.com (or more specifically www.aviatormastercard.egslb.barclaycardus.com).
### BIND version used
This is reproducible with git master as of right now:
```
BIND 9.17.15 (Development Release) <id:ddacc7e>
running on Linux x86_64 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021
built by make with default
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.34.2
linked to libuv version: 1.34.2
compiled with libnghttp2 version: 1.40.0
linked to libnghttp2 version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
It's also reproducible with 1:9.16.1-0ubuntu2.8 on Ubuntu 20.04.
However, it _works_ on 1:9.11.3+dfsg-1ubuntu1.15 on Ubuntu 18.04. It also works with that version of bind recompiled on Ubuntu 20.04. It also works on 1:9.11.5-P4-5.1ubuntu2.2 from Ubuntu 19.10 recompiled on Ubuntu 20.04.
Based on testing Ubuntu packages, it seems something changed between 9.11 and 9.16 to break this. I know that's a big range.
I did a `git bisect`. It reported:
```
dd7bb617be1ac4c09821f64a2d6e9bd6a54873d6 is the first bad commit
commit dd7bb617be1ac4c09821f64a2d6e9bd6a54873d6
Author: Witold Kręcicki <wpk@isc.org>
Date: Fri May 11 12:27:56 2018 +0200
- qname minimization:
- make qname-minimization option tristate {strict,relaxed,disabled}
- go straight for the record if we hit NXDOMAIN in relaxed mode
- go straight for the record after 3 labels without new delegation or 7 labels total
- use start of fetch (and not time of response) as 'now' time for querying cache for
zonecut when following delegation.
bin/named/config.c | 3 +-
bin/named/server.c | 18 ++-
bin/tests/system/qname-minimization/ans2/ans.py | 25 ++-
bin/tests/system/qname-minimization/ans3/ans.py | 175 ++++++++++++++++++++
bin/tests/system/qname-minimization/ans4/ans.py | 175 ++++++++++++++++++++
bin/tests/system/qname-minimization/clean.sh | 2 +-
.../system/qname-minimization/ns3/named.conf.in | 41 -----
.../system/qname-minimization/ns4/named.conf.in | 41 -----
.../system/qname-minimization/ns5/named.conf.in | 3 +-
.../system/qname-minimization/ns6/named.conf.in | 40 +++++
.../system/qname-minimization/ns7/named.conf.in | 40 +++++
bin/tests/system/qname-minimization/setup.sh | 4 +-
bin/tests/system/qname-minimization/tests.sh | 177 +++++++++++++++++----
lib/dns/adb.c | 8 +
lib/dns/include/dns/resolver.h | 4 +
lib/dns/resolver.c | 45 ++++--
lib/isccfg/namedconf.c | 13 +-
util/copyrights | 6 +-
18 files changed, 678 insertions(+), 142 deletions(-)
create mode 100755 bin/tests/system/qname-minimization/ans3/ans.py
create mode 100755 bin/tests/system/qname-minimization/ans4/ans.py
delete mode 100644 bin/tests/system/qname-minimization/ns3/named.conf.in
delete mode 100644 bin/tests/system/qname-minimization/ns4/named.conf.in
create mode 100644 bin/tests/system/qname-minimization/ns6/named.conf.in
create mode 100644 bin/tests/system/qname-minimization/ns7/named.conf.in
```
The bisect log was:
```
$ git bisect log
git bisect start
# bad: [d497c325e70400f082bf59f61430e3f20a708d0d] Update changes after QA review
git bisect bad d497c325e70400f082bf59f61430e3f20a708d0d
# good: [998753c7583eb7cea2a462630100cc183e0f30ee] Merge branch 'prep-release' into v9_11_5_patch
git bisect good 998753c7583eb7cea2a462630100cc183e0f30ee
# bad: [6491691ac4bec0dc59e3eeba2797d65527f3bcd6] Merge branch 'prep-release' into security-v9_14
git bisect bad 6491691ac4bec0dc59e3eeba2797d65527f3bcd6
# good: [28e45cd00e2e1e621a2e97ba1ee6bdc6a4102e16] Merge branch 'prep-release' into v9_12_4_patch
git bisect good 28e45cd00e2e1e621a2e97ba1ee6bdc6a4102e16
# good: [a6e307c5f1b3aeeb6b9702f5ca1e4655e4ba4691] update copyright notice / whitespace
git bisect good a6e307c5f1b3aeeb6b9702f5ca1e4655e4ba4691
# bad: [8e164f784df9833c588f734c23d786a5f4fd29f0] Merge branch 'gitlab-ci-make-install-job' into 'master'
git bisect bad 8e164f784df9833c588f734c23d786a5f4fd29f0
# good: [3fbf9d3ea18d8f4e6f01252c6aa914ad953c1430] Merge branch 'add-print.h' into 'master'
git bisect good 3fbf9d3ea18d8f4e6f01252c6aa914ad953c1430
# bad: [4354f44d9c7608cea9e585500ba04cdb263e20d3] Do not call exit() upon verify_nodes() errors
git bisect bad 4354f44d9c7608cea9e585500ba04cdb263e20d3
# good: [9b6b11f02a0faadbd8ab60986cb9cfc7cbcb6115] Merge branch '278-prevent-false-negatives-in-rootkeysentinel-system-test' into 'master'
git bisect good 9b6b11f02a0faadbd8ab60986cb9cfc7cbcb6115
# good: [b8b731bd20cd949f7e74c4a5e4cf71ca7b7de44f] Merge branch '302-use-ip-for-ifconfig' into 'master'
git bisect good b8b731bd20cd949f7e74c4a5e4cf71ca7b7de44f
# bad: [68f056b2a07098896d3f6898ba9927fea3158fef] Add helper variables in mkeys system test
git bisect bad 68f056b2a07098896d3f6898ba9927fea3158fef
# good: [bb2dfb3f49ab707d751c0d83eb26938ed29a1b70] Add dns_zone_logv()
git bisect good bb2dfb3f49ab707d751c0d83eb26938ed29a1b70
# bad: [31b0dc1f204d8f7520145f21e8ea46d1466412a7] Require python with dnspython module
git bisect bad 31b0dc1f204d8f7520145f21e8ea46d1466412a7
# bad: [dd7bb617be1ac4c09821f64a2d6e9bd6a54873d6] - qname minimization: - make qname-minimization option tristate {strict,relaxed,disabled} - go straight for the record if we hit NXDOMAIN in relaxed mode - go straight for the record after 3 labels without new delegation or 7 labels total
git bisect bad dd7bb617be1ac4c09821f64a2d6e9bd6a54873d6
# good: [c8de677eaeec447b5c8eb562fa025bf57d8fa982] Add CHANGES entry
git bisect good c8de677eaeec447b5c8eb562fa025bf57d8fa982
# good: [0698158eb004369e0afeeebda42e704a6ebed44b] QNAME minimization
git bisect good 0698158eb004369e0afeeebda42e704a6ebed44b
# first bad commit: [dd7bb617be1ac4c09821f64a2d6e9bd6a54873d6] - qname minimization: - make qname-minimization option tristate {strict,relaxed,disabled} - go straight for the record if we hit NXDOMAIN in relaxed mode - go straight for the record after 3 labels without new delegation or 7 labels total
```
### Steps to reproduce
1. Install and start bind
2. `dig www.aviatormastercard.egslb.barclaycardus.com @localhost`
### What is the current *bug* behavior?
named makes a request as expected. The DNS server for egslb.barclaycardus.com (either 167.203.35.32 or 167.203.51.32) responds. This response is rejected by _us_ with ICMP port unreachable!
I disabled all firewall rules, so this is _not_ coming from a REJECT iptables rule.
### What is the expected *correct* behavior?
It resolves. E.g.:
```
;; ANSWER SECTION:
www.aviatormastercard.egslb.barclaycardus.com. 30 IN A 167.203.49.71
```
### Relevant configuration files
This is reproducible with a stock Ubuntu configuration, which `named-checkconf -px` says is:
```
options {
directory "/var/cache/bind";
listen-on-v6 {
"any";
};
dnssec-validation auto;
};
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
```
### Relevant logs and/or screenshots
[bind-icmp-unreachable.pcap](/uploads/bcbf7470510bd5e49e4d1ad76bb5391c/bind-icmp-unreachable.pcap)August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/2825Retroactively add CHANGES entry 5624 for BIND 9.16.172021-08-09T07:55:45ZMichał KępieńRetroactively add CHANGES entry 5624 for BIND 9.16.17While trying to wrap my mind around all the ~"v9.16" backports related
to network manager and cleaning up `CHANGES`, I failed to account for
the fact that `CHANGES` entry 5638 originally had different contents in
`main` and `v9_16`:
-...While trying to wrap my mind around all the ~"v9.16" backports related
to network manager and cleaning up `CHANGES`, I failed to account for
the fact that `CHANGES` entry 5638 originally had different contents in
`main` and `v9_16`:
- `main`: 19431b1c831dfebda3d409c6c5354b852cb7fdf2
- `v9_16`: 4c9c6a882387bd39196ae8189514afff4cfbee5e
Down the line, this ultimately resulted in #2638 getting excluded from
`CHANGES` in `v9_16`, which (with some "help" from a leftover MR, !4924)
caused some confusion as to when `v9_16` started running taskmgr tasks
in netmgr loops.
#2638 is a **big** change, so I suggest to retroactively add its
`CHANGES` entry to the relevant section of that file in `v9_16`. I plan
to do that next week, when I merge July release branches back into
maintenance branches.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2822Inconsistent recursive performance2021-07-23T14:52:59ZOndřej SurýInconsistent recursive performanceDuring the testing it was discovered that on some runs the resolver performance would not be consistent.
Some time later, it was proven that this is caused by setting the thread affinity on both netmgr code and old socket code. On some...During the testing it was discovered that on some runs the resolver performance would not be consistent.
Some time later, it was proven that this is caused by setting the thread affinity on both netmgr code and old socket code. On some runs the affinity would work fine and everything would be fine, and on some runs the netmgr and socket code would compete over the same resource causing performance dips.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2821TCP timeout allowance too short2021-11-04T14:48:12ZMark AndrewsTCP timeout allowance too shortWhen testing tcp-on-no-cookie there where lots of fetch timeouts with the existing 1 second allowance. Updating this to 2 seconds reduced most of these and updating this to 3 second removed all of these.When testing tcp-on-no-cookie there where lots of fetch timeouts with the existing 1 second allowance. Updating this to 2 seconds reduced most of these and updating this to 3 second removed all of these.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/2820rndc reconfig does not act on change to zone-statistics2021-07-16T08:00:51ZEverett Fultonrndc reconfig does not act on change to zone-statisticsA customer has noticed that when they add 'zone-statistics full;' into the named.conf file and then issue 'rndc reconfig', the resulting 'named.stats' file produced on issuing 'rndc stats' is still the 'terse' (default) output. Restartin...A customer has noticed that when they add 'zone-statistics full;' into the named.conf file and then issue 'rndc reconfig', the resulting 'named.stats' file produced on issuing 'rndc stats' is still the 'terse' (default) output. Restarting BIND does implement the desired change. It had been expected for the reconfig to accomplish this change as well.
(Mark A. stated this appears to be a bug, and requested this issue be opened.)August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)