ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-10-04T18:55:45Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/908Release 9.12.4 enables python by default!2021-10-04T18:55:45ZDaniel StirnimannRelease 9.12.4 enables python by default!<!--
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
I'm upgrading from BIND 9.12.3-P4 to BIND 9.12.4 and encountered that the configure script now defaults to enable python by default. I'm all for default python support but this was an unexpected change in a minor version change on the stable release.
As far as I understood, python got enabled by default in 9.13.4 and onwards. Can it be that this is an error that you also enabled it by default for BIND 9.12.4?
### Relevant logs and/or screenshots
```
./configure
...
checking for python... /usr/bin/python
checking if /usr/bin/python is python2 version >= 2.7 or python3 version >= 3.2... yes
checking Python module 'argparse'... yes
checking Python module 'ply'... no
checking for python3... no
checking for python3.7... no
checking for python3.6... no
checking for python3.5... no
checking for python3.4... no
checking for python3.3... no
checking for python3.2... no
checking for python2... /usr/bin/python2
checking if /usr/bin/python2 is python2 version >= 2.7 or python3 version >= 3.2... yes
checking Python module 'argparse'... yes
checking Python module 'ply'... no
checking for python2.7... /usr/bin/python2.7
checking if /usr/bin/python2.7 is python2 version >= 2.7 or python3 version >= 3.2... yes
checking Python module 'argparse'... yes
checking Python module 'ply'... no
checking for Python support... no
BUILDSTDERR: configure: error: Python required for dnssec-keymgr
```
### Possible fixes
I have now used `--without-python` to retain the previous behavior of the BIND 9.12 stable release.https://gitlab.isc.org/isc-projects/bind9/-/issues/895Create KB article on mirror zones2021-10-04T18:51:46ZStephen MorrisCreate KB article on mirror zonesSuggested scope: "what to use mirror zones for and when not to use"
(Action from internal BIND Outreach meeting.)Suggested scope: "what to use mirror zones for and when not to use"
(Action from internal BIND Outreach meeting.)https://gitlab.isc.org/isc-projects/bind9/-/issues/883isc/keyzone.py should invoke named-compilezone to also consider journal files2021-10-04T18:50:41ZGhost Userisc/keyzone.py should invoke named-compilezone to also consider journal files### Description / Request / Links / references
In `bin/python/isc/keyzone.py.in#L43` `named-compilezone` is invoked in the following way:
```
fp, _ = Popen([czpath, "-o", "-", name, filename],
```
This does not take into accou...### Description / Request / Links / references
In `bin/python/isc/keyzone.py.in#L43` `named-compilezone` is invoked in the following way:
```
fp, _ = Popen([czpath, "-o", "-", name, filename],
```
This does not take into account any journals, so with dynamic updates and/or inline signing, the data read in, might actually not be the real deal. To make sure to load/analyze the correct data `named-compilezone` should be invoked with the `-j` flag, which, according to the man page does the following:
```
-j
When loading a zone file, read the journal if it exists. The journal file name is assumed to be the zone file name appended with the string .jnl.
```
If the file does not exist, this option is simply ignored, so simply adding it uncoditionally should not do any harm as far as I can tell.https://gitlab.isc.org/isc-projects/bind9/-/issues/840Assertion failure in socket.c (9.13.5) -- INSIST(((sock->send_list).head == (...2021-10-04T18:42:44ZMichael McNallyAssertion failure in socket.c (9.13.5) -- INSIST(((sock->send_list).head == ((void *)0)))<!--
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 user has reported an assertion failure in socket.c [INSIST(((sock->send_list).head == ((void *)0)))] to us via security-officer mail.
### BIND version used
Reported against 9.13.5.
> bind: bind913-9.13.5_2 (running as caching resolver only)
> OS: FreeBSD 12 (amd64)
### Steps to reproduce
Currently unknown.
Submitter email follows:
```
As per request on your gitlab instance I'm sending
this bugreport via email since it includes an assertion failure
bind: bind913-9.13.5_2 (running as caching resolver only)
OS: FreeBSD 12 (amd64)
BIND died with the following in the log:
general: critical: socket.c:2763: INSIST(((sock->send_list).head == ((void *)0))) failed, back trace
general: critical: #0 0x2ba5c0 in ??
general: critical: #1 0x48501a in ??
general: critical: #2 0x4abcdb in ??
general: critical: #3 0x34325d in ??
general: critical: #4 0x34274f in ??
general: critical: #5 0x4a17be in ??
general: critical: #6 0x800a48776 in ??
general: critical: exiting (due to assertion failure)
kernel: pid .. (named), uid 53: exited on signal 6
no dump file has been created.
some more version information:
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)
compiled with OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked to OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
excerpt from the config:
options {
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
qname-minimization relaxed;
dnssec-validation auto;
listen-on { 127.0.0.1; };
listen-on-v6 { none; };
query-source address x.x.x.x port *;
query-source-v6 address xxx:xxxx port *;
max-cache-size 2000m;
version none;
hostname none;
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "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.0.IP6.ARPA";
disable-empty-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";
};
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2261TSAN error to be investigated v9_112021-10-04T18:31:45ZMark AndrewsTSAN error to be investigated v9_11Job [#1286053](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1286053) failed for 5ce19734b9e21869d6c2c9ee515a3d26027a9b90:
```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1 (mutexes: write M1, ...Job [#1286053](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1286053) failed for 5ce19734b9e21869d6c2c9ee515a3d26027a9b90:
```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1 (mutexes: write M1, write M2):
#0 dns_zone_refresh lib/dns/zone.c:10484
#1 dns_zone_notifyreceive2 lib/dns/zone.c:14035
#2 dns_zone_notifyreceive2 lib/dns/zone.c:13886
#3 ns_notify_start bin/named/notify.c:150
#4 client_request bin/named/client.c:3125
#5 dispatch lib/isc/task.c:1157
#6 run lib/isc/task.c:1331
#7 <null> <null>
Previous read of size 4 at 0x000000000001 by thread T2:
#0 dns_zone_refresh lib/dns/zone.c:10465
#1 zone_maintenance lib/dns/zone.c:10254
#2 zone_timer lib/dns/zone.c:13525
#3 dispatch lib/isc/task.c:1157
#4 run lib/isc/task.c:1331
#5 <null> <null>
Location is heap block of size 2841 at 0x000000000011 allocated by thread T3:
#0 malloc <null>
#1 internal_memalloc lib/isc/mem.c:887
#2 mem_get lib/isc/mem.c:792
#3 mem_allocateunlocked lib/isc/mem.c:1545
#4 isc___mem_allocate lib/isc/mem.c:1566
#5 isc__mem_allocate lib/isc/mem.c:3048
#6 isc___mem_get lib/isc/mem.c:1304
#7 isc__mem_get lib/isc/mem.c:3012
#8 dns_zone_create lib/dns/zone.c:930
#9 configure_zone server.c:5697
#10 do_addzone server.c:12471
#11 ns_server_changezone server.c:12832
#12 ns_control_docommand bin/named/control.c:205
#13 control_recvmessage bin/named/controlconf.c:469
#14 dispatch lib/isc/task.c:1157
#15 run lib/isc/task.c:1331
#16 <null> <null>
```https://gitlab.isc.org/isc-projects/bind9/-/issues/831Add helpful hints to the ARM about generating pin files for HSMs when using B...2021-10-04T18:24:52ZCathy AlmondAdd helpful hints to the ARM about generating pin files for HSMs when using BIND build with --enable-native-pkcs11It may not be true of all HSM providers and their PKCS#11 lib, but in at least one instance we've encountered, how you generate the pin file is very significant - having a trailing newline or similar will make the difference between the ...It may not be true of all HSM providers and their PKCS#11 lib, but in at least one instance we've encountered, how you generate the pin file is very significant - having a trailing newline or similar will make the difference between the pin being accepted or the authentication failing.
Examples of how to generate an HSM pin file without a newline:
`$ echo -n 1234 > hsmpin`
or
`$ printf 1234 > hsmpin`
Easily verified as being clean of any additional characters using wc:
```
$ wc -l < hsmpin
0
```
or
```
$ wc < hsmpin
0 1 4
```
(The wc order of output always takes the form of line, word,byte, and file name.)
For comparison, this is a pin file that was not accepted by an HSM because 'echo' without -n adds the newline by default in this particular test environment:
```
$ echo 1234 > hsmpin
$ wc -l < hsmpin
1
$ wc < hsmpin
1 1 5
```
(From Support ticket [#14117](https://support.isc.org/Ticket/Display.html?id=14117) )https://gitlab.isc.org/isc-projects/bind9/-/issues/830dnssec-keyfromlabel error "pk11.c:564: fatal error: pkcs_C_Login: Error = 0x0...2021-10-04T18:24:18ZCathy Almonddnssec-keyfromlabel error "pk11.c:564: fatal error: pkcs_C_Login: Error = 0x000000A0" could be more helpfulThe problem in this instance was that the pin code was incorrect. But at this point the problem could have been several - for example that the pkcs#11 library wasn't accessible or something like that. After heading off on the wrong tra...The problem in this instance was that the pin code was incorrect. But at this point the problem could have been several - for example that the pkcs#11 library wasn't accessible or something like that. After heading off on the wrong track for quite some time, we eventually uncovered where the issue was.
```
# dnssec-keyfromlabel -v 5 -a RSASHA256 -l 'pkcs11:pin-source=/etc/named/hsmpin;object=sample_ksk' -K /etc/named/keys -f KSK example.com
pk11.c:564: fatal error: pkcs_C_Login: Error = 0x000000A0
```
I suspect that it's out of our hands to be able to interpret an error passed back to us by another lib, but what might be more helpful could be a summary of how far dnssec-key-label had got, so we know where *not* to look for the problem and maybe some suggestions for further troubleshooting?
In the above example, the PKCS#11 provider libs had been loaded OK, but the pin was wrong. Perhaps the error could indicate what the BIND code was trying to do (at a higher level) when it all went wrong?
(From Support ticket [#14117](https://support.isc.org/Ticket/Display.html?id=14117) )https://gitlab.isc.org/isc-projects/bind9/-/issues/829pkcs11 tools error "Unrecoverable error initializing PKCS#11: not found" coul...2021-10-04T18:23:44ZCathy Almondpkcs11 tools error "Unrecoverable error initializing PKCS#11: not found" could be more helpfulFor example:
```
# pkcs11-keygen -b 2048 -l sample-ksk
Enter Pin:
Unrecoverable error initializing PKCS#11: not found
```
and
```
# pkcs11-list
Enter Pin:
Unrecoverable error initializing PKCS#11: not found
Unrecoverable error init...For example:
```
# pkcs11-keygen -b 2048 -l sample-ksk
Enter Pin:
Unrecoverable error initializing PKCS#11: not found
```
and
```
# pkcs11-list
Enter Pin:
Unrecoverable error initializing PKCS#11: not found
Unrecoverable error initializing PKCS#11: not found
```
The problem in this instance was eventually tracked down, not to the lack of path to the PKCS11 provider (since this had been correctly specified in the BIND build with --with-pkcs11=<path to library>) but because the HSM slot ID hadn't been given using the -s option.
Would it be possible to give more clues as to where to look for the problem in this instance, or is that out of our hands?
(From Support ticket [#14117](https://support.isc.org/Ticket/Display.html?id=14117) )https://gitlab.isc.org/isc-projects/bind9/-/issues/819Corrupted zone is not always refused with error2021-10-04T18:12:55ZPetr MenšíkCorrupted zone is not always refused with error<!--
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
Broken zone file is not always refused with error.
### BIND version used
```
BIND 9.11.5-RedHat-9.11.5-2.fc29 (Extended Support Version) <id:3b0b204>
running on Linux x86_64 4.19.14-300.fc29.x86_64 #1 SMP Wed Jan 9 21:30:35 UTC 2019
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-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-geoip' '--with-libidn2' '--enable-openssl-hash' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--with-libjson' '--enable-dnstap' '--with-atf=/usr' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE'
compiled by GCC 8.2.1 20181011 (Red Hat 8.2.1-4)
compiled with OpenSSL version: OpenSSL 1.1.1 FIPS 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 FIPS 11 Sep 2018
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
### Steps to reproduce
when header->first_node_offset is greater than filesize, computed offset is outside memory mapped range.
### What is the current *bug* behavior?
it loads the file but fail when interpreting it.
### What is the expected *correct* behavior?
Should reject file as invalid.
### Relevant configuration files
none. ju
### Relevant logs and/or screenshots
no configuration required, just unit test with a bit of luck or reliable reproducer.
Discovered by running unit tests, which do corrupt the file at random.
```
$ kyua test rbt_serialize_test
rbt_serialize_test:deserialize_corrupt -> broken: Premature exit; test case received signal 11 (core dumped) [0.644s]
rbt_serialize_test:serialize -> passed [0.027s]
rbt_serialize_test:serialize_align -> passed [0.017s]
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)
[0001-Reproducer-for-crash-in-serialize_test.patch](/uploads/f00c46371518f9eaa5a18da9007418e1/0001-Reproducer-for-crash-in-serialize_test.patch)
[0002-Fix-possible-crash-when-loading-corrupted-file.patch](/uploads/3de8153d9d7f2237cea005a5df85e733/0002-Fix-possible-crash-when-loading-corrupted-file.patch)
I think specially crafted file could crash named, but I assume binary zones are not usually obtained from trusted sources. Anyway, leaving up to you if this should be public issue or not. Feel free to switch it public.BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/815odd serve-stale / SERVFAIL performance problem2021-10-04T18:12:10ZTony Finchodd serve-stale / SERVFAIL performance problemI have two identical newly installed servers running stock 9.12.3-P1 on Debian 9 "Stretch". They exhibit very different performance when trying to resolve reverse DNS under 48.in-addr.arpa. This domain has a lame delegation:
```
48.in-a...I have two identical newly installed servers running stock 9.12.3-P1 on Debian 9 "Stretch". They exhibit very different performance when trying to resolve reverse DNS under 48.in-addr.arpa. This domain has a lame delegation:
```
48.in-addr.arpa. NS psnyed01.prudential.com.
psnyed01.prudential.com. CNAME ns1.prudential.com.
```
I have a sample of 29000 domains under 48.in-addr.arpa which I am using as my test set. Machine "R" can SERVFAIL them all in about 12 seconds with a hot cache, using `adns-masterfile` as the client. I get the same time with a concurrency limit of 1000 or 4000 queries. Machine "S" takes much longer, about 25s with a concurrency of 1000, and 45s with a concurrency of 4000, and it develops a long backlog with the higher concurrency. Its ability to handle other queries suffers a lot while this is going on.
I've dumped the cache on the two machines. There are some differences
on R:
```
; answer
; stale
ns1.prudential.com. 2055 A 12.42.50.60
; answer
; stale
ns2.prudential.com. 2055 A 12.42.51.60
; pending-answer
psnyed01.prudential.com. 3697 CNAME ns1.prudential.com.
```
in R's address database dump there is
```
; psnyed01.prudential.com alias ns1.prudential.com [target TTL 92] [v4 unexpected] [v6 unexpected]
```
Weirdly, R doesn't have any addresses in its adb dump (probably because it's been idle apart from by 48/8 testing).
on S:
```
; answer
; stale
ns1.prudential.com. 3065 A 12.42.50.60
; answer
; stale
ns2.prudential.com. 3065 A 12.42.51.60
; answer
; stale
psnyed01.prudential.com. 3334 CNAME ns1.prudential.com.
```
On S there is no entry in the adb for psnyed01.prudential.com, and there are lots of addresses.
After restarting a server, or after flushing the prudential.com forward and reverse DNS, I get NXDOMAIN responses for names under 48.in-addr.arpa instead of SERVFAIL. I'm not sure how to provoke it to get into the servfail state.https://gitlab.isc.org/isc-projects/bind9/-/issues/802dnssec-keyfromfile core dump2021-10-04T18:09:01ZGhost Userdnssec-keyfromfile core dump<!--
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
dnssec-keyfromlable core dumps.
pkcs-keygen works fine, pkcs-list works fine, dnssec-keyfromlable core dumps.
We are currently trying to integrate our HSM into bind9 by using native PKCS#11 R2. We setup our HSM and configured P11. We followed the bind9 documentation in chapter "PKCS#11 (Cryptoki) Support"
The core dump occurs on any of the bind versions mentioned below and presumably comes up because the application does not ask for a PIN.
My environment:
OS: Ubuntu 18.04, linux kernel 4.15.0-43-generic (running in Oracle VM Virtualbox, 6.0.0r127566)
GCC: gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Make: GNU Make 4.1 Built for x86_64-pc-linux-gnu
### BIND version used
9.11.5-P1 built from bind-9.11.5-P1.tar.gz
9.12.3-P1 built from bind-9.12.3-P1.tar.gz
9.13.5-W1 built from bind-9.13.5-W1.tar.gz
built by make with '--enable-native-pkcs11' and '--with-pkcs11=/home/bind/Software/Linux/x86-64/Crypto_APIs/PKCS11_R2/lib/libcs_pkcs11_R2.so'
compiled by GCC 7.3.0
threads support is enabled
### Steps to reproduce
Download bind-9.11.5-P1.tar.gz | bind-9.12.3-P1.tar.gz | bind-9.13.5-W1.tar.gz from your homepage, run the configure script and make.
1.) bind-9.11.5-P1.tar.gz
bind@ubuntu1804:~/bind-9.11.5-P1$ ./configure --enable-native-pkcs11 --with-pkcs11=~/Software/Linux/x86-64/Crypto_APIs/PKCS11_R2/lib/libcs_pkcs11_R2.so
bind@ubuntu1804:~/bind-9.11.5-P1$ make
bind@ubuntu1804:~/bind-9.11.5-P1/bin/pkcs11$ ./pkcs11-keygen -b 2048 -l sample-ksk
Enter Pin:
Key pair generation complete.
bind@ubuntu1804:~/bind-9.11.5-P1/bin/pkcs11$ ./pkcs11-list
Enter Pin:
object[0]: handle 2 class 3 label[10] 'sample-ksk' id[0] E:never
object[1]: handle 1 class 2 label[10] 'sample-ksk' id[0]
bind@ubuntu1804:~/bind-9.11.5-P1/bin/dnssec$ ./dnssec-keyfromlabel -l sample-ksk -f KSK example.net
md5.c:124: fatal error: pkcs_C_DigestUpdate: Error = 0x00000101
Aborted (core dumped)
PKCS11-LOG:
31.12.2018 15:39:47 | [0000402A:0000402A] C_OpenSession | D: Insert session 0x01a82b72.
31.12.2018 15:39:47 | [0000402A:0000402A] log | D: Size: 1
31.12.2018 15:39:47 | [0000402A:0000402A] log | D: Index: 0x01a82b72
31.12.2018 15:39:47 | [0000402A:0000402A] C_OpenSession | T: leave...
31.12.2018 15:39:47 | [0000402A:0000402A] C_DigestInit | T: enter...
31.12.2018 15:39:47 | [0000402A:0000402A] C_DigestInit | T: leave...
31.12.2018 15:39:47 | [0000402A:0000402A] C_DigestUpdate | T: enter...
31.12.2018 15:39:47 | [0000402A:0000402A] C_DigestUpdate | E: Error CKR_USER_NOT_LOGGED_IN occurred.
31.12.2018 15:39:47 | [0000402A:0000402A] C_DigestUpdate | T: leave...
According to the P11 standard CKR_USER_NOT_LOGGED_IN is defined as 0x00000101
2.) bind-9.12.3-P1.tar.gz
bind@ubuntu1804:~/bind-9.12.3-P1$ ./configure --enable-native-pkcs11 --with-pkcs11=~/Software/Linux/x86-64/Crypto_APIs/PKCS11_R2/lib/libcs_pkcs11_R2.so
bind@ubuntu1804:~/bind-9.12.3-P1$ make
bind@ubuntu1804:~/bind-9.12.3-P1/bin/pkcs11$ ./pkcs11-keygen -b 2048 -l sample-ksk
Enter Pin:
Key pair generation complete.
bind@ubuntu1804:~/bind-9.12.3-P1/bin/pkcs11$ ./pkcs11-list
Enter Pin:
object[0]: handle 2 class 3 label[10] 'sample-ksk' id[0] E:never
object[1]: handle 1 class 2 label[10] 'sample-ksk' id[0]
bind@ubuntu1804:~/bind-9.12.3-P1/bin/dnssec$ ./dnssec-keyfromlabel -l sample-ksk -f KSK example.net
md5.c:120: fatal error: pkcs_C_DigestUpdate: Error = 0x00000101
Aborted (core dumped)
PKCS11-LOG:
31.12.2018 15:42:07 | [0000403A:0000403A] C_OpenSession | D: Insert session 0x017b4ae5.
31.12.2018 15:42:07 | [0000403A:0000403A] log | D: Size: 1
31.12.2018 15:42:07 | [0000403A:0000403A] log | D: Index: 0x017b4ae5
31.12.2018 15:42:07 | [0000403A:0000403A] C_OpenSession | T: leave...
31.12.2018 15:42:07 | [0000403A:0000403A] C_DigestInit | T: enter...
31.12.2018 15:42:07 | [0000403A:0000403A] C_DigestInit | T: leave...
31.12.2018 15:42:07 | [0000403A:0000403A] C_DigestUpdate | T: enter...
31.12.2018 15:42:07 | [0000403A:0000403A] C_DigestUpdate | E: Error CKR_USER_NOT_LOGGED_IN occurred.
31.12.2018 15:42:07 | [0000403A:0000403A] C_DigestUpdate | T: leave...
According to the P11 standard CKR_USER_NOT_LOGGED_IN is defined as 0x00000101
3.) bind-9.13.5-W1.tar.gz
Note: bind-9.13.5-W1:
configure without option '--with-python' or with option '--with-python=/usr/bin/python' results in an error:
..
checking for Python support... no
configure: error: Python required for dnssec-keymgr
bind@ubuntu1804:~/bind-9.13.5-W1$ ./configure --with-python=no --enable-native-pkcs11 --with-pkcs11=~/Software/Linux/x86-64/Crypto_APIs/PKCS11_R2/lib/libcs_pkcs11_R2.so
bind@ubuntu1804:~/bind-9.13.5-W1$ make
bind@ubuntu1804:~/bind-9.13.5-W1/bin/pkcs11$ ./pkcs11-keygen -b 2048 -l sample-ksk
Enter Pin:
Key pair generation complete.
bind@ubuntu1804:~/bind-9.13.5-W1/bin/pkcs11$ ./pkcs11-list
Enter Pin:
object[0]: handle 2 class 3 label[10] 'sample-ksk' id[0] E:never
object[1]: handle 1 class 2 label[10] 'sample-ksk' id[0]
bind@ubuntu1804:~/bind-9.13.5-W1/bin/dnssec$ ./dnssec-keyfromlabel -a RSASHA1 -l sample-ksk -f KSK example.net
pk11.c:445: fatal error: pkcs_C_Login: Error = 0x000000A0
Aborted (core dumped)
PKCS11-LOG:
31.12.2018 15:46:59 | [00004088:00004088] C_OpenSession | D: Insert session 0x013442d6.
31.12.2018 15:46:59 | [00004088:00004088] log | D: Size: 1
31.12.2018 15:46:59 | [00004088:00004088] log | D: Index: 0x013442d6
31.12.2018 15:46:59 | [00004088:00004088] C_OpenSession | T: leave...
31.12.2018 15:46:59 | [00004088:00004088] C_Login | T: enter...
31.12.2018 15:46:59 | [00004088:00004088] C_Login | D: session handle: 0x013442d6
31.12.2018 15:46:59 | [00004088:00004088] C_Login | D: user type: 0x00000001
31.12.2018 15:46:59 | [00004088:00004088] C_Login | E: Error CKR_PIN_INCORRECT occurred.
31.12.2018 15:46:59 | [00004088:00004088] C_Login | T: leave...
According to the P11 standard CKR_PIN_INCORRECT is defined as 0x000000A0
### What is the current *bug* behavior?
dnssec-keyfromlable never asks for PIN and core dumps.
### What is the expected *correct* behavior?
dnssec-keyfromlabel should log in via p11 to the HSM, asking for the PIN and then create the pair of BIND9 key files.
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixes
Make dnssec-key-fromlabel ask for the PIN to authenticate and thus being able to use keys in the HSM.https://gitlab.isc.org/isc-projects/bind9/-/issues/170Affinity for Notifies and Updates2021-10-04T18:08:17ZVicky Riskvicky@isc.orgAffinity for Notifies and Updates### Description
For large authoritative implementations with a large matrix of multiple layers of transfer servers and slaves with multiple alternative masters, it is possible that a slave will get a notify message, and the master they ...### Description
For large authoritative implementations with a large matrix of multiple layers of transfer servers and slaves with multiple alternative masters, it is possible that a slave will get a notify message, and the master they contact for an update may not yet have received that update.
### Request
Ensure that slaves only request update transfers from one of the servers that have sent them a notify message.
### Links / referencesOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/799Slave server don't use Master which one send NOTIFY2021-10-04T18:08:16ZGhost UserSlave server don't use Master which one send NOTIFY### Description
In https://kb.isc.org/docs/aa-01467,It say **The servers are queried in turn - named moves on to the next server in the list.**
But is it unreasonable. Usually, Slave use more than two master for HA. If first master happ...### Description
In https://kb.isc.org/docs/aa-01467,It say **The servers are queried in turn - named moves on to the next server in the list.**
But is it unreasonable. Usually, Slave use more than two master for HA. If first master happend some error such as kernel panic, and second master send a NOTIFY to slave. now the slave will wait 15s(udptimeout time) + 15s(try again without EDNS) + tcp_timeout(about 120s). it may cause some error.
### Request
When Slave receive a NOTIFY, the Slave should choose master who send the NOTIFY rathen than queried the masters list.
### Links / references
patch [diff](/uploads/a845795b92e3352021431a00cb1d94e7/diff)https://gitlab.isc.org/isc-projects/bind9/-/issues/777socket.c:3252: REQUIRE(sock->references == 1) failed2021-10-04T18:06:46ZGhost Usersocket.c:3252: REQUIRE(sock->references == 1) failed### Summary
socket.c:3252: REQUIRE(sock->references == 1) fails when interface is removed from system.
### BIND version used
``` BIND 9.11.5 (Extended Support Version) <id:3b0b204>
running on FreeBSD i386 11.2-RELEASE-p2 FreeBSD 11.2-...### Summary
socket.c:3252: REQUIRE(sock->references == 1) fails when interface is removed from system.
### BIND version used
``` BIND 9.11.5 (Extended Support Version) <id:3b0b204>
running on FreeBSD i386 11.2-RELEASE-p2 FreeBSD 11.2-RELEASE-p2 #0: Tue Aug 14 19:30:14 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-randomdev=/dev/random' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-gost=no' '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' '--disable-dnstap' '--enable-filter-aaaa' '--disable-fixed-rrset' '--without-geoip' '--without-gssapi' '--with-libidn2=/usr/local' '--enable-ipv6' '--with-libjson=/usr/local' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--with-python=/usr/local/bin/python2.7' '--disable-querytrace' '--enable-rpz-nsdname' '--enable-rpz-nsip' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--with-openssl=/usr' '--enable-symtable' '--enable-threads' '--with-tuning=default' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=i386-portbld-freebsd11.2' 'build_alias=i386-portbld-freebsd11.2' 'CC=cc' 'CFLAGS=-g -O0 -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final 326565)
compiled with OpenSSL version: OpenSSL 1.0.2o-freebsd 27 Mar 2018
linked to OpenSSL version: OpenSSL 1.0.2o-freebsd 27 Mar 2018
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
### Steps to reproduce
My DSL connection has been unstable for a couple of days, and when the DSL connection goes down, ppp exits, and tun0 is destroyed, named crashes. This did not happen in prior versions of bind. I can reproduce this bind crash by using ifconfig tun0 destroy.
### What is the current *bug* behavior?
bind crashes. I am running bind911-9.11.5_1 from freebsd ports, with a modification so that --enable-symtable at least gets me a backtrace:
cwd is /usr/local/etc/namedb/working, owned by bind:bind 755, and bind is running as user bind, but I am not getting a core dump. bind is running as follows:
/usr/local/sbin/named -u bind -c /usr/local/etc/namedb/named.conf
I am happy to get a core dump if someone knows how to get the freebsd port to build or run in such a way that it will dump core. The crash is completely repeatable. Note that in the bind conf below, tun0 is an Internet-facing interface without any of the IP addresses in listen-on on it.
### What is the expected *correct* behavior?
bind does not crash.
### Relevant configuration files
```
acl "trusted" {
"localhost";
"localnets";
};
logging {
category "resolver" {
"null";
};
};
options {
directory "/usr/local/etc/namedb/working";
dump-file "/var/dump/named_dump.db";
listen-on {
127.0.0.1/32;
192.168.4.1/32;
192.168.2.1/32;
192.168.3.1/32;
};
pid-file "/var/run/named/pid";
statistics-file "/var/stats/named.stats";
allow-query-cache {
"trusted";
};
allow-recursion {
"trusted";
};
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "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.0.IP6.ARPA";
disable-empty-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";
dnssec-validation auto;
};
zone "." {
type hint;
file "/usr/local/etc/namedb/named.root";
};
zone "localhost" {
type master;
file "/usr/local/etc/namedb/master/localhost-forward.db";
};
zone "127.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/localhost-reverse.db";
};
zone "255.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "0.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/localhost-reverse.db";
};
zone "0.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "10.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "16.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "17.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "18.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "19.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "20.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "21.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "22.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "23.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "24.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "25.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "26.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "27.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "28.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "29.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "30.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "31.172.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "168.192.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "64.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "65.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "66.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "67.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "68.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "69.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "70.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "71.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "72.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "73.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "74.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "75.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "76.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "77.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "78.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "79.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "80.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "81.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "82.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "83.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "84.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "85.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "86.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "87.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "88.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "89.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "90.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "91.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "92.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "93.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "94.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "95.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "96.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "97.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "98.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "99.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "100.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "101.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "102.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "103.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "104.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "105.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "106.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "107.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "108.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "109.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "110.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "111.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "112.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "113.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "114.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "115.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "116.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "117.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "118.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "119.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "120.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "121.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "122.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "123.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "124.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "125.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "126.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "127.100.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "254.169.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "0.0.192.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "2.0.192.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "100.51.198.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "113.0.203.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "8.b.d.0.1.0.0.2.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "test" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "example" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "invalid" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "example.com" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "example.net" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "example.org" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "18.198.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "19.198.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "240.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "241.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "242.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "243.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "244.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "245.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "246.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "247.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "248.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "249.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "250.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "251.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "252.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "253.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "254.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "1.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "3.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "4.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "5.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "6.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "7.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "8.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "9.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "a.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "b.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "c.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "d.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "e.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "0.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "1.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "2.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "3.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "4.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "5.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "6.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "7.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "8.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "9.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "a.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "b.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "0.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "1.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "2.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "3.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "4.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "5.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "6.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "7.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "c.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "d.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "8.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "9.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "a.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "b.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "c.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "d.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "e.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "f.e.f.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "ip6.int" {
type master;
file "/usr/local/etc/namedb/master/empty.db";
};
zone "luckie.org.nz" {
type master;
file "luckie.org.nz";
notify no;
};
zone "XXXXXX.dyndns.org" {
type master;
file "XXXXXX.dyndns.org";
notify no;
};
zone "4.168.192.in-addr.arpa" {
type master;
file "4.168.192.in-addr.arpa";
notify no;
};
zone "2.168.192.in-addr.arpa" {
type master;
file "2.168.192.in-addr.arpa";
notify no;
};
zone "3.168.192.in-addr.arpa" {
type master;
file "3.168.192.in-addr.arpa";
notify no;
};
```
### Relevant logs and/or screenshots
``` Dec 12 19:07:40 XXX named[15312]: socket.c:3252: REQUIRE(sock->references == 1) failed, back trace
Dec 12 19:07:40 XXX named[15312]: #0 0x809a2e8 in assertion_failed()+0xa8
Dec 12 19:07:40 XXX named[15312]: #1 0x8491db6 in isc_assertion_failed()+0x76
Dec 12 19:07:40 XXX named[15312]: #2 0x84fcf6c in isc__socket_close()+0x14c
Dec 12 19:07:40 XXX kernel: pid 15312 (named), uid 53: exited on signal 6
Dec 12 19:07:42 XXX dhcp6c[90941]: transmit failed: No buffer space available
```
### Possible fixes
socket.c line 3252.Not plannedWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/761Follow-up from "Resolve "Remove support for insecure RSAMD5""2021-10-04T18:05:31ZOndřej SurýFollow-up from "Resolve "Remove support for insecure RSAMD5""The following discussion from !1106 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1106#note_34163): (+2 comments)
> This comes from RFC 3110, section 4: Perfor...The following discussion from !1106 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1106#note_34163): (+2 comments)
> This comes from RFC 3110, section 4: Performance Considerations:
> ```
> A public exponent of 3 minimizes the effort needed to verify a
> signature. Use of 3 as the public exponent is weak for
> confidentiality uses since, if the same data can be collected
> encrypted under three different keys with an exponent of 3 then,
> using the Chinese Remainder Theorem [NETSEC], the original plain text
> can be easily recovered. If a key is known to be used only for
> authentication, as is the case with DNSSEC, then an exponent of 3 is
> acceptable. However other applications in the future may wish to
> leverage DNS distributed keys for applications that do require
> confidentiality. For keys which might have such other uses, a more
> conservative choice would be 65537 (F4, the fourth fermat number).
> ```
>
> I don't know if nowadays there are more weak exponents, I don't know if other RFC advises against other public exponent values. I would suggest to leave the check as is and update the `XXXOND` documentation with the RFC 3110 reference.https://gitlab.isc.org/isc-projects/bind9/-/issues/734Follow-up from "WIP: Fix compilation on CentOS 6 (i386)"2021-10-04T13:44:49ZOndřej SurýFollow-up from "WIP: Fix compilation on CentOS 6 (i386)"The following discussion from !1129 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1129#note_32353): (+1 comment)
> If we are doing this, we probably should fix t...The following discussion from !1129 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1129#note_32353): (+1 comment)
> If we are doing this, we probably should fix the ARMv6 builds too.https://gitlab.isc.org/isc-projects/bind9/-/issues/651Add an option to disable qname minimization for selected domains2021-10-04T13:33:45ZWitold KrecickiAdd an option to disable qname minimization for selected domainsNot plannedWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/650There's a slight possibility of race in dig code2021-10-04T13:30:33ZWitold KrecickiThere's a slight possibility of race in dig codein bin/dig/dighost.c query_clear unlinks the query, which sets link->prev/next to (void*) -1, but if the response is still in flight then we'll try to dereference this link in send_done.in bin/dig/dighost.c query_clear unlinks the query, which sets link->prev/next to (void*) -1, but if the response is still in flight then we'll try to dereference this link in send_done.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/636Selective 'stop' on CNAME-chasing for resolvers2021-10-04T13:27:53ZCathy AlmondSelective 'stop' on CNAME-chasing for resolvers### Description
This feature request is to help organisations who are using recursive servers to 'manage' boundary authoritative DNS services. The scenario specifically, is how to stop resolvers attempting to follow CNAME chains that p...### Description
This feature request is to help organisations who are using recursive servers to 'manage' boundary authoritative DNS services. The scenario specifically, is how to stop resolvers attempting to follow CNAME chains that point outside of the domain (and subdomains of that domain) that are being 'served' this way.
### Request
The scenario is one in which a complex organisation wishes to have all client queries for their authoritative domains (and subdomains) handled solely by a set of nameservers that are Internet-facing. These servers are authoritative for the top level domain(s) but delegate subdomains to other internal servers, who themselves may delegate yet again. It is not possible (for various reasons) for the Internet-facing servers to slave all of the delegated subdomains and sub-sub-domains...
These resolvers, therefore are acting as proxies, and use normal recursion towards the delegated subdomain servers in order to obtain the answers that they need for the clients.
Client queries, as you would expect, are non-recursive (originating from Internet resolvers) but have RD added by means of packet manipulation tools. Similarly, they are also flipping header bit settings again on the way out on the query responses.
One point (there are others - they are not for discussion here) where this design breaks is in handling CNAME chains in some circumstances.
A normal recursive resolver expects to follow a CNAME chain all the way to the final RRset and to return that, along with the CNAME chain itself, to the stub client that queried it with 'RD' set. If it cannot complete that, it will SERVFAIL. A genuine authoritative server will stop attempting to following CNAME chains if they point outside of the zones for which it is authoritative, and will fill the query response with what it has, assuming that the (resolver) client will be able to pick up and make onward queries to other servers to complete the chain.
The 'custom' resolvers in this unusual proxy configuration are only able to resolve names within the organisation's internal namespace. They cannot (and should not - recall that they are emulating authoritative servers) follow CNAMEs that point outside of their domain(s).
But there is currently no mechanism for telling named to stop trying and to return 'what it has so far' when it is configured to be a resolver, so when they encounter 'out of domain' CNAMEs, they fail.
What is wished for, is a configuration option to control this so that a resolver that is masquerading as authoritative can stop CNAME-chasing (probably on a per-domain basis) without SERVFAILing.
This is not an option that would ever be valid for a normal recursive server.
This request has been discussed with engineering - who agreed to do a technical feasibility evaluation only.
### Links / references
https://support.isc.org/Ticket/Display.html?id=13653https://gitlab.isc.org/isc-projects/bind9/-/issues/625dnssec-coverage complains about issues in the past2021-10-04T13:27:22ZOndřej Surýdnssec-coverage complains about issues in the pastReported by Peter Palfrader in Debian:
We regularly rotate our ZSKs, and just recently we started removing old
.key files from our keydir.
The oldest remaining ZSK now has a published date in the past, and an
activation date also in th...Reported by Peter Palfrader in Debian:
We regularly rotate our ZSKs, and just recently we started removing old
.key files from our keydir.
The oldest remaining ZSK now has a published date in the past, and an
activation date also in the past but after the publish date.
(Previously, the oldest ZSK was the *first* ZSK, and it had publish
and activate at the same time.)
dnssec-coverage complains about this:
```
| Checking scheduled ZSK events for zone debian.nl, algorithm RSASHA256...
| Wed Jul 11 12:07:03 UTC 2018:
| Publish: debian.nl/008/17304 (ZSK)
| ERROR: No ZSK's are active after this event
for
; This is a zone-signing key, keyid 17304, for debian.nl.
; Created: 20180211121307 (Sun Feb 11 12:13:07 2018)
; Publish: 20180711120703 (Wed Jul 11 12:07:03 2018)
; Activate: 20180810120703 (Fri Aug 10 12:07:03 2018)
; Inactive: 20181208120703 (Sat Dec 8 12:07:03 2018)
; Delete: 20190107120703 (Mon Jan 7 12:07:03 2019)
[..key..]
; This is a zone-signing key, keyid 29616, for debian.nl.
; Created: 20180612045523 (Tue Jun 12 04:55:23 2018)
; Publish: 20181108120703 (Thu Nov 8 12:07:03 2018)
; Activate: 20181208120703 (Sat Dec 8 12:07:03 2018)
; Inactive: 20190407120703 (Sun Apr 7 12:07:03 2019)
; Delete: 20190507120703 (Tue May 7 12:07:03 2019)
[..key..]
; This is a zone-signing key, keyid 37155, for debian.nl.
; Created: 20181009121102 (Tue Oct 9 12:11:02 2018)
; Publish: 20190308120703 (Fri Mar 8 12:07:03 2019)
; Activate: 20190407120703 (Sun Apr 7 12:07:03 2019)
; Inactive: 20190805120703 (Mon Aug 5 12:07:03 2019)
; Delete: 20190904120703 (Wed Sep 4 12:07:03 2019)
[..key..]
```
I propose dnssec-coverage ignore cases of no
active/publish/active&published that happened in the past.
```
--- /usr/sbin/dnssec-coverage 2018-01-15 21:40:17.000000000 +0000
+++ /srv/dns.debian.org/bin/dnssec-coverage 2018-10-24 18:24:01.216562896 +0000
@@ -15,6 +15,10 @@
# PERFORMANCE OF THIS SOFTWARE.
############################################################################
+# changes 2018-10-24, Peter Palfrader
+# - ignore "errors" in the past (like no active keys)
+# as that can result from retiring old (and deleted) keyfiles
+
import argparse
import os
import glob
@@ -23,6 +27,7 @@
import time
import calendar
from collections import defaultdict
+from itertools import zip_longest
import pprint
prog='dnssec-coverage'
@@ -531,7 +536,7 @@
if eventgroup:
eventgroups.append(eventgroup)
- for eventgroup in eventgroups:
+ for eventgroup, next_eventgroup in zip_longest(eventgroups, eventgroups[1:]):
if (args.checklimit and
calendar.timegm(eventgroup[0].when) > args.checklimit):
print("Ignoring events after %s" %
@@ -545,18 +550,19 @@
list_events(eventgroup)
# and then check for inconsistencies:
+
+ # but do not bail out on inconsistencies in the past that may be the result of keys that got retired
+ bygones = next_eventgroup is not None and calendar.timegm(next_eventgroup[0].when) < time.time()
if len(active) == 0:
- print ("ERROR: No %s's are active after this event" % keytype)
- return False
+ print ("%s: No %s's are active after this event" %(['ERROR', 'INFO'][bygones], keytype))
+ if not bygones: return False
elif len(published) == 0:
- sys.stdout.write("ERROR: ")
- print ("ERROR: No %s's are published after this event" % keytype)
- return False
+ print ("%s: No %s's are published after this event" % (['ERROR', 'INFO'][bygones], keytype))
+ if not bygones: return False
elif len(published.intersection(active)) == 0:
- sys.stdout.write("ERROR: ")
- print (("ERROR: No %s's are both active and published " +
- "after this event") % keytype)
- return False
+ print (("%s: No %s's are both active and published " +
+ "after this event") % (['ERROR', 'INFO'][bygones], keytype))
+ if not bygones: return False
if not eventsfound:
print ("ERROR: No %s events found in '%s'" %
```
To reproduce:
```
mkdir example.com
cd example.com
faketime -f '-1y' /usr/sbin/dnssec-keygen -f KSK -K . -a RSASHA256 -3 -b 2048 example.com
key=$(faketime -f '-1y' /usr/sbin/dnssec-keygen -K . -a RSASHA256 -3 -b 1024 -I +120d -D +150d example.com)
first=$key
lt=120
for i in `seq 1 5`; do
lt=$((lt + 120))
key=$(faketime -f '-1y' /usr/sbin/dnssec-keygen -K . -S "$key.key" -I +${lt}d -D +$((lt+30))d example.com)
done
/usr/sbin/dnssec-coverage -K . -l 200d -c /usr/sbin/named-compilezone example.com
rm $first.key $first.private
/usr/sbin/dnssec-coverage -K . -l 200d -c /usr/sbin/named-compilezone example.com
```Evan HuntEvan Hunt