BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-04-26T20:51:36Zhttps://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/2854DoH: Assign HTTP responses freshness lifetime according to the smallest TTL ...2021-12-01T07:30:45ZArtem BoldarievDoH: Assign HTTP responses freshness lifetime according to the smallest TTL found in the Answer section (by setting "max-age" in "Cache-Control" header)In the DoH spec there is a section on HTTP cache interaction.
https://datatracker.ietf.org/doc/html/rfc8484#section-5.1
We are now trying to bypass the caches. However, in the long run it might be beneficial to take advantage of it by ...In the DoH spec there is a section on HTTP cache interaction.
https://datatracker.ietf.org/doc/html/rfc8484#section-5.1
We are now trying to bypass the caches. However, in the long run it might be beneficial to take advantage of it by setting `max-age` to the least TTL from the answer section. In some cases, this can help us to take advantage of the existing HTTP caching infrastructure and lessen load on the DNS server itself by reusing the HTTP infrastructure caching capabilities.
Adding such a code to `http.c` is easy, however, we seem to currently lack a mechanism to track the minimal TTL value in `dns_message`. If we were adding one, we could put it into `dns_message`, updating the lowest TTL whenever a new rdataset was added to a message.
For the reference, at least Knot Resolver does it, as do Cloudflare and Quad9. So should we.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2853Allow DROP'ing requests that would result in DENIED responses2021-08-08T06:34:42ZCRCinAUAllow DROP'ing requests that would result in DENIED responses### Description
There has been an increase over the last few years of abusing nameservers for DNS amplification attacks - or even just to send data to target IP addresses. One I've seen documented lately in wide use is a RRSIG request f...### Description
There has been an increase over the last few years of abusing nameservers for DNS amplification attacks - or even just to send data to target IP addresses. One I've seen documented lately in wide use is a RRSIG request for pizzaseo.com. Even if you send back a DENIED response, you still add 30 bytes per response to the forged targets.
There seems to be a patch for an older version of BIND that will swap out REFUSED responses with a DROP, eg:
```
--- bind9-9.9.5.dfsg/bin/named/query.c.orig Thu Aug 6 21:56:57 2020
+++ bind9-9.9.5.dfsg/bin/named/query.c Thu Aug 6 22:08:15 2020
@@ -1038,7 +1038,7 @@
sizeof(msg));
ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
NS_LOGMODULE_QUERY, ISC_LOG_INFO,
- "%s denied", msg);
+ "%s dropped", msg);
}
/*
* We've now evaluated the view's query ACL, and
@@ -5809,8 +5809,9 @@
} else
inc_stats(client, dns_nsstatscounter_authrej);
if (!PARTIALANSWER(client))
- QUERY_ERROR(DNS_R_REFUSED);
- } else
+ // QUERY_ERROR(DNS_R_REFUSED);
+ QUERY_ERROR(DNS_R_DROP);
+ } else
QUERY_ERROR(DNS_R_SERVFAIL);
goto cleanup;
}
# diff -u query.c.orig query.c
```
### Request
It would be nice to have an option in the named.conf configuration schema that would allow to DROP replies for denied / refused queries and not respond to potential attackers at all.
A wrongly targeted client would simply time out on the DNS lookup instead of getting an immediate DENIED response, which wouldn't be the end of the world making the risk somewhat minimal. Authoritative or allowed queries would still happen as per normal.
### Links / references
https://www.linkedin.com/pulse/stop-feeding-pizza-ddos-dns-attack-jason-muskathttps://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/2851A rare crash in the DoH code caused by an assert2021-08-17T09:01:28ZArtem BoldarievA rare crash in the DoH code caused by an assertA rare issue was found while working on !5309. The unit test suite (`doh_test`) revealed a situation when `session->handle` got detached too early in the `http_send_outgoing()`, the function which takes data from nghttp2 and sends it via...A rare issue was found while working on !5309. The unit test suite (`doh_test`) revealed a situation when `session->handle` got detached too early in the `http_send_outgoing()`, the function which takes data from nghttp2 and sends it via the underlying connection.
As a result, when we have reached the call to `isc_nm_send()`
```
session->sending++;
isc_nm_send(session->handle, &send->data, http_writecb, send);
return (true);
}
```
the `session->handle` was `NULL` triggering an assert:
```
void
isc_nm_send(isc_nmhandle_t *handle, isc_region_t *region, isc_nm_cb_t cb,
void *cbarg) {
REQUIRE(VALID_NMHANDLE(handle));
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Artem BoldarievArtem Boldarievhttps://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/2848Release Checklist for BIND 9.11.35, BIND 9.11.35-S1, BIND 9.16.20, BIND 9.16....2021-08-19T07:28:53ZMichal NowakRelease Checklist for BIND 9.11.35, BIND 9.11.35-S1, BIND 9.16.20, BIND 9.16.20-S1, 9.17.17## Release Schedule
**Code Freeze:** Wednesday, August 4th, 2021
**Tagging Deadline:** Monday, August 9th, 2021
**Public Release:** Wednesday, August 18th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone...## Release Schedule
**Code Freeze:** Wednesday, August 4th, 2021
**Tagging Deadline:** Monday, August 9th, 2021
**Public Release:** Wednesday, August 18th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
* [9.17.17](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
* [9.16.20](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
* [9.11.35](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
* [9.17.17](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)¬[label_name][]=Release%20Notes&target_branch=main)
* [9.16.20](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)¬[label_name][]=Release%20Notes&target_branch=v9_16)
* [9.11.35](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
* [9.17.17](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)&label_name[]=No%20CHANGES&target_branch=main)
* [9.16.20](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)&label_name[]=No%20CHANGES&target_branch=v9_16)
* [9.11.35](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=August%202021%20(9.11.35%2C%209.11.35-S1%2C%209.16.20%2C%209.16.20-S1%2C%209.17.17)&label_name[]=No%20CHANGES&target_branch=v9_11)
## 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.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Michal NowakMichal Nowak2021-08-18https://gitlab.isc.org/isc-projects/bind9/-/issues/2847Bind doesn't stop contacting global ROOT DNS servers after commenting(#) the ...2021-08-02T14:44:15ZRamesh SahooBind doesn't stop contacting global ROOT DNS servers after commenting(#) the the root hint zone in named.confHello Team,
I commented the root hint zone section(default) in the named.conf file to stop bind from communicating to the global root DNS servers and it should only use the internal forwarders available in the options{} section.
```
#...Hello Team,
I commented the root hint zone section(default) in the named.conf file to stop bind from communicating to the global root DNS servers and it should only use the internal forwarders available in the options{} section.
```
#zone "." IN {
# type hint;
# file "named.ca";
#};
```
But the BIND still communicates to the ROOT DNS server when the query can't be answered by the internal forwarders.
- Is this a default behavior?
- Does bind has an inbuilt root hint zone even though the zone is not defined in the namd.conf file?
**I tried the following workaround and it worked for me.**
Disabled the global forwarders in the `options{}` section:
```
/*
forwarders {
x.x.x.3;
x.x.x.2;
x.x.x.1;
};
*/
```
Redefined the root hint as a forward type zone
```
zone "." IN {
//type hint;
//file "named.ca";
type forward;
forward only;
forwarders { x.x.x.3; x.x.x.2; x.x.x.1; };
};
```
Now bind only communicates to the forwarding DNS servers and never tries to communicate to the global root DNS servers.
- Any side effects with the above setting?
- My org. doesn't allow external DNS communication.
- Any other way to prevent bind communicating the root DNS servers but only ask the internal forwarders?https://gitlab.isc.org/isc-projects/bind9/-/issues/2846Automatic detection of masterfile format2021-08-25T16:13:27ZCarsten StrotmannAutomatic detection of masterfile format### Description
BIND 9 could automatically detect the format of the zone file format (text, raw or map)
### Request
Implement a setting "masterfile-format auto;" where BIND 9 will "sniff" the format of the supplied zone file (text or ...### Description
BIND 9 could automatically detect the format of the zone file format (text, raw or map)
### Request
Implement a setting "masterfile-format auto;" where BIND 9 will "sniff" the format of the supplied zone file (text or pre-compiled raw or map) and "do the right thing" based on the format of the file.
On a secondary this setting would reflect the current default (writing a "raw" file image).
### Links / references
This request came up during a BIND 9 training at Linuxhotel/Germany from a BIND 9 user.
https://bind9.readthedocs.io/en/v9_16_19/reference.html?highlight=masterfile-format#additional-file-formatsNot plannedArаm SаrgsyаnArаm Sаrgsyаnhttps://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/2843EC_KEY has been deprecated on OpenSSL 3.0.02022-01-19T11:20:50ZMark AndrewsEC_KEY has been deprecated on OpenSSL 3.0.0Need to workout what the replacement code needs to be as builds fail on strict systems.Need to workout what the replacement code needs to be as builds fail on strict systems.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Arаm SаrgsyаnArаm Sаrgsyаnhttps://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/2841general: client.c:798: INSIST(rcode != ((dns_rcode_t)dns_rcode_noerror) && rc...2021-08-19T08:17:04ZAndreas Kerbergeneral: client.c:798: INSIST(rcode != ((dns_rcode_t)dns_rcode_noerror) && rcode != ((dns_rcode_t)dns_rcode_nxdomain)) failed, back trace<!--
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
continous crashes of 3 authoritative servers since upgrading from 9.16.18 to 9.16.19
client.c:798: INSIST(rcode != ((dns_rcode_t)dns_rcode_noerror) && rcode != ((dns_rcode_t)dns_rcode_nxdomain)) failed, back trace
[core.17066.gz](/uploads/daa53199aeb7ca7f18dd8db37151fa53/core.17066.gz)
[named](/uploads/a4bb567f4ac126563e6c0605f2309231/named)
### BIND version used
BIND 9.16.19 (Stable Release) <id:df0e751>
running on Linux x86_64 3.10.0-1160.36.2.el7.x86_64 #1 SMP Wed Jul 21 11:57:15 UTC 2021
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--without-python' '--enable-pthread-rwlock' 'PKG_CONFIG_PATH=/usr/local/lib/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.42.0
linked to libuv version: 1.42.0
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
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: /usr/var/run/named/session.key
named PID file: /usr/var/run/named/named.pid
named lock file: /usr/var/run/named/named.lock
### Steps to reproduce
crash occours between 1 to 24 hours after starting 9.16.19 named.
same configuration, same build options work with 9.6.18 without any problem.
### What is the current *bug* behavior?
# ldd /usr/sbin/named
linux-vdso.so.1 => (0x00007ffe0c7a4000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f1dcca55000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f1dcc76c000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f1dcc539000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f1dcc335000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f1dcc0c3000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f1dcbc60000)
libz.so.1 => /lib64/libz.so.1 (0x00007f1dcba4a000)
libuv.so.1 => /usr/local/lib/libuv.so.1 (0x00007f1dcb81e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1dcb61a000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f1dcb415000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1dcb1f9000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1dcae2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1dccca2000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f1dcac1b000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f1dcaa17000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f1dca7fd000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f1dca5f8000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f1dca3d1000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f1dca16f000)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/named -u named'.
Program terminated with signal 6, Aborted.
#0 0x00007f9bf029a387 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-324.el7_9.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-50.el7.x86_64 libattr-2.4.46-13.el7.x86_64 libcap-2.22-11.el7.x86_64 libcom_err-1.42.9-19.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 libselinux-2.5-15.el7.x86_64 openssl-libs-1.0.2k-21.el7_9.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-19.el7_9.x86_64
(gdb) thread apply all bt full
Thread 8 (Thread 0x7f9bef394700 (LWP 17067)):
#0 0x00007f9bf0362fd3 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f9bf0c785a7 in uv__io_poll (loop=loop@entry=0x221fe60, timeout=<optimized out>) at src/unix/epoll.c:236
no_epoll_pwait_cached = 0
no_epoll_wait_cached = 0
no_epoll_pwait = 0
no_epoll_wait = 0
events = {{events = 1, data = {ptr = 0x23, fd = 35, u32 = 35, u64 = 35}}, {events = 1, data = {ptr = 0x23, fd = 35, u32 = 35, u64 = 35}}, {
events = 1, data = {ptr = 0x2b, fd = 43, u32 = 43, u64 = 43}}, {events = 1, data = {ptr = 0xb, fd = 11, u32 = 11, u64 = 11}}, {
events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}} <repeats 829 times>, {events = 0, data = {ptr = 0x1000, fd = 4096, u32 = 4096,
u64 = 4096}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {
events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0,
data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {
ptr = 0xd24f638000000000, fd = 0, u32 = 0, u64 = 15154440672531972096}}, {events = 32667, data = {ptr = 0x7f9be8000020,
fd = -402653152, u32 = 3892314144, u64 = 140307588972576}}, {events = 3505392, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {
events = 0, data = {ptr = 0x5232ed <update_rrsetstats+157>, fd = 5386989, u32 = 5386989, u64 = 5386989}}, {events = 0, data = {
ptr = 0xff000000000000, fd = 0, u32 = 0, u64 = 71776119061217280}}, {events = 8530, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {
events = 5386989, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x224200000021, fd = 33, u32 = 33,
u64 = 37666863185953}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0,
u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {
events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {
events = 6523215, data = {ptr = 0x186000000000, fd = 0, u32 = 0, u64 = 26800595927040}}, {events = 0, data = {ptr = 0x61800000241,
fd = 577, u32 = 577, u64 = 6700148982337}}, {events = 0, data = {ptr = 0x64e3de00000000, fd = 0, u32 = 0, u64 = 28398040293310464}}, {
events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 3931297328, data = {ptr = 0x100007f9b, fd = 32667, u32 = 32667,
u64 = 4294999963}}, {events = 0, data = {ptr = 0x64e469 <isc_rwlock_unlock+9>, fd = 6612073, u32 = 6612073, u64 = 6612073}}, {
events = 1, data = {ptr = 0x529ac200000000, fd = 0, u32 = 0, u64 = 23251106104606720}}, {events = 0, data = {ptr = 0x7f9be5d3d130,
fd = -439103184, u32 = 3855864112, u64 = 140307552522544}}, {events = 3793718704, data = {ptr = 0x7f9b, fd = 32667, u32 = 32667,
u64 = 32667}}, {events = 0, data = {ptr = 0x7f9be1905c60, fd = -510632864, u32 = 3784334432, u64 = 140307480992864}}, {
events = 3693820448, data = {ptr = 0xe21f8db000007f9b, fd = 32667, u32 = 32667, u64 = 16293897763903537051}}, {events = 32667, data = {
ptr = 0x7f9be5d3d020, fd = -439103456, u32 = 3855863840, u64 = 140307552522272}}, {events = 0, data = {ptr = 0x100000000, fd = 0,
u32 = 0, u64 = 4294967296}}, {events = 0, data = {ptr = 0x25, fd = 37, u32 = 37, u64 = 37}}, {events = 0, data = {
ptr = 0xd503957000000000, fd = 0, u32 = 0, u64 = 15349276263277658112}}, {events = 32667, data = {ptr = 0x0, fd = 0, u32 = 0,
u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x7f9be1905c60, fd = -510632864,
u32 = 3784334432, u64 = 140307480992864}}, {events = 3693880288, data = {ptr = 0xef3939f800007f9b, fd = 32667, u32 = 32667,
u64 = 17237872786051989403}}, {events = 32667, data = {ptr = 0x7f9bdc2b3a20, fd = -601146848, u32 = 3693820448,
u64 = 140307390478880}}, {events = 6612073, data = {ptr = 0xe4bd578000000000, fd = 0, u32 = 0, u64 = 16482426418513313792}}, {
events = 32667, data = {ptr = 0x52c957 <detachnode+151>, fd = 5425495, u32 = 5425495, u64 = 5425495}}, {events = 0, data = {ptr = 0x0,
---Type <return> to continue, or q <return> to quit---
fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0,
u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0xf0c7783a00000000, fd = 0,
u32 = 0, u64 = 17349968279971561472}}, {events = 32667, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 4039588944, data = {
ptr = 0xeadb071800007f9b, fd = 32667, u32 = 32667, u64 = 16923127824435412891}}, {events = 32667, data = {ptr = 0x10, fd = 16,
u32 = 16, u64 = 16}}, {events = 3940222904, data = {ptr = 0x100007f9b, fd = 32667, u32 = 32667, u64 = 4294999963}}, {events = 0,
data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {
ptr = 0x309, fd = 777, u32 = 777, u64 = 777}}, {events = 3758099352, data = {ptr = 0x1000007f9b, fd = 32667, u32 = 32667,
u64 = 68719509403}}, {events = 0, data = {ptr = 0x7f9be0000c38, fd = -536867784, u32 = 3758099512, u64 = 140307454757944}}, {
events = 1, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0,
data = {ptr = 0x6900000000, fd = 0, u32 = 0, u64 = 450971566080}}, {events = 0, data = {ptr = 0x7f9be0001358, fd = -536865960,
u32 = 3758101336, u64 = 140307454759768}}, {events = 16, data = {ptr = 0xe00013f800000000, fd = 0, u32 = 0,
u64 = 16140923020368674816}}, {events = 32667, data = {ptr = 0x1, fd = 1, u32 = 1, u64 = 1}}, {events = 0, data = {ptr = 0x0, fd = 0,
u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 105, data = {ptr = 0xe00022d800000000,
fd = 0, u32 = 0, u64 = 16140939375604137984}}, {events = 32667, data = {ptr = 0x10, fd = 16, u32 = 16, u64 = 16}}, {
events = 3758105464, data = {ptr = 0x100007f9b, fd = 32667, u32 = 32667, u64 = 4294999963}}, {events = 0, data = {ptr = 0x0, fd = 0,
u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x69, fd = 105, u32 = 105,
u64 = 105}}, {events = 3940222744, data = {ptr = 0x1000007f9b, fd = 32667, u32 = 32667, u64 = 68719509403}}, {events = 0, data = {
ptr = 0x7f9beadb07b8, fd = -354744392, u32 = 3940222904, u64 = 140307636881336}}, {events = 1, data = {ptr = 0x0, fd = 0, u32 = 0,
u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x6900000000, fd = 0, u32 = 0,
u64 = 450971566080}}, {events = 0, data = {ptr = 0x7f9bd0aa8cb8, fd = -794129224, u32 = 3500838072, u64 = 140307197496504}}, {
events = 28, data = {ptr = 0xd0aa8d5800000000, fd = 0, u32 = 0, u64 = 15035985715026460672}}, {events = 32667, data = {ptr = 0x1,
fd = 1, u32 = 1, u64 = 1}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0,
u32 = 0, u64 = 0}}, {events = 158, data = {ptr = 0xd07cac5800000000, fd = 0, u32 = 0, u64 = 15023071950958231552}}, {events = 32667,
data = {ptr = 0x1c, fd = 28, u32 = 28, u64 = 28}}, {events = 3497831672, data = {ptr = 0x100007f9b, fd = 32667, u32 = 32667,
u64 = 4294999963}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0,
u64 = 0}}, {events = 0, data = {ptr = 0x9d, fd = 157, u32 = 157, u64 = 157}}, {events = 3949386008, data = {ptr = 0x1c00007f9b,
fd = 32667, u32 = 32667, u64 = 120259116955}}, {events = 0, data = {ptr = 0x7f9beb66d9b8, fd = -345581128, u32 = 3949386168,
u64 = 140307646044600}}, {events = 1, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0,
u64 = 0}}, {events = 0, data = {ptr = 0x9900000000, fd = 0, u32 = 0, u64 = 657129996288}}, {events = 0, data = {ptr = 0x7f9bd08de578,
fd = -796007048, u32 = 3498960248, u64 = 140307195618680}}, {events = 28, data = {ptr = 0xd08de61800000000, fd = 0, u32 = 0,
u64 = 15027920522358816768}}, {events = 32667, data = {ptr = 0x632a36 <isc_log_doit+182>, fd = 6498870, u32 = 6498870,
u64 = 6498870}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0,
u64 = 0}}, {events = 152, data = {ptr = 0xd0a5455800000000, fd = 0, u32 = 0, u64 = 15034499175305707520}}, {events = 32667, data = {
ptr = 0x1c, fd = 28, u32 = 28, u64 = 28}}, {events = 9714208, data = {ptr = 0x68939800000000, fd = 0, u32 = 0,
u64 = 29435678622220288}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x300000000, fd = 0,
u32 = 0, u64 = 12884901888}}, {events = 0, data = {ptr = 0x99, fd = 153, u32 = 153, u64 = 153}}, {events = 3955927912, data = {
ptr = 0x1c00007f9b, fd = 32667, u32 = 32667, u64 = 120259116955}}, {events = 0, data = {ptr = 0x7f9bebcaac08, fd = -339039224,
u32 = 3955928072, u64 = 140307652586504}}, {events = 1, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0,
fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x9d00000000, fd = 0, u32 = 0, u64 = 674309865472}}, {events = 0, data = {
---Type <return> to continue, or q <return> to quit---
ptr = 0x7f9bd0aa84f8, fd = -794131208, u32 = 3500836088, u64 = 140307197494520}}, {events = 28, data = {ptr = 0xd0aa859800000000,
fd = 0, u32 = 0, u64 = 15035977193811345408}}, {events = 32667, data = {ptr = 0x1, fd = 1, u32 = 1, u64 = 1}}, {events = 0, data = {
ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 154, data = {
ptr = 0xebcab32800000000, fd = 0, u32 = 0, u64 = 16990589528588681216}}, {events = 32667, data = {ptr = 0x1c, fd = 28, u32 = 28,
u64 = 28}}, {events = 3955930056, data = {ptr = 0x100007f9b, fd = 32667, u32 = 32667, u64 = 4294999963}}, {events = 0, data = {
ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {
ptr = 0x63894f <isc___mem_put+271>, fd = 6523215, u32 = 6523215, u64 = 6523215}}, {events = 3943738104, data = {ptr = 0x1c00007f9b,
fd = 32667, u32 = 32667, u64 = 120259116955}}, {events = 615, data = {ptr = 0x7f9beb10ab98, fd = -351229032, u32 = 3943738264,
u64 = 140307640396696}}, {events = 6523215, data = {ptr = 0xe85c521000000000, fd = 0, u32 = 0, u64 = 16743347743329615872}}, {
events = 32667, data = {ptr = 0x2a1e463bc88, fd = -463225720, u32 = 3831741576, u64 = 2894344731784}}, {events = 4013505080, data = {
ptr = 0xef3939c000007f9b, fd = 32667, u32 = 32667, u64 = 17237872545533820827}}, {events = 32667, data = {ptr = 0x7f9be85c5210,
fd = -396602864, u32 = 3898364432, u64 = 140307595022864}}, {events = 4707662, data = {ptr = 0xef393a3800000000, fd = 0, u32 = 0,
u64 = 17237873060929863680}}, {events = 32667, data = {ptr = 0x63894f <isc___mem_put+271>, fd = 6523215, u32 = 6523215,
u64 = 6523215}}, {events = 3898364432, data = {ptr = 0x59873400007f9b, fd = 32667, u32 = 32667, u64 = 25199930335330203}}, {
events = 615, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 3837613952, data = {ptr = 0x7f9b, fd = 32667, u32 = 32667,
u64 = 32667}}, {events = 0, data = {ptr = 0x7f9be4bc3010, fd = -457428976, u32 = 3837538320, u64 = 140307534196752}}, {events = 0,
data = {ptr = 0xe4bc305000000000, fd = 0, u32 = 0, u64 = 16482101856424689664}}, {events = 32667, data = {ptr = 0x7f9bef393a38,
fd = -281462216, u32 = 4013505080, u64 = 140307710163512}}, {events = 0, data = {ptr = 0xe4bd578000000000, fd = 0, u32 = 0,
u64 = 16482426418513313792}}, {events = 32667, data = {ptr = 0x7f9be4bc3010, fd = -457428976, u32 = 3837538320,
u64 = 140307534196752}}, {events = 1, data = {ptr = 0x4f9d3b00000000, fd = 0, u32 = 0, u64 = 22409399888773120}}, {events = 0, data = {
ptr = 0xdc2c23e0, fd = -601087008, u32 = 3693880288, u64 = 3693880288}}, {events = 3837538384, data = {ptr = 0x7f9b, fd = 32667,
u32 = 32667, u64 = 32667}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0xe4bc301000000000,
fd = 0, u32 = 0, u64 = 16482101581546782720}}, {events = 32667, data = {ptr = 0x1, fd = 1, u32 = 1, u64 = 1}}, {events = 0, data = {
ptr = 0xe829264000000000, fd = 0, u32 = 0, u64 = 16728944347164180480}}, {events = 32667, data = {ptr = 0x7f9be8292658,
fd = -399956392, u32 = 3895010904, u64 = 140307591669336}}, {events = 3944821744, data = {ptr = 0x7f9b, fd = 32667, u32 = 32667,
u64 = 32667}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 6702569, data = {ptr = 0xeb2133f000000000,
fd = 0, u32 = 0, u64 = 16942880379029684224}}, {events = 32667, data = {ptr = 0x7f9be828f570, fd = -399968912, u32 = 3894998384,
u64 = 140307591656816}}, {events = 3894999464, data = {ptr = 0x63cf7500007f9b, fd = 32667, u32 = 32667, u64 = 28094124112510875}}, {
events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0xe828f57000000000, fd = 0, u32 = 0,
u64 = 16728890677252849664}}, {events = 32667, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {
ptr = 0x63d13a00000000, fd = 0, u32 = 0, u64 = 28096069732663296}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {
events = 0, data = {ptr = 0xe000108000000000, fd = 0, u32 = 0, u64 = 16140919206437715968}}, {events = 32667, data = {
ptr = 0x7f9be0001080, fd = -536866688, u32 = 3758100608, u64 = 140307454759040}}, {events = 0, data = {ptr = 0x63d8ef00000000, fd = 0,
u32 = 0, u64 = 28104543703138304}}, {events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {
ptr = 0xe828f7a000000000, fd = 0, u32 = 0, u64 = 16728893082434535424}}, {events = 32667, data = {ptr = 0x0, fd = 0, u32 = 0,
u64 = 0}}, {events = 3894998384, data = {ptr = 0x63e14700007f9b, fd = 32667, u32 = 32667, u64 = 28113717753315227}}, {events = 0,
data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0xe828f57000000000, fd = 0, u32 = 0,
u64 = 16728890677252849664}}, {events = 32667, data = {ptr = 0x7f9be828f7a0, fd = -399968352, u32 = 3894998944,
u64 = 140307591657376}}, {events = 3894999144, data = {ptr = 0x63f23100007f9b, fd = 32667, u32 = 32667, u64 = 28132314961706907}}, {
---Type <return> to continue, or q <return> to quit---
events = 0, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 3894998384, data = {ptr = 0xe000108000007f9b, fd = 32667,
u32 = 32667, u64 = 16140919206437748635}}, {events = 32667, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 3758101320,
data = {ptr = 0xf0c739dc00007f9b, fd = 32667, u32 = 32667, u64 = 17349899706523746203}}, {events = 32667, data = {ptr = 0x7f9bef393d00,
fd = -281461504, u32 = 4013505792, u64 = 140307710164224}}, {events = 3894999072, data = {ptr = 0xef393d0000007f9b, fd = 32667,
u32 = 32667, u64 = 17237876118946611099}}, {events = 32667, data = {ptr = 0x7f9be828f7a0, fd = -399968352, u32 = 3894998944,
u64 = 140307591657376}}, {events = 0, data = {ptr = 0xf0c74dc400000000, fd = 0, u32 = 0, u64 = 17349921593677053952}}, {
events = 32667, data = {ptr = 0x70, fd = 112, u32 = 112, u64 = 112}}, {events = 0, data = {ptr = 0xd4f750f800000004, fd = 4, u32 = 4,
u64 = 15345823281370365956}}, {events = 32667, data = {ptr = 0x6376dd <isc_mempool_destroy+477>, fd = 6518493, u32 = 6518493,
u64 = 6518493}}, {events = 3894809672, data = {ptr = 0x221e51000007f9b, fd = 32667, u32 = 32667, u64 = 153655719189577627}}, {
events = 0, data = {ptr = 0x550, fd = 1360, u32 = 1360, u64 = 1360}}, {events = 3492612592, data = {ptr = 0x55000007f9b, fd = 32667,
u32 = 32667, u64 = 5841155555227}}, {events = 0, data = {ptr = 0x221e528, fd = 35775784, u32 = 35775784, u64 = 35775784}}, {
events = 7139524, data = {ptr = 0x63894f00000000, fd = 0, u32 = 0, u64 = 28016995089776640}}, {events = 0, data = {ptr = 0x7f9bd02d0a00,
fd = -802354688, u32 = 3492612608, u64 = 140307189271040}}, {events = 7139524, data = {ptr = 0xe859ddf800000500, fd = 1280,
u32 = 1280, u64 = 16742657146948158720}}, {events = 32667, data = {ptr = 0x7f9bd02d09f0, fd = -802354704, u32 = 3492612592,
u64 = 140307189271024}}, {events = 1, data = {ptr = 0xd02d0a0000000000, fd = 0, u32 = 0, u64 = 15000656928957267968}}, {
events = 32667, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 0, data = {ptr = 0xd02d0c2000000000, fd = 0, u32 = 0,
u64 = 15000659265419476992}}...}
pe = <optimized out>
e = {events = 1, data = {ptr = 0x23, fd = 35, u32 = 35, u64 = 35}}
real_timeout = <optimized out>
q = <optimized out>
w = <optimized out>
sigset = {__val = {0 <repeats 16 times>}}
sigmask = <optimized out>
base = <optimized out>
have_signals = <optimized out>
nevents = <optimized out>
count = <optimized out>
nfds = <optimized out>
fd = <optimized out>
op = <optimized out>
i = <optimized out>
user_timeout = <optimized out>
reset_timeout = <optimized out>
__PRETTY_FUNCTION__ = "uv__io_poll"
#2 0x00007f9bf0c665d0 in uv_run (loop=loop@entry=0x221fe60, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:389
timeout = <optimized out>
r = 1
#3 0x000000000063ea36 in nm_thread (worker0=0x221fe50) at netmgr.c:734
---Type <return> to continue, or q <return> to quit---
r = <optimized out>
worker = 0x221fe50
mgr = 0x7f9bf22ae010
#4 0x0000000000654cb2 in isc__trampoline_run (arg=0x2221950) at trampoline.c:191
trampoline = 0x2221950
result = <optimized out>
#5 0x00007f9bf0639ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6 0x00007f9bf03629fd in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 7 (Thread 0x7f9bf22ea880 (LWP 17066)):
#0 0x00007f9bf06413c1 in sigwait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00000000006255d1 in isc_app_ctxrun (ctx=ctx@entry=0x957aa0 <isc_g_appctx>) at app.c:312
sset = {__val = {16387, 0 <repeats 15 times>}}
sig = -232086664
event = 0x0
next_event = <optimized out>
task = 0x0
#2 0x000000000062599c in isc_app_run () at app.c:365
result = 4294967292
#3 0x000000000044c24e in main (argc=<optimized out>, argv=<optimized out>) at ./main.c:1573
result = <optimized out>
Thread 6 (Thread 0x7f9bd53d8700 (LWP 17247)):
#0 0x00007f9bf063da35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f9bf0c730a9 in uv_cond_wait (cond=cond@entry=0x7f9bf0e82a60 <cond>, mutex=mutex@entry=0x7f9bf0e82a20 <mutex>) at src/unix/thread.c:780
No locals.
#2 0x00007f9bf0c60fd6 in worker (arg=0x0) at src/threadpool.c:76
w = <optimized out>
q = <optimized out>
is_slow_work = <optimized out>
#3 0x00007f9bf0639ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f9bf03629fd in clone () from /lib64/libc.so.6
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
Thread 5 (Thread 0x7f9bd55d9700 (LWP 17246)):
#0 0x00007f9bf063da35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f9bf0c730a9 in uv_cond_wait (cond=cond@entry=0x7f9bf0e82a60 <cond>, mutex=mutex@entry=0x7f9bf0e82a20 <mutex>) at src/unix/thread.c:780
No locals.
#2 0x00007f9bf0c60fd6 in worker (arg=0x0) at src/threadpool.c:76
w = <optimized out>
q = <optimized out>
is_slow_work = <optimized out>
#3 0x00007f9bf0639ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f9bf03629fd in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 4 (Thread 0x7f9bed24f700 (LWP 17071)):
#0 0x00007f9bf0362fd3 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x000000000065d0b6 in netthread (uap=0x7f9bf22bd100) at socket.c:3396
thread = 0x7f9bf22bd100
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = "\001\000\000\000\001\002", '\000' <repeats 121 times>
#2 0x0000000000654cb2 in isc__trampoline_run (arg=0x221eeb0) at trampoline.c:191
trampoline = 0x221eeb0
result = <optimized out>
#3 0x00007f9bf0639ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f9bf03629fd in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 3 (Thread 0x7f9bee251700 (LWP 17069)):
#0 0x00007f9bf063dde2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x0000000000664138 in isc_condition_waituntil (c=c@entry=0x7f9bf22bd070, m=m@entry=0x7f9bf22bd020, t=t@entry=0x7f9bf22bd064) at condition.c:56
presult = <optimized out>
result = <optimized out>
ts = {tv_sec = 1627473466, tv_nsec = 120808870}
strbuf = "\000\000\000\000\000\000\000\000\361/f\000\000\000\000\000\064F\001a\000\000\000\000o\350}6\000\000\000\000P\376!\002\000\000\000\00---Type <return> to continue, or q <return> to quit---
0[Pe\000\000\000\000\000\340\360,\362\233\177\000\000߱b", '\000' <repeats 13 times>, "\020\340+\362\233\177\000\000l\"\000\000\000\000\000\000X\233,\362\233\177\000\000\000\000\000\000\000\000\000\000\020\320+\362\233\177\000\000X\233,\362\233\177\000\000˵b\000\000\000\000"
#2 0x00000000006554ab in run (uap=0x7f9bf22bd010) at timer.c:625
manager = 0x7f9bf22bd010
now = {seconds = 1627473460, nanoseconds = 914221167}
result = <optimized out>
#3 0x0000000000654cb2 in isc__trampoline_run (arg=0x221ee50) at trampoline.c:191
trampoline = 0x221ee50
result = <optimized out>
#4 0x00007f9bf0639ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5 0x00007f9bf03629fd in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 2 (Thread 0x7f9beda50700 (LWP 17070)):
#0 0x00007f9bf0362fd3 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x000000000065d0b6 in netthread (uap=0x7f9bf22bd0b0) at socket.c:3396
thread = 0x7f9bf22bd0b0
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = "\001\000\000\000\000\002", '\000' <repeats 121 times>
#2 0x0000000000654cb2 in isc__trampoline_run (arg=0x221ee80) at trampoline.c:191
trampoline = 0x221ee80
result = <optimized out>
#3 0x00007f9bf0639ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f9bf03629fd in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 1 (Thread 0x7f9beea52700 (LWP 17068)):
#0 0x00007f9bf029a387 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f9bf029ba78 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x0000000000454465 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:270
tracebuf = {0x45429d <assertion_failed+77>, 0x625fda <isc_assertion_failed+10>, 0x47dcc1 <ns_client_error+1345>,
0x47ddd9 <client_senddone+185>, 0x63e13a <isc__nm_async_sendcb+122>, 0x63f231 <isc__nm_sendcb+177>,
---Type <return> to continue, or q <return> to quit---
0x7f9bf0c739b2 <uv__udp_run_completed+274>, 0x7f9bf0c74dc4 <uv__udp_io+68>, 0x7f9bf0c6659b <uv_run+299>, 0x63ea36 <nm_thread+134>,
0x654cb2 <isc__trampoline_run+82>, 0x7f9bf0639ea5 <start_thread+197>, 0x7f9bf03629fd <clone+109>, 0x7f9bf03629fd <clone+109>, 0x0, 0x0,
0x0, 0x7f9beea51240, 0x7f9bd6993fd0, 0x0, 0x0, 0x51f10d <dns_rbtnodechain_first+77>, 0x0, 0x7f9beea51240, 0x7f9be6910e10,
0x64e469 <isc_rwlock_unlock+9>, 0x7f9beea51240, 0x516576 <dns_ntatable_shutdown+214>, 0x0 <repeats 50 times>, 0x1000, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7f9bd11cccf0, 0x7f9be8000020, 0x446420 <zone_nsec3chain+1748>, 0x0, 0x5232ed <update_rrsetstats+157>, 0x0,
0x215200ff0000, 0x0, 0x5232ed <update_rrsetstats+157>, 0x0, 0x224200000001, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x63894f <isc___mem_put+271>, 0x2340, 0x61800000234, 0x0, 0x64e3de <isc_rwlock_lock+78>, 0x0, 0x7f9bea52e620, 0x1,
0x64e469 <isc_rwlock_unlock+9>, 0x1, 0x529ac2 <decrement_reference+1122>, 0x7f9be5d3d130, 0x7f9bd0d64af0, 0x0, 0x7f9be15fc950,
0x7f9bdce361f0, 0x7f9bd0d64af0, 0x7f9be5d3d020, 0x0}
i = <optimized out>
nframes = 13
result = <optimized out>
logsuffix = <optimized out>
fname = 0x689330 "__do_global_dtors_aux_fini_array_entry"
#3 0x0000000000625fda in isc_assertion_failed (file=file@entry=0x689371 "client.c", line=line@entry=798, type=type@entry=isc_assertiontype_insist,
cond=cond@entry=0x689ee8 "rcode != ((dns_rcode_t)dns_rcode_noerror) && rcode != ((dns_rcode_t)dns_rcode_nxdomain)") at assertions.c:46
No locals.
#4 0x000000000047dcc1 in ns_client_error (client=client@entry=0x7f9be1a8c278, result=result@entry=58) at client.c:797
wouldlog = <optimized out>
log_buf = "\370p\000\340\233\177\000\000\001", '\000' <repeats 31 times>, "X\000\000\000\000\000\000\000\030\364\000\340\233\177\000\000\020\000\000\000\000\000\000\000\270\364\000\340\233\177\000\000\001", '\000' <repeats 31 times>, "\325\000\000\000\000\000\000\000\270$~\353\233\177\000\000\020\000\000\000\000\000\000\000X%~\353\233\177\000\000\001", '\000' <repeats 31 times>, "j\000\000\000\000\000\000\000\230\344\000\340\233\177\000\000\020\000\000\000\000\000\000\000\070\345\000\340\233\177\000\000"...
rrl_result = <optimized out>
loglevel = <optimized out>
message = 0x7f9be5569400
rcode = 0
trunc = <optimized out>
#5 0x000000000047ddd9 in client_senddone (handle=0x7f9be1a8c110, result=<optimized out>, cbarg=0x7f9be1a8c278) at client.c:299
client = 0x7f9be1a8c278
#6 0x000000000063e13a in isc__nm_async_sendcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7f9beea51b70) at netmgr.c:2615
ievent = 0x7f9beea51b70
sock = 0x7f9be828fac0
uvreq = 0x7f9be000f140
eresult = 58
#7 0x000000000063f231 in isc__nm_sendcb (sock=0x7f9be828fac0, uvreq=<optimized out>, eresult=<optimized out>, async=<optimized out>)
at netmgr.c:2591
ievent = {type = netievent_udpconnect, sock = 0x7f9be828fac0, req = 0x7f9be000f140, result = 58}
ievent = <optimized out>
---Type <return> to continue, or q <return> to quit---
#8 0x00007f9bf0c739b2 in uv__udp_run_completed (handle=handle@entry=0x7f9be828fcf0) at src/unix/udp.c:157
req = 0x7f9be000f3b8
q = 0x7f9be000f408
__PRETTY_FUNCTION__ = "uv__udp_run_completed"
#9 0x00007f9bf0c74dc4 in uv__udp_io (loop=<optimized out>, w=0x7f9be828fd70, revents=4) at src/unix/udp.c:182
handle = 0x7f9be828fcf0
#10 0x00007f9bf0c6659b in uv__run_pending (loop=0x2220310) at src/unix/core.c:821
q = <optimized out>
pq = {0x7f9beea51d00, 0x7f9beea51d00}
w = <optimized out>
#11 uv_run (loop=loop@entry=0x2220310, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:381
timeout = <optimized out>
r = 1
#12 0x000000000063ea36 in nm_thread (worker0=0x2220300) at netmgr.c:734
r = <optimized out>
worker = 0x2220300
mgr = 0x7f9bf22ae010
#13 0x0000000000654cb2 in isc__trampoline_run (arg=0x22216a0) at trampoline.c:191
trampoline = 0x22216a0
result = <optimized out>
#14 0x00007f9bf0639ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#15 0x00007f9bf03629fd in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)
(gdb)
See #2856August 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/2840netmgr/netmgr.c:2064: fatal error: RUNTIME_CHECK(r == 0) failed in dig on Ope...2022-02-11T14:07:38ZMichal Nowaknetmgr/netmgr.c:2064: fatal error: RUNTIME_CHECK(r == 0) failed in dig on OpenBSDJob [#1895046](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1895046) failed for f563cd570c8a4e24e0c6a1cf7cf6e11da1b090fb:
```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (71)
netmgr/netmgr.c:2064: fatal erro...Job [#1895046](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1895046) failed for f563cd570c8a4e24e0c6a1cf7cf6e11da1b090fb:
```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (71)
netmgr/netmgr.c:2064: fatal error: RUNTIME_CHECK(r == 0) failed
Abort trap (core dumped)
I:doth:exit status: 0
I:doth:stopping servers
I:doth:Core dump(s) found: doth/dig.core
D:doth:backtrace from doth/dig.core:
D:doth:--------------------------------------------------------------------------------
D:doth:Core was generated by `dig'.
D:doth:Program terminated with signal SIGABRT, Aborted.
D:doth:#0 thrkill () at /tmp/-:3
D:doth:[Current thread is 1 (process 164094)]
D:doth:#0 thrkill () at /tmp/-:3
D:doth:#1 0x00000ee3b008379e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
D:doth:#2 0x00000ee413f78d30 in isc_error_fatal (file=<optimized out>, line=<optimized out>, format=<optimized out>) at error.c:68
D:doth:#3 0x00000ee413f78d45 in isc_error_runtimecheck (file=0x0, line=6, expression=0xee3b00699ba <thrkill+10> "r\001\303d\211\004% ") at error.c:73
D:doth:#4 0x00000ee413f62522 in isc__nmsocket_timer_restart (sock=<optimized out>) at netmgr/netmgr.c:2064
D:doth:#5 0x00000ee1aa1a9e8b in launch_next_query (query=0xee3b89c1820) at dighost.c:3143
D:doth:#6 0x00000ee1aa1aa339 in tcp_connected (handle=0xee44e611420, eresult=0, arg=<optimized out>) at dighost.c:3280
D:doth:#7 0x00000ee413f63a16 in isc__nm_async_connectcb (worker=<optimized out>, ev0=<optimized out>) at netmgr/netmgr.c:2662
D:doth:#8 0x00000ee413f5fe30 in process_netievent (worker=0xee3b89c1020, ievent=0xee44e611020) at netmgr/netmgr.c:958
D:doth:#9 0x00000ee413f5ae64 in process_queue (worker=0xee3b89c1020, type=<error reading variable: Cannot access memory at address 0x3>) at netmgr/netmgr.c:998
D:doth:#10 process_all_queues (worker=0xee3b89c1020) at netmgr/netmgr.c:746
D:doth:#11 async_cb (handle=0xee3b89c12f8) at netmgr/netmgr.c:775
D:doth:#12 0x00000ee3bb4b39cd in uv.async_io () from /usr/local/lib/libuv.so.3.0
D:doth:#13 0x00000ee3bb4c5a19 in uv.io_poll () from /usr/local/lib/libuv.so.3.0
D:doth:#14 0x00000ee3bb4b40b8 in uv_run () from /usr/local/lib/libuv.so.3.0
D:doth:#15 0x00000ee413f5af4b in nm_thread (worker0=0xee3b89c1020) at netmgr/netmgr.c:681
D:doth:#16 0x00000ee413fac063 in isc__trampoline_run (arg=0xee3b89ae3c0) at trampoline.c:180
D:doth:#17 0x00000ee43eef0f51 in _rthread_start (v=<optimized out>) at /usr/src/lib/librthread/rthread.c:96
D:doth:#18 0x00000ee3b002dd1a in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
D:doth:--------------------------------------------------------------------------------
D:doth:full backtrace from doth/dig.core saved in doth/dig.core-backtrace.txt
D:doth:core dump doth/dig.core archived as doth/dig.core.gz
R:doth:FAIL
E:doth:2021-07-28T07:20:21+0000
```
#2809 might be triggering this, but I was unable to reproduce this locally (0 out of 6 attempts).
[dig.core.gz](/uploads/47a706783f8bda7af03498fe9d01a5d2/dig.core.gz)
[dig.core-backtrace.txt](/uploads/2e9bf04594dec8804aa790a3245f72f8/dig.core-backtrace.txt)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Artem BoldarievArtem Boldarievhttps://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.org