ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-06-18T08:26:36Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1859Possible deadlock in unix/socket.c2020-06-18T08:26:36ZWitold KrecickiPossible deadlock in unix/socket.cIn process_fd we lock sock->lock, and then in internal_accept called from it we lock manager->lock while holding sock->lock
In isc_socketmgr_render{xml,json} we lock manager->lock and then for each sock we lock sock->lock.
That can cause...In process_fd we lock sock->lock, and then in internal_accept called from it we lock manager->lock while holding sock->lock
In isc_socketmgr_render{xml,json} we lock manager->lock and then for each sock we lock sock->lock.
That can cause a deadlock.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1858Silence TSAN in bin/nsupdate/nsupdate.c2020-05-28T01:14:09ZMark AndrewsSilence TSAN in bin/nsupdate/nsupdate.c```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by main thread:
#0 dns_rdataset_isassociated lib/dns/rdataset.c:143
#1 msgresetnames lib/dns/message.c:479
#2 msgreset lib/dns/message.c:564
#3 d...```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by main thread:
#0 dns_rdataset_isassociated lib/dns/rdataset.c:143
#1 msgresetnames lib/dns/message.c:479
#2 msgreset lib/dns/message.c:564
#3 dns_message_destroy lib/dns/message.c:837
#4 cleanup nsupdate.c:3245
#5 main nsupdate.c:3351
Previous write of size 8 at 0x000000000001 by thread T1:
#0 dns_rdataset_init lib/dns/rdataset.c:62
#1 getquestions lib/dns/message.c:1147
#2 dns_message_parse lib/dns/message.c:1740
#3 dns_request_getresponse lib/dns/request.c:1298
#4 update_completed nsupdate.c:2383
#5 dispatch lib/isc/task.c:1157
#6 run lib/isc/task.c:1331
#7 <null> <null>
Location is heap block of size 113 at 0x000000000012 allocated by thread T1:
#0 malloc <null>
#1 internal_memalloc lib/isc/mem.c:887
#2 mem_get lib/isc/mem.c:792
#3 isc___mempool_get lib/isc/mem.c:2083
#4 isc__mempool_get lib/isc/mem.c:3088
#5 dns_message_gettemprdataset lib/dns/message.c:2597
#6 dns_message_setquerytsig lib/dns/message.c:2897
#7 dns_request_getresponse lib/dns/request.c:1292
#8 update_completed nsupdate.c:2383
#9 dispatch lib/isc/task.c:1157
#10 run lib/isc/task.c:1331
#11 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:60
#2 isc__taskmgr_create lib/isc/task.c:1468
#3 isc_taskmgr_create lib/isc/task.c:2109
#4 setup_system nsupdate.c:994
#5 main nsupdate.c:3344
SUMMARY: ThreadSanitizer: data race lib/dns/rdataset.c:143 in dns_rdataset_isassociated
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1857assertion failure in 9.16.2: name.c:1738: INSIST(nlabels == name->labels)2020-06-23T05:01:40ZEvan Huntassertion failure in 9.16.2: name.c:1738: INSIST(nlabels == name->labels)Reported by Kevan Benson at Sonic, this has happened on two separate servers, Centos 7.8.2003 and FreeBSD 11.3.
Backtrace is [here](/uploads/4221622ae7fdfe5d4d2f0906dfcb35a1/named-backtrace.log).Reported by Kevan Benson at Sonic, this has happened on two separate servers, Centos 7.8.2003 and FreeBSD 11.3.
Backtrace is [here](/uploads/4221622ae7fdfe5d4d2f0906dfcb35a1/named-backtrace.log).June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1856Race in 'clear signing records' in dnssec system test.2020-05-19T03:52:24ZMark AndrewsRace in 'clear signing records' in dnssec system test.Job [#892140](https://gitlab.isc.org/isc-projects/bind9/-/jobs/892140) failed for 3353bbbe4ae1cb238e8b80a0877969b4a0357f45:
Updates to the zone are task locked and rndc command to clear the key returns as it is being processed. The
subs...Job [#892140](https://gitlab.isc.org/isc-projects/bind9/-/jobs/892140) failed for 3353bbbe4ae1cb238e8b80a0877969b4a0357f45:
Updates to the zone are task locked and rndc command to clear the key returns as it is being processed. The
subsequent rndc command to check can happen before the zone has updated.
```
I:dnssec:clear signing records (170)
I:dnssec:ns3 Done signing with key 14616/NSEC3RSASHA1
I:dnssec:failed
```
```
echo_i "clear signing records ($n)"
{ rndccmd 10.53.0.3 signing -clear all update-nsec3.example > /dev/null; } 2>&1 || ret=1
sleep 1
{ rndccmd 10.53.0.3 signing -list update-nsec3.example > signing.out; } 2>&1
grep -q "No signing records found" signing.out || {
ret=1
sed 's/^/ns3 /' signing.out | cat_i
}
n=$((n+1))
test "$ret" -eq 0 || echo_i "failed"
status=$((status+ret))
```
```
18-May-2020 22:26:03.628 received control channel command 'signing -clear all update-nsec3.example'
18-May-2020 22:26:03.628 keydone: zone update-nsec3.example/IN: enter
...
18-May-2020 22:26:03.640 del update-nsec3.example. 0 IN TYPE65534 \# 5 0739180001
...
18-May-2020 22:26:04.708 received control channel command 'signing -list update-nsec3.example'
...
18-May-2020 22:26:05.032 zone_needdump: zone update-nsec3.example/IN: enter
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1855"check max-journal-size limits" failed as not enough time allowed2020-05-18T22:19:28ZMark Andrews"check max-journal-size limits" failed as not enough time allowedJob [#890395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/890395) failed for d9f357d082da2f8ad68818771ccee96cbe72c0ee:
Test looped for 6 seconds when it took ~13 second.
```
n=`expr $n + 1`
echo_i "check max-journal-size limits ($...Job [#890395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/890395) failed for d9f357d082da2f8ad68818771ccee96cbe72c0ee:
Test looped for 6 seconds when it took ~13 second.
```
n=`expr $n + 1`
echo_i "check max-journal-size limits ($n)"
ret=0
rm -f nsupdate.out1-$n
# add one record
$NSUPDATE << EOF >> nsupdate.out1-$n 2>&1
server 10.53.0.1 ${PORT}
zone maxjournal.test
update add z.maxjournal.test 300 IN A 10.20.30.40
send
EOF
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do
# repeatedly add and remove the same set of records to fill up
# the journal file without changing the zone content
$NSUPDATE << EOF >> nsupdate.out1-$n 2>&1
server 10.53.0.1 ${PORT}
zone maxjournal.test
update add a.maxjournal.test 300 IN A 1.2.3.4
update add b.maxjournal.test 300 IN A 1.2.3.4
update add c.maxjournal.test 300 IN A 1.2.3.4
update add d.maxjournal.test 300 IN A 1.2.3.4
send
update del a.maxjournal.test
update del b.maxjournal.test
update del c.maxjournal.test
update del d.maxjournal.test
send
EOF
done
# check that the journal is big enough to require truncation.
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -gt 6000 ] || ret=1
sleep 1
$RNDCCMD 10.53.0.1 sync maxjournal.test
for i in 1 2 3 4 5 6
do
sleep 1
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -lt 5000 ] && break
done
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -lt 5000 ] || ret=1
[ $ret = 0 ] || { echo_i "failed"; status=1; }
```
```
18-May-2020 06:17:34.729 received control channel command 'sync maxjournal.test'
18-May-2020 06:17:34.733 zone_dump: zone maxjournal.test/IN: enter
18-May-2020 06:17:34.737 zone_gotwritehandle: zone maxjournal.test/IN: enter
18-May-2020 06:17:34.737 sync: dumping zone 'maxjournal.test/IN': success
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: socket_recv: event 0x7fb57ffde180 -> task 0x7fb58fc8b020
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -3 for socket 155
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -2 for socket -1
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: internal_recv: event 0x7fb57ffde180 -> task 0x7fb58fc8b020
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: destroying
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -5 for socket 155
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -2 for socket -1
18-May-2020 06:17:36.025 zone_timer: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_maintenance: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_dump: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_settimer: managed-keys-zone: enter
18-May-2020 06:17:45.393 dump_done: zone maxjournal.test/IN: enter
18-May-2020 06:17:45.393 zone_journal_compact: zone maxjournal.test/IN: target journal size 318
18-May-2020 06:17:45.393 journal file maxjournal.db.jnw does not exist, creating it
18-May-2020 06:17:47.353 zone maxjournal.test/IN: dns_journal_compact: success
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1854Extend loop limit by 1.2020-05-21T04:11:46ZMark AndrewsExtend loop limit by 1.Job [#889797](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889797) failed for 46c4e5d96f4b024117b4e462d3929bb68cb63136:
Extend the loop count by 1 to account for non-exact timing in `usleep(100000)`.
```
[==========] Running 6 test...Job [#889797](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889797) failed for 46c4e5d96f4b024117b4e462d3929bb68cb63136:
Extend the loop count by 1 to account for non-exact timing in `usleep(100000)`.
```
[==========] Running 6 test(s).
[ RUN ] getoriginnode_test
[ OK ] getoriginnode_test
[ RUN ] getsetservestalettl_test
[ OK ] getsetservestalettl_test
[ RUN ] dns_dbfind_staleok_test
21 is not within the range 0-20
db_test.c:214: error: Failure!
[ FAILED ] dns_dbfind_staleok_test
[ RUN ] class_test
[ OK ] class_test
[ RUN ] dbtype_test
[ OK ] dbtype_test
[ RUN ] version_test
[ OK ] version_test
[==========] 6 test(s) run.
[ PASSED ] 5 test(s).
[ FAILED ] 1 test(s), listed below:
[ FAILED ] dns_dbfind_staleok_test
1 FAILED TEST(S)
FAIL db_test (exit status: 1)
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1853Force promotion to unsigned int.2020-06-04T05:59:46ZMark AndrewsForce promotion to unsigned int.Job [#889498](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889498) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
lwinetaton.c:188:20: runtime error: left shift of 213 by 24 places cannot be represented in type 'int'Job [#889498](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889498) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
lwinetaton.c:188:20: runtime error: left shift of 213 by 24 places cannot be represented in type 'int'June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1852race in autosign system test.2020-05-18T13:41:13ZMark Andrewsrace in autosign system test.Job [#889493](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889493) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
`wait_for_log "add delay\.example\..*NSEC.a\.delay\.example\. NS SOA RRSIG NSEC DNSKEY" ns3/named.run`
returns b...Job [#889493](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889493) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
`wait_for_log "add delay\.example\..*NSEC.a\.delay\.example\. NS SOA RRSIG NSEC DNSKEY" ns3/named.run`
returns before the zone is marked as secure. This can result in the subsequent lookups being returned
without RRSIGs. Retry these lookups if they fail.
```
I:autosign:checking scheduled key activation (72)
I:autosign:waiting for changes to take effect
I:autosign:failed
```
```
echo_i "checking scheduled key activation ($n)"
ret=0
$SETTIME -K ns3 -A now+3s $zsk > settime.out.test$n.zsk || ret=1
$SETTIME -K ns3 -A now+3s $ksk > settime.out.test$n.ksk || ret=1
($RNDCCMD 10.53.0.3 loadkeys delay.example. 2>&1 | sed 's/^/ns2 /' | cat_i) || ret=1
echo_i "waiting for changes to take effect"
sleep 3
wait_for_log "add delay\.example\..*NSEC.a\.delay\.example\. NS SOA RRSIG NSEC DNSKEY" ns3/named.run
$DIG $DIGOPTS +noall +answer dnskey delay.example. @10.53.0.3 > dig.out.ns3.1.test$n || ret=1
# DNSKEY expected:
awk 'BEGIN {r=1} $4=="DNSKEY" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
$DIG $DIGOPTS +noall +answer a a.delay.example. @10.53.0.3 > dig.out.ns3.2.test$n || ret=1
# A expected:
awk 'BEGIN {r=1} $4=="A" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
n=`expr $n + 1`
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret`
```
```
head autosign/dig.out.ns3.[12].test72
==> autosign/dig.out.ns3.1.test72 <==
delay.example. 300 IN DNSKEY 256 3 7 AwEAAb0FjNazob/oUqj6yoPtX2zHZZBJ4lTMY6Dj5PFNIUnugIh3DtTf uyPRuby+6OAjTn24FNxOrlu/UcIpJllSI5U3hWEMRrowOL0UnkqB7GaC zxPcbTbyHvj51/fijdeFhK4mWzLDZPEbTYLNaxjOHsAI2Kyti3LelRzH VEw/wTU5
delay.example. 300 IN DNSKEY 257 3 7 AwEAAbZ3JQjYj4J0bbHfC496OClZx8PVTSsXEGPj9BFnlWQ8Zb7rhQn8 H45RuUYh/gt0btmjPetD9ANKPj/S2vB62lkZo+X8FoU8h2tSLtkJ7Rsp XGCSyldNgzgtYSjTcU1SD0vpaVGNxSVShF8tSrQyO66xBpeQOl/hXQBq ncBxffBABsMdNLPKW3SYJGX6WqgasNh0/RjZbA5mWtYA+6v1nNXY8m9Z cJwkTN7X64tOrNbEizaphRqumbeRen9EmqZ58hvpklDMA8fZz99vwDnS flPVLoM/jlSPGyMIKJpH8EJW2kxSrsXRz/cXVhZfEZ5fAj7iCkfInktp B1C7Al4A6U8=
==> autosign/dig.out.ns3.2.test72 <==
a.delay.example. 300 IN A 10.0.0.1
```
```
17-May-2020 23:47:49.971 received control channel command 'loadkeys delay.example.'
...
17-May-2020 23:47:52.976 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200616234752 20200517224752 57189 delay.example. HnZUVSTqk2heuru5n2ju+SZYk64836po4FLbEhkC1Ox71mJCdSvLG5SH 16ZM03Nx2P4eu7NzYNNpj+Ndn04cHzT3Q5TczYDxu6PY7YpdaYrNT2ng TLHcvfSbzqdYISJPmyC1y39zufR/tg1y3BVgpcOXdT9tnH6Odihgn6mM 9vE=
...
17-May-2020 23:47:52.976 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200616234752 20200517224752 19579 delay.example. k6VYi0hXM8wPowFry2TncPgoUAdH9tjqeMCLEmvW8MkUwsXer334fe+E tKU4K3/2WwujBwF1828EIR4ts03rtYCsDT2WQVbDaC1S3dy71CdErDDZ e3COggxN/opGiS+7Bp5w1SH2ctdCViV/jJkRp10Y+ByjPHVTqiBl13OW kaP/NZlUOKcWZyzVnBtF0hrUkDds1rKy8D7Uwm7/Qm1gyPIKSRJ7HM76 kfBdoWsyAwuU7CzoD8yEHxDHeAqtpblCcN71rjEy085DLcab0oB83knU 12BoQx/7rgAo3fJHv1IHZR4vQdVVJcAI87KfaKZvlhRXwOpTrAb5JGVt TPIHoQ==
...
17-May-2020 23:47:53.624 add re-sign a.delay.example. 300 IN RRSIG A 7 3 300 20200602150652 20200517224753 57189 delay.example. F5sae3NdEnj250wHmWQkdxwotLvM41EQCY7xwgFXX8L0x6Bucy0adAYH 9fJpGX9q07D1FTesi1Jz8i6r00U4PNLoR82qPSBY6CAQmpoTLKxi7Shq PL4eN6j9+Z1wrMhLFmZmJmOO92g6Sfe1Sa02VAc/0tU3NUacCYuzawZl gk0=
...
17-May-2020 23:47:54.024 add delay.example. 3600 IN NSEC a.delay.example. NS SOA RRSIG NSEC DNSKEY
...
17-May-2020 23:47:54.045 query client=0x7fcc6807fcd0 thread=0x7fcc9c821700 (delay.example/DNSKEY): query_find
...
17-May-2020 23:47:54.066 query client=0x7fcc9121dc40 thread=0x7fcc9a81d700 (a.delay.example/A): query_find
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1240extend JSON files describing commands2020-09-17T14:17:29ZFrancis Dupontextend JSON files describing commandsIn application of https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent#proposal-32-extend-json-files add an access entry with read or write values to the JSON files describing commands in `doc/sphinx/ap...In application of https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent#proposal-32-extend-json-files add an access entry with read or write values to the JSON files describing commands in `doc/sphinx/api`:
- update README
- update template and generator
- update all command files
- update api2doc script
- update Makefile so these files are installedkea1.9.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1851single-query trace logging2022-04-26T13:10:59ZEvan Huntsingle-query trace logging@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/kea/-/issues/1239TSAN reports that several HA components are not kea thread safe2020-06-16T09:06:27ZRazvan BecheriuTSAN reports that several HA components are not kea thread safereviewing #1219 I have discovered that HAService::asyncSendLeaseUpdate calls HttpClient::asyncSendRequest which is not thread safe.reviewing #1219 I have discovered that HAService::asyncSendLeaseUpdate calls HttpClient::asyncSendRequest which is not thread safe.kea1.7.9Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1850[CVE-2020-8618] A buffer boundary check assertion in rdataset.c can fail inco...2020-06-18T08:26:37ZWitold Krecicki[CVE-2020-8618] A buffer boundary check assertion in rdataset.c can fail incorrectly during zone transferAssertion failure: `rdataset.c:527: INSIST(rrbuffer.used < 65536) failed, back trace`
This one was reported in https://support.isc.org/Ticket/Display.html?id=16195 .
The problem is in lib/ns/include/ns/client.h:
```
#define NS_CLIENT_T...Assertion failure: `rdataset.c:527: INSIST(rrbuffer.used < 65536) failed, back trace`
This one was reported in https://support.isc.org/Ticket/Display.html?id=16195 .
The problem is in lib/ns/include/ns/client.h:
```
#define NS_CLIENT_TCP_BUFFER_SIZE (65535 + 2)
```
It's a leftover from 'old' socket code where the TCP buffer for rendering included the 2 bytes length in front. With netmgr it's the buffer we do rendering to, and we might overflow it.
There are two 'modes' of this bug - the first one is when we don't render partial rdatasets in ANSWER section- and that's what happening when we have EDNS0 enabled (msg->reserved != 0). In this mode we can render a 65536 or 65537-byte-long message which is then sent over TCP. The 'length' is still set using htons, so the 2-byte length is then either [0 0] or [0 1] - we send a malformed packet.
The second mode is worse - with EDNS0 disabled msg->reserved == 0, and a carefully crafted zone we can go over 65535-bytes limit, then go over 65537-limit with triggers ISC_R_NOSPACE on the buffer, and then we check that the buffer 'used' was below 65536 bytes - which is untrue, triggering an assertion:
```
rollback:
if (partial && result == ISC_R_NOSPACE) {
INSIST(rrbuffer.used < 65536);
```
I wasn't able to trigger the issue with recursion (as we'd have to have a rdataset that's > 65535 bytes long in cache, and there's no way to receive that).
The fix is trivial (remove '+2' from the aforementioned line).June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/stork/-/issues/275implement refresh data model2020-06-05T16:31:45ZMichal Nowikowskiimplement refresh data modelaccording to this design: https://gitlab.isc.org/isc-projects/stork/-/wikis/Designs/Refreshing-Dataaccording to this design: https://gitlab.isc.org/isc-projects/stork/-/wikis/Designs/Refreshing-Data0.8Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1237hammer: add support for building kea on alpine 3.112020-05-15T08:11:07ZMichal Nowikowskihammer: add support for building kea on alpine 3.11kea1.7.8https://gitlab.isc.org/isc-projects/kea/-/issues/1236Release version type check introduced a compiler warning2020-05-19T13:47:02ZThomas MarkwalderRelease version type check introduced a compiler warningUnder Ubuntu 18.04, I now get warnings like this:
```
mv -f .deps/dhcp6_messages.Tpo .deps/dhcp6_messages.Plo
g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -I../../../src/bin -I../../../src/bin -I../../../src...Under Ubuntu 18.04, I now get warnings like this:
```
mv -f .deps/dhcp6_messages.Tpo .deps/dhcp6_messages.Plo
g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib -I../../../src/bin -I../../../src/bin -I../../../src -I../../../src -isystem /opt/boost/boost_1_63_0 -DOS_LINUX -Wno-unused-variable -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cc
main.cc: In function ‘int main(int, char**)’:
main.cc:223:37: warning: comparison with string literal results in unspecified behavior [-Waddress]
if (PACKAGE_VERSION_TYPE == "development") {
```
This corrects it:
```
diff --git a/src/bin/dhcp6/main.cc b/src/bin/dhcp6/main.cc
index f24322055a..4e690a6cf4 100644
--- a/src/bin/dhcp6/main.cc
+++ b/src/bin/dhcp6/main.cc
@@ -220,7 +220,7 @@ main(int argc, char* argv[]) {
.arg(VERSION)
.arg(PACKAGE_VERSION_TYPE);
- if (PACKAGE_VERSION_TYPE == "development") {
+ if (std::string(PACKAGE_VERSION_TYPE) == "development") {
LOG_WARN(dhcp6_logger, DHCP6_DEVELOPMENT_VERSION);
}
```kea1.7.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1849CIDR rejected by 9.11.18 and higher2023-03-21T19:04:05ZWilliam D ColburnCIDR rejected by 9.11.18 and higher<!--
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
ondrej@isc.org requested I file this as a regression rather than a feature drop. We have a very old setup that did something clever with CIDR notation. The two CIDRs we use are 10.80.201.0/19 and 10.80.211.0/19 which (as I understand it) covers a range of addresses in 5 class C networks that need access. Making changes is hard, and it was requested that we not change how this works during the pandemic. But the new secretiive bug announcement makes me worry that this is important and we should stop lurking at 9.11.7. When I wrote the email I assumed that the CIDR change had gone from warning to error.
My original email:
```
> On 14 May 2020, at 15:03, William D. Colburn <wcolburn@nrao.edu> wrote:
>
> That this upcoming security announcement is pre-announced makes me worry
> that it is very imporant, and not one we can ignore. Not that we should
> have ignored the last four either, but changes like this are hard.
>
> BIND stopped working for us at 9.11.8, and because of the intricacies of
> making massive changes to our infrastructure, we have been sitting at
> 9.11.7 for quite a while. The problem we have is that you deprecated
> support for legacy CIDR, and our configuration is now invalid. No one
> wants to attempt any changes to the BIND config right now because we are
> in an infectous disease status and almost no one is at work.
>
> The CIDRs in question are 10.80.201.0/19, and 10.80.211.0/19, which we
> use to control access of special hardware across a range of IP
> addresses. It's a "clever" solution, and clever is never really a good
> idea, but it has been in place for more than a decade. The official
> request was not to change those during this pandemic. Unfortunately,
> the system serving these systems is also the system public-facing to the
> internet.
>
> Is there something I can do when compiling this new bind to make CIDR
> notation work again, as in an option at compile time?
>
> --Schlake
```
### BIND version used
WORKS:
```
root@anotheruvula</home/anotheruvula/services/named># bind-9.11.7/*/named -V
BIND 9.11.7 (Extended Support Version) <id:084ef47>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.7' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-18)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled
```
FAILS:
```
root@anotheruvula</home/anotheruvula/services/named># bind-9.11.18/*/named -V
BIND 9.11.18 (Extended Support Version) <id:bc6c00f>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.18' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-23)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/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
```
### Steps to reproduce
```
allow-update {
10.80.201.0/19;
10.80.211.0/19;
}
```
### What is the current *bug* behavior?
The named exits without starting.
syslog errors:
```
May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)
```
### What is the expected *correct* behavior?
I'd expect no error, but for many versions I got this warning:
```
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch
```
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
Just the allow-update is needed, as above.
```
allow-update {
10.80.201.0/19;
10.80.211.0/19;
}
```
### Relevant logs and/or screenshots
```
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch
```
and
```
May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1235Implement v6 Leasequery in Leasequery hook library2020-06-19T14:54:58ZThomas MarkwalderImplement v6 Leasequery in Leasequery hook libraryThis issue builds upon #978 which created the LeaseQuery hook library and implemented DHCP V4 LeaseQuery (per RFC 4388) and create the v6 implementation stubs. Originally #978 was to provide both, we split the effort so V4 can roll out f...This issue builds upon #978 which created the LeaseQuery hook library and implemented DHCP V4 LeaseQuery (per RFC 4388) and create the v6 implementation stubs. Originally #978 was to provide both, we split the effort so V4 can roll out first. This issue fills in the v6 Leasequery implementation.kea1.7.9Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1848The table in /doc/arm/logging-categories.rst is too wide2020-08-13T00:40:05ZSuzanne GoldlustThe table in /doc/arm/logging-categories.rst is too wideThe table in /doc/arm/logging-categories.rst appears to be formatted correctly, but it is way too wide for the RTD page. There is a horizontal scroll bar at the very bottom, but the table is long and there's no way to scroll when you're ...The table in /doc/arm/logging-categories.rst appears to be formatted correctly, but it is way too wide for the RTD page. There is a horizontal scroll bar at the very bottom, but the table is long and there's no way to scroll when you're in the middle.BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1234kea logs error every time command channel command is received2020-06-19T16:48:17ZWlodzimierz Wencelkea logs error every time command channel command is received1. setup is simple Kea4 + kea-ctrl-agent, configs at the bottom, important thing is that here I am sending commands on the same interface as dhcp traffic (in system tests we use separate networks)
2. send command via http to ctrl-agent, ...1. setup is simple Kea4 + kea-ctrl-agent, configs at the bottom, important thing is that here I am sending commands on the same interface as dhcp traffic (in system tests we use separate networks)
2. send command via http to ctrl-agent, logs:
```
May 14 15:59:16 ubuntu20-64-1 kea-ctrl-agent: INFO [kea-ctrl-agent.commands.140266868430400] COMMAND_RECEIVED Received command 'config-get'
May 14 15:59:16 ubuntu20-64-1 kea-ctrl-agent: INFO [kea-ctrl-agent.ctrl-agent.140266868430400] CTRL_AGENT_COMMAND_FORWARDED command config-get successfully forwarded to the service dhcp4
```
kea-dhcp4 logs:
```
2020-05-14 15:59:16.351 ERROR [kea-dhcp4.packets/6770.140286406021056] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: received data over unknown socket
2020-05-14 15:59:16.351 INFO [kea-dhcp4.commands/6770.140286406021056] COMMAND_RECEIVED Received command 'config-get'
```
4. commands actually works
```
[
{
"arguments": {
"Control-agent": {
"control-sockets": {
"dhcp4": {
"socket-name": "/tmp/control_socket",
"socket-type": "unix"
}
},
"hooks-libraries": [],
"http-host": "192.168.59.2",
"http-port": 8000,
"loggers": [
{
"debuglevel": 0,
"name": "kea-ctrl-agent",
"output_options": [
{
"flush": true,
"maxsize": 10240000,
"maxver": 1,
"output": "syslog",
"pattern": ""
}
],
"severity": "INFO"
}
]
}
},
"result": 0
}
```
```
[
{
"arguments": {
"Dhcp4": {
"authoritative": false,
"boot-file-name": "",
"calculate-tee-times": false,
"config-control": {
"config-databases": [
{
"name": "keatest",
"password": "keatest",
"type": "mysql",
"user": "keatest"
}
],
"config-fetch-wait-time": 0
},
"control-socket": {
"socket-name": "/tmp/control_socket",
"socket-type": "unix"
},
"ddns-generated-prefix": "myhost",
"ddns-override-client-update": false,
"ddns-override-no-update": false,
"ddns-qualifying-suffix": "",
"ddns-replace-client-name": "never",
"ddns-send-updates": true,
"decline-probation-period": 86400,
"dhcp-ddns": {
"enable-updates": false,
"max-queue-size": 1024,
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"sender-ip": "0.0.0.0",
"sender-port": 0,
"server-ip": "127.0.0.1",
"server-port": 53001
},
"dhcp-queue-control": {
"capacity": 500,
"enable-queue": false,
"queue-type": "kea-ring4"
},
"dhcp4o6-port": 0,
"echo-client-id": true,
"expired-leases-processing": {
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"reclaim-timer-wait-time": 10,
"unwarned-reclaim-cycles": 5
},
"hooks-libraries": [
{
"library": "/home/wlodek/kea_bin/lib/kea/hooks/libdhcp_mysql_cb.so"
},
{
"library": "/home/wlodek/kea_bin/lib/kea/hooks/libdhcp_cb_cmds.so"
}
],
"host-reservation-identifiers": [
"hw-address",
"duid",
"circuit-id",
"client-id"
],
"hostname-char-replacement": "",
"hostname-char-set": "[^A-Za-z0-9.-]",
"interfaces-config": {
"interfaces": [
"enp0s8"
],
"re-detect": true
},
"lease-database": {
"type": "memfile"
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "stdout"
}
],
"severity": "DEBUG"
}
],
"match-client-id": true,
"multi-threading": {
"enable-multi-threading": false,
"packet-queue-size": 64,
"thread-pool-size": 0
},
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"reservation-mode": "all",
"sanity-checks": {
"lease-checks": "warn"
},
"server-hostname": "",
"server-tag": "abc",
"shared-networks": [],
"statistic-default-sample-age": 0,
"statistic-default-sample-count": 20,
"store-extended-info": false,
"subnet4": [],
"t1-percent": 0.5,
"t2-percent": 0.875,
"valid-lifetime": 7200
}
},
"result": 0
}
]
```kea1.7.9Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/18479.16.* recursor has issues recursing2020-09-02T14:52:51ZArsen Stasic9.16.* recursor has issues recursingHi,
we have rolled out 9.16.2 (and 9.16.1) and discovered a recurser issue with following "awkward" query:
```
dig @127.0.0.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa...Hi,
we have rolled out 9.16.2 (and 9.16.1) and discovered a recurser issue with following "awkward" query:
```
dig @127.0.0.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
```
>>>
; <<>> DiG 9.16.2 <<>> @127.0.0.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5790
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 59d6fa9f053c5865010000005ebd47c3e8421c3834504eb2 (good)
;; QUESTION SECTION:
;rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. IN TXT
;; Query time: 556 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Do Mai 14 15:29:39 CEST 2020
;; MSG SIZE rcvd: 166
>>>
Resolving works with bind up to version 9.11.18, unbound, knot-resolver, powerdns-recursor and following public-resolvers 1.1.1.1, 8.8.8.8, 9.9.9.9:
```
dig @1.1.1.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
```
>>>
; <<>> DiG 9.16.2 <<>> @1.1.1.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 689
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. IN TXT
;; ANSWER SECTION:
rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. 68400 IN TXT "recursiontest"
;; Query time: 3984 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Do Mai 14 15:38:48 CEST 2020
;; MSG SIZE rcvd: 273
>>>
And querying the authoritative NS for this zone works as well:
```
dig @ns3.univie.ac.at. rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
```
>>>
; <<>> DiG 9.16.2 <<>> @ns3.univie.ac.at. rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37613
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 40d61bae24f2455a010000005ebd4c9c5b4182e0414b7787 (good)
;; QUESTION SECTION:
;rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. IN TXT
;; ANSWER SECTION:
rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. 68400 IN TXT "recursiontest"
;; Query time: 0 msec
;; SERVER: 2001:62a:4:322::53:3#53(2001:62a:4:322::53:3)
;; WHEN: Do Mai 14 15:50:20 CEST 2020
;; MSG SIZE rcvd: 192
>>>
If you need anything for further debugging don't hesitate to contact me.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Diego dos Santos FronzaDiego dos Santos Fronza