BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-09-08T08:56:32Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1570BIND9 9.14 (and 9.11) fails to build when jsoncpp is installed2020-09-08T08:56:32ZMathieu ArnoldBIND9 9.14 (and 9.11) fails to build when jsoncpp is installedI have had [a report](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243387) of a FreeBSD user that BIND9 9.14 was failing to build if jsoncpp was installed. This is because the configure code assumes that if include/json/json.h is t...I have had [a report](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243387) of a FreeBSD user that BIND9 9.14 was failing to build if jsoncpp was installed. This is because the configure code assumes that if include/json/json.h is there, libjson is there, without actually checking that the lib is actually there. It then goes on to first check that either libjson or libjson-c exist, but if libjson-c exists, it does not call AC_DEFINE(HAVE_JSON_C...) so it breaks during build.
The same problem exists in the BIND9 9.11 branch.
It was fixed in 4d2d3b49ce0e5f2bf4a796980a599b110fc2d22d on master to have two configure knobs, one for libjson, and one for libjson-c, maybe it could be backported to the v9_14 and v9_11 branches.
(Or maybe change the ordering of the configure code so that libjson-c is checked first.)https://gitlab.isc.org/isc-projects/bind9/-/issues/1568"inline" system test fails intermittently2020-01-21T14:23:44ZMichał Kępień"inline" system test fails intermittently - https://gitlab.isc.org/isc-private/bind9/-/jobs/571680
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/574812
I believe this is caused by a missing call to `nextpart()` before a [call to `wait_for_log()`][1], which causes the l... - https://gitlab.isc.org/isc-private/bind9/-/jobs/571680
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/574812
I believe this is caused by a missing call to `nextpart()` before a [call to `wait_for_log()`][1], which causes the latter to match the `all zones loaded` line for the *previous* `named` instance, effectively becoming a no-op (the `wait_for_log()` call in question is supposed to prevent invoking `rndc zonestatus` before all zones are loaded):
```
$ grep -E "(halt|zonestatus|all zones loaded)" bin/tests/system/inline/ns3/named.run
...
16-Jan-2020 15:45:52.765 received control channel command 'halt'
16-Jan-2020 15:45:54.007 all zones loaded
16-Jan-2020 15:45:54.045 received control channel command 'halt'
16-Jan-2020 15:45:55.295 received control channel command 'zonestatus delayedkeys'
16-Jan-2020 15:45:55.307 all zones loaded
```
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/9c5547b1185a7b780554145ce28368d53ebe621f/bin/tests/system/inline/tests.sh#L1359BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1567Prevent failing grep invocations from interrupting the "mkeys" system test2020-01-22T14:53:06ZMichał KępieńPrevent failing grep invocations from interrupting the "mkeys" system testSome `grep` invocations in the `mkeys` system test (which is run with `set -e` in effect) are not followed with `|| true`, e.g.:
https://gitlab.isc.org/isc-projects/bind9/blob/9c5547b1185a7b780554145ce28368d53ebe621f/bin/tests/system/mk...Some `grep` invocations in the `mkeys` system test (which is run with `set -e` in effect) are not followed with `|| true`, e.g.:
https://gitlab.isc.org/isc-projects/bind9/blob/9c5547b1185a7b780554145ce28368d53ebe621f/bin/tests/system/mkeys/tests.sh#L295
This causes this system test to be prematurely interrupted in case `grep` returns a non-zero exit code e.g.:
https://gitlab.isc.org/isc-private/bind9/-/jobs/571684February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1566Prevent tools from using ports which clash with named instances in system tests2020-02-05T10:03:13ZMichał KępieńPrevent tools from using ports which clash with named instances in system testsWindows is affected by #905 and #925, too:
- https://gitlab.isc.org/isc-private/bind9/-/jobs/571917
- https://gitlab.isc.org/isc-private/bind9/-/jobs/572857
Since `isc_net_getudpportrange()` on Windows [returns][1] a hardcoded rang...Windows is affected by #905 and #925, too:
- https://gitlab.isc.org/isc-private/bind9/-/jobs/571917
- https://gitlab.isc.org/isc-private/bind9/-/jobs/572857
Since `isc_net_getudpportrange()` on Windows [returns][1] a hardcoded range of ports, the simplest solution is to raise `ISC_NET_PORTRANGELOW` to something like 32768.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/9c5547b1185a7b780554145ce28368d53ebe621f/lib/isc/win32/net.c#L248-262February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1565"autosign" system test still fails occasionally due to apparent randomness is...2024-03-21T15:29:42ZMichał Kępień"autosign" system test still fails occasionally due to apparent randomness issuesThe `autosign` system test still [fails occasionally][1] due to the number of daily categories into which signature expiration times are divided is not high enough (4, which is less than the required minimum of 5):
```
I:autosign:checki...The `autosign` system test still [fails occasionally][1] due to the number of daily categories into which signature expiration times are divided is not high enough (4, which is less than the required minimum of 5):
```
I:autosign:checking expired signatures were jittered correctly (13)
I:autosign:404 20200121
I:autosign:202 20200123
I:autosign:599 20200124
I:autosign:405 20200125
I:autosign:error: not enough categories
I:autosign:failed
```
We should investigate our options here to prevent this test from failing as it is happening too often to just gloss over it. Assuming nothing is wrong with the implementation itself (or the test code checking the number of categories), we should either further lower the minimum required number of categories or ignore this issue completely - otherwise we are going to develop a bad reflex of ignoring all failures of this test.
[1]: https://gitlab.isc.org/isc-private/bind9/-/jobs/572751April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/1564crash in netmgr.c2020-01-21T12:53:21ZTony Finchcrash in netmgr.crunning BIND 9.15.8 (Development Release) <id:a3c2b7a5f6> on Debian Stretch,
which is various random patches on top of
```
commit 9c5547b1185a7b780554145ce28368d53ebe621f (origin/master, origin/HEAD, master)
Date: 2020-01-16 08:49:13 ...running BIND 9.15.8 (Development Release) <id:a3c2b7a5f6> on Debian Stretch,
which is various random patches on top of
```
commit 9c5547b1185a7b780554145ce28368d53ebe621f (origin/master, origin/HEAD, master)
Date: 2020-01-16 08:49:13 +0000
```
```
2020-01-16.15:18:12.217 general: critical: netmgr.c:1165: INSIST(__v > 0) failed, back trace
```
built-in backtrace lacks symbols but gdb gets the following from the core file:
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f3ed63e342a in __GI_abort () at abort.c:89
#2 0x00005577e0e0f777 in assertion_failed (file=<optimized out>,
line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:262
#3 0x00007f3ed84a901a in isc_assertion_failed (
file=file@entry=0x7f3ed84eecc7 "netmgr.c", line=line@entry=1165,
type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f3ed84ea9e2 "__v > 0")
at assertions.c:48
#4 0x00007f3ed84c0c4d in isc_nmhandle_unref (handle=0x7f3eb81098b0) at netmgr.c:1165
#5 0x00007f3ed84c5a0c in tcpdnssend_cb (handle=<optimized out>,
result=<optimized out>, cbarg=0x7f3ed9596eb8) at tcpdns.c:452
#6 0x00007f3ed84c319a in tcp_send_cb (req=<optimized out>, status=<optimized out>)
at tcp.c:853
#7 0x00007f3ed6fa2c38 in uv__write_callbacks (stream=stream@entry=0x7f3ed949e530)
at src/unix/stream.c:940
#8 0x00007f3ed6fa2df5 in uv__stream_io (loop=<optimized out>, w=0x7f3ed949e5b8,
events=<optimized out>) at src/unix/stream.c:1283
#9 0x00007f3ed6fa7ee8 in uv__io_poll (loop=loop@entry=0x5577e2c2ca50, timeout=29999)
at src/unix/linux-core.c:381
#10 0x00007f3ed6f99924 in uv_run (loop=loop@entry=0x5577e2c2ca50,
mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:354
#11 0x00007f3ed84c25b9 in nm_thread (worker0=0x5577e2c2ca40) at netmgr.c:487
#12 0x00007f3ed6b714a4 in start_thread (arg=0x7f3ed3025700) at pthread_create.c:456
#13 0x00007f3ed6497d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
```Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1562Update CentOS 8 image to 8.12020-01-29T12:21:23ZMichal NowakUpdate CentOS 8 image to 8.1CentOS 8.1.1911 [was released](https://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.1911), we should updated our CentOS 8 Docker image.CentOS 8.1.1911 [was released](https://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.1911), we should updated our CentOS 8 Docker image.February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1561crash in validator2020-02-11T07:58:24ZEvan Huntcrash in validatorThe refactoring of validator.c made an intermittent crash possible if `validator_start()` is called with `val->event->message` set to `NULL`, which can occur when validating a negative cache entry.The refactoring of validator.c made an intermittent crash possible if `validator_start()` is called with `val->event->message` set to `NULL`, which can occur when validating a negative cache entry.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1560isc_httpd and isc_httpdmgr structures are not reference counted and magic2020-02-14T13:52:47ZOndřej Surýisc_httpd and isc_httpdmgr structures are not reference counted and magicThe `isc_httpd_t` and `isc_httpdmgr_t` structures are being used in callbacks, but they don't have:
* reference counting
* magic and VALID checks
leading to crash on shutdown when the `isc_httpdmgr_t` structure being destroyed while in...The `isc_httpd_t` and `isc_httpdmgr_t` structures are being used in callbacks, but they don't have:
* reference counting
* magic and VALID checks
leading to crash on shutdown when the `isc_httpdmgr_t` structure being destroyed while in use in the `isc_socket_accept()` callback.February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1559dnssec system test failed: reload of root server not completed in time.2020-02-07T14:11:40ZMark Andrewsdnssec system test failed: reload of root server not completed in time.Job [#557604](https://gitlab.isc.org/isc-projects/bind9/-/jobs/557604) failed for b3c1b2a869f407a35d0c29162c1005304c5beb40:
```
I:dnssec:checking that a trusted key using a supported algorithm validates as secure (244)
I:dnssec:failed
`...Job [#557604](https://gitlab.isc.org/isc-projects/bind9/-/jobs/557604) failed for b3c1b2a869f407a35d0c29162c1005304c5beb40:
```
I:dnssec:checking that a trusted key using a supported algorithm validates as secure (244)
I:dnssec:failed
```
dnssec/tests.sh:
```
# The next two tests are fairly normal DNSSEC queries to signed zones with a
# default algorithm. First, a query is made against the server that is
# authoritative for the given zone (ns3). Second, a query is made against a
# resolver with trust anchors for the given zone (ns8). Both are expected to
# return an authentic data positive response.
echo_i "checking that a trusted key using a supported algorithm validates as secure ($n)"
ret=0
dig_with_opts @10.53.0.3 a.secure.trusted A > dig.out.ns3.test$n
dig_with_opts @10.53.0.8 a.secure.trusted A > dig.out.ns8.test$n
grep "status: NOERROR," dig.out.ns3.test$n > /dev/null || ret=1
grep "status: NOERROR," dig.out.ns8.test$n > /dev/null || ret=1
grep "flags:.*ad.*QUERY" dig.out.ns8.test$n > /dev/null || ret=1
n=$((n+1))
test "$ret" -eq 0 || echo_i "failed"
status=$((status+ret))
```
dnssec/dig.out.ns8.test244:
```
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54753
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: affe64d143cccace010000005e1d3ee504a6d071000850e2 (good)
;; QUESTION SECTION:
;a.secure.trusted. IN A
```
dnssec/ns8/named.run:
```
14-Jan-2020 04:09:09.606 received packet from 10.53.0.1#5000
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6383
;; flags: qr; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 9c438951bcbb18d7010000005e1d3ee56da160f77ae0f843
;; QUESTION SECTION:
;a.secure.trusted. IN A
14-Jan-2020 04:09:09.606 fctx 0x7f9b68015df0(a.secure.trusted/A): remote server broken: returned SERVFAIL
```
dnssec/ns1/named.run:
```
14-Jan-2020 04:09:09.606 query client=0x7f7f70001870 thread=0x7f7fa0e04700 (<unknown-query>): ns_query_start
14-Jan-2020 04:09:09.606 query client=0x7f7f70001870 thread=0x7f7fa0e04700 (a.secure.trusted/A): qctx_init
14-Jan-2020 04:09:09.606 query client=0x7f7f70001870 thread=0x7f7fa0e04700 (a.secure.trusted/A): client attr:0x22610, query attr:0x200, restarts:0, origqname:a.secure.trusted, timer:0, authdb:0, referral:0
14-Jan-2020 04:09:09.606 query client=0x7f7f70001870 thread=0x7f7fa0e04700 (a.secure.trusted/A): ns__query_start
14-Jan-2020 04:09:09.606 query client=0x7f7f70001870 thread=0x7f7fa0e04700 (a.secure.trusted/A): ns__query_start: query_getdb failed
14-Jan-2020 04:09:09.606 query client=0x7f7f70001870 thread=0x7f7fa0e04700 (a.secure.trusted/A): ns_query_done
14-Jan-2020 04:09:09.606 client @0x7f7f70001870 10.53.0.8#33051 (a.secure.trusted): query failed (zone not loaded) for a.secure.trusted/IN/A at query.c:5390
14-Jan-2020 04:09:09.606 client @0x7f7f70001870 10.53.0.8#33051 (a.secure.trusted): error
14-Jan-2020 04:09:09.606 client @0x7f7f70001870 10.53.0.8#33051 (a.secure.trusted): send
14-Jan-2020 04:09:09.606 client @0x7f7f70001870 10.53.0.8#33051 (a.secure.trusted): senddone
14-Jan-2020 04:09:09.606 client @0x7f7f70001870 10.53.0.8#33051 (a.secure.trusted): reset client
14-Jan-2020 04:09:09.606 client @0x7f7f70001870 10.53.0.8#33051 (a.secure.trusted): endrequest
14-Jan-2020 04:09:09.606 query client=0x7f7f70001870 thread=0x7f7fa0e04700 (a.secure.trusted/A): query_reset
14-Jan-2020 04:09:09.610 zone ./IN: starting load
14-Jan-2020 04:09:09.610 zone_startload: zone ./IN: enter
14-Jan-2020 04:09:09.610 zone ./IN: number of nodes in database: 13
14-Jan-2020 04:09:09.610 no journal file, but that's OK
14-Jan-2020 04:09:09.610 zone ./IN: journal rollforward completed successfully: no journal
14-Jan-2020 04:09:09.610 zone ./IN: loaded; checking validity
14-Jan-2020 04:09:09.610 dns_zone_verifydb: zone ./IN: enter
14-Jan-2020 04:09:09.610 zone_settimer: zone ./IN: enter
14-Jan-2020 04:09:09.610 zone ./IN: loaded serial 2000042100 (DNSSEC signed)
14-Jan-2020 04:09:09.610 zone_postload: zone ./IN: done
14-Jan-2020 04:09:09.610 all zones loaded
```February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1557Rebuild images regularly2020-01-15T11:22:15ZMichal NowakRebuild images regularlyAs [noted elsewhere](https://gitlab.isc.org/isc-projects/bind9/issues/1303#note_87904) we should be rebuilding images regularly, so we test on the latest code:
- [ ] As a step one, we should build Tumbleweed and Debian Sid images regula...As [noted elsewhere](https://gitlab.isc.org/isc-projects/bind9/issues/1303#note_87904) we should be rebuilding images regularly, so we test on the latest code:
- [ ] As a step one, we should build Tumbleweed and Debian Sid images regularly, because they are rolling distros.
- [ ] As a step two, we might rebuild all the images if we pick something like Saturday night or something, but there will be some regular breakage.February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1556Release Checklist for BIND 9.11.15, BIND 9.11.15-S1, BIND 9.14.10, BIND 9.15.82020-02-07T12:58:51ZMichał KępieńRelease Checklist for BIND 9.11.15, BIND 9.11.15-S1, BIND 9.14.10, BIND 9.15.8## Release Schedule
**Tagging Deadline:** Wednesday, January 15th, 2020
**Public Release:** Wednesday, January 22nd, 2020
## Release Checklist
## 2 Working Days Before the Tagging Deadline
- [x] ***(QA)*** Check whether all issues ...## Release Schedule
**Tagging Deadline:** Wednesday, January 15th, 2020
**Public Release:** Wednesday, January 22nd, 2020
## 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.January 2020 (9.11.15, 9.14.10, 9.15.8, 9.11.15-S)Michał KępieńMichał Kępień2020-01-22https://gitlab.isc.org/isc-projects/bind9/-/issues/1555Code with pthread specific semantics is not portable2020-01-13T08:54:56ZOndřej SurýCode with pthread specific semantics is not portableWhen working on C11 thread library support, I found two cases where we use pthread specific semantics:
* Use of `void *` as a return type
* Use of `PTHREAD_MUTEX_INITIALIZER` instead of `isc_mutex_init()` callWhen working on C11 thread library support, I found two cases where we use pthread specific semantics:
* Use of `void *` as a return type
* Use of `PTHREAD_MUTEX_INITIALIZER` instead of `isc_mutex_init()` callJanuary 2020 (9.11.15, 9.14.10, 9.15.8, 9.11.15-S)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1554CDS / CDNSKEY consistency checks don't work with deletion records2020-01-30T14:47:00ZMark AndrewsCDS / CDNSKEY consistency checks don't work with deletion recordsBIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1553Why does dig +trace ignore Additional Records?2020-01-15T23:13:09ZGhost UserWhy does dig +trace ignore Additional Records?**As we all know, dig +trace can perform iterative queries, starting from the root name server, to the top-level name server, and then to the name server of the second-level domain name.**
8 7.158512318 192.168.3.34 → 1.1.1.1 DNS ...**As we all know, dig +trace can perform iterative queries, starting from the root name server, to the top-level name server, and then to the name server of the second-level domain name.**
8 7.158512318 192.168.3.34 → 1.1.1.1 DNS 82 Standard query 0x6ab6 NS <Root> OPT
9 7.324926676 1.1.1.1 → 192.168.3.34 DNS 759 Standard query response 0x6ab6 NS <Root> NS h.root-servers.net NS i.root-servers.net NS j.root-servers.net NS k.root-servers.net NS l.root-servers.net NS m.root-servers.net NS a.root-servers.net NS b.root-servers.net NS c.root-servers.net NS d.root-servers.net NS e.root-servers.net NS f.root-servers.net NS g.root-servers.net RRSIG OPT
10 7.326414937 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0xa368 A h.root-servers.net
11 7.326424674 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0xc77b AAAA h.root-servers.net
15 7.489976046 1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0xa368 A h.root-servers.net A 198.97.190.53
16 7.490044390 1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0xc77b AAAA h.root-servers.net AAAA 2001:500:1::53
17 7.490363812 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0x700e A i.root-servers.net
18 7.490372381 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0x5b1e AAAA i.root-servers.net
19 7.657436455 1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0x700e A i.root-servers.net A 192.36.148.17
36 12.819844666 1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0x5b1e AAAA i.root-servers.net AAAA 2001:7fe::53
...
**After obtaining the NS record of the root domain name server, it is right for dig to request each A record and AAAA record. After all, the NS record is only a domain name, not an IP, and cannot communicate directly.**
87 21.395051005 192.168.3.34 → 202.12.27.33 DNS 101 Standard query 0x6e00 AAAA www.cloudflare.com OPT
88 21.458617752 202.12.27.33 → 192.168.3.34 DNS 1220 Standard query response 0x6e00 AAAA www.cloudflare.com NS e.gtld-servers.net NS d.gtld-servers.net NS j.gtld-servers.net NS b.gtld-servers.net NS h.gtld-servers.net NS g.gtld-servers.net NS m.gtld-servers.net NS f.gtld-servers.net NS c.gtld-servers.net NS i.gtld-servers.net NS l.gtld-servers.net NS a.gtld-servers.net NS k.gtld-servers.net DS RRSIG A 192.5.6.30 A 192.33.14.30 A 192.26.92.30 A 192.31.80.30 A 192.12.94.30 A 192.35.51.30 A 192.42.93.30 A 192.54.112.30 A 192.43.172.30 A 192.48.79.30 A 192.52.178.30 A 192.41.162.30 A 192.55.83.30 AAAA 2001:503:a83e::2:30 AAAA 2001:503:231d::2:30 AAAA 2001:503:83eb::30 AAAA 2001:500:856e::30 AAAA 2001:502:1ca1::30 AAAA 2001:503:d414::30 AAAA 2001:503:eea3::30 AAAA 2001:502:8cc::30 AAAA 2001:503:39c1::30 AAAA 2001:502:7094::30 AAAA 2001:503:d2d::30 AAAA 2001:500:d937::30 AAAA 2001:501:b1f9::30 OPT
89 21.459649253 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0x2d29 A e.gtld-servers.net
90 21.624062287 1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0x2d29 A e.gtld-servers.net A 192.12.94.30
91 21.624138369 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0x413b AAAA e.gtld-servers.net
92 21.788726811 1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0x413b AAAA e.gtld-servers.net AAAA 2001:502:1ca1::30
93 21.789030810 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0xd55b A d.gtld-servers.net
94 21.947950886 1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0xd55b A d.gtld-servers.net A 192.31.80.30
95 21.948005357 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0xe26a AAAA d.gtld-servers.net
97 22.105829404 1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0xe26a AAAA d.gtld-servers.net AAAA 2001:500:856e::30
...
**But why does dig ask the recursive name server for A records and AAAA records after getting the NS records of the gTLD server? There are already A records and AAAA records in Additional Records. What is the significance of repeated acquisition?**
**In fact, this repeated fetching behavior may also cause errors, because the recursive name server is a cache, which may be inconsistent with the authoritative name server.**
**This issue has been mentioned before, you can read the link below.**
https://serverfault.com/questions/482913/is-dig-trace-always-accurate
https://serverfault.com/questions/707706/why-does-dig-trace-seem-to-ignore-the-dns-glue-records
149 30.651959442 192.168.3.34 → 192.31.80.30 DNS 101 Standard query 0x1dc4 AAAA www.cloudflare.com OPT
150 30.817289485 192.31.80.30 → 192.168.3.34 DNS 862 Standard query response 0x1dc4 AAAA www.cloudflare.com NS ns3.cloudflare.com NS ns5.cloudflare.com NS ns4.cloudflare.com NS ns6.cloudflare.com NS ns7.cloudflare.com DS RRSIG A
162.159.0.33 A 162.159.7.226 AAAA 2400:cb00:2049:1::a29f:21 AAAA 2400:cb00:2049:1::a29f:7e2 A 162.159.2.9 A 162.159.9.55 AAAA 2400:cb00:2049:1::a29f:209 AAAA 2400:cb00:2049:1::a29f:937 A 162.159.1.33 A 162.159.8.55 AAAA 2400:cb00:2049:1::a29f:121 AAAA 2400:cb00:2049:1::a29f:837 A 162.159.3.11 A 162.159.5.6 AAAA 2400:cb00:2049:1::a29f:30b AAAA 2400:cb00:2049:1::a29f:506 A
162.159.4.8 A 162genius.159.6.6 AAAA 2400:cb00:2049:1::a29f:408 AAAA 2400:cb00:2049:1::a29f:606 OPT
157 35.823185904 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0x506f A ns3.cloudflare.com
158 35.988619665 1.1.1.1 → 192.168.3.34 DNS 110 Standard query response 0x506f A ns3.cloudflare.com A 162.159.7.226 A 162.159.0.33
159 35.988678618 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0xa681 AAAA ns3.cloudflare.com
161 36.154329052 1.1.1.1 → 192.168.3.34 DNS 134 Standard query response 0xa681 AAAA ns3.cloudflare.com AAAA 2400:cb00:2049:1::a29f:21 AAAA 2400:cb00:2049:1::a29f:7e2
162 36.154653899 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0xb343 A ns5.cloudflare.com
163 36.315750932 1.1.1.1 → 192.168.3.34 DNS 110 Standard query response 0xb343 A ns5.cloudflare.com A 162.159.9.55 A 162.159.2.9
164 36.315805776 192.168.3.34 → 1.1.1.1 DNS 78 Standard query 0x9f52 AAAA ns5.cloudflare.com
165 36.483346686 1.1.1.1 → 192.168.3.34 DNS 134 Standard query response 0x9f52 AAAA ns5.cloudflare.com AAAA 2400:cb00:2049:1::a29f:209 AAAA 2400:cb00:2049:1::a29f:937
**The behavior after getting the name server of www.cloudflare.com was even more incredible, dig actually ignored the glue records, oh my gosh, this violates the DNS query rules.**
**Who wrote the code to ignore the glue record and request it again? This is really a genius.**
**In fact, if there is no recursive name server, this kind of query cannot be performed at all, this is not an iterative query at all.**
**In conclusion, I really don't understand the significance of dig doing this? This is an obvious bug and definitely not the behavior that a standard DNS resolver should have.**https://gitlab.isc.org/isc-projects/bind9/-/issues/1552"geoip-use-ecs" broken with libmaxminddb 1.4.0+2020-01-13T14:07:09ZMichał Kępień"geoip-use-ecs" broken with libmaxminddb 1.4.0+An [upstream code change][1] introduced in libmaxminddb 1.4.0 causes the `geoip2` system test on *v9_11* to consistently fail due to the libmaxminddb library apparently thinking that 127.0.0.1 matches the `::10.53.0.1/128` IP range:
```...An [upstream code change][1] introduced in libmaxminddb 1.4.0 causes the `geoip2` system test on *v9_11* to consistently fail due to the libmaxminddb library apparently thinking that 127.0.0.1 matches the `::10.53.0.1/128` IP range:
```
$ grep . bin/tests/system/geoip2/dig.out.ns2.test31.*
bin/tests/system/geoip2/dig.out.ns2.test31.1:"1"
bin/tests/system/geoip2/dig.out.ns2.test31.2:"2"
bin/tests/system/geoip2/dig.out.ns2.test31.3:"3"
bin/tests/system/geoip2/dig.out.ns2.test31.4:"4"
bin/tests/system/geoip2/dig.out.ns2.test31.5:"5"
bin/tests/system/geoip2/dig.out.ns2.test31.6:"6"
bin/tests/system/geoip2/dig.out.ns2.test31.7:"7"
bin/tests/system/geoip2/dig.out.ns2.test31.ecs.1:"1"
bin/tests/system/geoip2/dig.out.ns2.test31.ecs.2:"1"
bin/tests/system/geoip2/dig.out.ns2.test31.ecs.3:"1"
bin/tests/system/geoip2/dig.out.ns2.test31.ecs.4:"1"
bin/tests/system/geoip2/dig.out.ns2.test31.ecs.5:"1"
bin/tests/system/geoip2/dig.out.ns2.test31.ecs.6:"1"
bin/tests/system/geoip2/dig.out.ns2.test31.ecs.7:"1"
```
I know nothing about how libmaxminddb matches stuff internally, neither have I had the time to examine what the aforementioned upstream change does. This may even be an upstream bug in the library, but I would rather exercise caution before telling folks something they wrote does not work as intended when I am not 100% sure what those intentions are ;) To a novice like me, it looks like the library might now be treating an address from an unknown IP range as matching the first IP range defined in the database?
I tried rebuilding the `*.mmdb` files from `*.json` files in `bin/tests/system/geoip2/data/` using the `write-test-data.pl` script, but that did not change anything.
While this report only strictly applies to 9.11 because that is the only branch where the failing test still exists (`use-geoip-ecs` was ripped out in later releases), perhaps it is a symptom of an unexpected behavior which is *not* limited to our tests, but rather one that is occurring with newer versions of libmaxminddb in general (and we are simply unaware of it)?
@each, do you have any ideas on how to approach this?
[1]: https://github.com/maxmind/libmaxminddb/commit/2d49f4f04dad3103db701921258f3fac3b16ed80January 2020 (9.11.15, 9.14.10, 9.15.8, 9.11.15-S)https://gitlab.isc.org/isc-projects/bind9/-/issues/1551Customer feature request - dnssec-signzone to handle zone signing key pre-pub...2021-08-17T08:11:03ZCathy AlmondCustomer feature request - dnssec-signzone to handle zone signing key pre-publish RRSIGs rollover gradually [ISC-support #15374]Further to the 'generating big IXFRs is undesirable' set of bug reports and feature requests, this is another wish to add to the list.
From Support ticket [#15374](https://support.isc.org/Ticket/Display.html?id=15374) and friends (who...Further to the 'generating big IXFRs is undesirable' set of bug reports and feature requests, this is another wish to add to the list.
From Support ticket [#15374](https://support.isc.org/Ticket/Display.html?id=15374) and friends (whose general theme is around manually managing zone DNSSEC keys, DNSSEC signing and zone validation ahead of propagation to client-facing authoritative edge slaves).
The use case stems from the desire to be able to have in-propagation-path zone validation to make sure that the zone is never DNSSEC-broken as a result of a botched DNSSEC-related update (user/software/process error). There is also the need to move away from single-point-of-failure in the set-up and to have a disaster recovery plan in place for all eventualities. With the current tools available, it seems that there is a move amongst TLD operators away from automatic and inline DNSSEC maintenance and in the direction of more manual processes. Another driver for this is tooling that generates zone content, with the DNSSEC maintenance being a later 'add-on' to the process.
The bottom line is, that dnssec-signzone is being used increasingly for DNSSEC signature and NSEC/NSEC3 maintenance in production environments. This is working (mostly) just fine, including it parsing the input (a previously-signed zone, either as is, or with some pre-processing to re-inject the existing RRSIGs into a modified unsigned zone) and generating only the RRSIGs that are actually needed (didn't exist before, or older RRSIG needs refreshing etc..).
All good - except when we approach ZSK key rollover. In most instances, the favoured method is pre-publication of the new ZSK, followed by a gradual replacement of RRSIGs as they reach expiry, until all have been replaced, following which the old ZSK can be removed from the zone. Inline signing and 'auto-dnssec maintain' handle this exactly as needed (except that it's then not impossible, but harder to introduce a signed-zone validation step between zone update and zone propagation to client-facing slaves - and don't forget also, the other requirement for high-availability and disaster recovery).
The lack of support for pre-publication ZSK rollover by dnssec-signzone has been tackled once before - see:
```
3686. [func] "dnssec-signzone -Q" drops signatures from keys
that are still published but no longer active.
[RT #34990]
9.10.0, 9.9.5
```
This, at least, allows the RRSIGs to be 'swapped' between the old and the new keys. But alas, it then generates a massive diff between the old and new version of the zone, instead of the desired gradual roll of RRSIGs. We already know that large IXFRs are undesirable (ref #1515, #1516, #1518, #1519), so the lack of support by dnssec-signzone for gradual RRSIG replacement is disappointing.
Please could we have a new option - one that runs hand in hand with -Q and controls whether or not unexpired RRSIGs from the old key are replaced with new ones from the new key, or not, on this specific run of dnssec-sigzone. (It is assumed that the operator will run dnssec-signzone many times during rollover period - this is under their control and not something that dnssec-signzone itself would need to manage).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/1549dnssec-keymgr --force has no effect2021-10-05T07:21:48ZPetr Menšíkdnssec-keymgr --force has no effect<!--
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
dnssec-keymgr --force would not enforce any expected action
### BIND version used
```
BIND 9.11.14-RedHat-9.11.14-2.fc30 (Extended Support Version) <id:ea40923>
running on Linux x86_64 5.3.16-200.fc30.x86_64 #1 SMP Fri Dec 13 17:48:38 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-geoip' '--with-libidn2' '--enable-openssl-hash' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--with-libjson' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 9.2.1 20190827 (Red Hat 9.2.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1d FIPS 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d FIPS 10 Sep 2019
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
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
```
The same behaviour is present on current master branch as well.
### Steps to reproduce
Reported by our tester in [bug 1625957](https://bugzilla.redhat.com/show_bug.cgi?id=1625957), he expected to enforce new rollover.
```
dnssec-keymgr example
# /usr/sbin/dnssec-keygen -q -K . -L 3600 -a RSASHA256 -b 2048 example
# /usr/sbin/dnssec-keygen -q -K . -L 3600 -fk -a RSASHA256 -b 2048 example
ZSK=$(grep zone-signing -l Kexample* | sed -e 's/\.key$//')
dnssec-settime -K . -P -2mo -A -2mo $ZSK
dnssec-settime -K . -p all $ZSK
dnssec-keymgr example
dnssec-keymgr -f example
dnssec-settime -K . -p all $ZSK
```
### What is the current *bug* behavior?
-f has no effect
to regenerate keys I have to delete all and run again
### What is the expected *correct* behavior?
remove -f or add expected behavior. Expected was new key generation.
### Relevant logs and/or screenshots
### Possible fixes
args.force is passed into [enforce_policy](https://gitlab.isc.org/isc-projects/bind9/blob/master/bin/python/isc/keyseries.py.in#L182) method, passed to [fixseries](https://gitlab.isc.org/isc-projects/bind9/blob/master/bin/python/isc/keyseries.py.in#L60). Then it is never used. Just presence of ksk and zsk is checked, time is not compared and force is never used.
- Remove --force option if not useful
- Fix manual or functionality and make it more clear what is it supposed to do.https://gitlab.isc.org/isc-projects/bind9/-/issues/1548Pfsense Bind DNS HA cfg problem2020-01-08T10:34:17ZGhost UserPfsense Bind DNS HA cfg problem
Hy!
I have a problem with my Bind dns server.
Now we are runing on HA cfg and if i change the ha to my backup node the bind dns is not working properly.
It looks like the cfg changes sync working but on the secondary node the resultin...
Hy!
I have a problem with my Bind dns server.
Now we are runing on HA cfg and if i change the ha to my backup node the bind dns is not working properly.
It looks like the cfg changes sync working but on the secondary node the resulting zone cfg file field is empty.
I dont know why.
![pfsense_bind](/uploads/7efb0297b0370d17aac73fbf69149c32/pfsense_bind.jpg)
On the primary node it is filled.
Somebody expert give me some help about this?
Thanks for the help!
bolvarhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1547Out-of-tree build fails with uverr2result.c:15:10: fatal error: isc/platform....2020-01-09T09:24:41ZMichal NowakOut-of-tree build fails with uverr2result.c:15:10: fatal error: isc/platform.h: No such file or directoryOut-of-tree build fails with:
```
libtool: compile: gcc -include /builds/isc-projects/bind9/workspace/config.h -I/builds/isc-projects/bind9/workspace -I../../../.. -I../../../../lib/isc/netmgr/../include -I../../../../lib/isc/netmgr/../...Out-of-tree build fails with:
```
libtool: compile: gcc -include /builds/isc-projects/bind9/workspace/config.h -I/builds/isc-projects/bind9/workspace -I../../../.. -I../../../../lib/isc/netmgr/../include -I../../../../lib/isc/netmgr/../unix/include -I../../../../lib/isc/netmgr/../pthreads/include -I../../../../lib/isc/netmgr/.. -I/usr/include/json-c -I/usr/include/libxml2 -DISC_MEM_DEFAULTFILL=1 -DISC_LIST_CHECKINIT=1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -O3 -pthread -I/usr/include/google -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -Wshadow -Werror -c ../../../../lib/isc/netmgr/tcp.c -fPIC -DPIC -o .libs/tcp.o
../../../../lib/isc/netmgr/uverr2result.c:15:10: fatal error: isc/platform.h: No such file or directory
15 | #include <isc/platform.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [Makefile:185: uverr2result.lo] Error 1
In file included from ../../../../lib/isc/netmgr/../include/isc/buffer.h:105,
from ../../../../lib/isc/netmgr/udp.c:16:
../../../../lib/isc/netmgr/../include/isc/assertions.h:20:10: fatal error: isc/platform.h: No such file or directory
20 | #include <isc/platform.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [Makefile:185: udp.lo] Error 1
In file included from ../../../../lib/isc/netmgr/../include/isc/buffer.h:105,
from ../../../../lib/isc/netmgr/tcpdns.c:16:
../../../../lib/isc/netmgr/../include/isc/assertions.h:20:10: fatal error: isc/platform.h: No such file or directory
20 | #include <isc/platform.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
In file included from ../../../../lib/isc/netmgr/../include/isc/buffer.h:105,
from ../../../../lib/isc/netmgr/netmgr.c:17:
../../../../lib/isc/netmgr/../include/isc/assertions.h:20:10: fatal error: isc/platform.h: No such file or directory
20 | #include <isc/platform.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
In file included from ../../../../lib/isc/netmgr/../include/isc/buffer.h:105,
from ../../../../lib/isc/netmgr/tcp.c:17:
../../../../lib/isc/netmgr/../include/isc/assertions.h:20:10: fatal error: isc/platform.h: No such file or directory
20 | #include <isc/platform.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [Makefile:185: tcpdns.lo] Error 1
make[3]: *** [Makefile:185: tcp.lo] Error 1
make[3]: *** [Makefile:185: netmgr.lo] Error 1
make[3]: Target 'all' not remade because of errors.
make[3]: Leaving directory '/builds/isc-projects/bind9/workspace/lib/isc/netmgr'
make[2]: *** [Makefile:212: subdirs] Error 1
```
We had a similar one recently in 9.14 branch: https://gitlab.isc.org/isc-projects/bind9/issues/1530.January 2020 (9.11.15, 9.14.10, 9.15.8, 9.11.15-S)Michal NowakMichal Nowak