BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-01-05T16:13:28Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/81shorten allow_query system test2020-01-05T16:13:28ZEvan Huntshorten allow_query system testThis test takes a long time because the name server needs to be reconfigured fifty-odd times with different combinations of allow-query ACLs. Between each reconfiguration we sleep for a few seconds.
I propose instead setting up ns1 thor...This test takes a long time because the name server needs to be reconfigured fifty-odd times with different combinations of allow-query ACLs. Between each reconfiguration we sleep for a few seconds.
I propose instead setting up ns1 thorugh ns8, each of which would have eight views, listening for different source addresses. If you send a query from 10.53.0.1->10.53.0.1 you get one configuration; 10.53.0.1->10.53.0.2 gets a different one, and so forth up to 10.53.0.8->10.53.0.8. This would give us 64 configurations we can test without having to reconfigure and sleep, and probably reduce the runtime to a few seconds.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/79Add working directory to example in doc/dev/dev.md2018-03-19T22:21:25ZGhost UserAdd working directory to example in doc/dev/dev.mdAdd missing working directory to example in doc/dev/dev.md, as it is usually not set in path.
(This is my gitlab test ticket.)Add missing working directory to example in doc/dev/dev.md, as it is usually not set in path.
(This is my gitlab test ticket.)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/71xfer system test fails intermittently2018-02-25T21:41:10ZMichał Kępieńxfer system test fails intermittentlyOne failure has been observed so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1180
```
S:xfer:Fri Feb 16 12:14:54 UTC 2018
T:xfer:1:A
A:System test xfer
I:testing basic zone transfer functionality
I:testing TSIG signed zone ...One failure has been observed so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1180
```
S:xfer:Fri Feb 16 12:14:54 UTC 2018
T:xfer:1:A
A:System test xfer
I:testing basic zone transfer functionality
I:testing TSIG signed zone transfers
I:reload servers for in preparation for ixfr-from-differences tests
I:ns1 server reload successful
I:ns2 server reload successful
I:ns3 server reload successful
I:ns6 server reload successful
I:ns7 server reload successful
I:updating master zones for ixfr-from-differences tests
I:ns1 server reload successful
I:ns2 server reload successful
I:ns6 server reload successful
I:ns7 server reload successful
I:testing zone is dumped after successful transfer
I:testing ixfr-from-differences yes;
Only in dig.out.ns3 (missing from dig2.good):
> example. 86400 IN SOA ns2.example. hostmaster.example. 1397051952 5 5 1814400 3600
> a01.example. 3600 IN A 0.0.0.0
> apl01.example. 3600 IN APL !1:10.0.0.1/32 1:10.0.0.0/24
> example. 86400 IN SOA ns2.example. hostmaster.example. 1397051952 5 5 1814400 3600
Only in dig2.good (missing from dig.out.ns3):
< example. 86400 IN SOA ns2.example. hostmaster.example. 1397051953 5 5 1814400 3600
< a01.example. 3600 IN A 0.0.0.1
< apl01.example. 3600 IN APL !1:10.0.0.1/32 1:10.0.0.1/24
< example. 86400 IN SOA ns2.example. hostmaster.example. 1397051953 5 5 1814400 3600
I:failed
I:testing ixfr-from-differences master; (master zone)
I:testing ixfr-from-differences master; (slave zone)
I:testing ixfr-from-differences slave; (master zone)
I:testing ixfr-from-differences slave; (slave zone)
I:check that a multi-message uncompressable zone transfers
I:testing that incorrectly signed transfers will fail...
I:initial correctly-signed transfer should succeed
I:ns4 server reload successful
I:unsigned transfer
I:bad keydata
I:partially-signed transfer
I:unknown key
I:incorrect key
I:check that we ask for and get a EDNS EXPIRE response (8)
I:ns7 zone refresh queued
I:test smaller transfer TCP message size (9)
I:test mapped zone with out of zone data (10)
I:test that a zone with too many records is rejected (AXFR) (11)
I:test that a zone with too many records is rejected (IXFR) (12)
I:exit status: 1
R:FAIL
E:xfer:Fri Feb 16 12:15:47 UTC 2018
```
Contents of `bin/tests/system/xfer/` [attached](/uploads/1cffe78f2f386e67b3348c12d6077636/xfer.tar.gz).BIND-9.13.0Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/67cacheclean system test fails intermittently2021-01-19T09:14:46ZMichał Kępieńcacheclean system test fails intermittentlySame failure mode has been observed in multiple jobs:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/988
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/993
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1028
* https://gitlab...Same failure mode has been observed in multiple jobs:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/988
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/993
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1028
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1153
```
S:cacheclean:Fri Feb 16 09:03:14 UTC 2018
T:cacheclean:1:A
A:System test cacheclean
I:check correctness of routine cache cleaning
I:only one tcp socket was used
I:reset and check that records are correctly cached initially
I:check flushing of the full cache
I:check flushing of individual nodes (interior node)
I:check flushing of individual nodes (leaf node, under the interior node)
I:check flushing of individual nodes (another leaf node, with both positive and negative cache entries)
I:check flushing a nonexistent name
I:check flushing of namespaces
I:check flushing a nonexistent namespace
I:check the number of cached records remaining
I:check the check that flushname of a partial match works.
I:check the number of cached records remaining
I:check flushtree clears adb correctly
I:failed
I:check expire option returned from master zone
I:check expire option returned from slave zone
I:exit status: 1
R:FAIL
E:cacheclean:Fri Feb 16 09:03:37 UTC 2018
```BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/66ixfr system test fails intermittently2018-02-26T23:21:18ZMichał Kępieńixfr system test fails intermittentlyTwo different failure modes, both seem to be related to timing at first glance:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1050
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1092
```
S:ixfr:Thu Feb 15 19:54:14 UTC 2018
T:i...Two different failure modes, both seem to be related to timing at first glance:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1050
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1092
```
S:ixfr:Thu Feb 15 19:54:14 UTC 2018
T:ixfr:1:A
A:System test ixfr
I:testing initial AXFR
server reload successful
I:testing successful IXFR
zone refresh queued
I:testing AXFR fallback after IXFR failure
zone refresh queued
I:testing ixfr-from-differences option
server reload successful
I:failed to get incremental response
I:testing request-ixfr option in view vs zone
I: this result should be AXFR
server reload successful
I: this result should be AXFR
I: success: AXFR it was
I: this result should be IXFR
server reload successful
I: success: IXFR it was
I:testing DiG's handling of a multi message AXFR style IXFR response
I:test 'dig +notcp ixfr=<value>' vs 'dig ixfr=<value> +notcp' vs 'dig ixfr=<value>'
I:exit status: 1
R:FAIL
E:ixfr:Thu Feb 15 19:54:51 UTC 2018
```
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1083
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1095
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1129
```
S:ixfr:Thu Feb 15 23:40:59 UTC 2018
T:ixfr:1:A
A:System test ixfr
I:testing initial AXFR
server reload successful
I:testing successful IXFR
zone refresh queued
I:testing AXFR fallback after IXFR failure
zone refresh queued
I:testing ixfr-from-differences option
server reload successful
I:testing request-ixfr option in view vs zone
I: this result should be AXFR
server reload successful
I: this result should be AXFR
I:failed to get nonincremental response in 2nd AXFR test
I: this result should be IXFR
server reload successful
I: success: IXFR it was
I:testing DiG's handling of a multi message AXFR style IXFR response
I:test 'dig +notcp ixfr=<value>' vs 'dig ixfr=<value> +notcp' vs 'dig ixfr=<value>'
I:exit status: 1
R:FAIL
E:ixfr:Thu Feb 15 23:41:29 UTC 2018
```
I grabbed the test artifacts from all the jobs listed above lest they get removed.BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/58inline test suite fails in GitLab CI2018-03-19T22:19:28ZOndřej Surýinline test suite fails in GitLab CIOne of the full build logs can be found here: https://gitlab.isc.org/isc-projects/bind9/-/jobs/777/raw
But more distros and archs are affected: https://gitlab.isc.org/isc-projects/bind9/pipelines/54
The inline test fails at several su...One of the full build logs can be found here: https://gitlab.isc.org/isc-projects/bind9/-/jobs/777/raw
But more distros and archs are affected: https://gitlab.isc.org/isc-projects/bind9/pipelines/54
The inline test fails at several subtests when running inside GitLab CI:
```
S:inline:Mon Feb 12 15:00:01 UTC 2018
T:inline:1:A
A:System test inline
I:checking that rrsigs are replaced with ksk only (1)
I:checking that the zone is signed on initial transfer (2)
I:failed
[...]
I:exit status: 1
R:FAIL
```BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/57dnssec test suite fails in GitLab CI2018-03-19T22:19:55ZOndřej Surýdnssec test suite fails in GitLab CIOne of the full build logs can be found here: https://gitlab.isc.org/isc-projects/bind9/-/jobs/777/raw
But more distros and archs are affected: https://gitlab.isc.org/isc-projects/bind9/pipelines/54
The dnssec test fails at several su...One of the full build logs can be found here: https://gitlab.isc.org/isc-projects/bind9/-/jobs/777/raw
But more distros and archs are affected: https://gitlab.isc.org/isc-projects/bind9/pipelines/54
The dnssec test fails at several subtests when running inside GitLab CI:
```
S:dnssec:Mon Feb 12 14:49:59 UTC 2018
T:dnssec:1:A
A:System test dnssec
[...]
I:nsec3 chain generation not complete
I:failed
[...]
I:check that increasing the sig-validity-interval resigning triggers re-signing (190)
I:failed
[...]
I:checking initialization with a revoked managed key (215)
I:failed
I:check that a non matching CDNSKEY record is accepted with a matching CDNSKEY record (216)
; Communication with 10.53.0.2#5300 failed: timed out
I:failed
[...]
I:exit status: 7
R:FAIL
E:dnssec:Mon Feb 12 14:58:14 UTC 2018
```BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/56Revise usage of getquad()2018-03-28T22:46:20ZOndřej SurýRevise usage of getquad()Copied from !5:
We want also revise `getquad()` usage whether this is really needed at all places to accept *almost-valid* IP addresses:
```
lib/dns/rdata/generic/ipseckey_45.c
lib/dns/rdata/generic/l32_105.c
lib/dns/rdata/hs_4/a_1.c
l...Copied from !5:
We want also revise `getquad()` usage whether this is really needed at all places to accept *almost-valid* IP addresses:
```
lib/dns/rdata/generic/ipseckey_45.c
lib/dns/rdata/generic/l32_105.c
lib/dns/rdata/hs_4/a_1.c
lib/dns/rdata/in_1/a_1.c
lib/dns/rdata/in_1/wks_11.c
```
Again deprecating the usage of obscure formats might be the right thing to do.BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/55Update the 2018 copyright in all files2018-03-19T22:20:15ZOndřej SurýUpdate the 2018 copyright in all files(IANAL) As far I as understand the US copyright law, there's no real reason why to update the copyright to new year only when you touch the file.
Instead of cluttering the git history with two extra commits for almost every merge reques...(IANAL) As far I as understand the US copyright law, there's no real reason why to update the copyright to new year only when you touch the file.
Instead of cluttering the git history with two extra commits for almost every merge request, the source files should be updated in bulk and add 2018 everywhere.
A reminder to do the same thing on 1. January next year should be set in the cron job to be sent to bind team list in addition to the merge requests on maintained branches.BIND-9.13.0Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/51Fix cppcheck-detected source code errors2018-03-19T22:18:48ZStephen MorrisFix cppcheck-detected source code errorsThe current list of issues detected by cppcheck are at:
https://jenkins.isc.org/view/BIND/job/bind9-cpp-check/
(currently not visible outside ISC - you need to be logged into Jenkins to see them). A number are false positives, but the...The current list of issues detected by cppcheck are at:
https://jenkins.isc.org/view/BIND/job/bind9-cpp-check/
(currently not visible outside ISC - you need to be logged into Jenkins to see them). A number are false positives, but there are also a significant number of real issues (mainly relating to a mismatch between a format string and variable type).BIND-9.13.0Stephen MorrisStephen Morrishttps://gitlab.isc.org/isc-projects/bind9/-/issues/49unittest.sh fails to run on openBSD2021-02-22T11:17:06ZCurtis Blackburnunittest.sh fails to run on openBSDthe 'type' command produces different output on openBSD than on other platforms, leading the script to always behave as if the 'kyua' binary in on the PATH.
we can fix this by using 'command -v' instead of 'type'
(tested command -v on ...the 'type' command produces different output on openBSD than on other platforms, leading the script to always behave as if the 'kyua' binary in on the PATH.
we can fix this by using 'command -v' instead of 'type'
(tested command -v on openbsd, macos, centos, and solaris)BIND-9.13.0Curtis BlackburnCurtis Blackburnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/44scan-build: Dead increment in multiple tests2018-03-18T11:14:07ZOndřej Surýscan-build: Dead increment in multiple testsllvm 5.0.0 scan-build reports Dead increment (Dead store) in bin/tests/system/pipelined/pipequeries.c, bin/tests/system/tkey/keydelete.c and bin/tests/system/pipelined/pipequeries.
Install full llvm (on Mac OS X: `brew install llvm --wi...llvm 5.0.0 scan-build reports Dead increment (Dead store) in bin/tests/system/pipelined/pipequeries.c, bin/tests/system/tkey/keydelete.c and bin/tests/system/pipelined/pipequeries.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uploads/4d79cc3e65e3e30453dff492a830a443/scan-build-2017-12-18-110416-46298-1.zip) and run:
`scan-view scan-build-2017-12-18-110416-46298-1` (on Mac OS X `/usr/local/opt/llvm/scan-view scan-build-2017-12-18-110416-46298-1`)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/43scan-build: Dead assignment in lib/ns/query.c2018-03-18T11:14:13ZOndřej Surýscan-build: Dead assignment in lib/ns/query.cllvm 5.0.0 scan-build reports Dead assignment in lib/ns/query.c in query_synthcnamewildcard function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uplo...llvm 5.0.0 scan-build reports Dead assignment in lib/ns/query.c in query_synthcnamewildcard function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uploads/4d79cc3e65e3e30453dff492a830a443/scan-build-2017-12-18-110416-46298-1.zip) and run:
`scan-view scan-build-2017-12-18-110416-46298-1` (on Mac OS X `/usr/local/opt/llvm/scan-view scan-build-2017-12-18-110416-46298-1`)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/42scan-build: Branch condition evaluates to a garbage value in bin/dnssec/dnsse...2022-06-17T16:42:28ZOndřej Surýscan-build: Branch condition evaluates to a garbage value in bin/dnssec/dnssec-signzone.cllvm 5.0.0 scan-build reports Logic error in bin/dnssec/dnssec-signzone.c in `hashlist_free` function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/upl...llvm 5.0.0 scan-build reports Logic error in bin/dnssec/dnssec-signzone.c in `hashlist_free` function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uploads/4d79cc3e65e3e30453dff492a830a443/scan-build-2017-12-18-110416-46298-1.zip) and run:
`scan-view scan-build-2017-12-18-110416-46298-1` (on Mac OS X `/usr/local/opt/llvm/scan-view scan-build-2017-12-18-110416-46298-1`)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/37Implement Geoff Huston's trusted key sentinel feature2018-04-22T19:51:54ZVicky Riskvicky@isc.orgImplement Geoff Huston's trusted key sentinel featureThis is still pending but Geoff Huston has proposed APNIC sponsorship for this feature. Obviously the purpose is to add telemetry for the eventual root KSK rollover.
ref: https://tools.ietf.org/html/draft-huston-kskroll-sentinel-01This is still pending but Geoff Huston has proposed APNIC sponsorship for this feature. Obviously the purpose is to add telemetry for the eventual root KSK rollover.
ref: https://tools.ietf.org/html/draft-huston-kskroll-sentinel-01BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/27Remove the extra RFC and I-D copies from BIND source distribution2018-03-08T16:08:15ZOndřej SurýRemove the extra RFC and I-D copies from BIND source distributionCopied from here: https://bugs.isc.org/Ticket/Display.html?id=46211
@marka Argues that it's handy to have a copies, but:
* We can have an extra repository and not distribute them in the BIND 9 source code
* We are missing erratas anywa...Copied from here: https://bugs.isc.org/Ticket/Display.html?id=46211
@marka Argues that it's handy to have a copies, but:
* We can have an extra repository and not distribute them in the BIND 9 source code
* We are missing erratas anyway
We should just make a list with the RFCs and I-D and explicitly declare which standards (and at what levels) we support.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/26Switch to IDNA2008 non-transitional processing (and use libidn2 for that)2023-12-01T10:23:29ZOndřej SurýSwitch to IDNA2008 non-transitional processing (and use libidn2 for that)Copied here from https://bugs.isc.org/Ticket/Display.html?id=36101
The most current (and maintained) implementation of IDNA is libidn2 and that what we should be using. Moreover the DNS world just needs to bite the bullet and switch to...Copied here from https://bugs.isc.org/Ticket/Display.html?id=36101
The most current (and maintained) implementation of IDNA is libidn2 and that what we should be using. Moreover the DNS world just needs to bite the bullet and switch to IDNA2008 non-transitional processing and finally be done with that.
Firefox, curl and wget have already switched to IDNA2008 non-transitional, and it's not like dig/host/nslookup IDNA processing would have any security implications like with the web browser software.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/336Default of rrset-order silently changed to be sorted (rather than random)2023-03-16T11:03:02ZGhost UserDefault of rrset-order silently changed to be sorted (rather than random)<!--
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
The default rrset-order changed in bind 9.12 to sort returned results in an rrset rather than to randomize them. This is not listed in the change notes and is an operationally dangerous change. For example, this breaks services relying on DNS round-robin load balancing by overloading the machine with the lowest IP address. Even when the authority returns round-robin rrsets, bind 9.12 still sorts them by default.
This silent default change may be a critical issue in bind 9.12 that could cause major service incidents. It may be necessary to broadly communicate this broken/changed behavior and recommend fixes.
### Steps to reproduce
Resolve a name with multiple records in the rrset. With bind versions prior to 9.12, each lookup returns results in a different order. In bind 9.12, results are returned sorted. (As an example, doing an "ssh" or "curl" with a bind 9.12 resolver will always try the first IP, whereas with previous versions of bind9 different IPs will be tried.)
For example these are sorted (while the authority ns1.google.com even permutes with each lookup):
```
$ dig +short www.youtube.com @127.0.0.1
youtube-ui.l.google.com.
172.217.3.110
172.217.6.206
172.217.7.14
172.217.10.46
172.217.10.78
172.217.10.142
172.217.10.238
172.217.11.14
172.217.11.46
172.217.12.142
172.217.12.174
```
With the above, many clients using the stock Linux system libraries will always connect to "172.217.3.110".
### What is the current *bug* behavior?
rrsets with the default configuration are sorted.
### What is the expected *correct* behavior?
rrset responses should be randomized by default.
### Relevant configuration files
Behavior with the default configuration.
### Relevant logs and/or screenshots
### Possible fixes
I suspect this commit changed the behavior:
https://gitlab.isc.org/isc-projects/bind9/commit/03be5a6b4e6311b14a12dec5b15a62f55586aaf4
The issue is fixed by adding back in:
rrset-order { order random; };
If this is an intentional change, it should be discussed much more widely in the community as this has potentially operational implications.BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/108repeated crashes in 9.12.02019-04-25T15:44:31ZEvan Huntrepeated crashes in 9.12.0Reported by Andrew Fried in private mail:
I've experienced half a dozen core dumps over the past week with BIND
9.12.0. Every time it happens I found critical logs like this in bind.log:
```
24-Feb-2018 06:43:49.404 general: critical:...Reported by Andrew Fried in private mail:
I've experienced half a dozen core dumps over the past week with BIND
9.12.0. Every time it happens I found critical logs like this in bind.log:
```
24-Feb-2018 06:43:49.404 general: critical: rbt.c:2119: REQUIRE((__builtin_expect(!!((node) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(node))->magic == ((('R') << 24 | ('B') << 16 | ('N') << 8 | ('O')))), 1))) failed, back trace
24-Feb-2018 06:43:49.404 general: critical: #0 0x42e460 in assertion_failed()+0x60
24-Feb-2018 06:43:49.404 general: critical: #1 0x61660a in isc_assertion_failed()+0xa
24-Feb-2018 06:43:49.404 general: critical: #2 0x4ff232 in dns_rbt_deletenode()+0x522
24-Feb-2018 06:43:49.404 general: critical: #3 0x503674 in delete_node()+0x214
24-Feb-2018 06:43:49.404 general: critical: #4 0x50d1c6 in decrement_reference()+0x936
24-Feb-2018 06:43:49.404 general: critical: #5 0x50d68e in expire_header()+0xbe
24-Feb-2018 06:43:49.404 general: critical: #6 0x517164 in addrdataset()+0x8a4
24-Feb-2018 06:43:49.404 general: critical: #7 0x4eeea1 in addoptout()+0x861
24-Feb-2018 06:43:49.404 general: critical: #8 0x4ef054 in dns_ncache_add()+0x14
24-Feb-2018 06:43:49.404 general: critical: #9 0x56aaad in ncache_adderesult()+0xad
24-Feb-2018 06:43:49.404 general: critical: #10 0x57824a in validated()+0xfea
24-Feb-2018 06:43:49.404 general: critical: #11 0x63b397 in run()+0x2f7
24-Feb-2018 06:43:49.404 general: critical: #12 0x7fa3d58dc6ba in __do_global_dtors_aux_fini_array_entry()+0x7fa3d4fcdc4a
24-Feb-2018 06:43:49.404 general: critical: #13 0x7fa3d525741d in __do_global_dtors_aux_fini_array_entry()+0x7fa3d49489ad
24-Feb-2018 06:43:49.404 general: critical: exiting (due to assertion failure)
```
This is not a one-off issue - it's happened to multiple servers. I'd
really appreciate it if you'd look into this. I have the core dump
files available on the last two issues that happened this evening an
hour or so apart.BIND-9.12.2https://gitlab.isc.org/isc-projects/bind9/-/issues/398BIND 9.13.2 Release2018-07-17T20:29:24ZOndřej SurýBIND 9.13.2 Release1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view...1. [x] Prepare the sources for tarball generation
1. [x] Change software version and library versions in `configure.in`
2. [x] Update CHANGES
3. [x] [Ensure the release notes are correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_release_notes_are_cor)
4. [x] [Ensure the metainformation is correct for this release](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Ensure_the_metainformation_is_co)
3. [x] Make sure the tests are passing
4. [x] Create a tag (name `vX_Y_Z[-alphatag]`, content `BIND X.Y.Z[-alphatag]`, signed with a developer's GPG key): `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z`
5. [x] Push the changes and tag
6. [x] [Create the tarball](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Create_the_tar_ball_using_a_util)
7. [x] [Create the Windows zips](https://wiki.isc.org/bin/view/Main/BindReleaseProcedures#Creating_Windows_zips)
7. [x] Have QA sanity check the tarball and zips
9. [x] Request the signature on the tarballs
10. [x] Make tarballs and signatures available to download
10. [x] Communication
1. [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
2. [x] Update the website(?), public release notes(?)
3. [x] Write release e-mail to bind9-announce
4. [x] Post short note to Twitter
5. [ ] Update http://en.wikipedia.org/wiki/BIND
11. [ ] Update DEB and RPM packagesBIND-9.13.2Evan HuntEvan Hunt2018-07-10