ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-05-24T16:37:21Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1685Forensic logging based on device type2021-05-24T16:37:21ZVicky Riskvicky@isc.orgForensic logging based on device typeIt would be useful to be able to optionally log on device type. This would make it possible to ignore classes of devices for which you don't have to save Forensic logs, to cut down on their volume.
For example,
Evaluate DHCP options 43...It would be useful to be able to optionally log on device type. This would make it possible to ignore classes of devices for which you don't have to save Forensic logs, to cut down on their volume.
For example,
Evaluate DHCP options 43, 60 or 125 to classify devices as CM, eMTA or CPE.
If option 125 contains docsisX:Y do not store forensic logs (device is a cable modem).Kea1.9-backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1680[ISC-support #17598] Forensic logging enhancements2021-05-24T16:37:21ZPeter Davies[ISC-support #17598] Forensic logging enhancements**Advanced logging facility for forensic logging.**
A number of customers have been asking for enhanced logging features to be available to the forensic logging library hook.
These enhancement could include:
**Logging format:**
...**Advanced logging facility for forensic logging.**
A number of customers have been asking for enhanced logging features to be available to the forensic logging library hook.
These enhancement could include:
**Logging format:**
The ability to configure the output logging string.
Represent the client-id as ascii instead of hex.
**Logfile attributes**:
The ability to configure rollover settings
The ability automatically compresses rollover files.
[RT #17277](https://support.isc.org/Ticket/Display.html?id=17277)
[RT #17559](https://support.isc.org/Ticket/Display.html?id=17559)
[RT #17523](https://support.isc.org/Ticket/Display.html?id=17523)
[RT #17598](https://support.isc.org/Ticket/Display.html?id=17598)kea1.9.8Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1686Forensic logging based on Relay ID2021-05-24T16:37:30ZVicky Riskvicky@isc.orgForensic logging based on Relay IDUses DHCP option 82 or giaddr
Store forensic logs (only) for devices that belongs to a specific network location
For example, include/exclude when giaddr is 10.0.20.1 (a specific CMTS interface)
This is to minimize unnecessary forensi...Uses DHCP option 82 or giaddr
Store forensic logs (only) for devices that belongs to a specific network location
For example, include/exclude when giaddr is 10.0.20.1 (a specific CMTS interface)
This is to minimize unnecessary forensic logging (specifically requested for cable network scenario.)Kea1.9-backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2629man pages aren't installed when building 9.17.x2021-05-25T09:34:13ZChuck Stearnsman pages aren't installed when building 9.17.xThis has been reported by a customer, and I've been able to duplicate the behavior on my system (MacBook Pro M1). There have been reported ways to get the man pages to build (using sphinx-build, or running make doc), but I was unable to ...This has been reported by a customer, and I've been able to duplicate the behavior on my system (MacBook Pro M1). There have been reported ways to get the man pages to build (using sphinx-build, or running make doc), but I was unable to get either of these to work. I was finally able to build and install manpages by descending into doc/man at the source root and running `make` and `make install` there.June 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)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2718Can't get rcode statics by zone from statistics-channel.2021-05-25T10:26:37ZManabu SonodaCan't get rcode statics by zone from statistics-channel.<!--
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
Can't get rcode statics by zone from statistics-channel.
(Summarize the bug encountered concisely.)
### BIND version used
BIND 9.11.31 (Extended Support Version) <id:ac3f4eb>
### Steps to reproduce
```
$ dig @localhost example.jp TXT
$ curl http://localhost:10053/json/v1 | jq '.views._default.zones '
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 611k 100 611k 0 0 2282k 0 --:--:-- --:--:-- --:--:-- 2274k
[
{
"name": "example.jp",
"class": "IN",
"type": "slave",
"rcodes": {
"QrySuccess": 1,
"QryAuthAns": 1,
"QryUDP": 1
},
"qtypes": {
"TXT": 1
}
},
```
### What is the current *bug* behavior?
- Key is "rcodes", but returned nsstats.
### What is the expected *correct* behavior?
- Rcode counter value is assigned to "rcodes".
```
{
"name": "example.jp",
"class": "IN",
"type": "slave",
"rcodes": {
"QUERY": 1,
"IQUERY": 0,
"STATUS": 0,
"RESERVED3": 0,
"NOTIFY": 0,
"UPDATE": 0,
"RESERVED6": 0,
"RESERVED7": 0,
"RESERVED8": 0,
"RESERVED9": 0,
"RESERVED10": 0,
"RESERVED11": 0,
"RESERVED12": 0,
"RESERVED13": 0,
"RESERVED14": 0,
"RESERVED15": 0
},
"qtypes": {
"TXT": 1
}
```
### Relevant configuration files
```
controls {
inet 127.0.0.1 port 953 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
};
options {
directory "/etc/named";
interface-interval 0;
listen-on {
"any";
};
listen-on-v6 {
"any";
};
querylog no;
check-names slave warn;
recursion no;
allow-query {
"any";
};
masterfile-format text;
multi-master yes;
notify explicit;
zone-statistics yes;
};
statistics-channels {
inet 127.0.0.1 port 10053 allow {
127.0.0.1/32;
};
};
key "rndc-key" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
zone "example.jp" {
type master;
file "example.jp";
};
```
### Relevant logs and/or screenshots
```
/ # dig @localhost example.jp A
; <<>> DiG 9.16.15 <<>> @localhost example.jp A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35022
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3c4dff88f795ae6aa18c4f6f60ab43d66d51e96071fb1f12 (good)
;; QUESTION SECTION:
;example.jp. IN A
;; ANSWER SECTION:
example.jp. 3600 IN A 127.0.0.1
;; AUTHORITY SECTION:
example.jp. 3600 IN NS localhost.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon May 24 06:12:38 UTC 2021
;; MSG SIZE rcvd: 106
/ # curl http://localhost:10053/json/v1/zones
{
"json-stats-version":"1.2",
"boot-time":"2021-05-24T06:09:57.895Z",
"config-time":"2021-05-24T06:12:21.187Z",
"current-time":"2021-05-24T06:12:42.304Z",
"version":"9.11.31",
"views":{
"_default":{
"zones":[
{
"name":"example.jp",
"class":"IN",
"serial":0,
"type":"master",
"rcodes":{
"QrySuccess":1,
"QryAuthAns":1,
"QryUDP":1
},
"qtypes":{
"A":1
}
}
]
},
"_bind":{
"zones":[
{
"name":"authors.bind",
"class":"CH",
"serial":0,
"type":"builtin"
},
{
"name":"hostname.bind",
"class":"CH",
"serial":0,
"type":"builtin"
},
{
"name":"version.bind",
"class":"CH",
"serial":0,
"type":"builtin"
},
{
"name":"id.server",
"class":"CH",
"serial":0,
"type":"builtin"
}
]
}
}
}
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2722bad sizeof declaration in main2021-05-26T08:10:47ZMark Andrewsbad sizeof declaration in main```
** CID 331858: Incorrect expression (SIZEOF_MISMATCH)
/lib/ns/interfacemgr.c: 274 in ns_interfacemgr_create()
________________________________________________________________________________________________________
*** CID 331858...```
** CID 331858: Incorrect expression (SIZEOF_MISMATCH)
/lib/ns/interfacemgr.c: 274 in ns_interfacemgr_create()
________________________________________________________________________________________________________
*** CID 331858: Incorrect expression (SIZEOF_MISMATCH)
/lib/ns/interfacemgr.c: 274 in ns_interfacemgr_create()
268 #else /* ifdef USE_ROUTE_SOCKET */
269 isc_refcount_init(&mgr->references, 1);
270 #endif /* ifdef USE_ROUTE_SOCKET */
271 mgr->magic = IFMGR_MAGIC;
272 *mgrp = mgr;
273
CID 331858: Incorrect expression (SIZEOF_MISMATCH)
Passing argument "mgr->ncpus * 184UL /* sizeof (*mgr->clientmgrs[0]) */" to function "isc__mem_get" and then casting the return value to "ns_clientmgr_t **" is suspicious.
274 mgr->clientmgrs = isc_mem_get(mgr->mctx,
275 mgr->ncpus * sizeof(*mgr->clientmgrs[0]));
276 for (size_t i = 0; i < (size_t)mgr->ncpus; i++) {
277 result = ns_clientmgr_create(mgr->sctx, mgr->taskmgr,
278 mgr->timermgr, mgr->aclenv, (int)i,
279 &mgr->clientmgrs[i]);
________________________________________________________________________________________________________
```June 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/2210BIND 9.11.19 dead lock2021-05-26T20:44:51Znanwn147929@alibaba-inc.comBIND 9.11.19 dead lock<!--
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
Seems that BIND has a deadlock. and I don't find any related race condition issues, maybe it is a new issue?
### BIND version used
```
BIND 9.11.19-RedHat-9.11.10-20200601113814.alios7 (Extended Support Version) <id:905ec64>
running on Linux x86_64 3.10.0-327.ali2012.alios7.x86_64 #1 SMP Mon Oct 9 14:09:14 CST 2017
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-epoll' '--with-tuning=large' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-python=/home/tops/bin/python2.7' '--with-python-install-dir=/home/tops' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '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=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-4)
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.9.1
linked to libxml2 version: 20901
compiled with zlib version: 1.2.7
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
Not clear.
### What is the current *bug* behavior?
BIND is hung.
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
```
logging {
channel "default_debug" {
file "data/named.run";
severity dynamic;
};
};
options {
bindkeys-file "/etc/named.iscdlv.key";
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
listen-on port 53 {
127.0.0.1/32;
};
listen-on-v6 port 53 {
::1/128;
};
memstatistics-file "/var/named/data/named_mem_stats.txt";
statistics-file "/var/named/data/named_stats.txt";
dnssec-enable yes;
dnssec-lookaside auto;
dnssec-validation yes;
recursion yes;
allow-query {
"localhost";
};
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "localhost" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update {
"none";
};
};
```
### Relevant logs and/or screenshots
Pstack result as followed:
```
Thread 19 (Thread 0x7f8a3d2fa700 (LWP 20008)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 18 (Thread 0x7f8a3caf9700 (LWP 20009)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 17 (Thread 0x7f8a3c2f8700 (LWP 20010)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e20cd5 in empty_bucket (res=0x7f87d17a14b8) at resolver.c:8910
#4 0x00007f8a40e26c51 in fctx_doshutdown (task=<optimized out>, event=<optimized out>) at resolver.c:4144
#5 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#6 run (uap=0x7f8a41514eb0) at task.c:1331
#7 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#8 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 16 (Thread 0x7f8a3baf7700 (LWP 20011)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 15 (Thread 0x7f8a3b2f6700 (LWP 20012)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 14 (Thread 0x7f8a3aaf5700 (LWP 20013)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 13 (Thread 0x7f8a3a2f4700 (LWP 20014)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 12 (Thread 0x7f8a39af3700 (LWP 20015)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 11 (Thread 0x7f8a392f2700 (LWP 20016)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafcc33 in isc__task_beginexclusive (task0=<optimized out>) at task.c:1757
#2 0x000000000046850b in load_configuration ()
#3 0x000000000046c1d5 in loadconfig ()
#4 0x000000000046c42e in ns_server_reconfigcommand ()
#5 0x00000000004373bd in ns_control_docommand ()
#6 0x000000000043a483 in control_recvmessage ()
#7 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#8 run (uap=0x7f8a41514eb0) at task.c:1331
#9 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#10 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 10 (Thread 0x7f8a38af1700 (LWP 20017)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 9 (Thread 0x7f8a382f0700 (LWP 20018)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 8 (Thread 0x7f8a37aef700 (LWP 20019)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e253ee in dns_resolver_shutdown (res=0x7f87d17a14b8) at resolver.c:9399
#4 0x00007f8a40e650c9 in view_flushanddetach (viewp=<optimized out>, flush=<optimized out>) at view.c:601
#5 0x000000000042e387 in exit_check ()
#6 0x0000000000443310 in prefetch_done ()
#7 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#8 run (uap=0x7f8a41514eb0) at task.c:1331
#9 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#10 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 7 (Thread 0x7f8a372ee700 (LWP 20020)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 6 (Thread 0x7f8a36aed700 (LWP 20021)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e20cd5 in empty_bucket (res=0x7f87d17a14b8) at resolver.c:8910
#4 0x00007f8a40d35d9a in fetch_callback (task=<optimized out>, ev=0x7f85a1732568) at adb.c:3868
#5 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#6 run (uap=0x7f8a41514eb0) at task.c:1331
#7 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#8 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 5 (Thread 0x7f8a362ec700 (LWP 20022)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e62106 in dns_view_findzonecut2 (view=0x7f88f1f49240, name=name@entry=0x7f851fd3cd08, fname=fname@entry=0x7f8a362e9070, now=now@entry=0, options=0, use_hints=use_hints@entry=true, use_cache=use_cache@entry=true, rdataset=rdataset@entry=0x7f89103158e8, sigrdataset=sigrdataset@entry=0x0) at view.c:1295
#4 0x00007f8a40e625e8 in dns_view_findzonecut (view=<optimized out>, name=name@entry=0x7f851fd3cd08, fname=fname@entry=0x7f8a362e9070, now=now@entry=0, options=<optimized out>, use_hints=use_hints@entry=true, rdataset=rdataset@entry=0x7f89103158e8, sigrdataset=sigrdataset@entry=0x0) at view.c:1256
#5 0x00007f8a40e23b62 in fctx_create (res=res@entry=0x7f87d17a14b8, name=name@entry=0x7f851fd3cd08, type=type@entry=1, domain=0x7f8a362e9070, domain@entry=0x0, nameservers=nameservers@entry=0x0, client=client@entry=0x0, options=options@entry=32, bucketnum=bucketnum@entry=400, depth=depth@entry=2, qc=qc@entry=0xf7d4918, fctxp=fctxp@entry=0x7f8a362e9f98) at resolver.c:4454
#6 0x00007f8a40e25dd8 in dns_resolver_createfetch3 (res=<optimized out>, name=name@entry=0x7f851fd3cd08, type=type@entry=1, domain=domain@entry=0x0, nameservers=nameservers@entry=0x0, forwarders=forwarders@entry=0x0, client=client@entry=0x0, id=id@entry=0, options=options@entry=32, depth=depth@entry=2, qc=qc@entry=0xf7d4918, task=0x7f8930a85ae8, action=action@entry=0x7f8a40d35c90 <fetch_callback>, arg=arg@entry=0x7f851fd3cd00, rdataset=rdataset@entry=0x7f851fd39088, sigrdataset=sigrdataset@entry=0x0, fetchp=fetchp@entry=0x7f851fd39080) at resolver.c:9630
#7 0x00007f8a40d30269 in fetch_name (adbname=adbname@entry=0x7f851fd3cd00, start_at_zone=start_at_zone@entry=false, depth=depth@entry=2, qc=qc@entry=0xf7d4918, type=type@entry=1) at adb.c:4056
#8 0x00007f8a40d39dde in dns_adb_createfind2 (adb=0x7f851fd08aa0, task=0x7f89251db3f0, action=action@entry=0x7f8a40e2b4b0 <fctx_finddone>, arg=arg@entry=0x7f88eadec120, name=name@entry=0x7f8a362eadd0, qname=qname@entry=0x7f88eadec130, qtype=28, options=223, now=now@entry=1601867731, target=target@entry=0x0, port=53, depth=2, qc=0xf7d4918, findp=findp@entry=0x7f8a362ea8b8) at adb.c:3192
#9 0x00007f8a40e1f92d in findname (fctx=fctx@entry=0x7f88eadec120, name=name@entry=0x7f8a362eadd0, port=port@entry=0, options=<optimized out>, options@entry=31, flags=flags@entry=0, now=1601867731, overquota=overquota@entry=0x7f8a362ead70, need_alternate=need_alternate@entry=0x7f8a362ead57, no_addresses=no_addresses@entry=0x7f8a362ead5c) at resolver.c:3166
#10 0x00007f8a40e27ca2 in fctx_getaddresses (fctx=fctx@entry=0x7f88eadec120, badcache=badcache@entry=false) at resolver.c:3462
#11 0x00007f8a40e2a36a in fctx_try (fctx=0x7f88eadec120, retrying=<optimized out>, badcache=<optimized out>) at resolver.c:3819
#12 0x00007f8a40e2d994 in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:8747
#13 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#14 run (uap=0x7f8a41514eb0) at task.c:1331
#15 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#16 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 4 (Thread 0x7f8a35aeb700 (LWP 20023)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 3 (Thread 0x7f8a352ea700 (LWP 20024)):
#0 0x00007f8a3ee2fd42 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fb1a3c8 in isc_condition_waituntil (c=c@entry=0x7f8a4151c078, m=m@entry=0x7f8a4151c028, t=t@entry=0x7f8a4151c06c) at condition.c:59
#2 0x00007f8a3fb036b3 in run (uap=0x7f8a4151c010) at timer.c:811
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 2 (Thread 0x7f8a34ae9700 (LWP 20025)):
#0 0x00007f8a3e7ec183 in epoll_wait () from /usr/lib64/libc.so.6
#1 0x00007f8a3fb112f6 in watcher (uap=0x7f8a4151e010) at socket.c:4302
#2 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#3 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 1 (Thread 0x7f8a41555840 (LWP 20007)):
#0 0x00007f8a3e7235f2 in sigsuspend () from /usr/lib64/libc.so.6
#1 0x00007f8a3fb04f00 in isc__app_ctxrun (ctx0=ctx0@entry=0x7f8a3fd38dc0 <isc_g_appctx>) at app.c:723
#2 0x00007f8a3fb0515c in isc__app_run () at app.c:756
#3 0x00007f8a3fb05a30 in isc_app_run () at ../app_api.c:207
#4 0x000000000042a905 in main ()
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2704Bind9 version 9.17.12 not starting without different DNS server2021-05-26T22:26:34ZDo HeBind9 version 9.17.12 not starting without different DNS serverI tried version **9.17.12** because of the new TLS features.
My _resolv.conf_ only contains the local resolver _127.0.0.1_ and _::1_.
The problem is that the new Bind9 doesn't start without having an alternative resolver in resolv.conf....I tried version **9.17.12** because of the new TLS features.
My _resolv.conf_ only contains the local resolver _127.0.0.1_ and _::1_.
The problem is that the new Bind9 doesn't start without having an alternative resolver in resolv.conf. It looks like something in the Bind9 startup process relies on DNS before itself is serving queries.
The last message in the logfile is:
`named[14264]: managed-keys-zone: Failed to create fetch for DNSKEY update`
After that the Bind9 process is running but doesn't answer queries.
Using the same build with the same config, but with an alternative resolver in _resolv.conf_ starts fine and serves DNS afterwards.
Starting with disabled DNSSEC makes the error message go away, but still spawns an unresponsive DNS resolver.
Thanks for any help.
Dominik
[named.conf](/uploads/100f7b902e9d09630c996a919c014367/named.conf)
[log.txt](/uploads/cdc57d006323edca79cd6817faab78e7/log.txt)June 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/2282"shutdown" system test needs to be tweaked to account for recent netmgr changes2021-05-27T02:59:27ZMichał Kępień"shutdown" system test needs to be tweaked to account for recent netmgr changesThe `shutdown` system test on `main` fails intermittently and I believe
that it may be caused by the recent changes in `named` behavior during
shutdown (caused by various tweaks to netmgr code).
Here is an example failure:
https://gitl...The `shutdown` system test on `main` fails intermittently and I believe
that it may be caused by the recent changes in `named` behavior during
shutdown (caused by various tweaks to netmgr code).
Here is an example failure:
https://gitlab.isc.org/isc-private/bind9/-/jobs/1299652
What happened here is that a call to `resolver.query()` raised a
`NoNameservers` exception because `ns3` did not respond to one of the
random queries which are sent just before `ns3` gets `kill`ed by a
SIGTERM signal. This is certainly possible as `ns3` needs to recurse to
resolve those random queries; in fact, it seems that it did even get a
recursive response in time:
```
16-Nov-2020 11:51:06.817 received packet from 10.53.0.2#32288
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38572
;; flags: qr aa ra cd; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 2fc13823006109bb010000005fb267aaa20d2412c8c3b6d3
;; QUESTION SECTION:
;gyggbf.test. IN A
;; AUTHORITY SECTION:
;test. 60 IN SOA ns1.test. root.test. (
; 2020040101 ; serial
; 14400 ; refresh (4 hours)
; 3600 ; retry (1 hour)
; 604800 ; expire (1 week)
; 60 ; minimum (1 minute)
; )
```
but the response was never sent as the server was SIGTERM'd beforehand:
```
16-Nov-2020 11:51:06.675 shutting down
```
which resulted in:
```
16-Nov-2020 11:51:06.820 client @0x8073e5160 10.53.0.3#37091 (gyggbf.test): send failed: operation canceled
```
All in all, it seems to me that nothing extraordinary happened here and
this looks like a false positive. It may be enough to catch
`NoNameservers` exceptions, but a closer look at what the `shutdown`
system test does in the light of recent netmgr changes would not hurt.June 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/2729[FreeBSD] could not listen on UDP socket: permission denied ; creating IPv4 i...2021-05-27T03:38:35Zyuri@FreeBSD[FreeBSD] could not listen on UDP socket: permission denied ; creating IPv4 interface sk0 failed; interface ignoredI am getting these messages in ```/var/log/messages```:
```
$ grep named /var/log/messages
May 25 18:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 18:43:06 yv named[1416]: creating IPv4 interface sk0 fail...I am getting these messages in ```/var/log/messages```:
```
$ grep named /var/log/messages
May 25 18:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 18:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 19:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 19:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 20:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 20:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 21:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 21:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 22:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 22:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 23:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 23:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 26 00:17:03 yv named[1416]: could not listen on UDP socket: permission denied
May 26 00:17:03 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 26 00:17:03 yv named[1416]: could not listen on UDP socket: permission denied
May 26 00:17:03 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
```
```sockstat``` shows that ```named``` listens on the DNS socket:
```
$ sudo sockstat -l | grep named
bind named 1416 21 tcp6 *:53 *:*
bind named 1416 22 tcp4 127.0.0.1:953 *:*
bind named 1416 23 tcp6 ::1:953 *:*
bind named 1416 512 udp6 *:53 *:*
bind named 1416 513 udp6 *:53 *:*
bind named 1416 514 udp6 *:53 *:*
bind named 1416 515 udp6 *:53 *:*
bind named 1416 516 udp6 *:53 *:*
bind named 1416 517 udp6 *:53 *:*
bind named 1416 518 udp6 *:53 *:*
```
bind911-9.11.31 (installed from the port)
FreeBSD 13https://gitlab.isc.org/isc-projects/kea/-/issues/1864forensic logging documentation is duplicated2021-05-27T05:21:25ZAndrei Pavelandrei@isc.orgforensic logging documentation is duplicatedForensic logging documentation, particularly referring to custom formatting and rotation, is in two places:
* doc/sphinx/arm/hooks.rst
* premium/src/hooks/dhcp/forensic_log/libdhcp_legal_log.dox
As one gets updated, the other one gets o...Forensic logging documentation, particularly referring to custom formatting and rotation, is in two places:
* doc/sphinx/arm/hooks.rst
* premium/src/hooks/dhcp/forensic_log/libdhcp_legal_log.dox
As one gets updated, the other one gets outdated.
Revert dox file to the previous state. And complete rst with the extra information that was only placed in dox.kea1.9.9Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2536inline-signing documentation doesn't match reality2021-05-27T13:27:13ZMark Andrewsinline-signing documentation doesn't match realityinline-signing is documented as being inherited from options / view but is only accepted at the zone level.
I think the current behaviour (only effective at the zone level) is sensible and intend to fix the doc (if needed) after moving ...inline-signing is documented as being inherited from options / view but is only accepted at the zone level.
I think the current behaviour (only effective at the zone level) is sensible and intend to fix the doc (if needed) after moving to the correct cause set in namedconf.cMay 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/kea/-/issues/1891Sanity checks for Kea 1.9.8 rc12021-05-27T13:44:31ZjenkinsSanity checks for Kea 1.9.8 rc1```We are now at step SANITY CHECKS of Kea 1.9.8 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Bef...```We are now at step SANITY CHECKS of Kea 1.9.8 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Before starting any checks, please state what check you are doing in a
thread/discussion (not as comment) in Sanity Checks issue in GitLab:
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/1.9.8-rc1
/data/shared/sweng/kea/releases/premium-1.9.8-rc1
/data/shared/sweng/kea/releases/subscription-1.9.8-rc1
SHA256 (kea-1.9.8.tar.gz) = 1008b521cdd8105d28af7ec0b78f2c68ac2601ccd3c1fe46b5b12c40da296e5d
SHA256 (kea-premium-1.9.8.tar.gz) = f119f7104eae98af18f6cf4ac6d3146e677358c4a143213de69373d4fc8c09d6
SHA256 (kea-subscription-1.9.8.tar.gz) = 9da26fff0f5a32ba1218db2e0c3ebaa0a52c270c436d1f6526197f3180187d4d
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/377/
Release version is 1.9.8-isc0034220210524113122 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```kea1.9.8https://gitlab.isc.org/isc-projects/kea/-/issues/1898bump up kea version2021-05-27T14:34:34ZWlodzimierz Wencelbump up kea versionto kea 1.9.9-gitto kea 1.9.9-gitkea1.9.9https://gitlab.isc.org/isc-projects/bind9/-/issues/2367Named segmentation fault in libisc.so.1608.0.12021-05-27T14:50:19ZSøren AndersenNamed segmentation fault in libisc.so.1608.0.1<!--
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
(Summarize the bug encountered concisely.)
### BIND version used
```
named -V
BIND 9.16.10 (Stable Release) <id:fac8def>
running on Linux x86_64 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020
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-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--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=-Wl,-z,relro -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.10/sphinx/bin/sphinx-build'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-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.3
linked to protobuf-c version: 1.3.3
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
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
(What actually happens.)
Named "just" crashed under normal operation.
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
```
named-checkconf -px
acl "XX-Customers" {
....
};
logging {
channel "query" {
file "/var/opt/isc/isc-bind/log/query.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "security" {
file "/var/opt/isc/isc-bind/log/security.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "client" {
file "/var/opt/isc/isc-bind/log/client.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "dnssec" {
file "/var/opt/isc/isc-bind/log/dnssec.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "rate-limit" {
file "/var/opt/isc/isc-bind/log/rate-limit.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "general" {
file "/var/opt/isc/isc-bind/log/general.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "resolver" {
file "/var/opt/isc/isc-bind/log/resolver.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "network" {
file "/var/opt/isc/isc-bind/log/network.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "dispatch" {
file "/var/opt/isc/isc-bind/log/dispatch.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
};
channel "default" {
file "/var/opt/isc/isc-bind/log/named.log" versions 2 size 52428800;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"default";
};
category "queries" {
"null";
};
category "security" {
"null";
};
category "client" {
"client";
};
category "dnssec" {
"dnssec";
};
category "rate-limit" {
"rate-limit";
};
category "query-errors" {
"null";
};
category "resolver" {
"resolver";
};
category "lame-servers" {
"null";
};
category "rpz" {
"null";
};
category "dispatch" {
"dispatch";
};
category "network" {
"network";
};
};
options {
directory "/var/opt/isc/isc-bind/named/data";
listen-on port 53 {
"any";
};
listen-on-v6 port 53 {
"none";
};
recursive-clients 1000;
tcp-clients 500;
version "Nothing to see here.";
dnssec-validation auto;
max-cache-size 8589934592;
minimal-responses yes;
query-source address 85.218.232.228 port 0;
rate-limit {
errors-per-second 100;
ipv4-prefix-length 32;
log-only no;
nxdomains-per-second 100;
responses-per-second 100;
window 5;
};
recursion yes;
response-policy {
zone "XX";
zone "XX";
zone "XX";
zone "XX";
zone "XX";
} qname-wait-recurse no;
allow-query {
"XX-Customers";
};
};
statistics-channels {
inet 127.0.0.1 port 8080 allow {
127.0.0.1/32;
};
};
zone "XX.com" {
type forward;
forwarders {
1.1.1.1;
};
};
zone "XX.com" {
type forward;
forwarders {
1.1.1.1;
};
};
zone "XX.org" {
type forward;
forwarders {
1.1.1.1;
};
};
zone "XX" {
type master;
file "XX.db";
allow-query {
"XX-Customers";
};
};
zone "XX" {
type master;
file "XX.db";
allow-query {
"XX-Customers";
};
};
zone "XX" {
type master;
file "X.db";
allow-query {
"XX-Customers";
};
};
zone "XX" {
type master;
file "XX.db";
allow-query {
"XX-Customers";
};
};
zone "XX" {
type master;
file "XX.db";
allow-query {
"XX-Customers";
};
};
```
### Relevant logs and/or screenshots
Nothing in the logs.. But the kernel logged this:
```
[Wed Dec 30 14:42:36 2020] isc-net-0011[1933]: segfault at 10 ip 00007fd9beb61a4b sp 00007fd9b54b3900 error 4 in libisc.so.1608.0.1[7fd9beb2c000+75000]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2726inline signed zone journal goes out of sync if zone is modified when restarti...2021-05-27T22:30:22ZMichel Lespinasseinline signed zone journal goes out of sync if zone is modified when restarting bind9### Summary
When restarting bind9, it seems to be easy for inline signed zones to go out of sync with their journal. Note, the issue does not happen when reloading bind9.
### BIND version used
Debian buster-backports package version 1...### Summary
When restarting bind9, it seems to be easy for inline signed zones to go out of sync with their journal. Note, the issue does not happen when reloading bind9.
### BIND version used
Debian buster-backports package version 1:9.16.15-1~bpo10+1
### Steps to reproduce
- configure some inline signed zone. Mine are master zones with a dnssec-policy applied.
- start bind (using /etc/init.d/named start)
- edit the zone file
- restart bind (using /etc/init.d/named restart)
- the modified zone fails to load:
~~~
zone test.lespinasse.org/IN/public (unsigned): journal rollforward failed: journal out of sync with zone
zone test.lespinasse.org/IN/public (unsigned): not loaded due to errors.
~~~
Note, everything works fine if one reloads bind (using etc/init.d/named reload, or just rndc reload). Also, the server restats without issue if one edits the zone file, reloads bind to sync up the journal, and then issues the restart.
### What is the current *bug* behavior?
any edited zone fails to load when the server is restarted, without having been reloaded first.
### What is the expected *correct* behavior?
reload and restart should both pick up the current zone file.
### Relevant configuration files
### Relevant logs and/or screenshots
I think I covered the basics; I can provide more details on request.https://gitlab.isc.org/isc-projects/bind9/-/issues/2676Missing May backports2021-05-28T06:11:32ZMichal NowakMissing May backportsThe following merge requests merged to %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" milestone indicate that they also should be backported in %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" but they wer...The following merge requests merged to %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" milestone indicate that they also should be backported in %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" but they were not. For them not to be forgotten I list them here:
**BIND 9.11.32**
- @ondrej
- [x] isc-projects/bind9!4928 (backported by @mnowak)
**BIND 9.11.32-S1**
- @matthijs
- [x] isc-projects/bind9!4799 (moved to `v9_11_sub-with-serve-stale-improvements` branch in the private project and is [scheduled](https://mattermost.isc.org/isc/pl/6zrhycx1etr3mq8eajf7y8xzbr) to be merged to `v9_11_sub` early in June merge window with the rest of the 9.11-S serve-stale work)
**BIND 9.16.16**
- @marka
- [x] isc-projects/bind9!4751
- [x] isc-projects/bind9!5013
- [x] isc-projects/bind9!4947
- @ondrej
- [x] isc-projects/bind9!4918 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!4928 (backported by @mnowak)
- [x] isc-projects/bind9!4980 - as isc-projects/bind9!5025
- [x] isc-projects/bind9!4981 - partially as isc-projects/bind9!5026, partially in isc-projects/bind9!5018
- [x] isc-projects/bind9!4982 - not needed, Windows-only, too intrusive
- [x] isc-projects/bind9!4983 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5006 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5008 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5009 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5010 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5021 - backported in isc-projects/bind9!5018
- @dfronza
- [x] #2529 to be backported in %"June 2021 (9.11.33, 9.11.33-S1, 9.16.17, 9.16.17-S1, 9.17.14)", see !5001June 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/stork/-/issues/531Kea config viewer2021-05-28T08:41:20ZTomek MrugalskiKea config viewerStork users would benefit from being able to view the current Kea configuration, as described [here](https://gitlab.isc.org/isc-projects/stork/-/wikis/Ideas#21-phase-1-visualising-kea-configuration). This ticket aims to address the phase...Stork users would benefit from being able to view the current Kea configuration, as described [here](https://gitlab.isc.org/isc-projects/stork/-/wikis/Ideas#21-phase-1-visualising-kea-configuration). This ticket aims to address the phase 1, i.e. retrieve the Kea json configuration from backend to front-end and display it.
This is a part of a much broader initiative to address the requirement as defined in #43.0.18Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2452iterated_hash.c: warning: argument 1 of type ‘unsigned char[20]’ with mismatc...2021-05-28T10:00:42ZMichal Nowakiterated_hash.c: warning: argument 1 of type ‘unsigned char[20]’ with mismatched boundOn Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include...On Fedora 33 with custom experimental gcc snapshot version 11.0.0 20210124 I get the following warning:
```
/opt/gcc-latest/bin/gcc -I/home/newman/isc/ws/bind9 -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include -I./include -I/home/newman/isc/ws/bind9/lib/dns/include -I../../lib/dns/include -D_REENTRANT -DOPENSSL -DPK11_LIB_LOCATION=\"undefined\" -D_GNU_SOURCE -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -fsanitize=address,undefined -DISC_MEM_USE_INTERNAL_MALLOC=0 -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -c iterated_hash.c
iterated_hash.c:21:33: warning: argument 1 of type ‘unsigned char[20]’ with mismatched bound [-Warray-parameter=]
21 | isc_iterated_hash(unsigned char out[ISC_SHA1_DIGESTLENGTH],
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from iterated_hash.c:18:
./include/isc/iterated_hash.h:33:37: note: previously declared as ‘unsigned char[155]’
33 | int isc_iterated_hash(unsigned char out[NSEC3_MAX_HASH_LENGTH],
| ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
```June 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)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2685max-ixfr-ratio appears to be forcing AXFR very prematurely on BIND 9.16.152021-05-28T10:26:15ZCathy Almondmax-ixfr-ratio appears to be forcing AXFR very prematurely on BIND 9.16.15We have three reports of problems with authoritative servers frequently (most of the time) responding with AXFR instead of the requested IXFR since updating to BIND 9.16.15. In two of the cases (we have not yet received results from the...We have three reports of problems with authoritative servers frequently (most of the time) responding with AXFR instead of the requested IXFR since updating to BIND 9.16.15. In two of the cases (we have not yet received results from the third), disabling max-ixfr-ratio returned the servers to their expected behaviour:
`max-ixfr-ratio unlimited;`
The symptom appears to be a problem in the calculation of the comparative sizes of zone and incremental update - although it may turn out to be an issue with .jnl file format (each increment header carries the 'size' of the update), or with the the way that the size of the zone itself is determined. In at least one case, the zone involved is very large.June 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)Mark AndrewsMark Andrews