ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-08-06T08:06:32Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/339Start/stop monitoring button for inactive services2020-08-06T08:06:32ZTomek MrugalskiStart/stop monitoring button for inactive servicesThere's a problem that Stork detects Kea CA has sockets for all 3 daemons: dhcpv4, dhcpv6 and ca. Usually, at least one of them is not running. This is reported as red.
There are two things that can be improved here:
- [x] services that...There's a problem that Stork detects Kea CA has sockets for all 3 daemons: dhcpv4, dhcpv6 and ca. Usually, at least one of them is not running. This is reported as red.
There are two things that can be improved here:
- [x] services that were never up and they don't have their own configs, could be reported as yellow warnings, not red errors
- [x] there should be a way to disable monitoring (a button "stop monitoring" would do the trick)
We discussed this a long time ago (I couldn't find the original note), also see [stork ui, line 113](https://pad.isc.org/p/stork-ui)0.10https://gitlab.isc.org/isc-projects/stork/-/issues/338Terminology cleanup (services)2024-03-26T11:25:44ZTomek MrugalskiTerminology cleanup (services)One of the conclusions of the UI discussions (see [stork ui](https://pad.isc.org/p/stork-ui)) was that the services naming is confusing. This ticket should cover 2 things:
- [ ] Propose naming update, have a discussion with everyone int...One of the conclusions of the UI discussions (see [stork ui](https://pad.isc.org/p/stork-ui)) was that the services naming is confusing. This ticket should cover 2 things:
- [ ] Propose naming update, have a discussion with everyone interested
- [ ] Once there's general consensus, implement the changes
Couple ideas: rename services to something more intuitive, maybe add a vocabulary, restructure the services view. Some ideas are more expensive to implement than others.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/337Add breadcrumbs navigation2024-02-05T06:40:26ZTomek MrugalskiAdd breadcrumbs navigationAs a follow-up to [our UI discussion](https://pad.isc.org/p/stork-ui) (also, see 2020-06-30 stork call notes), we decided to improve navigation and overall hierarchy in Stork. We want to do this by implementing breadcrumbs navigation.
U...As a follow-up to [our UI discussion](https://pad.isc.org/p/stork-ui) (also, see 2020-06-30 stork call notes), we decided to improve navigation and overall hierarchy in Stork. We want to do this by implementing breadcrumbs navigation.
UPDATE: The remaining task here is to make the breadcrumbs clickable.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2009Update ISC logo in documentation2020-07-16T06:54:50ZMark AndrewsUpdate ISC logo in documentationAugust 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/kea/-/issues/1319MySQL error 1452 in kea-admin tests2020-08-04T08:36:05ZFrancis DupontMySQL error 1452 in kea-admin testsThe last MySQAL test mysql_unused_subnet_id_test raised an error which does not make it to fail:
```
Processing /tmp/k1196/src/share/database/scripts/mysql/upgrade_9.1_to_9.2.sh file...
ERROR 1452 (23000) at line 8: Cannot add or update ...The last MySQAL test mysql_unused_subnet_id_test raised an error which does not make it to fail:
```
Processing /tmp/k1196/src/share/database/scripts/mysql/upgrade_9.1_to_9.2.sh file...
ERROR 1452 (23000) at line 8: Cannot add or update a child row: a foreign key constraint fails (`keatest`.`#sql-22f3_4b5d`, CONSTRAINT `fk_dhcp4_options_subnet` FOREIGN KEY (`dhcp4_subnet_id`) REFERENCES `dhcp4_subnet` (`subnet_id`) ON DELETE CASCADE ON UPDATE CASCADE)
Processing /tmp/k1196/src/share/database/scripts/mysql/upgrade_9.2_to_9.3.sh file...
This script upgrades 9.2 to 9.3. Reported version is 9.1. Skipping upgrade.
Database version reported after upgrade: 9.1
Wiping whole database keatest
PASSED mysql.unused_subnet_id_test
```
I think the second (subnet) new constraint fails, something as having a subnet option when the subnet itself does not exist.kea1.8.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1318Support 'include' files for configuration management2020-07-06T19:38:40ZVicky Riskvicky@isc.orgSupport 'include' files for configuration managementWe have a request from a support customer and prospective Kea user to add support for 'include' files for parity with ISC DHCP and to enable automated maintenance for larger configurations. This is a very popular feature in our other pro...We have a request from a support customer and prospective Kea user to add support for 'include' files for parity with ISC DHCP and to enable automated maintenance for larger configurations. This is a very popular feature in our other products.
[https://support.isc.org/Ticket/Display.html?id=16779]https://gitlab.isc.org/isc-projects/bind9/-/issues/2008dnstap-read.1 manpage installed even when dnstap is disabled2020-07-07T06:58:40ZAndreas Hasenackandreas@canonical.comdnstap-read.1 manpage installed even when dnstap is disabledThis is a minor issue in 9.16.4, but while building the Ubuntu packages I noticed that the `dnstap-read.1` manpage is being installed by `make install` even when `./configure --disable-dnstap` (or simple not using `--enable-dnstap`) was ...This is a minor issue in 9.16.4, but while building the Ubuntu packages I noticed that the `dnstap-read.1` manpage is being installed by `make install` even when `./configure --disable-dnstap` (or simple not using `--enable-dnstap`) was used. This is a change from bind 9.16.3.https://gitlab.isc.org/isc-projects/stork/-/issues/336Lease stats puller sends too many commands2020-08-11T15:22:53ZThomas MarkwalderLease stats puller sends too many commandsThe Keacommand instances created in func (statsPuller *StatsPuller) getLeaseStatsFromApp() are sent to all the dhcp Daemons instead of only to the dhcp4 or dhcp6 daemon:
```
// issue 2 commands to dhcp daemons at once to get their ...The Keacommand instances created in func (statsPuller *StatsPuller) getLeaseStatsFromApp() are sent to all the dhcp Daemons instead of only to the dhcp4 or dhcp6 daemon:
```
// issue 2 commands to dhcp daemons at once to get their lease stats for v4 and v6
cmds := []*agentcomm.KeaCommand{}
if dhcpDaemons["dhcp4"] {
cmds = append(cmds, &agentcomm.KeaCommand{
Command: "stat-lease4-get",
Daemons: &dhcpDaemons, <--- should not be the whole list
})
}
if dhcpDaemons["dhcp6"] {
cmds = append(cmds, &agentcomm.KeaCommand{
Command: "stat-lease6-get",
Daemons: &dhcpDaemons, <--- should not be the whole list
})
}
```0.10Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2007QNAME minimization may trigger "premature" priming queries2023-11-02T17:00:02ZMichał KępieńQNAME minimization may trigger "premature" priming queriesI do not believe this is a serious issue, maybe it can even be closed
with `-EWORKSASDESIGNED`, but perhaps there is room for improvement
here. I mostly wanted to document what is happening because figuring it
out required me to run `rr...I do not believe this is a serious issue, maybe it can even be closed
with `-EWORKSASDESIGNED`, but perhaps there is room for improvement
here. I mostly wanted to document what is happening because figuring it
out required me to run `rr` for 10 days straight :-)
With QNAME minimization enabled, a `named` resolver might send priming
queries before the last cached `./NS` response expires. The "root
cause" here is that the glue TTL for the `root-servers.net.` zone
differs between the root servers (3600000) and the servers authoritative
for `net.` (172800). This can be demonstrated using the following `dig`
invocations:
$ dig @a.root-servers.net root-servers.net. NS +norec
$ dig @a.gtld-servers.net root-servers.net. NS +norec +multi
Since the `root-servers.net.` zone is unsigned, the RFC 2181 trust level
of the RRsets found in the ADDITIONAL section of the referrals returned
by `net.` authoritative servers is *higher* than those returned in the
ADDITIONAL section of unsigned authoritative responses generated by the
root servers (which are authoritative for `root-servers.net.`). This
results in the 172800 TTL for `[a-m].root-servers.net/A(AAA)` overriding
the higher one received from the root servers.
To reproduce the issue:
1. Start a `named` resolver with QNAME minimization enabled and
preferably `max-stale-ttl 0;` set, so that the DB dump from the next
step is easier to interpret.
2. Do an `rndc dumpdb -cache`, then run:
grep -F root-servers.net named_dump.db
The result should contain lines like:
a.root-servers.net. 518399 A 198.41.0.4
b.root-servers.net. 518399 A 199.9.14.201
c.root-servers.net. 518399 A 192.33.4.12
d.root-servers.net. 518399 A 199.7.91.13
e.root-servers.net. 518399 A 192.203.230.10
f.root-servers.net. 518399 A 192.5.5.241
g.root-servers.net. 518399 A 192.112.36.4
h.root-servers.net. 518399 A 198.97.190.53
i.root-servers.net. 518399 A 192.36.148.17
j.root-servers.net. 518399 A 192.58.128.30
k.root-servers.net. 518399 A 193.0.14.129
l.root-servers.net. 518399 A 199.7.83.42
m.root-servers.net. 518399 A 202.12.27.33
These are cache entries created by the resolver priming query sent
during startup. The TTL is about 1 week, which is consistent with
`max-cache-ttl`.
3. Query the resolver for `root-servers.net/NS`. This will cause the
resolver to first ask the root servers about `_.net.`, which will
allow it to learn about the servers authoritative for
`root-servers.net.`. These will subsequently be queried for
`_.root-servers.net.`, triggering a referral with TTL=172800.
4. Repeat step 2. The relevant lines should now turn into something
like:
a.root-servers.net. 172799 A 198.41.0.4
b.root-servers.net. 172799 A 199.9.14.201
c.root-servers.net. 172799 A 192.33.4.12
d.root-servers.net. 172799 A 199.7.91.13
e.root-servers.net. 172799 A 192.203.230.10
f.root-servers.net. 172799 A 192.5.5.241
g.root-servers.net. 172799 A 192.112.36.4
h.root-servers.net. 172799 A 198.97.190.53
i.root-servers.net. 172799 A 192.36.148.17
j.root-servers.net. 172799 A 192.58.128.30
k.root-servers.net. 172799 A 193.0.14.129
l.root-servers.net. 172799 A 199.7.83.42
m.root-servers.net. 172799 A 202.12.27.33
With the TTL lowered, this resolver will now send the next priming query
in about 2 days instead of 6 days.
This scenario does not happen without QNAME minimization, in which case
the resolver would start processing the `root-servers.net/NS` query by
immediately querying the root servers - and since the root servers are
authoritative for `root-servers.net.`, the servers authoritative for
`net.` would not get a chance to send any TTL=172800 referrals.
I found this purely because I was curious why a `named` resolver whose
cache size limit never gets exceeded would *sometimes* send a priming
query earlier than 6 days after the last priming query. This "problem"
with the interaction of QNAME minimization with root servers is not
nearly as grave as the [other one][1] described in #1896.
I *think* triggering this requires a client query for something in the
`root-servers.net.` zone. The issue manifests itself two days later :-)
[1]: https://gitlab.isc.org/isc-projects/bind9/-/issues/1896#note_141492Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2006Coverity reports CHECKED_RETURN defects in keymgr2020-07-15T06:27:32ZMatthijs Mekkingmatthijs@isc.orgCoverity reports CHECKED_RETURN defects in keymgr```
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 304937: (CHECKED_RETURN)
/lib/dns/keymgr.c: 2004 in dns_keymgr_status()
/lib/dns/keymgr.c: 2005 in dns_keymgr_status()
__________________________________...```
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 304937: (CHECKED_RETURN)
/lib/dns/keymgr.c: 2004 in dns_keymgr_status()
/lib/dns/keymgr.c: 2005 in dns_keymgr_status()
________________________________________________________________________________________________________
*** CID 304937: (CHECKED_RETURN)
/lib/dns/keymgr.c: 2004 in dns_keymgr_status()
1998
1999 if (dst_key_is_unused(dkey->key)) {
2000 continue;
2001 }
2002
2003 // key data
>>> CID 304937: (CHECKED_RETURN)
>>> Calling "dst_key_getbool" without checking return value (as is done elsewhere 25 out of 29 times).
2004 dst_key_getbool(dkey->key, DST_BOOL_KSK, &ksk);
2005 dst_key_getbool(dkey->key, DST_BOOL_ZSK, &zsk);
2006 dns_secalg_format((dns_secalg_t)dst_key_alg(dkey->key), algstr,
2007 sizeof(algstr));
2008 isc_buffer_printf(&buf, "\nkey: %d (%s), %s\n",
2009 dst_key_id(dkey->key), algstr,
/lib/dns/keymgr.c: 2005 in dns_keymgr_status()
1999 if (dst_key_is_unused(dkey->key)) {
2000 continue;
2001 }
2002
2003 // key data
2004 dst_key_getbool(dkey->key, DST_BOOL_KSK, &ksk);
>>> CID 304937: (CHECKED_RETURN)
>>> Calling "dst_key_getbool" without checking return value (as is done elsewhere 25 out of 29 times).
2005 dst_key_getbool(dkey->key, DST_BOOL_ZSK, &zsk);
2006 dns_secalg_format((dns_secalg_t)dst_key_alg(dkey->key), algstr,
2007 sizeof(algstr));
2008 isc_buffer_printf(&buf, "\nkey: %d (%s), %s\n",
2009 dst_key_id(dkey->key), algstr,
2010 keymgr_keyrole(dkey->key));
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1317Remove boost code that's available in c++112022-11-02T15:10:17ZTomek MrugalskiRemove boost code that's available in c++11We moved to C++11 quite a long time ago. However, there are still many constructs in the code that use boost equivalents:
- [ ] BOOST_FOREACH => for (var : container)
- [ ] bind placeholdersWe moved to C++11 quite a long time ago. However, there are still many constructs in the code that use boost equivalents:
- [ ] BOOST_FOREACH => for (var : container)
- [ ] bind placeholdersbackloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2005Coverity is reporting double unlock.2020-07-16T07:29:44ZMark AndrewsCoverity is reporting double unlock.```
3159
10. Condition readable, taking true branch.
11. Condition !!(readable || writeable), taking true branch.
3160 REQUIRE(readable || writeable);
12. Condition readable, taking true branch.
3161 if (read...```
3159
10. Condition readable, taking true branch.
11. Condition !!(readable || writeable), taking true branch.
3160 REQUIRE(readable || writeable);
12. Condition readable, taking true branch.
3161 if (readable) {
13. Condition sock->listener, taking true branch.
3162 if (sock->listener) {
14. unlock: internal_accept unlocks sock->lock. [show details]
3163 internal_accept(sock);
15. Falling through to end of if statement.
3164 } else {
3165 internal_recv(sock);
3166 }
3167 }
3168
16. Condition writeable, taking true branch.
3169 if (writeable) {
17. Condition sock->connecting, taking false branch.
3170 if (sock->connecting) {
3171 internal_connect(sock);
3172 } else {
CID 303441 (#1-2 of 2): Double unlock (LOCK)
18. double_unlock: internal_send unlocks sock->lock while it is unlocked. [show details]
3173 internal_send(sock);
3174 }
3175 }
3176
3177 /* sock->lock is unlocked in internal_* function */
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2004ddns-confgen needs to be tested post install2021-10-06T05:33:40ZMark Andrewsddns-confgen needs to be tested post installddns-confgen needs to be tested post install as libtool gets in the way of testing in the build tree.ddns-confgen needs to be tested post install as libtool gets in the way of testing in the build tree.https://gitlab.isc.org/isc-projects/dhcp/-/issues/118Failed to start the dhclient2022-03-09T18:56:26ZgaoxingwangFailed to start the dhclientThe dhclient can not start when the pid in dhclient-eth0.pid file is holding by another process which is not a dhclient.
The process name corresponding to the PID is not checked.
I think we should check process name before using dhclien...The dhclient can not start when the pid in dhclient-eth0.pid file is holding by another process which is not a dhclient.
The process name corresponding to the PID is not checked.
I think we should check process name before using dhclient -r to kill the process whose pid is saved in /var/run/dhclient-eth0.pidOutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2003Remove redundant listener != NULL check2020-07-16T06:53:46ZMark AndrewsRemove redundant listener != NULL checkWith isc_mem_get no longer failing this check is no longer needed.
```
1258 } else {
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null...With isc_mem_get no longer failing this check is no longer needed.
```
1258 } else {
CID 304936 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking listener suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1259 if (listener != NULL) {
1260 listener->exiting = true;
1261 free_listener(listener);
1262 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2002some tests fail in 9.11 if newer bind.keys file is installed2020-07-09T06:52:03ZEvan Huntsome tests fail in 9.11 if newer bind.keys file is installedSystem tests that don't specify `dnssec-validation yes` or `bindkeys-file` in their configurations will try to open the installed `bind.keys` file, and in 9.11 they fail because `trust-anchors` isn't recognized.
In other branches this d...System tests that don't specify `dnssec-validation yes` or `bindkeys-file` in their configurations will try to open the installed `bind.keys` file, and in 9.11 they fail because `trust-anchors` isn't recognized.
In other branches this doesn't cause test failures but it should be cleaned up anyway; there's no good reason for a test to access installed files.BIND 9.17 BackburnerEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2001kasp, statschannel and rpzextra tests fail2020-07-03T17:42:45ZJean-Christophe Manciotkasp, statschannel and rpzextra tests fail- Ubuntu 20.04
- tag: v9_17_2
The first failure is identical to [an already reported issue](https://gitlab.isc.org/isc-projects/bind9/-/issues/1939).
Building & testing bind9 with:
```
autoreconf -f -i
./configure --build=x86_64-pc-li...- Ubuntu 20.04
- tag: v9_17_2
The first failure is identical to [an already reported issue](https://gitlab.isc.org/isc-projects/bind9/-/issues/1939).
Building & testing bind9 with:
```
autoreconf -f -i
./configure --build=x86_64-pc-linux-gnu \
--prefix=/usr --sysconfdir=/etc/bind --localstatedir=/ \
--datarootdir=/usr/share --docdir=/usr/share/doc --mandir=/usr/share/man \
--disable-native-pkcs11 \
--disable-querytrace \
--enable-auto-validation \
--enable-developer \
--enable-dnstap \
--enable-fixed-rrset \
--enable-full-report \
--enable-largefile \
--enable-linux-caps \
--enable-shared=yes \
--enable-static=yes \
--with-cmocka=yes \
--with-gnu-ld=yes \
--with-gperftools-profiler=yes \
--with-gssapi=/usr/bin/krb5-config \
--with-json-c=yes \
--with-libidn2 \
--with-libxml2=yes \
--with-lmdb=auto \
--with-maxminddb=yes \
--with-openssl=/usr/lib/x86_64-linux-gnu \
--with-tuning=large \
--with-zlib=yes
make all
bin/tests/system/ifconfig.sh up
make check
```
leads to: [test-suite.log](/uploads/0a11a1ac6148bdf6fe5dfaf535c9324f/test-suite.log)
Full log: [bind9_9_17_2_amd64.build.log](/uploads/a294c51d3bebb59194477f33e29df50a/bind9_9_17_2_amd64.build.log)https://gitlab.isc.org/isc-projects/dhcp/-/issues/117ISC DHCP does not build with gcc102022-01-20T12:10:27ZFrancis DupontISC DHCP does not build with gcc10Again an issue from the -fno-common by default with gcc10. Please look at #116 for more details (including what solution to apply and how to find needed changes without a gcc10 compiler).Again an issue from the -fno-common by default with gcc10. Please look at #116 for more details (including what solution to apply and how to find needed changes without a gcc10 compiler).4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2000[v9_17_2] autogen.sh has been removed2020-07-03T09:05:56ZJean-Christophe Manciot[v9_17_2] autogen.sh has been removed- what is the rationale behind this decision?
- is ```autoreconf -f -i``` still appropriate?- what is the rationale behind this decision?
- is ```autoreconf -f -i``` still appropriate?https://gitlab.isc.org/isc-projects/bind9/-/issues/1999Add a regular "make dist" job to CI2020-07-24T13:53:56ZMichal NowakAdd a regular "make dist" job to CIIt's easy to break `make dist` on `main`, we should test this scenario regularly, to prevent surprises like https://gitlab.isc.org/isc-private/bind9/-/jobs/1006996.It's easy to break `make dist` on `main`, we should test this scenario regularly, to prevent surprises like https://gitlab.isc.org/isc-private/bind9/-/jobs/1006996.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michal NowakMichal Nowak