BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2019-11-05T11:04:13Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1226dig: EDNS options in requests cause bad YAML output2019-11-05T11:04:13ZPaul Hoffmandig: EDNS options in requests cause bad YAML outputThe YAML output for +qr with +nsid is bad. Note the "NSID" line below has no colon and no value, so the YAML output is invalid.
```
# /dig ns va @c.root-servers.net -4 +notcp +yaml +qr +nsid +recurse +time=4 +tries=1
-
type: MESSAGE
...The YAML output for +qr with +nsid is bad. Note the "NSID" line below has no colon and no value, so the YAML output is invalid.
```
# /dig ns va @c.root-servers.net -4 +notcp +yaml +qr +nsid +recurse +time=4 +tries=1
-
type: MESSAGE
message:
type: RECURSIVE_QUERY
query_time: !!timestamp 2019-09-13T16:34:17.956Z
message_size: 47b
socket_family: INET
socket_protocol: UDP
response_address: 192.33.4.12
response_port: 53
query_address: 0.0.0.0
query_port: 62875
query_message_data:
opcode: QUERY
status: NOERROR
id: 17687
flags: rd ad
QUESTION: 1
ANSWER: 0
AUTHORITY: 0
ADDITIONAL: 1
OPT_PSEUDOSECTION:
EDNS:
version: 0
flags:
udp: 4096
NSID
COOKIE: ba61ac759b7b483f
QUESTION_SECTION:
- va. IN NS
```November 2019 (9.11.13, 9.14.8, 9.15.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/1220runtime test fails on OpenBSD 6.52019-11-05T11:04:17ZMichal Nowakruntime test fails on OpenBSD 6.5### Summary
The `runtime` test fails on OpenBSD 6.5 with
```
S:runtime:Thu Sep 5 15:17:52 CEST 2019
T:runtime:1:A
A:runtime:System test runtime
I:runtime:PORTRANGE:11600 - 11699
I:runtime:verifying that named started normally (1)
I:run...### Summary
The `runtime` test fails on OpenBSD 6.5 with
```
S:runtime:Thu Sep 5 15:17:52 CEST 2019
T:runtime:1:A
A:runtime:System test runtime
I:runtime:PORTRANGE:11600 - 11699
I:runtime:verifying that named started normally (1)
I:runtime:verifying that named checks for conflicting named processes (2)
I:runtime:verifying that 'lock-file none' disables process check (3)
I:runtime:checking that named refuses to reconfigure if working directory is not writable (4)
I:runtime:failed
I:runtime:checking that named refuses to reconfigure if managed-keys-directory is not writable (5)
I:runtime:failed
I:runtime:checking that named refuses to reconfigure if new-zones-directory is not writable (6)
I:runtime:failed
I:runtime:checking that named refuses to start if working directory is not writable (7)
I:runtime:checking that named refuses to start if managed-keys-directory is not writable (8)
I:runtime:checking that named logs control characters in octal notation (9)
I:runtime:checking that named escapes special characters in the logs (10)
I:runtime:checking that named logs an ellipsis when the command line is larger than 8k bytes (11)
I:runtime:exit status: 3
R:runtime:FAIL
```
### BIND version used
```
openbsd# bin/named/named -V
BIND 9.15.3 (Development Release) <id:2367d61016>
running on OpenBSD amd64 6.5 GENERIC.MP#3
built by make with '--enable-full-report' '--with-libtool' '--with-libidn2' '--without-lmdb' '--without-readline' '--with-cmocka' 'CC=clang' 'KYUA=/usr/local/bin/kyua'
compiled by CLANG 4.2.1 Compatible OpenBSD Clang 7.0.1 (tags/RELEASE_701/final)
compiled with OpenSSL version: LibreSSL 2.9.1
linked to OpenSSL version: LibreSSL 2.9.1
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled
```
### Steps to reproduce
`make test`
### What is the current *bug* behavior?
The `runtime` test fails.
### What is the expected *correct* behavior?
The `runtime` test passes.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
N/ANovember 2019 (9.11.13, 9.14.8, 9.15.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/1206Customer Feature Request: Add "high-water" measurement for tcp-clients2019-11-06T20:09:50ZMichael McNallyCustomer Feature Request: Add "high-water" measurement for tcp-clientsSince we changed tcp-clients limit enforcement in response to CVE-2018-5743, several customers have contacted us asking how to set limits appropriately.
Yoshitaka Aharen of M-root has offered what we think would be a useful suggestion ...Since we changed tcp-clients limit enforcement in response to CVE-2018-5743, several customers have contacted us asking how to set limits appropriately.
Yoshitaka Aharen of M-root has offered what we think would be a useful suggestion which would help him and other operators who want to scale limits appropriately. He asks if named can keep track of a "high-water" limit for the number of simultaneous TCP clients, correctly pointing out that this is likely to be of more help to customers than random periodic polling via 'rndc status' which, if not performed frequently, could easily miss spikes in usage.
Related to Support [#15134](https://support.isc.org/Ticket/Display.html?id=15134) and [#15065](https://support.isc.org/Ticket/Display.html?id=15065)November 2019 (9.11.13, 9.14.8, 9.15.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/1143A minor documentation issue & consideration of parsing inconsistencies in IPv...2019-11-05T11:03:28ZGhost UserA minor documentation issue & consideration of parsing inconsistencies in IPv4s in address match lists and in a controls/inet statement### Description
This was discovered during a course. It was confusing for students, but nothing is really wrong except perhaps a minor issue in the ARM.
1. Quick overview:
* The first of these statements is valid, the last two are no...### Description
This was discovered during a course. It was confusing for students, but nothing is really wrong except perhaps a minor issue in the ARM.
1. Quick overview:
* The first of these statements is valid, the last two are not:
> controls { inet 127.0.0.1 allow { 127.1; } keys { "XXkey"; }; };
>
> controls { inet 127.1 allow { 127.0.0.1; } keys { "XXkey"; }; };
>
> controls { inet 127.1 allow { 127.1; } keys { "XXkey"; }; };
* Without other information, comparing the statements above, it is difficult to understand why 127.1 is permitted in one location, but not the other.
* Someone used to using 127.1 on the command-line is likely to misinterpret the meaning of 127.1 in an Address Match List.
1. Address Match Lists accept IPv4 addresses with less than four octets and without a netmask.
* Example: 177.44.8 is parsed as 177.44.8.0/32
* Example: 127.1 is parsed as 127.1.0.0/32
* This is reasonable. However, it is worth noting that it is very different than the parsing on the command line using commands such as dig and ping:
* ping 177.44.8 is parsed to ping 177.44.0.8 (not to 177.44.8.0)
* dig @127.1 is parsed to dig @127.0.0.1 (not to @127.1.0.0)
* Particularly because dig and named.conf are both part of BIND, the inconsistency is understandably confusing at first glance.
* For 127.1, I presume most people using it in an Address Match List would incorrectly think it parses to 127.0.0.1.
* Note: As I read it, there is a documentation issue on page 51 of the 9.14.3 ARM in the definition of ipv4_addr:
* ipv4_addr: An IPv4 address with exactly four elements in dotted_decimal notation.
* However, Address Match Lists access IPv4s with less than four elements.
* Possible correction:
* ipv4_addr: An IPv4 address in dotted_decimal notation. If there are less than four elements, the remainder are taken to be zero.
* AFAICT, the definition of ip_prefix does not come into play because there is no slash in the address.
1. The inet statement in a controls statement does not accept an IPv4 with less than four octets.
* If it did, the parsing would need to match the what one gets on the command-line, and differ from an Address Match List.
* 127.1 would need to parse to 127.0.0.1.
* "Quick overview" above has examples.
### Request
1. Change the definition of ipv4_addr in the ARM. Possibly update the definition if ip_prefix and dotted_decimal at the same time.
1. Maybe allow IPv4s in inet statements with less than four octets. For example:
* This: controls { inet 127.1 ...
* Would become: controls { inet 127.0.0.1 ...
* I see arguments for and against.
1. In an Address Match List, for the address 127.1, named-checkconf could produce a warning message about the parsing, perhaps:
* named.conf:<line#>: warning: In the Address Match List, 127.1 is interpreted as 127.1.0.0/32
* Perhaps any address beginning with 127 and less than four octets should get this treatment.
1. Forgive me for leading you down this rabbit hole of the unimportant.November 2019 (9.11.13, 9.14.8, 9.15.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/1059Fix TCP failure handling2019-11-05T11:03:04ZMichał KępieńFix TCP failure handlingThere are two issues with TCP failure handling in resolver code which are somewhat intertwined yet still distinct:
- for servers which respond to EDNS queries but never send responses larger than 512 bytes and are unavailable over TCP...There are two issues with TCP failure handling in resolver code which are somewhat intertwined yet still distinct:
- for servers which respond to EDNS queries but never send responses larger than 512 bytes and are unavailable over TCP, `named` may go into a pointless query loop which is only interrupted after the fetch context restart limit is hit; this cannot really be exploited, but is harmful to broken servers,
- TCP connection failures affect EDNS timeout statistics while EDNS mechanisms only apply to DNS over UDP.
Both of these issues are exposed by the `legacy` system test, but they went under the radar so far because they do not cause test failures - I only noticed something was up because I was running that test with Wireshark in the background.November 2019 (9.11.13, 9.14.8, 9.15.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/876Documentation feedback.2019-11-05T11:02:50ZMark AndrewsDocumentation feedback.```automatic-interface-scan```
How does this interact with ```interface-interval``` and why does it require routing sockets?
```lock-file```
I was running 9.11.5 with no ```lock-file``` directive and no lock file on disk...```automatic-interface-scan```
How does this interact with ```interface-interval``` and why does it require routing sockets?
```lock-file```
I was running 9.11.5 with no ```lock-file``` directive and no lock file on disk. When I added a ```lock-file``` directive specifying /var/run/named/named.lock that file was created. I don't think the ARM is entirely correct about the default. Also, your implementation of the lock file could be better. The file BIND created was just an empty file. If BIND dies and leaves that lock file in place it will prevent BIND from being restarted. If you write BIND's PID into the file, then if the file exists you can send a signal 0 to that PID to verify that a process with that number is running. If the kill fails you can allow BIND to start even if the lock file exists. This works unless another process with the same PID just happens to have been started in the meantime; that's unlikely, but this is still better than not testing at all.
```require-server-cookie```
The ARM doesn't indicate the default setting (or why one might pick yes versus no, for that matter). It says "Require a valid server cookie before sending a full response to a UDP request from a cookie aware client. BADCOOKIE is sent if there is a bad or no existent server cookie." I think this is trying to tell me that if I turn this on I get a BADCOOKIE error response and if I leave it off I get a normal response which is possibly truncated by the nocookie-udp-size parameter. It's a shame that's not what it says.
bin/named/config.c seems to tell me that the default is no. Why would I want to set it to yes? "yes" seems like it would be a really bad setting for servers behind a load balancer unless they were all configured with the same secret....
```resolver-nonbackoff-tries```
This option appears in the grammar but there is no description. The code tells me the default is 3.
```resolver-retry-interval```
Ditto. The code tells me the default is 800.
```send-cookie```
The ARM doesn't indicate the default setting. Again, the code seems to tell me the default is true.
stale-answer-enable
This option appears in the grammar but there is no description. The code tells me the default is false.
edit: more from the same source
Under ```dnskey-sig-validity``` the ARM says "If set to a non-zero value, this overrides the value set by ```sig-validity-interval```. The default is zero, meaning ```sig-validity-interval``` is used" However, if I specify "```dnskey-sig-validity 0;```" it says "'0' is out of range (1..3660)". November 2019 (9.11.13, 9.14.8, 9.15.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/664fetches-per-server quota is lower-bounded to 1 instead of to 2% of quota2019-11-18T18:03:12ZCathy Almondfetches-per-server quota is lower-bounded to 1 instead of to 2% of quotaOn a server with "fetches-per-server 4000;" I was surprised to see a cache dump with the ADB values for a server showing me a quota set to 1.
> ; problem-server.example.com [v4 TTL 2658] [v4 not_found] [v6 unexpected]
> ; 192.0.2.25 [sr...On a server with "fetches-per-server 4000;" I was surprised to see a cache dump with the ADB values for a server showing me a quota set to 1.
> ; problem-server.example.com [v4 TTL 2658] [v4 not_found] [v6 unexpected]
> ; 192.0.2.25 [srtt 948570] [flags 00004000] [ttl -342230] [atr 0.62] [quota 1]
Although we didn't document the lower bound in the ARM (this also needs to be addressed), the KB article ([https://kb.isc.org/docs/aa-01304](https://kb.isc.org/docs/aa-01304)) explaining how fetchlimits work, based on information from Engineering, describes the adjustment algorithm thus:
> The fetches-per-server option sets a hard upper limit to the number of outstanding fetches allowed for a single server. The lower limit is 2% of fetches-per-server, but never below 1. It also allows you to select what to do with the queries that are being limited - either drop them, or send back a SERVFAIL response.
Clearly however, this is not what is in code, as seen in adb.c maybe-adjust-quota(), the last thing we do:
```
/* Ensure we don't drop to zero */
if (addr->entry->quota == 0)
addr->entry->quota = 1;
}
```
The background to this, although very much a corner case, is a mis-configured server that responds to A queries but sends back nothing (so the fetches timeout) for AAAA queries for the same name. This is interacting particularly badly with fetches-per-server because the 'good' queries all get answers and are cached, whereas the 'bad' ones all timeout, SERVFAIL to the client and are not cached.
Turning on servfail cache would mitigate that to some extent.
But nevertheless, the quota going all the way down to 1 (instead of to 80) is making matter much worse.
Please fix, because although this corner case is not our problem as such (the mis-behaving server is being fixed), it is bad that the quota is going down so low that it's very hard to get enough queries to be processed in order to recalculate the atr often enough to be reasonably representative of the query rate to this server.
There was also no evidence of the low quota in the logging - presumably because it had been a rock bottom for longer than the logfile sample I looked at - which was for several hours. It therefore needed a cache dump to identify the problem.
(P.S. I'm assuming it's inefficient to calculate "2% of quota" every time we pass this way, so the bottom limit probably wants calculating initially to use here, and might well be something we want to add to adb on a per-server basis too, in anticipation of future work on fetches-per-server to allow for server-specific quota overrides)
Reference: https://support.isc.org/Ticket/Display.html?id=13720November 2019 (9.11.13, 9.14.8, 9.15.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/148Add BSDs to GitLab CI2019-11-05T11:03:22ZOndřej SurýAdd BSDs to GitLab CINovember 2019 (9.11.13, 9.14.8, 9.15.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/10Use and require atomic primitives support2024-01-03T14:09:50ZOndřej SurýUse and require atomic primitives supportUse the atomic primitives to replace the custom atomics code.Use the atomic primitives to replace the custom atomics code.November 2019 (9.11.13, 9.14.8, 9.15.6)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/5Revise coding style and documentation requirements2024-01-03T14:09:50ZOndřej SurýRevise coding style and documentation requirementsThis is unsorted list:
* [ ] opening curly braces on new line when the outside construct is multiline, e.g.
```
for (foo;
bar;
baz) {
```
vs current
```
for (foo;
bar;
baz)
{
```
* [ ] Using parentheses to e...This is unsorted list:
* [ ] opening curly braces on new line when the outside construct is multiline, e.g.
```
for (foo;
bar;
baz) {
```
vs current
```
for (foo;
bar;
baz)
{
```
* [ ] Using parentheses to explicitly set priority in conditions, e.g.
```
((foo == TRUE) || (bar == FALSE))
```
vs current
```
(foo == TRUE || bar == FALSE)
```
* [ ] Explicit `NULL` or `FALSE` comparison
```
(foo == FALSE && bar == NULL)
```
vs current
```
(!foo && !bar)
```November 2019 (9.11.13, 9.14.8, 9.15.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1494lock-order-inversion (potential deadlock) - nm_thread vs nm_destroy2019-12-12T13:14:08ZMark Andrewslock-order-inversion (potential deadlock) - nm_thread vs nm_destroyUnit tests are generating.
```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000001) => M2 (0x000000000002) => M1
Mutex M2 acquired here while holding mutex M1 in thread...Unit tests are generating.
```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000001) => M2 (0x000000000002) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_mutex_lock <null>
#1 nm_thread lib/isc/netmgr/netmgr.c:426:4
Mutex M1 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 nm_thread lib/isc/netmgr/netmgr.c:424:3
Mutex M1 acquired here while holding mutex M2 in main thread:
#0 pthread_mutex_lock <null>
#1 nm_destroy lib/isc/netmgr/netmgr.c:177:3
#2 isc_nm_detach lib/isc/netmgr/netmgr.c:308:3
#3 cleanup_managers lib/ns/tests/nstest.c:194:3
#4 ns_test_end lib/ns/tests/nstest.c:337:2
#5 _teardown lib/ns/tests/notify_test.c:59:2
#6 <null> <null>
#7 __libc_start_main <null>
Mutex M2 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 nm_destroy lib/isc/netmgr/netmgr.c:171:2
#2 isc_nm_detach lib/isc/netmgr/netmgr.c:308:3
#3 cleanup_managers lib/ns/tests/nstest.c:194:3
#4 ns_test_end lib/ns/tests/nstest.c:337:2
#5 _teardown lib/ns/tests/notify_test.c:59:2
#6 <null> <null>
#7 __libc_start_main <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:75:8
#2 isc_nm_start lib/isc/netmgr/netmgr.c:149:3
#3 create_managers lib/ns/tests/nstest.c:231:7
#4 ns_test_begin lib/ns/tests/nstest.c:316:3
#5 _setup lib/ns/tests/notify_test.c:49:11
#6 <null> <null>
#7 __libc_start_main <null>
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_mutex_lock
```December 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1491Release Checklist for BIND 9.11.14, BIND 9.11.14-S1, BIND 9.14.9, BIND 9.15.72019-12-19T15:02:00ZMichał KępieńRelease Checklist for BIND 9.11.14, BIND 9.11.14-S1, BIND 9.14.9, BIND 9.15.7## Release Schedule
**Tagging Deadline:** Wednesday, December 11th, 2019
**Public Release:** Wednesday, December 18th, 2019
## Release Checklist
## 2 Working Days Before the Tagging Deadline
- [x] ***(QA)*** Check whether all issue...## Release Schedule
**Tagging Deadline:** Wednesday, December 11th, 2019
**Public Release:** Wednesday, December 18th, 2019
## Release Checklist
## 2 Working Days Before the Tagging Deadline
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
## Before the Tagging Deadline
- [x] ***(QA)*** Inform Support/Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(SwEng)*** Update API files for libraries with new version information.
- [x] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(SwEng)*** Update `CHANGES`.
- [x] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(SwEng)*** Update `README.md`.
- [x] ***(SwEng)*** Update `version`.
- [x] ***(SwEng)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that all the above steps were performed correctly.
- [x] ***(QA)*** Check that the contents of release notes match the merge requests comprising the releases.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.)
- [x] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
## Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
## On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** 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] ***(SwEng)*** Push tags for the published releases to the public repository.
- [x] ***(SwEng)*** 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`).
[^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]: Preferred command line: `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc.December 2019 (9.11.14, 9.14.9, 9.15.7)Michal NowakMichal Nowak2019-12-18https://gitlab.isc.org/isc-projects/bind9/-/issues/1479_wait_for_rcode adds extraneous query2020-01-10T09:42:10ZMark Andrews_wait_for_rcode adds extraneous queryThe file name is also queried for
```
% more catz/dig.out.test20
; <<>> DiG 9.15.6 <<>> -p 6200 @10.53.0.1 SOA dom3.example. dig.out.test20
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status...The file name is also queried for
```
% more catz/dig.out.test20
; <<>> DiG 9.15.6 <<>> -p 6200 @10.53.0.1 SOA dom3.example. dig.out.test20
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49825
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 552f143ecf928ed7010000005df01a16958efc13984e1f65 (good)
;; QUESTION SECTION:
;dom3.example. IN SOA
;; ANSWER SECTION:
dom3.example. 3600 IN SOA . . 1 3600 3600 3600 3600
;; Query time: 12 msec
;; SERVER: 10.53.0.1#6200(10.53.0.1)
;; WHEN: Tue Dec 10 22:20:06 UTC 2019
;; MSG SIZE rcvd: 103
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 38697
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 552f143ecf928ed7010000005df01a16958efc13984e1f65 (good)
;; QUESTION SECTION:
;dig.out.test20. IN SOA
;; Query time: 8 msec
;; SERVER: 10.53.0.1#6200(10.53.0.1)
;; WHEN: Tue Dec 10 22:20:06 UTC 2019
;; MSG SIZE rcvd: 71
%
```December 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1473ThreadSanitizer: data race /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr....2019-12-10T13:00:20ZOndřej SurýThreadSanitizer: data race /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1027 in nmhandle_free```
WARNING: ThreadSanitizer: data race (pid=29181)
Write of size 8 at 0x7b90000a0010 by thread T16 (mutexes: write M562522896233146464):
#0 nmhandle_free /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1027 (libisc.so.1504+0x3...```
WARNING: ThreadSanitizer: data race (pid=29181)
Write of size 8 at 0x7b90000a0010 by thread T16 (mutexes: write M562522896233146464):
#0 nmhandle_free /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1027 (libisc.so.1504+0x3e3b7)
#1 nmhandle_deactivate /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1057 (libisc.so.1504+0x3e59f)
#2 isc_nmhandle_unref /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1108 (libisc.so.1504+0x409f0)
#3 fetch_callback /home/ondrej/Projects/bind9/lib/ns/query.c:5680 (libns.so.1502+0x46b71)
#4 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#5 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#6 <null> <null> (libtsan.so.0+0x29b3d)
Previous read of size 4 at 0x7b90000a0010 by thread T1:
#0 isc_nmhandle_unref /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1067 (libisc.so.1504+0x4091d)
#1 isc__nm_uvreq_put /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1214 (libisc.so.1504+0x41bef)
#2 udp_send_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/udp.c:439 (libisc.so.1504+0x46c1d)
#3 <null> <null> (libuv.so.1+0x1d283)
#4 <null> <null> (libtsan.so.0+0x29b3d)
Location is heap block of size 7489 at 0x7b90000a0000 allocated by thread T8:
#0 malloc <null> (libtsan.so.0+0x2b1a3)
#1 default_memalloc /home/ondrej/Projects/bind9/lib/isc/mem.c:685 (libisc.so.1504+0x33fee)
#2 mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:598 (libisc.so.1504+0x34c7e)
#3 mem_allocateunlocked /home/ondrej/Projects/bind9/lib/isc/mem.c:1222 (libisc.so.1504+0x34c7e)
#4 isc___mem_allocate /home/ondrej/Projects/bind9/lib/isc/mem.c:1242 (libisc.so.1504+0x34c7e)
#5 isc__mem_allocate /home/ondrej/Projects/bind9/lib/isc/mem.c:2387 (libisc.so.1504+0x3be64)
#6 isc___mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:1007 (libisc.so.1504+0x3c6ca)
#7 isc__mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:2365 (libisc.so.1504+0x3aef1)
#8 alloc_handle /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:916 (libisc.so.1504+0x40547)
#9 isc__nmhandle_get /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:940 (libisc.so.1504+0x40547)
#10 udp_recv_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/udp.c:312 (libisc.so.1504+0x46841)
#11 <null> <null> (libuv.so.1+0x1d6d4)
#12 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M562522896233146464 is already destroyed.
Thread T16 'isc-worker0007' (tid=29211, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410 (libisc.so.1504+0x59cf3)
#3 create_managers main.c:902 (named+0x1aeec)
#4 setup main.c:1235 (named+0x1aeec)
#5 main main.c:1515 (named+0x1aeec)
Thread T1 'isc-net-0000' (tid=29196, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_nm_start /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:149 (libisc.so.1504+0x3ec4a)
#3 create_managers main.c:895 (named+0x1ae90)
#4 setup main.c:1235 (named+0x1ae90)
#5 main main.c:1515 (named+0x1ae90)
Thread T8 'isc-net-0007' (tid=29203, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_nm_start /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:149 (libisc.so.1504+0x3ec4a)
#3 create_managers main.c:895 (named+0x1ae90)
#4 setup main.c:1235 (named+0x1ae90)
#5 main main.c:1515 (named+0x1ae90)
SUMMARY: ThreadSanitizer: data race /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1027 in nmhandle_free
```
and
```
WARNING: ThreadSanitizer: data race (pid=29181)
Write of size 8 at 0x7b90000a0018 by thread T16 (mutexes: write M562522896233146464):
#0 nmhandle_free /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1027 (libisc.so.1504+0x3e3b7)
#1 nmhandle_deactivate /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1057 (libisc.so.1504+0x3e59f)
#2 isc_nmhandle_unref /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1108 (libisc.so.1504+0x409f0)
#3 fetch_callback /home/ondrej/Projects/bind9/lib/ns/query.c:5680 (libns.so.1502+0x46b71)
#4 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#5 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#6 <null> <null> (libtsan.so.0+0x29b3d)
Previous atomic write of size 8 at 0x7b90000a0018 by thread T1:
#0 __tsan_atomic64_fetch_sub <null> (libtsan.so.0+0x648dd)
#1 isc_nmhandle_unref /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1069 (libisc.so.1504+0x4093c)
#2 isc__nm_uvreq_put /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1214 (libisc.so.1504+0x41bef)
#3 udp_send_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/udp.c:439 (libisc.so.1504+0x46c1d)
#4 <null> <null> (libuv.so.1+0x1d283)
#5 <null> <null> (libtsan.so.0+0x29b3d)
Location is heap block of size 7489 at 0x7b90000a0000 allocated by thread T8:
#0 malloc <null> (libtsan.so.0+0x2b1a3)
#1 default_memalloc /home/ondrej/Projects/bind9/lib/isc/mem.c:685 (libisc.so.1504+0x33fee)
#2 mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:598 (libisc.so.1504+0x34c7e)
#3 mem_allocateunlocked /home/ondrej/Projects/bind9/lib/isc/mem.c:1222 (libisc.so.1504+0x34c7e)
#4 isc___mem_allocate /home/ondrej/Projects/bind9/lib/isc/mem.c:1242 (libisc.so.1504+0x34c7e)
#5 isc__mem_allocate /home/ondrej/Projects/bind9/lib/isc/mem.c:2387 (libisc.so.1504+0x3be64)
#6 isc___mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:1007 (libisc.so.1504+0x3c6ca)
#7 isc__mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:2365 (libisc.so.1504+0x3aef1)
#8 alloc_handle /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:916 (libisc.so.1504+0x40547)
#9 isc__nmhandle_get /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:940 (libisc.so.1504+0x40547)
#10 udp_recv_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/udp.c:312 (libisc.so.1504+0x46841)
#11 <null> <null> (libuv.so.1+0x1d6d4)
#12 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M562522896233146464 is already destroyed.
Thread T16 'isc-worker0007' (tid=29211, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410 (libisc.so.1504+0x59cf3)
#3 create_managers main.c:902 (named+0x1aeec)
#4 setup main.c:1235 (named+0x1aeec)
#5 main main.c:1515 (named+0x1aeec)
Thread T1 'isc-net-0000' (tid=29196, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_nm_start /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:149 (libisc.so.1504+0x3ec4a)
#3 create_managers main.c:895 (named+0x1ae90)
#4 setup main.c:1235 (named+0x1ae90)
#5 main main.c:1515 (named+0x1ae90)
Thread T8 'isc-net-0007' (tid=29203, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_nm_start /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:149 (libisc.so.1504+0x3ec4a)
#3 create_managers main.c:895 (named+0x1ae90)
#4 setup main.c:1235 (named+0x1ae90)
#5 main main.c:1515 (named+0x1ae90)
SUMMARY: ThreadSanitizer: data race /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1027 in nmhandle_free
```December 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1471ThreadSanitizer: lock-order-inversion (potential deadlock) - fcount_incr vs. ...2019-12-12T11:38:28ZOndřej SurýThreadSanitizer: lock-order-inversion (potential deadlock) - fcount_incr vs. dns_resolver_createfetch```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=21211)
Cycle in lock order graph: M1110 (0x7b7400000008) => M1728 (0x7b4c000001d0) => M1110
Mutex M1728 acquired here while holding mutex M1110 in main thr...```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=21211)
Cycle in lock order graph: M1110 (0x7b7400000008) => M1728 (0x7b4c000001d0) => M1110
Mutex M1728 acquired here while holding mutex M1110 in main thread:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 fcount_incr /home/ondrej/Projects/bind9/lib/dns/resolver.c:1525 (libdns.so.1505+0x185598)
#2 fctx_create /home/ondrej/Projects/bind9/lib/dns/resolver.c:4925 (libdns.so.1505+0x190783)
#3 dns_resolver_createfetch /home/ondrej/Projects/bind9/lib/dns/resolver.c:10581 (libdns.so.1505+0x1976b1)
#4 start_fetch /home/ondrej/Projects/bind9/lib/dns/client.c:777 (libdns.so.1505+0x27d26a)
#5 client_resfind /home/ondrej/Projects/bind9/lib/dns/client.c:862 (libdns.so.1505+0x27d26a)
#6 dns_client_startresolve /home/ondrej/Projects/bind9/lib/dns/client.c:1388 (libdns.so.1505+0x281c0c)
#7 dns_client_resolve /home/ondrej/Projects/bind9/lib/dns/client.c:1249 (libdns.so.1505+0x283501)
#8 main /home/ondrej/Projects/bind9/bin/delv/delv.c:1788 (delv+0x5d92)
Mutex M1110 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_resolver_createfetch /home/ondrej/Projects/bind9/lib/dns/resolver.c:10538 (libdns.so.1505+0x196da5)
#2 start_fetch /home/ondrej/Projects/bind9/lib/dns/client.c:777 (libdns.so.1505+0x27d26a)
#3 client_resfind /home/ondrej/Projects/bind9/lib/dns/client.c:862 (libdns.so.1505+0x27d26a)
#4 dns_client_startresolve /home/ondrej/Projects/bind9/lib/dns/client.c:1388 (libdns.so.1505+0x281c0c)
#5 dns_client_resolve /home/ondrej/Projects/bind9/lib/dns/client.c:1249 (libdns.so.1505+0x283501)
#6 main /home/ondrej/Projects/bind9/bin/delv/delv.c:1788 (delv+0x5d92)
Mutex M1110 acquired here while holding mutex M1728 in main thread:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_resolver_shutdown /home/ondrej/Projects/bind9/lib/dns/resolver.c:10305 (libdns.so.1505+0x196844)
#2 view_flushanddetach /home/ondrej/Projects/bind9/lib/dns/view.c:582 (libdns.so.1505+0x1fc44d)
#3 dns_view_detach /home/ondrej/Projects/bind9/lib/dns/view.c:635 (libdns.so.1505+0x1fc53e)
#4 destroyclient /home/ondrej/Projects/bind9/lib/dns/client.c:611 (libdns.so.1505+0x2810ec)
#5 dns_client_destroy /home/ondrej/Projects/bind9/lib/dns/client.c:652 (libdns.so.1505+0x2810ec)
#6 main /home/ondrej/Projects/bind9/bin/delv/delv.c:1827 (delv+0x3bf2)
Mutex M1728 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_resolver_shutdown /home/ondrej/Projects/bind9/lib/dns/resolver.c:10300 (libdns.so.1505+0x196777)
#2 view_flushanddetach /home/ondrej/Projects/bind9/lib/dns/view.c:582 (libdns.so.1505+0x1fc44d)
#3 dns_view_detach /home/ondrej/Projects/bind9/lib/dns/view.c:635 (libdns.so.1505+0x1fc53e)
#4 destroyclient /home/ondrej/Projects/bind9/lib/dns/client.c:611 (libdns.so.1505+0x2810ec)
#5 dns_client_destroy /home/ondrej/Projects/bind9/lib/dns/client.c:652 (libdns.so.1505+0x2810ec)
#6 main /home/ondrej/Projects/bind9/bin/delv/delv.c:1827 (delv+0x3bf2)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/usr/lib/x86_64-linux-gnu/libtsan.so.0+0x3d62b) in pthread_mutex_lock
```December 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1469ThreadSanitizer: lock-order-inversion (potential deadlock) - isc__nm_enqueue_...2019-12-12T13:13:50ZOndřej SurýThreadSanitizer: lock-order-inversion (potential deadlock) - isc__nm_enqueue_ievent vs isc_nm_listentcp```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=18511)
Cycle in lock order graph: M596862637233476224 (0x000000000000) => M1105 (0x7fbaf719dcd0) => M596862637233476224
Mutex M1105 acquired here while hol...```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=18511)
Cycle in lock order graph: M596862637233476224 (0x000000000000) => M1105 (0x7fbaf719dcd0) => M596862637233476224
Mutex M1105 acquired here while holding mutex M596862637233476224 in thread T9:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 isc__nm_enqueue_ievent /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:601 (libisc.so.1504+0x3f20c)
#2 isc_nm_listentcp /home/ondrej/Projects/bind9/lib/isc/netmgr/tcp.c:190 (libisc.so.1504+0x452ab)
#3 isc_nm_listentcpdns /home/ondrej/Projects/bind9/lib/isc/netmgr/tcpdns.c:299 (libisc.so.1504+0x4899f)
#4 ns_interface_listentcp /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:463 (libns.so.1502+0x1b0d3)
#5 ns_interface_setup /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:516 (libns.so.1502+0x1b0d3)
#6 do_scan /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:1070 (libns.so.1502+0x1c023)
#7 ns_interfacemgr_scan0 /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:1130 (libns.so.1502+0x1c8fd)
#8 ns_interfacemgr_scan /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:1177 (libns.so.1502+0x1ca72)
#9 load_configuration server.c:8712 (named+0x53e83)
#10 run_server server.c:9654 (named+0x59a47)
#11 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#12 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#13 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M596862637233476224 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 isc_nm_listentcp /home/ondrej/Projects/bind9/lib/isc/netmgr/tcp.c:189 (libisc.so.1504+0x4526b)
#2 isc_nm_listentcpdns /home/ondrej/Projects/bind9/lib/isc/netmgr/tcpdns.c:299 (libisc.so.1504+0x4899f)
#3 ns_interface_listentcp /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:463 (libns.so.1502+0x1b0d3)
#4 ns_interface_setup /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:516 (libns.so.1502+0x1b0d3)
#5 do_scan /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:1070 (libns.so.1502+0x1c023)
#6 ns_interfacemgr_scan0 /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:1130 (libns.so.1502+0x1c8fd)
#7 ns_interfacemgr_scan /home/ondrej/Projects/bind9/lib/ns/interfacemgr.c:1177 (libns.so.1502+0x1ca72)
#8 load_configuration server.c:8712 (named+0x53e83)
#9 run_server server.c:9654 (named+0x59a47)
#10 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#11 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#12 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M596862637233476224 acquired here while holding mutex M1105 in thread T3:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 isc__nm_async_tcplisten /home/ondrej/Projects/bind9/lib/isc/netmgr/tcp.c:338 (libisc.so.1504+0x44e9b)
#2 process_queue /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:538 (libisc.so.1504+0x41fd5)
#3 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:438 (libisc.so.1504+0x422b1)
#4 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M1105 previously acquired by the same thread here:
#0 pthread_cond_wait <null> (libtsan.so.0+0x48e9e)
#1 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:435 (libisc.so.1504+0x4228e)
#2 <null> <null> (libtsan.so.0+0x29b3d)
Thread T9 'isc-worker0000' (tid=18534, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410 (libisc.so.1504+0x59cf3)
#3 create_managers main.c:902 (named+0x1aeec)
#4 setup main.c:1235 (named+0x1aeec)
#5 main main.c:1515 (named+0x1aeec)
Thread T3 'isc-net-0002' (tid=18528, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_nm_start /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:149 (libisc.so.1504+0x3ec4a)
#3 create_managers main.c:895 (named+0x1ae90)
#4 setup main.c:1235 (named+0x1ae90)
#5 main main.c:1515 (named+0x1ae90)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/usr/lib/x86_64-linux-gnu/libtsan.so.0+0x3d62b) in pthread_mutex_lock
```December 2019 (9.11.14, 9.14.9, 9.15.7)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1466kasp system test sometimes create suspicious 00000 key id2020-01-23T08:15:20ZMatthijs Mekkingmatthijs@isc.orgkasp system test sometimes create suspicious 00000 key id```
I:kasp:check number of keys with algorithm 13 for zone step2.zsk-prepub.autosign in dir ns3 (299)
I:kasp:check key 49751
I:kasp:check key 00000
I:kasp:failed
I:kasp:check key 03140
I:kasp:error: No KEY2 found for zone step2.zsk-prepu...```
I:kasp:check number of keys with algorithm 13 for zone step2.zsk-prepub.autosign in dir ns3 (299)
I:kasp:check key 49751
I:kasp:check key 00000
I:kasp:failed
I:kasp:check key 03140
I:kasp:error: No KEY2 found for zone step2.zsk-prepub.autosign
I:kasp:failed
```December 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1465idna system test failing on centos[67] (v9_11)2019-12-11T09:24:04ZMark Andrewsidna system test failing on centos[67] (v9_11)Job [#459966](https://gitlab.isc.org/isc-projects/bind9/-/jobs/459966) failed for 614bc25b901006051d0cfc6e14087e87ab3bf30d:
```
I:idna:Checking invalid input U-label (41)
I:idna:Checking invalid input U-label: +noidnin +noidnout (42)
I:...Job [#459966](https://gitlab.isc.org/isc-projects/bind9/-/jobs/459966) failed for 614bc25b901006051d0cfc6e14087e87ab3bf30d:
```
I:idna:Checking invalid input U-label (41)
I:idna:Checking invalid input U-label: +noidnin +noidnout (42)
I:idna:Checking invalid input U-label: +noidnin +idnout (43)
I:idna:Checking invalid input U-label: +idnin +noidnout (44)
I:idna:failed: dig command unexpectedly succeeded
I:idna:Checking invalid input U-label: +idnin +idnout (45)
```
idn_locale_to_ace is not failing on invalid input.
```
% more *44
; <<>> DiG 9.11.13 <<>> -i -p 8700 @10.53.0.1 +idnin +noidnout 🧦.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18972
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0290622b9447012620106a855ded889488bee751228b272a (good)
;; QUESTION SECTION:
;xn--wv9h.com. IN A
;; AUTHORITY SECTION:
. 300 IN SOA gson.nominum.com. a.root.servers.nil. 2000042100 600 600 1200 600
;; Query time: 0 msec
;; SERVER: 10.53.0.1#8700(10.53.0.1)
;; WHEN: Sun Dec 08 23:34:44 UTC 2019
;; MSG SIZE rcvd: 135
% more *45
/builds/isc-projects/bind9/bin/dig/.libs/lt-dig: 'xn--wv9h.com.' is not a legal IDNA2008 name (string contains a disallowed character), use +noidnout
%
```December 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1460checkconf test failure on Solaris2020-01-23T08:17:49ZWitold Krecickicheckconf test failure on SolarisThere seems to be something wrong with interval parser/printer:
```
--- good-kasp.conf.in 2019-12-06 09:05:30.604845787 +0000
+++ good-kasp.conf.out 2019-12-06 09:05:30.614674414 +0000
@@ -1,5 +1,5 @@
dnssec-policy "test" {
- d...There seems to be something wrong with interval parser/printer:
```
--- good-kasp.conf.in 2019-12-06 09:05:30.604845787 +0000
+++ good-kasp.conf.out 2019-12-06 09:05:30.614674414 +0000
@@ -1,5 +1,5 @@
dnssec-policy "test" {
- dnskey-ttl 3600;
+ dnskey-ttl 3600PT3600S;
keys {
ksk key-directory lifetime P1Y algorithm 13 256;
zsk key-directory lifetime P30D algorithm 13;
@@ -10,9 +10,9 @@
signatures-refresh P3D;
signatures-validity P2W;
signatures-validity-dnskey P14D;
- zone-max-ttl 86400;
+ zone-max-ttl 86400PT86400S;
zone-propagation-delay PT5M;
- parent-ds-ttl 7200;
+ parent-ds-ttl 7200PT7200S;
parent-propagation-delay PT1H;
parent-registration-delay P1D;
};
```December 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1458Intermittent failure in the forward system test2019-12-09T17:15:55ZOndřej SurýIntermittent failure in the forward system test```
T:forward:1:A
A:forward:System test forward
I:forward:PORTRANGE:8200 - 8299
I:forward:checking that a forward zone overrides global forwarders
I:forward:checking that a forward first zone no forwarders recurses
I:forward:checking tha...```
T:forward:1:A
A:forward:System test forward
I:forward:PORTRANGE:8200 - 8299
I:forward:checking that a forward zone overrides global forwarders
I:forward:checking that a forward first zone no forwarders recurses
I:forward:checking that a forward only zone no forwarders fails
I:forward:checking that global forwarders work
I:forward:checking that a forward zone works
I:forward:checking that forwarding doesn't spontaneously happen
I:forward:checking that a forward zone with no specified policy works
I:forward:checking that a forward only doesn't recurse
I:forward:checking for negative caching of forwarder response
I:forward:checking that forward only zone overrides empty zone
I:forward:checking that DS lookups for grafting forward zones are isolated
I:forward:checking that rfc1918 inherited 'forward first;' zones are warned about
I:forward:checking that ULA inherited 'forward first;' zones are warned about
I:forward:checking that a forwarder timeout prevents it from being reused in the same fetch context
I:forward:checking that priming queries are not forwarded
I:forward:failed
I:forward:checking recovery from forwarding to a non-recursive server
I:forward:exit status: 1
R:forward:FAIL
E:forward:Thu Dec 5 17:19:35 UTC 2019
```
Full CI job:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/455922December 2019 (9.11.14, 9.14.9, 9.15.7)Ondřej SurýOndřej Surý