ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-11-06T11:08:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1733Additional parameter to minimal-responses2023-11-06T11:08:42ZPeter DaviesAdditional parameter to minimal-responses### Description
Description:
In order to minimise the data returned from a forwarder to a forwardee when the forwarder has "minimal-responses" enabled; including delegations, negative responses etc.
This is because, in a typical setup, t...### Description
Description:
In order to minimise the data returned from a forwarder to a forwardee when the forwarder has "minimal-responses" enabled; including delegations, negative responses etc.
This is because, in a typical setup, the forwardee will be configured to "forward only" and so has no use for additional or authority data.
Suggestions on how this might be enabled are:
1) If the query received by the forwarder has RD=1 (from the forwardee), additional/authority data is NOT returned, even for delegations and negative responses.
Note: The danger with this is there might be a use case where the forwardee needs some or all of this data, even if RD=1
or
2) An additional parameter for "minimal-responses", something like "always", which if configured on the forwarder would cause it to never return additional/authority data to the forwardee under any circumstances.
Note: I think this would involve changing its parameter type from boolean to integer(?) in order to introduce a third option.
see RT [#16200](https://support.isc.org/Ticket/Display.html?id=16200)Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1177Options stanza in query packet doesn't reflect the information from dhcpd2020-04-03T13:04:34ZMunroe SollogOptions stanza in query packet doesn't reflect the information from dhcpdUsing dhcpd to write the requested options to a log file with this code:
<pre>
on commit {
log(info,
concat("Client :",
binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)),
": requests ",
binary-to-...Using dhcpd to write the requested options to a log file with this code:
<pre>
on commit {
log(info,
concat("Client :",
binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)),
": requests ",
binary-to-ascii(16, 8, ":", option dhcp-parameter-request-list),
" - ",
pick-first-value(option vendor-class-identifier, "no_vendor_id"))
);
}
</pre>
We get log output like: (Debian Buster VM as a client).
<pre>
Apr 2 19:32:33 128.180.2.9 dhcpd[8378]: Client :0:50:56:bf:89:87: requests 1:1c:2:3:f:6:77:c:2c:2f:1a:79:2a - no_vendor_id
</pre>
Using the same client against kea 1.7.6, we added the following to the forensic logging hook in lease4_callout.cc:
<pre>
stream << " Full packet: " << query->toText();
</pre>
And we get this in the forensic log:
<pre>
2020-04-02 19:32:08 EDT Address: 192.0.2.2 has been renewed for 1 hrs 0 mins 0 secs to a device with hardware address: hwtype=1 00:50:56:bf:ba:d4, client-id: ff:56:bf:ba:d4:00:01:00:01:26:18:e8:9c:00:50:56:bf:ba:d4 Full packet: local_address=192.0.2.222:67, remote_address=192.0.2.2:68, msg_type=DHCPREQUEST (3), transid=0xd09df007,
options:
type=012, len=010: "dhcpclient" (string)
type=053, len=001: 3 (uint8)
type=055, len=013: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8) 6(uint8) 119(uint8) 12(uint8) 44(uint8) 47(uint8) 26(uint8) 121(uint8) 42(uint8)
type=061, len=019: ff:56:bf:ba:d4:00:01:00:01:26:18:e8:9c:00:50:56:bf:ba:d4
</pre>
It looks like kea isn't capturing all of the same options that dhcpd is capturing, and it also looks like kea isn't preserving the order in which the options are requested.https://gitlab.isc.org/isc-projects/bind9/-/issues/1732"rndc loadkeys" and "rndc sign" provide no feedback on missing or unreadable ...2023-11-02T16:51:56ZMichael Graff"rndc loadkeys" and "rndc sign" provide no feedback on missing or unreadable keysWhen using inline-signing, issuing a "rndc loadkeys" where there are no keys, the key directory specified in the config is unreadable, or the key files themselves are unreadable due to permission issues, no error is logged.
This made de...When using inline-signing, issuing a "rndc loadkeys" where there are no keys, the key directory specified in the config is unreadable, or the key files themselves are unreadable due to permission issues, no error is logged.
This made debugging fairly difficult.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1731Sort Automake files nicely2021-10-05T14:31:01ZMichał KępieńSort Automake files nicelyThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120925): (+1 comment)
> I think all such lists should be sorted alpha...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120925): (+1 comment)
> I think all such lists should be sorted alphabetically. I mean, why
> sort `*_SOURCES` but no `AM_CPPFLAGS`?
>
> I can spare you the trouble and do all the sorting myself, and I would
> leave that for the last moment before merging.
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120926): (+1 comment)
> Apart from block *contents*, I would also sort the *blocks* themselves alphabetically, perhaps with `LIBLTDL_*` being the sole exception. It just seems to make navigating the file a bit easier and - maybe just for me - it indicates that dependency resolution is done *elsewhere*.
>
> I think I will stop flagging the sorting issue now and just check everything again later.
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120946): (+1 comment)
> Maybe a matter of taste, but I would first define "standard" library components and then add all the `if` blocks below that. (Right now, we specify `SOURCES`, then optional `SOURCES`, then `CFLAGS`, then optional `CFLAGS`; I would change that to `SOURCES` → `CFLAGS` → optional `SOURCES` → optional `CFLAGS`.)
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120652): (+1 comment)
> Is there any reason for *not* sorting the entries in each of the `AC_CONFIG_FILES` blocks above alphabetically? A quick test shows that the order does not matter.
- [ ] Ensure Automake `if`/`endif` style is consistent tree-wideBIND 9.17 BackburnerMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1730Clean up no-op AC_SUBST calls2020-11-27T12:21:54ZMichał KępieńClean up no-op AC_SUBST callsThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121372): (+1 comment)
> It seems that we can drop:
>
> - `...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121372): (+1 comment)
> It seems that we can drop:
>
> - `STD_CDEFINES`
> - `STD_CINCLUDES`
> - `STD_CWARNINGS`
>
> That would require updating `OPTIONS`. There are also lots of other
> `AC_SUBST` calls for unused macros, so maybe let's tackle this in a
> separate issue?December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1729Remove unused helper scripts from bin/tests/system/2022-01-27T11:48:13ZMichał KępieńRemove unused helper scripts from bin/tests/system/The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121149): (+1 comment)
> I may be confused, but I do not really see wh...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121149): (+1 comment)
> I may be confused, but I do not really see why we still need the
> following scripts:
>
> - `bin/tests/system/start.sh`
> - `bin/tests/system/stop.sh`
> - `bin/tests/system/stopall.sh`
> - `bin/tests/system/setup.sh`
>
> I would take a shot at removing them in a separate MR. AFAICT, only
> `stop.sh` is actively used (in the `rrsetorder` test), but it should be
> easy to use `stop()` from `conf.sh.common` instead.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/kea/-/issues/1176investigate MT compatibility of crypto backend2022-11-02T15:10:18ZFrancis Dupontinvestigate MT compatibility of crypto backendKea used Botan and OpenSSL as crypto backends but they are no neutral from the multi-threading point of view even we use only pretty low level functions which should not be critical from this.Kea used Botan and OpenSSL as crypto backends but they are no neutral from the multi-threading point of view even we use only pretty low level functions which should not be critical from this.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1175static thread safety analysis2020-07-13T13:32:54ZRazvan Becheriustatic thread safety analysisusing static analysis: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
advantages:
compile time checking (even not covered by runtime paths)
disadvantages:
a lot of changes in the code
code must be maintained
feature must be supp...using static analysis: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
advantages:
compile time checking (even not covered by runtime paths)
disadvantages:
a lot of changes in the code
code must be maintained
feature must be supported by compiler (which could also evolve/change alongside kea)outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1728Integrate bigkey to system test2021-10-05T11:50:30ZMichał KępieńIntegrate bigkey to system testThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121135): (+1 comment)
> Hmm, I do not see anything that would prevent...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121135): (+1 comment)
> Hmm, I do not see anything that would prevent this test from being run
> for a PKCS#11 build? I believe this is what the `prereq.sh` script was
> guarding against?
>
> Also, if `bin/tests/system/rsabigexponent/bigkey.c` is not built any
> more, it should just be removed from the tree.
>
> (I have not looked at this system test closely, so I may be confused.)BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1727Drop use of "$FEATURETEST --have-dlopen"2020-07-30T12:38:06ZMichał KępieńDrop use of "$FEATURETEST --have-dlopen"The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121125):
> `dlopen()` support seems to be a hard build-time requireme...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121125):
> `dlopen()` support seems to be a hard build-time requirement now, so I
> would drop all uses of `$FEATURETEST --have-dlopen` (a follow-up MR is
> fine).August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1726Unit tests: rename TESTS to something more descriptive2020-06-04T11:50:26ZMichał KępieńUnit tests: rename TESTS to something more descriptiveThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120967): (+1 comment)
> I would change this to `TESTS_DIR`, if not fo...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120967): (+1 comment)
> I would change this to `TESTS_DIR`, if not for anything else then to
> avoid confusion with the `TESTS` Automake variable.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1725Ensure correct use of lib/ns/tests/wrap.c2020-09-28T07:11:55ZMichał KępieńEnsure correct use of lib/ns/tests/wrap.cThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120964): (+1 comment)
> I am confused here, but maybe I just do not u...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120964): (+1 comment)
> I am confused here, but maybe I just do not understand what the intent
> is. A [comment in `lib/ns/tests/wrap.c`][1] says that `wrap.c` is
> supposed to be used when `LD_WRAP` is *not* available. Here, it will be
> used when `LD_WRAP` is available. 🤯
>
> Current `master` also wraps `isc_nmhandle_unref()` for other libns unit
> tests, but I am not sure if that is intentional or a copy-paste issue.
>
> There is also no `else !HAVE_LD_WRAP` branch here - not sure if that is
> an intentional omission.
>
> [1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/8e74974ce182b2fcd7dce82b1b68fa2ad922751b/lib/ns/tests/wrap.c#L28-32October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1724Revise installation locations for certain BIND binaries2020-06-08T12:53:48ZMichał KępieńRevise installation locations for certain BIND binariesThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120928): (+2 comments)
> Here is an exhaustive list of binaries which...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120928): (+2 comments)
> Here is an exhaustive list of binaries which are currently installed
> into `${sbindir}` that this MR causes to be installed into `${bindir}`:
>
> - `ddns-confgen`
> - `named-checkconf`
> - `named-checkzone`
> - `named-journalprint`
> - `named-nzd2nzf`
> - `nsec3hash`
> - `rndc-confgen`
- [ ] @ondrej [said](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121048):
> BTW it's wrong to install these to sbin, as they don't require administrator privileges to run.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1723Replace fputs() with fprintf()2020-05-04T10:37:46ZMichał KępieńReplace fputs() with fprintf()The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120581): (+3 comments)
> Replacing `fputs()` with `fprintf()` sounds ...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120581): (+3 comments)
> Replacing `fputs()` with `fprintf()` sounds like something to do
> tree-wide in another issue (may be possible with Coccinelle)?May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1722Ensure unit test core dumps are collected for Automake builds2020-06-08T10:16:20ZMichał KępieńEnsure unit test core dumps are collected for Automake buildsThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120597): (+1 comment)
> We need to make sure that - with this MR merg...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120597): (+1 comment)
> We need to make sure that - with this MR merged (post-factum is okay) -
> if any unit test crashes, usable core dumps are placed among job
> artifacts in GitLab CI. Most of the work put into the
> `unit/unittest.sh.in` script was done to ensure that.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1721Grow and shrink dnssec-sign statistics on key rollover events2021-08-31T13:28:54ZMatthijs Mekkingmatthijs@isc.orgGrow and shrink dnssec-sign statistics on key rollover events!2067 introduced dnssec-sign statistics (#513) to the zone statistics. This introduced an operational issue because when using `zone-statistics full;` the memory usage is going through the roof. It turns out that using the key id as inde...!2067 introduced dnssec-sign statistics (#513) to the zone statistics. This introduced an operational issue because when using `zone-statistics full;` the memory usage is going through the roof. It turns out that using the key id as index wasn't the greatest idea.
!3304 fixes this (#1179) by allocating just four key slots per zone. If a zone exceeds the number of keys for example through a key rollover, the keys will be rotated out on a FIFO basis.
This works for most cases, and fixes the immediate problem of high memory usage, but if you sign your zone with many, many keys, or are sign with a ZSK/KSK double algorithm strategy you may experience weird statistics.
A better strategy would to grow the number of key slots per zone on key rollover events: Grow during key rollover, shrink on a LRU basis.
In addition, if a zone is signed with two algorithms there is a very small chance that two keys will have the same key tag. The dnssec-sign statistics prevents operators identifying which key is which when there are common key ids across algorithms.
When dumping stats, rather than passing the key tag, pass `kval` and show an appropriate value label to be constructed or something like this to be emitted.
```
{
"algorithm": value,
"tag": value,
"sign-count": value
"refresh-count": value
},
```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/1720Building documentation is broken with Automake2020-05-11T11:07:47ZMichał KępieńBuilding documentation is broken with AutomakeThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120576): (+1 comment)
> This breaks the existing release process and ...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_120576): (+1 comment)
> This breaks the existing release process and will either need to be
> tweaked before we release a version with this MR merged or we will need
> to fix building documentation and revert this removal.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/stork/-/issues/223Update Stork ARM describing host reservations support2020-04-02T19:01:55ZMarcin SiodelskiUpdate Stork ARM describing host reservations supportFollowing the ticket #210 and #214 we need to describe host reservation support in Stork.Following the ticket #210 and #214 we need to describe host reservation support in Stork.0.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1719Observed stats underflow in multiple stats2021-12-03T13:02:15ZBrian ConryObserved stats underflow in multiple statsWhile looking at a customer-provided named.stats file it was observed that several counters had underflowed in BIND version 9.11.16-S1.
A selection of the underflowing stats:
```
+++ Statistics Dump +++ (1584405000)
++ Cache DB RRsets +...While looking at a customer-provided named.stats file it was observed that several counters had underflowed in BIND version 9.11.16-S1.
A selection of the underflowing stats:
```
+++ Statistics Dump +++ (1584405000)
++ Cache DB RRsets ++
[View: default]
18446744073709551614 ~A
18446744073709551615 ~NS
++ Socket I/O Statistics ++
18446744073709551556 UDP/IPv4 sockets active
18446744073709551584 UDP/IPv6 sockets active
18446744073709551600 TCP/IPv4 sockets active
+++ Statistics Dump +++ (1584405300)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~CNAME
18446744073709551614 ~!AAAA
+++ Statistics Dump +++ (1584405900)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~AAAA
+++ Statistics Dump +++ (1584408000)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~RRSIG
+++ Statistics Dump +++ (1584418500)
++ Resolver Statistics ++
[View: default]
18446744073709551615 active fetches
+++ Statistics Dump +++ (1584447000)
++ Cache DB RRsets ++
[View: default]
18446744073709551608 ~NXDOMAIN
+++ Statistics Dump +++ (1584485100)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~NULL
+++ Statistics Dump +++ (1584504300)
++ Cache DB RRsets ++
[View: default]
18446744073709551521 NULL
+++ Statistics Dump +++ (1584515400)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~TXT
+++ Statistics Dump +++ (1584518400)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~NSEC
+++ Statistics Dump +++ (1584676500)
++ Cache DB RRsets ++
[View: default]
18446744073709551557 !AAAA
+++ Statistics Dump +++ (1584737700)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 !CNAME
+++ Statistics Dump +++ (1584886800)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~MX
+++ Statistics Dump +++ (1585119900)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 !MX
+++ Statistics Dump +++ (1585137000)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 ~DS
+++ Statistics Dump +++ (1585282500)
++ Cache DB RRsets ++
[View: default]
18446744073709551610 !A
+++ Statistics Dump +++ (1585457400)
++ Cache DB RRsets ++
[View: default]
18446744073709551506 CNAME
```
I'd like to specifically call out `active fetches` which might get lost in the noise near the middle of those lines.
The same stats file has history going back to unknown prior versions (August 2019) also has underflows on:
```
+++ Statistics Dump +++ (1566255596)
++ Cache DB RRsets ++
[View: default]
18446744073709547273 #A
18446744073709551608 #TXT
18446744073709551247 #AAAA
18446744073709551615 #SRV
18446744073709548950 #!AAAA
+++ Statistics Dump +++ (1566260101)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #NS
+++ Statistics Dump +++ (1566307500)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #RRSIG
+++ Statistics Dump +++ (1566355500)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #!A
+++ Statistics Dump +++ (1567977300)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 !A6
+++ Statistics Dump +++ (1568136600)
++ Name Server Statistics ++
18446744073709551466 recursing clients
+++ Statistics Dump +++ (1570120200)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #!SRV
+++ Statistics Dump +++ (1571707501)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #CNAME
+++ Statistics Dump +++ (1571768400)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #!TXT
+++ Statistics Dump +++ (1574442900)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #DS
+++ Statistics Dump +++ (1574886601)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #NXDOMAIN
+++ Statistics Dump +++ (1575558600)
++ Cache DB RRsets ++
[View: default]
18446744073709551615 #PTR
```
The most significant of the last set is probably `recursing clients`.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/1718[CVE-2020-8619] An asterisk character in an empty non-terminal can cause an a...2020-08-05T12:05:41ZHolger Wirtz[CVE-2020-8619] An asterisk character in an empty non-terminal can cause an assertion failure in rbtdb.c### Summary
Sudden crash of the named process (1-10 minutes after restart)
### BIND version used
```
BIND 9.11.17 (Extended Support Version) <id:65c9496>
running on Linux x86_64 3.16.0-10-amd64 #1 SMP Debian 3.16.81-1 (2020-01-17)
bui...### Summary
Sudden crash of the named process (1-10 minutes after restart)
### BIND version used
```
BIND 9.11.17 (Extended Support Version) <id:65c9496>
running on Linux x86_64 3.16.0-10-amd64 #1 SMP Debian 3.16.81-1 (2020-01-17)
built by make with '--prefix=/usr' '--mandir=/usr/share/man' '--libdir=/usr/lib/x86_64-linux-gnu' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--enable-ipv6' '--enable-filter-aaaa'
compiled by GCC 4.9.2
compiled with OpenSSL version: OpenSSL 1.0.1t 3 May 2016
linked to OpenSSL version: OpenSSL 1.0.1t 3 May 2016
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with libjson-c version: 0.11.99
linked to libjson-c version: 0.11.99
compiled with zlib version: 1.2.8
linked to zlib version: 1.2.8
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
```
### Steps to reproduce
```
# Created bind as usual (works with <= 9.11.14):
VERSION=9.11.17
wget -O bind-$(VERSION).tar.gz https://downloads.isc.org/isc/bind9/$(VERSION)/bind-$(VERSION).tar.gz
wget -O bind-$(VERSION).tar.gz.sha512.asc https://downloads.isc.org/isc/bind9/$(VERSION) /bind-$(VERSION).tar.gz.sha512.asc
gpg --verify bind-$(VERSION).tar.gz.sha512.asc bind-$(VERSION).tar.gz
tar -zxf bind-$(VERSION).tar.gz
bind-$(VERSION)
./configure --prefix=/usr \
--mandir=\$${prefix}/share/man \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--infodir=\$${prefix}/share/info \
--sysconfdir=/etc/bind \
--with-python=python3 \
--localstatedir=/ \
--enable-threads \
--enable-largefile \
--with-libtool \
--enable-shared \
--enable-static \
--with-openssl=/usr \
--with-gssapi=/usr \
--with-gnu-ld \
--enable-ipv6 \
--enable-filter-aaaa
make && make install
```
### What is the current *bug* behavior?
After a few minutes, bind crashes with the following message in general.log:
```
01-Apr-2020 11:24:11.101 general: rbtdb.c:2097: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed, back trace
01-Apr-2020 11:24:11.101 general: #0 0x43fecd in ??
01-Apr-2020 11:24:11.101 general: #1 0x7ff0f7cedcaa in ??
01-Apr-2020 11:24:11.101 general: #2 0x7ff0f8fb2da5 in ??
01-Apr-2020 11:24:11.101 general: #3 0x7ff0f8fc2d6c in ??
01-Apr-2020 11:24:11.101 general: #4 0x44e3fd in ??
01-Apr-2020 11:24:11.101 general: #5 0x4585b8 in ??
01-Apr-2020 11:24:11.101 general: #6 0x4353f6 in ??
01-Apr-2020 11:24:11.101 general: #7 0x7ff0f7d179c7 in ??
01-Apr-2020 11:24:11.101 general: #8 0x7ff0f6e98064 in ??
01-Apr-2020 11:24:11.101 general: #9 0x7ff0f686662d in ??
01-Apr-2020 11:24:11.101 general: exiting (due to assertion failure)
```
### What is the expected *correct* behavior?
No crash.
### Relevant configuration files
named.conf:
```
include "/etc/bind/named.conf.local"; // only ACLs, logging and statistic channels
include "/etc/bind/named.conf.options"; // look down
include "/etc/bind/bind.keys";
include "/etc/bind/named.conf.namedboot";
include "/etc/bind/tsig.key";
```
named.options:
```
options {
directory "/var/cache/bind";
pid-file "/var/run/named/named.pid";
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { ::1; ********; };
listen-on { 127.0.0.1; *********; };
allow-query { any; };
allow-transfer { ******; };
recursion no;
version "0";
dnssec-enable yes;
dnssec-validation yes;
tcp-clients 1500;
rate-limit {
responses-per-second 50;
};
};
controls {
inet 127.0.0.1 allow { 127.0.0.1; ::1; };
};
```
### Relevant logs and/or screenshots
general.log:
```
...
01-Apr-2020 11:24:11.101 general: rbtdb.c:2097: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed, back trace
01-Apr-2020 11:24:11.101 general: #0 0x43fecd in ??
01-Apr-2020 11:24:11.101 general: #1 0x7ff0f7cedcaa in ??
01-Apr-2020 11:24:11.101 general: #2 0x7ff0f8fb2da5 in ??
01-Apr-2020 11:24:11.101 general: #3 0x7ff0f8fc2d6c in ??
01-Apr-2020 11:24:11.101 general: #4 0x44e3fd in ??
01-Apr-2020 11:24:11.101 general: #5 0x4585b8 in ??
01-Apr-2020 11:24:11.101 general: #6 0x4353f6 in ??
01-Apr-2020 11:24:11.101 general: #7 0x7ff0f7d179c7 in ??
01-Apr-2020 11:24:11.101 general: #8 0x7ff0f6e98064 in ??
01-Apr-2020 11:24:11.101 general: #9 0x7ff0f686662d in ??
01-Apr-2020 11:24:11.101 general: exiting (due to assertion failure)
```
### Possible fixes
see above...June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrews