ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-03-04T10:29:50Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2532TSAN: digdelv:3 sanitizer report(s) found2021-03-04T10:29:50ZMatthijs Mekkingmatthijs@isc.orgTSAN: digdelv:3 sanitizer report(s) foundS:digdelv:2021-02-18T22:30:54+0000
Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
T:digdelv:1:A
A:digdelv:System test digdelv
I:digdelv:PORTS:20841,20842...S:digdelv:2021-02-18T22:30:54+0000
Job [#1507620](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507620) failed for 3d340ecfd2f4a703608a001c6821949b534c9312:
```
T:digdelv:1:A
A:digdelv:System test digdelv
I:digdelv:PORTS:20841,20842,20843,20844,20845,20846,20847,20848,20849,20850,20851,20852,20853
I:digdelv:starting servers
...
...
I:digdelv:checking mdig +multi +norrcomments works for DNSKEY (when default is rrcomments)(89)
I:digdelv:failed
I:digdelv:checking mdig +multi +norrcomments works for SOA (when default is rrcomments)(90)
I:digdelv:failed
I:digdelv:check mdig +yaml output (91)
I:digdelv:failed
...
I:digdelv:exit status: 3
I:digdelv:stopping servers
I:digdelv:3 sanitizer report(s) found
R:digdelv:FAIL
E:digdelv:2021-02-18T22:31:35+0000
FAIL digdelv (exit status: 1)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2531TSAN: rrl: 15 sanitizer report(s) found2021-03-04T10:29:39ZMatthijs Mekkingmatthijs@isc.orgTSAN: rrl: 15 sanitizer report(s) foundJob [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
=========
S:rrl:2021-02-25T08:54:57+0000
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTS:18835,18836,18837,188...Job [#1527486](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1527486) failed for 89c47b3b42c30fecdc515bee1dfbd954f29aeec0:
```
=========
S:rrl:2021-02-25T08:54:57+0000
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTS:18835,18836,18837,18838,18839,18840,18841,18842,18843,18844,18845,18846,18847
I:rrl:starting servers
I:rrl:exit status: 0
I:rrl:stopping servers
I:rrl:15 sanitizer report(s) found
R:rrl:FAIL
E:rrl:2021-02-25T08:55:24+0000
FAIL rrl (exit status: 1)
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2530Bind 9.16.11 segfault on DLZ with mysql2022-03-01T09:45:37ZjpsollieBind 9.16.11 segfault on DLZ with mysql### Summary
When running bind with DLZ against a mysql database, the system aborts with segfault
This database is set up to answer all spam domains
### BIND version used
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 ...### Summary
When running bind with DLZ against a mysql database, the system aborts with segfault
This database is set up to answer all spam domains
### BIND version used
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 5.10.17+ #8 SMP Mon Feb 22 18:54:47 CET 2021
built by make with '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--docdir=/usr/share/doc/bind-9.16.11' '--htmldir=/usr/share/doc/bind-9.16.11/html' '--with-sysroot=/' '--libdir=/usr/lib64' 'AR=/usr/bin/x86_64-pc-linux-gnu-ar' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--without-readline' '--with-openssl=/usr' '--without-cmocka' '--enable-linux-caps' '--disable-dnsrps' '--disable-dnstap' '--disable-fixed-rrset' '--without-dlz-bdb' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--without-gssapi' '--without-json-c' '--without-dlz-ldap' '--with-dlz-mysql' '--without-dlz-odbc' '--without-dlz-postgres' '--without-lmdb' '--without-libxml2' '--with-zlib' '--without-python' '--with-maxminddb' '--enable-geoip' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=znver1 -O3 -ggdb3 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.0
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: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
### Steps to reproduce
1. install BIND 9.16.11 with DLZ support
2. install mariadb 10.5.8
3. install DLZ converted spam domain list (view attachment)
4. install DLZ connector
### What is the current *bug* behavior?
Bind crashes with segfaults, when using file instead of dlz, everything is OK.
### What is the expected *correct* behavior?
Bind loads zones + runs correctly
### Relevant configuration files
DLZ connector:
```
dlz "null_dlz" {
database "mysql
{host=127.0.0.1 port=3306 dbname=dlz_null ssl=false user=named pass=named}
{select '$zone$' AS zone from dns_records where zone = 'null' OR zone = '$zone$' LIMIT 1}
{select ttl, type, mx_priority, case when lower(type)='txt' then concat('\"', data, '\"')
else data end from dns_records where (zone = 'null' OR zone = '$zone$') and (host = '*' OR host = '$record$') AND NOT (type = 'SOA' or type='NS')}
{select ttl, type, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum
from dns_records where (zone = 'null' OR zone = '$zone$') AND (type = 'SOA' or type='NS')}
{select ttl, type, host, mx_priority, data, resp_person, serial, refresh, retry, expire,
minimum from dns_records where (zone = 'null' OR zone = '$zone$') and NOT (type = 'SOA' or type = 'NS')}
{select '$zone$' AS zone from xfr_table where (zone = 'null' OR zone = '$zone$') and client = '$client$'}
{update data_count set count = count + 1 where (zone ='null' OR zone = '$zone$') AND client = '$client$'}";
search no;
};
include "blacklist.inc.dlz"
```
SQL database dump:
```
Enter password:
-- MariaDB dump 10.18 Distrib 10.5.8-MariaDB, for Linux (x86_64)
--
-- Host: localhost Database: dlz_null
-- ------------------------------------------------------
-- Server version 10.5.8-MariaDB-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `data_count`
--
DROP TABLE IF EXISTS `data_count`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `data_count` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`count` bigint(20) unsigned NOT NULL DEFAULT 0,
`zone` varchar(255) DEFAULT 'null',
`client` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `zone` (`zone`)
) ENGINE=Aria AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `data_count`
--
LOCK TABLES `data_count` WRITE;
/*!40000 ALTER TABLE `data_count` DISABLE KEYS */;
INSERT INTO `data_count` VALUES (1,0,'null','');
/*!40000 ALTER TABLE `data_count` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `dns_records`
--
DROP TABLE IF EXISTS `dns_records`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `dns_records` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`zone` varchar(255) NOT NULL,
`host` varchar(255) NOT NULL DEFAULT '@',
`type` varchar(255) NOT NULL,
`data` text DEFAULT NULL,
`ttl` int(11) NOT NULL DEFAULT 86400,
`mx_priority` int(11) DEFAULT NULL,
`refresh` int(11) DEFAULT NULL,
`retry` int(11) DEFAULT NULL,
`expire` int(11) DEFAULT NULL,
`minimum` int(11) DEFAULT NULL,
`serial` bigint(20) DEFAULT NULL,
`resp_person` varchar(255) DEFAULT NULL,
`primary_ns` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `type` (`type`),
KEY `host` (`host`),
KEY `zone` (`zone`),
KEY `zone_host_index` (`zone`(30),`host`(30)),
KEY `type_index` (`type`(8))
) ENGINE=Aria AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `dns_records`
--
LOCK TABLES `dns_records` WRITE;
/*!40000 ALTER TABLE `dns_records` DISABLE KEYS */;
INSERT INTO `dns_records` VALUES (1,'null','@','SOA',NULL,180,NULL,10800,7200,604800,86400,2011091101,'localhost.','admin.localhost.'),(2,'null','@','NS','localhost',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(3,'null','@','A','0.0.0.0',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(4,'null','*','A','0.0.0.0',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(5,'null','*','AAAA','::',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
/*!40000 ALTER TABLE `dns_records` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `xfr_table`
--
DROP TABLE IF EXISTS `xfr_table`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `xfr_table` (
`zone` varchar(255) NOT NULL,
`client` varchar(255) NOT NULL,
KEY `zone` (`zone`),
KEY `client` (`client`),
KEY `zone_client_index` (`zone`(30),`client`(30))
) ENGINE=Aria DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `xfr_table`
--
LOCK TABLES `xfr_table` WRITE;
/*!40000 ALTER TABLE `xfr_table` DISABLE KEYS */;
INSERT INTO `xfr_table` VALUES ('null','*');
/*!40000 ALTER TABLE `xfr_table` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2021-02-25 10:21:58
```
GDB backtrace:
```
(gdb) setargs -d 1 -u named -n 1 -g -c /etc/named/named2.conf
(gdb) run
... -- truncated
Query String: select 'paczkonnat.app' AS zone from dns_records where zone = 'null' OR zone = 'paczkonnat.app' LIMIT 1
Thread 3 "isc-worker0000" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6211640 (LWP 20149)]
0x00007ffff7116746 in strlen () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7116746 in strlen () from /lib64/libc.so.6
#1 0x00005555555ab3bd in sdlzh_build_querystring (mctx=mctx@entry=0x5555555eb090, querylist=0x7fffd6acd210) at ../../contrib/dlz/drivers/sdlz_helper.c:287
#2 0x00005555555ac8ac in mysql_get_resultset (zone=<optimized out>, record=<optimized out>, client=<optimized out>, query=5, dbdata=0x7fffd6adfd68, rs=0x0) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:276
#3 0x00005555555ad5f7 in mysql_findzone (driverarg=<optimized out>, methods=<optimized out>, clientinfo=<optimized out>, name=0x7ffff6210740 "paczkonnat.app", dbdata=0x7fffd6adfd68) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:508
#4 mysql_findzone (driverarg=<optimized out>, dbdata=0x7fffd6adfd68, name=0x7ffff6210740 "paczkonnat.app", methods=<optimized out>, clientinfo=<optimized out>) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:478
#5 0x00007ffff7e70cc6 in dns_sdlzfindzone (driverarg=0x7ffff6b552e0, dbdata=0x7fffd6adfd68, mctx=0x5555555eb090, rdclass=<optimized out>, name=0x7fffde822720, methods=0x0, clientinfo=0x0, dbp=0x7ffff6210bd8) at sdlz.c:1681
#6 0x00007ffff7ed2c84 in zone_load (zone=0x7fffde8225e0, flags=<optimized out>, locked=locked@entry=true) at zone.c:2159
#7 0x00007ffff7ed3141 in zone_asyncload (task=0x7ffff091f220, event=<optimized out>) at zone.c:2303
#8 0x00007ffff7c91150 in dispatch (threadid=<optimized out>, manager=0x7ffff6b60010) at task.c:1152
#9 run (queuep=<optimized out>) at task.c:1344
#10 0x00007ffff7574fde in start_thread () from /lib64/libpthread.so.0
#11 0x00007ffff717973f in clone () from /lib64/libc.so.6
(gdb)
```
[blacklist.inc.dlz](/uploads/ce48ba8e26a6e4e5657c4a5d22e12d98/blacklist.inc.dlz)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2529Add __attribute__((malloc)) for isc_mempool_get2021-05-05T18:14:45ZMark AndrewsAdd __attribute__((malloc)) for isc_mempool_getisc_mempool_get() can fail so we need to ensure that all instances the returned value is checked for NULL. `__attribute__((malloc))` will catch missing cases at compile time where it is supported.isc_mempool_get() can fail so we need to ensure that all instances the returned value is checked for NULL. `__attribute__((malloc))` will catch missing cases at compile time where it is supported.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2528named does not check RDATA of the SOA record ending an AXFR2021-06-24T14:32:42ZMichał Kępieńnamed does not check RDATA of the SOA record ending an AXFRWhile `lib/dns/xfrin.c:xfr_rr()` [checks][1] whether the last RR in the
AXFR stream is an SOA record, it does not check its RDATA.
[RFC 5936 section 2.2][2] says:
An AXFR response that is transferring the zone's contents will
...While `lib/dns/xfrin.c:xfr_rr()` [checks][1] whether the last RR in the
AXFR stream is an SOA record, it does not check its RDATA.
[RFC 5936 section 2.2][2] says:
An AXFR response that is transferring the zone's contents will
consist of a series (which could be a series of length 1) of DNS
messages. In such a series, the first message MUST begin with the
SOA resource record of the zone, and the last message MUST conclude
with the same SOA resource record.
Meanwhile, `named` accepts the following AXFR stream as valid:
```
nil. 300 SOA localhost. root.nil. 3 300 300 604800 300
nil. 300 NS localhost.
nil. 300 SOA localhost. root.nil. 1 300 300 604800 300
```
This results in the following (rather confusing) set of log messages
being generated (note the serial number discrepancies):
```
24-Feb-2021 22:36:49.732 zone nil/IN: transferred serial 1
24-Feb-2021 22:36:49.732 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer status: success
24-Feb-2021 22:36:49.732 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 3 records, 121 bytes, 0.001 secs (121000 bytes/sec) (serial 3)
```
After processing the above transfer, `named` puts the SOA record with
serial number 1 into the zone database.
I do not think this problem poses a security threat, but I am reporting
it in a confidential issue to rather be safe than sorry.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/965848a11a1032d66807811e2f7e15676760d67f/lib/dns/xfrin.c#L637
[2]: https://tools.ietf.org/html/rfc5936#section-2.2June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2527Confusing IXFR logging in BIND 9.17.7+2022-03-01T09:41:21ZMichał KępieńConfusing IXFR logging in BIND 9.17.7+A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff...A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff50b899ed4264d1d as it removed an early `return`
statement from `lib/dns/xfrin.c:xfrin_recv_done()`.
Here is what is logged for a successful IXFR in BIND 9.17.7+:
24-Feb-2021 22:17:23.280 zone nil/IN: transferred serial 2
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: failed while receiving responses: no more
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer status: IXFR failed
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 4 records, 179 bytes, 0.016 secs (11187 bytes/sec) (serial 2)
These messages are quite confusing because by the time the "failed while
receiving responses: no more" message is logged, the IXFR is already
journalled and applied to the zone.
The simplest solution seems to be to "promote" `ISC_R_NOMORE` to
`ISC_R_SUCCESS` [after going through the ANSWER section of the
transfer][1].
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/965848a11a1032d66807811e2f7e15676760d67f/lib/dns/xfrin.c#L1342-1344Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2526Example configuration for authoritative DNS server for docker container is mi...2021-02-24T20:45:03ZMalte BögershausenExample configuration for authoritative DNS server for docker container is misleadingThe example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```...The example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```
mean that the DNS server is not accessible from outside the container (and there is no reason to access it from inside the container).
Additionally there is no filename suggested for the config file. If `named.conf` is used the default structure for config files is overridden.https://gitlab.isc.org/isc-projects/bind9/-/issues/2525Automated test for upgrading BIND2023-11-02T16:26:05ZVicky Riskvicky@isc.orgAutomated test for upgrading BINDsuggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the f...suggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the first scenario to address is migrating from the latest 9.11 version to the latest 9.16 version.
It might be good to measure how long the update takes, the time to reload (in case either of these are surprising that might indicate a problem), of course that bind restarts and reloads, maybe run a few queries??Not plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/488Perf: dedicated call to count authorized/unauthorized machines2022-11-16T11:55:06ZTomek MrugalskiPerf: dedicated call to count authorized/unauthorized machinesThe implementation introduced in !267 to get a list of unauthorized machines is pretty inefficient. It retrieves all the machines with all the configurations just to count them. We should optimize it. One way would be to have a dedicated...The implementation introduced in !267 to get a list of unauthorized machines is pretty inefficient. It retrieves all the machines with all the configurations just to count them. We should optimize it. One way would be to have a dedicated query for simply returning the number of machines.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/487Add missing TLS tests2021-03-29T13:20:20ZTomek MrugalskiAdd missing TLS testsWhile working on #483, a number of test gaps have been identified. Due to @godfryd's unexpected unavailability and approaching release date, @marcin and @tomek decided that the best way forward is to make an exception to the requirement ...While working on #483, a number of test gaps have been identified. Due to @godfryd's unexpected unavailability and approaching release date, @marcin and @tomek decided that the best way forward is to make an exception to the requirement for unit tests, merge #483 and implement the tests soon afterward. Hence this ticket.
The following tests are needed:
* [ ] extensions to PingMachine code in backend/server/restservice/machines.go:437, see https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_194921
* [ ] extensions to UpdateMachine code in backend/server/restservice/machines.go:536, see https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_194922
* [ ] better testing for DEB/RPM packages download, as suggested in https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_194941
* [ ] machines-page component received substantial updates, but there are no unit tests to cover this functionality, see https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_1949440.16Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/486agent-server TLS part 5: document machines registration in the ARM2021-03-02T07:38:52ZMarcin Siodelskiagent-server TLS part 5: document machines registration in the ARMDescribe the agents registration using agent's token and server's token in the Stork ARM. Describe all other operational aspects.Describe the agents registration using agent's token and server's token in the Stork ARM. Describe all other operational aspects.0.15Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/163More detailed logging for DHCPv6-PD operations2022-12-27T12:26:06ZMathieu PoussinMore detailed logging for DHCPv6-PD operations---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Yes
- Are you sure your feature is not already imp...---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Yes
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration? N/R
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists? No
**Is your feature request related to a problem? Please describe.**
Currently, we have some tools taking action from the data in the logs of ISC-DHCP, we have some tools that required the line to contain information about the peer IP and the link address, we had to fork the original isc-dhcp to modify the related log_info line to show the related data.
We have the following like generated
```
Reply PD: address 2001:bc8:xxxx:xxx::/56 to client with duid 00:03:00:01:43:69:26:64:49:b2 iaid = -1578006392 static, peer = fe80::e42:a1ff:fef1:8888, link = 2001:bc8:xxxx:x::1
```
Instead of
```
Reply PD: address 2001:bc8:xxxx:xxx::/56 to client with duid 00:03:00:01:43:69:26:64:49:b2 iaid = -1578006392 static
```
**Describe the solution you'd like**
The corresponding `log_info` line in `server/dhcpv6.c` should be updated to add the information
**Describe alternatives you've considered**
Forking it and maintaining it like we do. Rewriting a dhcpv6 implementation from scratch (we don't need any other feature in our case)
**Additional context**
N/R
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs?
I am not the one who can decide that for the company unfortunately
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
We already have a working implementation that we can pass to your thru MR. (it's just a few lines in a single file)
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.
Email is finehttps://gitlab.isc.org/isc-projects/bind9/-/issues/2524Coccinelle unhappy about lib/ns/tests/nstest.c2023-11-01T07:36:21ZMichal NowakCoccinelle unhappy about lib/ns/tests/nstest.cCoccinelle is [unhappy](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1522218) about `lib/ns/tests/nstest.c` on `main` and `v9_16`:
```
EXN: Failure("rule starting on line 26: already tagged token:\nC code context\nFile \"./lib/ns/te...Coccinelle is [unhappy](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1522218) about `lib/ns/tests/nstest.c` on `main` and `v9_16`:
```
EXN: Failure("rule starting on line 26: already tagged token:\nC code context\nFile \"./lib/ns/tests/nstest.c\", line 716, column 1, charpos = 16367\n around = 'if',\n whole content = \tif (qctx != NULL) {")
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2523Unable to thaw a frozen dynamic zone when KASP is configured.2021-04-01T11:20:19ZLM JogbäckUnable to thaw a frozen dynamic zone when KASP is configured.<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
A zone is configured as a dynamic zone and KASP with 'dnssec-policy default'.
When the zone is frozen it cannot be thawed afterwards.
### BIND version used
```
BIND 9.16.12-Debian (Stable Release) <id:aeb943d>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-9.16.12=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libuv version: 1.38.1
linked to libuv version: 1.38.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Freezing the zone:
```
# rndc freeze domain.name
```
Zones is frozen and dumped to file (including all KASP-generated records)
Thawing the zone:
```
# rndc thaw domain.name
rndc: 'thaw' failed: dynamic zone
```
### What is the current *bug* behavior?
Zone is frozen and cannot be thawed.
### What is the expected *correct* behavior?
Zone can be thawed :-)
### Relevant configuration files
Zone configuration:
```
zone "domain.name." {
type master;
file "/etc/bind/master/domain.name./zone.db";
update-policy {
grant local-ddns zonesub any;
};
dnssec-policy default;
};
```
### Relevant logs and/or screenshots
```
Feb 24 13:37:00 nic named[10000]: received control channel command 'freeze domain.name'
Feb 24 13:37:00 nic named[10000]: freezing zone 'domain.name/IN': success
```
```
Feb 24 13:38:12 nic named[10000]: received control channel command 'thaw domain.name'
Feb 24 13:38:12 nic named[10000]: thawing zone 'domain.name/IN': dynamic zone
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1729Feature request: DHCPv6 - use real MAC address from dhcp6 request (mac-source...2024-01-25T14:53:47ZVojtech PithartFeature request: DHCPv6 - use real MAC address from dhcp6 request (mac-sources=raw)This is a request to implement
```
"mac-sources": [ "raw" ]
```
within DHCPv6 configuration.
As the [documentation](https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#mac-hardware-addresses-in-dhcpv6) suggests, in principle DHCPv6 ...This is a request to implement
```
"mac-sources": [ "raw" ]
```
within DHCPv6 configuration.
As the [documentation](https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#mac-hardware-addresses-in-dhcpv6) suggests, in principle DHCPv6 server could extract MAC/hardware address information from raw sockets. :pray: Please do so.
Neither Kea nor [ISC DHCP](https://www.isc.org/dhcp/) nor any DHCPv6 server known to me can do this.
**Is your feature request related to a problem? Please describe.**
Yes. Deployment of IPv6 itself. It's no-go without reliable MAC-address-based DHCP in a large scale networks. All the other methods (`ipv6-link-local`, `client-link-addr-option`, etc) aren't reliable.
And unfortunately the whole concept of DUIDs is wrong.
**Describe the solution you'd like**
We simply need the reservation configuration like this
```
{
"hw-address": "00:01:02:03:04:05",
"ip-addresses": [ "2001:db8:1::101", "2001:db8:1::102" ]
},
```
to work reliably.
**Describe alternatives you've considered**
- rely on `client-link-addr-option` (option 79) ... many clients provide wrong MAC address here (for example of their *other* interface)
- try manage to acquire DUID of all current and future client hardware pieces ... too complicated (DUID not printed on stickers; many don't even show it on web interface; some randomly change it on firmware upgrade; dual-boot PCs have more than one)
**Funding its development** ...
no
**Participating in development** ...
I am willing to participate in the feature development. I'm a seasoned developer, new to Kea though. With some basic steering, I'd be able to help.
**Contacting you** ...
E-mail in my profile.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/485agent-server TLS part 4: adapt Stork demo to new machine registration methods2021-03-02T07:38:51ZMarcin Siodelskiagent-server TLS part 4: adapt Stork demo to new machine registration methodsAfter implementing #483 it is necessary to modify docker configuration and apply other changes to be able to run the demo with the new agent registration methods.After implementing #483 it is necessary to modify docker configuration and apply other changes to be able to run the demo with the new agent registration methods.0.15Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1728bump up version in configure.ac2021-02-24T12:26:41ZWlodzimierz Wencelbump up version in configure.ackea1.9.6Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1727DHCP6: ALLOC_ENGINE_V6_ALLOC_FAIL error seen in the logs2022-11-02T15:10:17ZlaaubertDHCP6: ALLOC_ENGINE_V6_ALLOC_FAIL error seen in the logs---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I'm using KEA DHCPv6 to assign two type of addresses:
- IPv6 loopback to router with an infinite lease
- IoT endpoint with a 30 days lease using r...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I'm using KEA DHCPv6 to assign two type of addresses:
- IPv6 loopback to router with an infinite lease
- IoT endpoint with a 30 days lease using rapid-commit
Each time KEA assigns an IPv6 address to an endpoint, I see the following warning message in the logs:
```
2021-02-22 02:48:30.828 INFO [kea-dhcp6.leases/1] DHCP6_LEASE_ALLOC duid=[00:03:00:06:00:a7:42:10:00:e9:06:fa], tid=0xdb0147: lease for address fd12:0:0:4::4 and iaid=0 has been allocated for 2592000 seconds
2021-02-22 02:48:30.828 WARN [kea-dhcp6.alloc-engine/1] ALLOC_ENGINE_V6_ALLOC_FAIL duid=[00:03:00:06:00:a7:42:10:00:e9:06:fa], tid=0xdb0147: failed to allocate an IPv6 address after 0 attempt(s)
```
But the endpoint actually got its address initially so everything looks good. After sometime and some churns in the network where the endpoint requests several times their addresses, KEA actually stops replying and we start seeing the following error:
```
2021-02-23 02:17:09.719 INFO [kea-dhcp6.leases/1] DHCP6_LEASE_ALLOC duid=[00:03:00:06:08:4f:a9:10:00:21:ad:e8], tid=0x2fa760: lease for address fd12:0:0:5::2 and iaid=0 has been allocated for 2592000 seconds
2021-02-23 02:17:09.719 WARN [kea-dhcp6.alloc-engine/1] ALLOC_ENGINE_V6_ALLOC_FAIL duid=[00:03:00:06:08:4f:a9:10:00:21:ad:e8], tid=0x2fa760: failed to allocate an IPv6 address after 0 attempt(s)
2021-02-23 02:17:09.720 ERROR [kea-dhcp6.packets/1] DHCP6_PACKET_SEND_FAIL failed to send DHCPv6 packet: pkt6 send failed: sendmsg() returned with an error: Message too long
```
At this point, the only way to recover is to delete the leases csv file and restart the DHCP server. It will recreate a new one and load the previous leases from kea-leases6.csv.2
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv6 daemon. (/uploads/f386848ed04dc709e249c36d2c5c53bb/kea-dhcp6.conf)
2. The IoT endpoints sends a DHCPv6 solicit which is relayed by a router
3. The server does the address allocation and add this warning message to the logs.
4. Initially the allocation works despite the warning message but after sometime, it starts failing.
**Expected behavior**
The server should be able to assign the IPv6 address without any error and in a reliable way.
**Environment:**
- Kea version: 1.6.3
- OS: Ubuntu 20.04 (based layer for a docker image deployed on a Centos7 host)
**Additional Information**
- Config file: [kea-dhcp6.conf](/uploads/4b4d3f0cff5a24e1984e25eef2dc8114/kea-dhcp6.conf)
- log file: [kea-dhcpv6.log](/uploads/6276fd92cca2dc0566328309653c3b2f/kea-dhcpv6.log)
- kea-leases6.csv lease file when the issue is happening: [kea-leases6.csv](/uploads/913ab70fad3186d15ff9b93c7dc1c22c/kea-leases6.csv)
- kea-leases6.csv.2 lease file when the issue is happening: [kea-leases6.csv.2](/uploads/4c61417d895904f2893c7fa2341df243/kea-leases6.csv.2)
**Contacting you**
e-mail is preferredbackloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2522Monitoring zone transfer dropped due to quota limits2022-03-01T09:58:59ZPeter DaviesMonitoring zone transfer dropped due to quota limitsMonitoring zone transfer dropped due to quota limits:
The maximum number of simultaneous outgoing zone transfers is defined by the value of “transfers-out” which is configurable within “options” and currently defaults to 10.
To b...Monitoring zone transfer dropped due to quota limits:
The maximum number of simultaneous outgoing zone transfers is defined by the value of “transfers-out” which is configurable within “options” and currently defaults to 10.
To better configure and supervise their servers, it would be useful for administrators to be able to retrieve information about the number of zone transfers that get dropped due to this quota limit.
An incremental counter that would record these occurrences has been suggested. The value of this counter could be exposed on the statistics channel.
[RT #17780 ](https://support.isc.org/Ticket/Display.html?id=17780)Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2521ThreadSanitizer: data race in memset after #24332021-03-04T10:29:23ZMichal NowakThreadSanitizer: data race in memset after #2433!4659 introduced ThreadSanitizer warnings identified by [GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507021) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507022).
GCC:
```
WARNING: ThreadSanitizer: data race ...!4659 introduced ThreadSanitizer warnings identified by [GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507021) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1507022).
GCC:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 free <null>
#1 default_memfree lib/isc/mem.c:440
#2 mem_put lib/isc/mem.c:363
#3 isc__mem_free lib/isc/mem.c:1012
#4 main bin/tools/mdig.c:2231
Previous read of size 1 at 0x000000000005 by thread T1:
#0 dns_name_fromtext lib/dns/name.c:1121
#1 sendquery bin/tools/mdig.c:596
#2 sendqueries bin/tools/mdig.c:779
#3 dispatch lib/isc/task.c:1152
#4 run lib/isc/task.c:1344
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 main bin/tools/mdig.c:2148
SUMMARY: ThreadSanitizer: data race in __interceptor_free
```
Clang:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by main thread:
#0 memset <null>
#1 memset /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10
#2 mem_put lib/isc/mem.c:361:3
#3 isc__mem_free lib/isc/mem.c:1012:2
#4 main bin/tools/mdig.c:2231:3
Previous read of size 4 at 0x000000000001 by thread T1:
#0 sendquery bin/tools/mdig.c:764:10
#1 sendqueries bin/tools/mdig.c:779:3
#2 dispatch lib/isc/task.c:1152:7
#3 run lib/isc/task.c:1344:2
Location is heap block of size 1120 at 0x000000000010 allocated by main thread:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:411:8
#2 mem_get lib/isc/mem.c:343:8
#3 mem_allocateunlocked lib/isc/mem.c:918:7
#4 isc__mem_allocate lib/isc/mem.c:935:7
#5 clone_default_query bin/tools/mdig.c:1831:10
#6 parse_args bin/tools/mdig.c:1959:11
#7 parse_args bin/tools/mdig.c:2049:4
#8 main bin/tools/mdig.c:2124:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 main bin/tools/mdig.c:2148:2
SUMMARY: ThreadSanitizer: data race in memset
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Ondřej SurýOndřej Surý