ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-06-08T12:30:22Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1798Reject master zones with DS records at the apex.2020-06-08T12:30:22ZMark AndrewsReject master zones with DS records at the apex.DS records belong to the parent zone and should never appear at the zone apex. Reject zones which have a DS record at the apex when loading if they are a master zone.
ISC's operations managed to do this.DS records belong to the parent zone and should never appear at the zone apex. Reject zones which have a DS record at the apex when loading if they are a master zone.
ISC's operations managed to do this.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1797libuv >= 1.37 requires uv_udp_init_ex() to be used for mmsg2020-05-04T10:53:23ZOndřej Surýlibuv >= 1.37 requires uv_udp_init_ex() to be used for mmsglibuv >= 1.37 has changed the way it enabled mmsg, and now `uv_udp_init_ex()` with proper flags needs to be called. We should adapt our code to that.libuv >= 1.37 has changed the way it enabled mmsg, and now `uv_udp_init_ex()` with proper flags needs to be called. We should adapt our code to that.May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1796Log files should not be closed until their successor is open.2021-10-05T12:11:16ZTimothe LittLog files should not be closed until their successor is open.From #1042 as requested by @ondrej :
> Identifying and debugging this would be much simpler if **named ensured that all errors are logged by changing logging such that a log file isn't closed until its successor is open** (assuming my g...From #1042 as requested by @ondrej :
> Identifying and debugging this would be much simpler if **named ensured that all errors are logged by changing logging such that a log file isn't closed until its successor is open** (assuming my guess is correct). This would guarantee that a failure to open gets logged in the previous logfile, which could continue to log. I have verified that the current logging code closes files before opening a successor
The quote is 11 months old - I haven't re-verified the observation in current code as I'm seriously underwater at the moment.https://gitlab.isc.org/isc-projects/dhcp/-/issues/100Building with bind 9.162022-01-20T10:30:13ZTomek MrugalskiBuilding with bind 9.16[Ubuntu 20.04 release notes](https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Bind_9.16) mention a problem with building isc-dhcp with bind 9.16. Depending on how complex the fix is, this may be something we could possibly fix.[Ubuntu 20.04 release notes](https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Bind_9.16) mention a problem with building isc-dhcp with bind 9.16. Depending on how complex the fix is, this may be something we could possibly fix.4.4.3-beta1https://gitlab.isc.org/isc-projects/bind9/-/issues/1795Some dnstap data may not be logged in BIND 9.15.6+2020-05-01T13:26:59ZMichał KępieńSome dnstap data may not be logged in BIND 9.15.6+The introduction of netmgr doubled the number of threads from which
dnstap data may be logged: previously, it could only happen from within
taskmgr worker threads; with netmgr, it can happen both from taskmgr
worker threads and from netw...The introduction of netmgr doubled the number of threads from which
dnstap data may be logged: previously, it could only happen from within
taskmgr worker threads; with netmgr, it can happen both from taskmgr
worker threads and from network threads. Since the argument [passed][1]
to `fstrm_iothr_options_set_num_input_queues()` was not updated to
reflect this change, some [calls][2] to `fstrm_iothr_get_input_queue()`
can now return `NULL`, effectively preventing some dnstap data from
being logged. Whether this bug is triggered or not depends on thread
scheduling order and packet distribution between network threads, but
will almost certainly be triggered on any recursive resolver sooner or
later.
This issue has been introduced by !2528 (specifically by commit
53f0b6c34d3fe01c885d8020d155061d55c19477), i.e. it affects BIND 9.15.6+.
It was not caught by the `dnstap` system test for two reasons:
- the problem is rarely triggered in that system test as a low number
of queries is sent to the tested servers,
- another rarely triggered issue (with the test code itself) has been
known to exist before and it has very similar symptoms.
I believe a fix for this issue warrants a release note.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/e2dd8f48b1ec923ef151708628d987fec1e73531/bin/named/server.c#L3680
[2]: https://gitlab.isc.org/isc-projects/bind9/-/blob/e2dd8f48b1ec923ef151708628d987fec1e73531/lib/dns/dnstap.c#L449-450May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/kea/-/issues/1200Escape character code in keactrl2020-11-06T13:18:26ZFrancis DupontEscape character code in keactrlLooking the FreeBSD source package (aka ports) for Kea I found a patch to change Escape characters from '\e' to '\033' in keactrl.in near lines 520. I support this change as the \033 is clearly more portable.Looking the FreeBSD source package (aka ports) for Kea I found a patch to change Escape characters from '\e' to '\033' in keactrl.in near lines 520. I support this change as the \033 is clearly more portable.kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1794zone unsigned while re-salting2024-01-04T16:34:25ZEvan Huntzone unsigned while re-saltingA while ago I set up a test server to generate a lot of IXFR traffic; it has a very large zone, and a script that loops forever running `rndc signing -nsec3param` to change the salt, generating a new NSEC3 chain every time the previous o...A while ago I set up a test server to generate a lot of IXFR traffic; it has a very large zone, and a script that loops forever running `rndc signing -nsec3param` to change the salt, generating a new NSEC3 chain every time the previous one finishes building.
I've just noticed that the server doesn't behave the way I expected during re-salting. When the new chain starts building, the old chain's NSEC3PARAM is deleted immediately, and a new one isn't created until the new chain is complete. In a zone with half a million records, that takes hours. During that time, with no NSEC or NSEC3PARAM, the server treats the zone as if it were transitioning to unsigned. It doesn't return RRSIGs in any response except zone transfers or explicit RRSIG queries. It also hides DNSKEY in type=ANY queries.
I had thought the old chain wouldn't be removed until the new one was fully in place. If the zone is small, the new chain builds quickly enough to avoid any problems, but for a big zone there would be validation failures during the transition.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1199Kea fails to build with macOS homebrew postgresql 12.2_12020-05-22T17:36:01ZFrancis DupontKea fails to build with macOS homebrew postgresql 12.2_1The postgresql 12.2_1 from homebrew on macOS can fail to build: src/lib/pgsql/pgsql_connection.cc does not compile because a boost header includes the wrong math.h and some functions like signbit can't be found.The postgresql 12.2_1 from homebrew on macOS can fail to build: src/lib/pgsql/pgsql_connection.cc does not compile because a boost header includes the wrong math.h and some functions like signbit can't be found.kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/258BIND-free mode2020-05-07T12:30:36ZVicky Riskvicky@isc.orgBIND-free modeAll of our users at the outset, and maybe for a while, will be using Stork Kea and not for BIND.
Can we make it a configurable setting whether you are using Stork with BIND or Kea, and hide the BIND dashboard or menu choices, links to t...All of our users at the outset, and maybe for a while, will be using Stork Kea and not for BIND.
Can we make it a configurable setting whether you are using Stork with BIND or Kea, and hide the BIND dashboard or menu choices, links to the BIND docs, etc, if the admin is not using it with BIND?
At one point when I suggested this, Godfryd said that this might be something Stork could just infer from the servers it was configure to monitor - that is fine too, and I suppose even cooler, but either is ok.
There are several places in the UI where we mention BIND, perhaps we can remove those as well for the time being.0.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/257Configurable thresholds for alerting2023-07-25T13:42:33ZVicky Riskvicky@isc.orgConfigurable thresholds for alertingObviously one of the main purposes of a dashboard is to display warnings and alerts, indicators of degradation or failures.
As an administrator I am going to want to adjust the thresholds for these alerts so that they reflect the condit...Obviously one of the main purposes of a dashboard is to display warnings and alerts, indicators of degradation or failures.
As an administrator I am going to want to adjust the thresholds for these alerts so that they reflect the conditions that are specifically alarming to me - which may vary depending on the criticality of the service being monitored (e.g. is it a paid production service, an service for internal users, a test network or something like free guest wifi).
I would like Stork to assign defaults for these thresholds, enable me to adjust the default values (e.g. global to Stork), and override them on a per server basis.
thresholds we may want to enable alarming on, eventually:
* [ ] pool utilization (high - red, approaching high - yellow)
* [ ] LPS (high, low) (Ideally what we want is variance from the usual LPS but I dk if there is any way for us to determine what is usual, given there may be quite a lot of daily and weekly variation.)
* [ ] cpu utilization (on Kea, maybe also on the db backend?)
* [ ] # of rejected leases?
* [ ] is there something we should monitor wrt the LFC, does it build up a backlog or something?
* [ ] database connection quality (delay in responses?)
* [ ] other platform factors (temperature, is that a thing we get?, is there some alarm about low available memory?)
* [ ] report when an updated package is available in the UI (likely that Stork packages will have security vulnerabilities because of web dependencies from outside Stork) - presumably when there is a new package for the same Stork version, that is due to a security issue.
* [ ] conflicts when the operator is running multiple Keas with the same address range, using a shared lease db
* [ ] ring buffer length/size to identify when over-long buffers cause cascading retriesbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1198bump up lib versions before 1.7.72020-04-24T18:05:58ZRazvan Becheriubump up lib versions before 1.7.7kea1.7.7Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1793failed query to a `forward only` forwarder increments `serverquota` counter (...2023-11-02T16:58:14ZCathy Almondfailed query to a `forward only` forwarder increments `serverquota` counter (spilled due to server quota)As observed in [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
I was inspecting the stats output and was very surprised to see this:
` 13779 spilled due to server quota`
The server in questi...As observed in [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
I was inspecting the stats output and was very surprised to see this:
` 13779 spilled due to server quota`
The server in question does not have `fetches-per-server` configured, so this defaults to zero (unlimited). But yet...
Looking at the code - I suspect there's a failure mode that drops through the 'out' block in fctx_getaddresses() without resetting all_spilled (which starts at 'true').
```c
static isc_result_t
fctx_getaddresses(fetchctx_t *fctx, bool badcache) {
dns_rdata_t rdata = DNS_RDATA_INIT;
isc_result_t result;
dns_resolver_t *res;
isc_stdtime_t now;
unsigned int stdoptions = 0;
dns_forwarder_t *fwd;
dns_adbaddrinfo_t *ai;
bool all_bad;
dns_rdata_ns_t ns;
bool need_alternate = false;
bool all_spilled = true;
```
...
```c
/*
* If all of the addresses found were over the
* fetches-per-server quota, return the configured
* response.
*/
if (all_spilled) {
result = res->quotaresp[dns_quotatype_server];
inc_stats(res, dns_resstatscounter_serverquota);
}
```
This is a server that is using global forwarding, so we skip case 'normal_nses', which is where 'all_spilled' is normally reset from true to false during processing:
```c
if (fctx->fwdpolicy == dns_fwdpolicy_only)
goto out;
```
So I'm guessing that what's been 'counted' and then reported here, is failures in getting responses back from any of the global forwarders (which tallies quite nicely with the problem I'm investigating - even though this wasn't a counter I was expecting to see in the stats!).
The assumption seems to be if it's a failure for any other reason than fetch-limits, that something will reset the 'all_spilled' flag - it would appear that assumption is flawed for some configurations and situations. Could someone have a look at this please - it should be an easy one to fix.
I note that this has also been noticed before on bind-users:
https://lists.isc.org/pipermail/bind-users/2016-June/097011.html
I observed this in 9.11.15-S1, but the code path looks the same still on master.
Requested changes:
- [ ] fix serverquota counter
- [ ] add a new counter for specifically for situation when all forwarders have failedNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1792Convert the checks from testsummary.sh into log driver (run.sh)2020-06-04T16:06:42ZOndřej SurýConvert the checks from testsummary.sh into log driver (run.sh)The checks for:
1. coredumps
2. assertion failures
3. tsan reports
needs to be moved into the log driver (`run.sh`)The checks for:
1. coredumps
2. assertion failures
3. tsan reports
needs to be moved into the log driver (`run.sh`)June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/kea/-/issues/1197qualifying_suffix is deprecated and dhcp6_parser.yy must be updated2020-09-14T14:59:08ZRazvan Becheriuqualifying_suffix is deprecated and dhcp6_parser.yy must be updatedkea1.9.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/256add support for global search2020-04-30T08:47:27ZMichal Nowikowskiadd support for global search0.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1791Explore if we need to make changes for OpenSSL 3.0.02021-10-05T12:48:05ZMark AndrewsExplore if we need to make changes for OpenSSL 3.0.0OpenSSL 3.0.0 alpha1 has just been released. Explore if there are changes needed to support working with OpenSSL 3.0.0.OpenSSL 3.0.0 alpha1 has just been released. Explore if there are changes needed to support working with OpenSSL 3.0.0.https://gitlab.isc.org/isc-projects/stork/-/issues/255Setting for BIND or Kea interface2020-05-05T16:16:00ZVicky Riskvicky@isc.orgSetting for BIND or Kea interfaceOur users are going to be either Kea users or BIND users. At the moment, there is no compelling use for having both in the same UI. I would like a setting, such as a per-user setting possibly, that establishes whether we are providing a ...Our users are going to be either Kea users or BIND users. At the moment, there is no compelling use for having both in the same UI. I would like a setting, such as a per-user setting possibly, that establishes whether we are providing a BIND dashboard or a Kea dashboard. If a user sets Stork up for Kea, then we should not display menus or metrics or links (e.g. documentation links) for BIND.https://gitlab.isc.org/isc-projects/stork/-/issues/254Update templates for new Kea cumulative assigned statistics2022-11-16T11:54:50ZFrancis DupontUpdate templates for new Kea cumulative assigned statisticsKea 1.7.7 now has a new statistic that shows an ever increasing number of assigned addresses. The customer wanted to observe how many devices were provisioned in his network each day (he'll be resetting this every midnight).Kea 1.7.7 now has a new statistic that shows an ever increasing number of assigned addresses. The customer wanted to observe how many devices were provisioned in his network each day (he'll be resetting this every midnight).backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/253paging bar elements are misaligned2022-02-04T09:12:02ZMichal Nowikowskipaging bar elements are misalignedThis happens on subnets page, but can appear on other pages too.
![image](/uploads/0868b4faf7b7acc94e4e19cf49173247/image.png)This happens on subnets page, but can appear on other pages too.
![image](/uploads/0868b4faf7b7acc94e4e19cf49173247/image.png)backlogMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1787BIND (master) does not work with krb5 1.18 (NegoEx)2020-06-23T11:47:32ZMichał KępieńBIND (master) does not work with krb5 1.18 (NegoEx)Current `master` does not work with krb5 1.18 (released in February
2020) - `nsupdate` and `tsiggss` system tests are consistently failing.
`git bisect` claims that an [upstream commit][1] implementing
[NegoEx][2]) is the culprit.
This ...Current `master` does not work with krb5 1.18 (released in February
2020) - `nsupdate` and `tsiggss` system tests are consistently failing.
`git bisect` claims that an [upstream commit][1] implementing
[NegoEx][2]) is the culprit.
This is only an issue for `master` as we do not use krb5's SPNEGO
mechanism in any other branch. Older branches either use an internal
SPNEGO implementation or no SPNEGO mechanism at all when
`--disable-isc-spnego` is used.
Out of all our Docker images, only the Tumbleweed one has krb5 1.18,
though - as luck would have it - the `krb5-devel` package there installs
`krb5-config` into a custom prefix (`/usr/lib/mit`), which prevents
BIND's `./configure` from autodetecting it and thus BIND builds on
Tumbleweed lack GSSAPI support altogether. I will push a branch shortly
which fixes this so that the breakage can be demonstrated in CI.
I cannot say I understand GSSAPI, so this needs attention from someone
who does.
[1]: https://github.com/krb5/krb5/commit/c2ca2f26eaf817a6a7ed42257c380437ab802bd9
[2]: https://tools.ietf.org/html/draft-zhu-negoex-04BIND 9.17 BackburnerOndřej SurýOndřej Surý