ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-03-22T11:02:58Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1740The gssapi and krb5 headers polute the public API2021-03-22T11:02:58ZOndřej SurýThe gssapi and krb5 headers polute the public APIThe GSSAPI usage currently exports the gssapi.h headers to the public API of libdns. The use of GSSAPI and KRB5 needs to become opaque, so it does not polute the libdns public API, so there's no need to include the headers in downstream...The GSSAPI usage currently exports the gssapi.h headers to the public API of libdns. The use of GSSAPI and KRB5 needs to become opaque, so it does not polute the libdns public API, so there's no need to include the headers in downstream users of the library.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/stork/-/issues/230add hosts db to stork demo on stork.lab.isc.org2020-04-14T10:27:40ZMichal Nowikowskiadd hosts db to stork demo on stork.lab.isc.orgCurrently hosts db container and kea with hosts reservations are not present in stork.lab.isc.org.
They should be added there.Currently hosts db container and kea with hosts reservations are not present in stork.lab.isc.org.
They should be added there.0.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1738Revise the contents of "./configure" summary2020-05-01T07:07:02ZMichał KępieńRevise the contents of "./configure" summary - Some of the checks in the summary printed out by `./configure` test
variables corresponding to options which were already removed.
- Some of the checks in the summary printed out by `./configure` test
incorrect variables w... - Some of the checks in the summary printed out by `./configure` test
variables corresponding to options which were already removed.
- Some of the checks in the summary printed out by `./configure` test
incorrect variables which causes misleading output.
- Some of the checks in the summary printed out by `./configure` use
Yoda conditions.
- Maybe drop `--enable-full-report`? Is there any harm in printing
all configuration options by default?May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)https://gitlab.isc.org/isc-projects/stork/-/issues/229server rpm/deb packages contain agent files2020-04-09T10:05:06ZMichal Nowikowskiserver rpm/deb packages contain agent filesref: https://gitlab.isc.org/isc-projects/stork/-/issues/227#note_122036ref: https://gitlab.isc.org/isc-projects/stork/-/issues/227#note_1220360.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/228Database model for Kea High Availability2020-04-15T15:01:47ZMarcin SiodelskiDatabase model for Kea High AvailabilityAs of Kea 0.6.0, the HA status is fetched directly from the monitored Kea servers and displayed in the UI. We'd like to move to a different model in which the Stork server is fetching the HA status from the servers and stores them in the...As of Kea 0.6.0, the HA status is fetched directly from the monitored Kea servers and displayed in the UI. We'd like to move to a different model in which the Stork server is fetching the HA status from the servers and stores them in the database. The UI can then fetch this information from the db along with some additional information not present in the response to the `status-get` command. Such information may include things like last failover event seen from the Stork server's perspective or anything else that the server is able to gather from the Kea servers over a period of time.
This ticket extends the Stork database to accommodate the HA specific information.0.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1737Coverity report: dst_key_gettime return value unchecked2020-04-29T11:50:37ZMatthijs Mekkingmatthijs@isc.orgCoverity report: dst_key_gettime return value unchecked```
** CID 292398: (CHECKED_RETURN)
/lib/dns/keymgr.c: 1288 in keymgr_key_init()
/lib/dns/keymgr.c: 1293 in keymgr_key_init()
/lib/dns/keymgr.c: 1296 in keymgr_key_init()
/lib/dns/keymgr.c: 1291 in keymgr_key_init()
``````
** CID 292398: (CHECKED_RETURN)
/lib/dns/keymgr.c: 1288 in keymgr_key_init()
/lib/dns/keymgr.c: 1293 in keymgr_key_init()
/lib/dns/keymgr.c: 1296 in keymgr_key_init()
/lib/dns/keymgr.c: 1291 in keymgr_key_init()
```May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1736stub zone foiled by minimal-responses2022-11-14T18:04:49ZDavid Zychstub zone foiled by minimal-responses### Summary
It appears that BIND stub zones whose nameservers need glue records (because the NS targets are inside the zone) do not function correctly if the authoritative nameservers are configured to return minimal-responses.
* autho...### Summary
It appears that BIND stub zones whose nameservers need glue records (because the NS targets are inside the zone) do not function correctly if the authoritative nameservers are configured to return minimal-responses.
* authoritative nameserver (adns) with zone "example.com" type master, listing itself as ns1.example.com
* recursive nameserver (rdns) with zone "example.com" type stub
### BIND version used
```
# named -V
BIND 9.11.17 (Extended Support Version) <id:65c9496>
running on Linux x86_64 3.10.0-862.2.3.el7.x86_64 #1 SMP Wed May 9 18:05:47 UTC 2018
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-threads' '--enable-ipv6' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-libjson' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS= -L/opt/isc/isc-bind/root/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with libjson-c version: 0.11
linked to libjson-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/opt/isc/isc-bind/named.conf
rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
named PID file: /var/opt/isc/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/isc-bind/run/named/named.lock
```
### Steps to reproduce
1. Configure two CentOS 7 instances (adns and rdns) running BIND 9.11.17-1.1.el7 from https://copr.fedorainfracloud.org/coprs/isc/bind-esv/
(For convenience, use low TTLs and disable DNSSEC validation. Don't configure minimal-responses yet. See full configs below.)
2. On rdns, verify that the stub zone works properly:
```
[root@dmrz-test-rdns ~]# dig @localhost +noall +ans example.com txt
example.com. 60 IN TXT "hello world"
[root@dmrz-test-rdns ~]# dig @localhost +noall +ans ns1.example.com a
ns1.example.com. 60 IN A 10.224.255.51
[root@dmrz-test-rdns ~]# cat /var/opt/isc/isc-bind/named/data/example.com
$ORIGIN .
$TTL 60 ; 1 minute
example.com IN SOA ns1.example.com. dns-admin.example.com. (
1 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
60 ; minimum (1 minute)
)
NS ns1.example.com.
$ORIGIN example.com.
ns1 A 10.224.255.51
```
As expected, our local file contains the SOA, NS, and glue records for this zone.
3. On adns, configure `minimal-responses yes;`.
Also edit the master zone file to add a fictitious ns2.example.com (NS record and A record) and increment SOA serial to 2, in order to illustrate how these changes are received.
Finally, `rndc reload`.
4. Observe at this point that rdns can still answer queries (because the local file already contains one working glue record), but rdns does not *update* its local glue records to reflect recent changes in the authoritative data.
```
[root@dmrz-test-rdns ~]# rndc refresh example.com
zone refresh queued
[root@dmrz-test-rdns ~]# dig @localhost +noall +ans ns2.example.com a
ns2.example.com. 60 IN A 192.168.1.1
[root@dmrz-test-rdns ~]# cat /var/opt/isc/isc-bind/named/data/example.com
$ORIGIN .
$TTL 60 ; 1 minute
example.com IN SOA ns1.example.com. dns-admin.example.com. (
2 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
60 ; minimum (1 minute)
)
NS ns1.example.com.
NS ns2.example.com.
$ORIGIN example.com.
ns1 A 10.224.255.51
```
Note that our local file now contains the updated serial and the new NS record, but *not* the new A record.
5. Remove the existing local file on rdns and try to bootstrap it again from scratch.
```
[root@dmrz-test-rdns ~]# systemctl stop isc-bind-named
[root@dmrz-test-rdns ~]# rm /var/opt/isc/isc-bind/named/data/example.com
rm: remove regular file ‘/var/opt/isc/isc-bind/named/data/example.com’? y
[root@dmrz-test-rdns ~]# systemctl start isc-bind-named
```
Observe that rdns now has no glue records for the stub zone at all:
```
[root@dmrz-test-rdns ~]# cat /var/opt/isc/isc-bind/named/data/example.com
$ORIGIN .
$TTL 60 ; 1 minute
example.com IN SOA ns1.example.com. dns-admin.example.com. (
2 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
60 ; minimum (1 minute)
)
NS ns1.example.com.
NS ns2.example.com.
```
and is consequently unable to answer queries for the zone:
```
[root@dmrz-test-rdns ~]# dig @localhost example.com txt
; <<>> DiG 9.11.17 <<>> @localhost example.com txt
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46974
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 098de2585799f5c405e3568b5e87f44315250340a61a221b (good)
;; QUESTION SECTION:
;example.com. IN TXT
;; Query time: 4000 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sat Apr 04 02:43:15 UTC 2020
;; MSG SIZE rcvd: 68
```
6. Optionally rectify the problem by removing `minimal-responses yes;` and incrementing the SOA serial again (on adns), then `rndc refresh example.com` (on rdns).
### What is the current *bug* behavior?
As shown above, a newly bootstrapped rdns returns SERVFAIL for queries in the stub zone, while an established rdns which already knows some glue records will not immediately break but will gradually drift (and possibly break later on).
The latter behavior is particularly insidious; it turns out that my production resolvers have been in this state ever since I changed my authoritative nameservers over a year ago, but since they haven't stopped working, I never noticed anything was amiss until I tried to stand up a brand new resolver.
### What is the expected *correct* behavior?
I think the stub zone on rdns should notice whenever the NS records it retrieves from the master will require glue in order to use, and (if no glue records were included in the additional section) should send follow-up A/AAAA queries to the master to retrieve them.
Failing that (i.e. if ISC determines that it would complicate the implementation of stub zones too much), the description of stub zones in https://ftp.isc.org/isc/bind9/9.11.17/doc/arm/Bv9ARM.ch06.html#zone_statement should clearly warn that this use case is not supported. FWIW if the decision is not to support it, it may be less fragile to also stop supporting it even when the master _does_ provide an additional section.
Further wrinkle: will the same master which knows the NS records always know the A records (in cases where glue is required)? I would think so in the real world, but I can imagine a theoretical corner-case scenario where asking that master for the A record might give a referral response instead:
* com.
```
example.com. NS parent-ns1.childzone.example.com.
parent-ns1.childzone.example.com. A 10.224.255.51
```
* example.com. (served by 10.224.255.51)
```
example.com. NS parent-ns1.childzone.example.com.
childzone.example.com. NS child-ns1.childzone.example.com.
child-ns1.childzone.example.com. A 10.224.255.53
```
* childzone.example.com. (served by 10.224.255.53)
```
childzone.example.com. NS child-ns1.childzone.example.com.
child-ns1.childzone.example.com. A 10.224.255.53
parent-ns1.childzone.example.com. A 10.224.255.51
```
### Relevant configuration files
adns:/etc/opt/isc/isc-bind/named.conf
```
options {
directory "/var/opt/isc/isc-bind/named/data";
dnssec-validation auto;
allow-query { any; };
recursion no;
#minimal-responses yes;
};
logging {
channel default_debug {
file "named.run";
print-time yes;
severity dynamic;
};
};
zone "example.com" IN {
file "example.com";
type master;
};
```
adns:/var/opt/isc/isc-bind/named/data/example.com
```
$ORIGIN .
$TTL 60
example.com IN SOA ns1.example.com. dns-admin.example.com. (
1 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
60 ; minimum (1 minute)
)
NS ns1.example.com.
TXT "hello world"
$ORIGIN example.com.
ns1 A 10.224.255.51
```
rdns:/etc/opt/isc/isc-bind/named.conf
```
options {
directory "/var/opt/isc/isc-bind/named/data";
allow-query { localhost; };
recursion yes;
dnssec-validation no;
};
logging {
channel default_debug {
file "named.run";
print-time yes;
severity dynamic;
};
};
zone "example.com" IN {
file "example.com";
type stub;
masters { 10.224.255.51; };
};
```November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/stork/-/issues/227Sanity checks for 0.6.02022-02-02T09:51:28ZTomek MrugalskiSanity checks for 0.6.0Please test latest master and put your sanity checks in this ticket.Please test latest master and put your sanity checks in this ticket.0.7https://gitlab.isc.org/isc-projects/stork/-/issues/226fill dashboard with some content2020-04-22T11:05:16ZMichal Nowikowskifill dashboard with some content0.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/225Host reservations from config are tossed by hosts puller2020-04-03T11:49:10ZMarcin SiodelskiHost reservations from config are tossed by hosts pullerApparently, host_cmds also returns hosts from the config. The hosts puller periodically fetching the hosts from Kea instances would delete hosts with non matching sequence id. The hosts fetched from the config have non matching sequence ...Apparently, host_cmds also returns hosts from the config. The hosts puller periodically fetching the hosts from Kea instances would delete hosts with non matching sequence id. The hosts fetched from the config have non matching sequence id, thus they are removed after first fetch of the hosts from the host_cmds. This must be corrected.0.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/224bump version to 0.62020-04-03T12:40:11ZTomek Mrugalskibump version to 0.6Need to bump up the version before 0.6 release, update changelog etc.Need to bump up the version before 0.6 release, update changelog etc.0.6https://gitlab.isc.org/isc-projects/kea/-/issues/1179inconsistent syntax context for database parameters2020-04-24T12:54:43ZFrancis Dupontinconsistent syntax context for database parametersAs all database parameters are in the same parser rule they are valid in all database contexts (lease, host and config) and of course (even it seems silly) for all database types (memfile, mysql, postgresql and cassandra).
It seems the ...As all database parameters are in the same parser rule they are valid in all database contexts (lease, host and config) and of course (even it seems silly) for all database types (memfile, mysql, postgresql and cassandra).
It seems the dhcp4_lexer.ll does not follow this rule so must be fixed.
Note this only change the parser error message: instead of accepting the parameter and eventually detect the misuse later the parameter is simply not recognized...kea1.7.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1734edns behaviour on forward only configuration2021-06-23T15:48:20ZPeter Daviesedns behaviour on forward only configuration### Description
I would like is a way to fix the advertised payload and guarantee it will always stayed fixed because I know my environment and I don't need BIND to try and work out what the forwarders or the intervening will permit.
1)...### Description
I would like is a way to fix the advertised payload and guarantee it will always stayed fixed because I know my environment and I don't need BIND to try and work out what the forwarders or the intervening will permit.
1) Use existing settings to infer how EDNS payload advertisement should work. e.g. if 'forward only' is enabled, don't do slow start. The danger with this is there might be a use case that needs both.
or
2) A new configuration parameter e.g. 'edns-udp-behaviour' that takes arguments "fixed" or "auto"
see RT [#16201]( https://support.isc.org/Ticket/Display.html?id=16201)Ondřej SurýOndřej Surýhttps://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/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/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 Backburner