BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-11-14T17:51:35Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/613Add option for min-cache2018-11-14T17:51:35ZOndřej SurýAdd option for min-cacheAt least Debian and Ubuntu carry additional patch to add min-cache-ttl and min-ncache-ttl. It seems like reasonable thing to add.At least Debian and Ubuntu carry additional patch to add min-cache-ttl and min-ncache-ttl. It seems like reasonable thing to add.BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/712LeakSanitizer: detected memory leaks in delv2018-11-19T16:38:56ZOndřej SurýLeakSanitizer: detected memory leaks in delvWith gcc 8, the LeakSanitizer reports:
```
=================================================================
==20969==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 201 byte(s) in 1 object(s) allocated from:
#0 0x7f260a...With gcc 8, the LeakSanitizer reports:
```
=================================================================
==20969==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 201 byte(s) in 1 object(s) allocated from:
#0 0x7f260aecaed0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f2608b4a08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
Indirect leak of 4189 byte(s) in 24 object(s) allocated from:
#0 0x7f260aecaed0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f2608b4a08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
SUMMARY: AddressSanitizer: 4390 byte(s) leaked in 25 allocation(s).
```
and the dnssec and mkeys tests fail: https://gitlab.isc.org/isc-private/bind9/-/jobs/99009
Both are using `delv` for the tests.BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/711LeakSanitizer: detected memory leaks2018-11-19T06:57:35ZOndřej SurýLeakSanitizer: detected memory leaks`lib/isc/tests/lex_test.c` reports:
```
=================================================================
==897==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 658 byte(s) in 2 object(s) allocated from:
#0 0x7f58a314ced...`lib/isc/tests/lex_test.c` reports:
```
=================================================================
==897==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 658 byte(s) in 2 object(s) allocated from:
#0 0x7f58a314ced0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f58a2d5e08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
Indirect leak of 4440 byte(s) in 10 object(s) allocated from:
#0 0x7f58a314ced0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f58a2d5e08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
SUMMARY: AddressSanitizer: 5098 byte(s) leaked in 12 allocation(s).
```BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/710AddressSanitizer: heap-buffer-overflow socket_test.c:104 in event_done2018-11-19T17:02:43ZOndřej SurýAddressSanitizer: heap-buffer-overflow socket_test.c:104 in event_doneI found this while working on #707 and after some thinking about what I did wrong in the MR, I realised that I did nothing wrong and this is a bug hidden by small allocations allocator and it could be reproduced by `CFLAGS="-fsanitize=ad...I found this while working on #707 and after some thinking about what I did wrong in the MR, I realised that I did nothing wrong and this is a bug hidden by small allocations allocator and it could be reproduced by `CFLAGS="-fsanitize=address,undefined -DISC_MEM_USE_INTERNAL_MALLOC=0 -Os -g" ./configure --with-cmocka` and running `lib/isc/tests/socket_test`.
One more reason why #707 will be useful.
```
=================================================================
==49218==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c0000002fc at pc 0x000109aa74f1 bp 0x7000089a8c90 sp 0x7000089a8c88
READ of size 4 at 0x60c0000002fc thread T21
#0 0x109aa74f0 in event_done socket_test.c:104
#1 0x109b27382 in dispatch task.c:1116
#2 0x109b1b340 in run task.c:1293
#3 0x7fff7b1b9338 in _pthread_body (libsystem_pthread.dylib:x86_64+0x3338)
#4 0x7fff7b1bc2a6 in _pthread_start (libsystem_pthread.dylib:x86_64+0x62a6)
#5 0x7fff7b1b8444 in thread_start (libsystem_pthread.dylib:x86_64+0x2444)
Address 0x60c0000002fc is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow socket_test.c:104 in event_done
Shadow bytes around the buggy address:
0x1c1800000000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x1c1800000010: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x1c1800000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
0x1c1800000030: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x1c1800000040: 00 00 00 00 00 00 01 fa fa fa fa fa fa fa fa fa
=>0x1c1800000050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
0x1c1800000060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c1800000070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c1800000080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c1800000090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c18000000a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Thread T21 created by T0 here:
#0 0x109ec21cd in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4f1cd)
#1 0x109b8af27 in isc_thread_create thread.c:65
#2 0x109b1a6ed in isc_taskmgr_create task.c:1380
#3 0x109aa859c in isc_test_begin isctest.c:89
#4 0x109aa2166 in _setup socket_test.c:51
#5 0x109e6ab17 in cmocka_run_one_test_or_fixture (libcmocka.0.dylib:x86_64+0x5b17)
#6 0x109e68ec2 in _cmocka_run_group_tests (libcmocka.0.dylib:x86_64+0x3ec2)
#7 0x7fff7afc708c in start (libdyld.dylib:x86_64+0x1708c)
==49218==ABORTING
Abort trap: 6
```
Marking as confidential as I have no idea about the impact of this one (is the bug only in the test or in the library?), but it affects v9.10+ that have the test (version <= 9.9 doesn't have the test nor DSCP support).BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/687Reduce the overall files we consider copyrightable2018-11-12T15:14:34ZOndřej SurýReduce the overall files we consider copyrightable* configuration files (`CONF-C`)
* zone file (*.db)
And perhaps some more...* configuration files (`CONF-C`)
* zone file (*.db)
And perhaps some more...BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/659Make task manager more threaded2018-11-15T08:15:44ZWitold KrecickiMake task manager more threadedCurrently task manager is using a single queue for all the runners. It should have a per-runner queue, and possibility to send tasks to specific runners to take advantage of CPU/memory affinity.Currently task manager is using a single queue for all the runners. It should have a per-runner queue, and possibility to send tasks to specific runners to take advantage of CPU/memory affinity.BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/656Add support for Utimaco HSM2019-01-01T17:29:25ZOndřej SurýAdd support for Utimaco HSMThere are couple of issues found by my testing:
1. BIND 9.11 and BIND 9.12 fails on DigestUpdate, as Utimaco HSM requires user to be authenticated before any crypto operation is executed and our code checks for MD5 and SHA1 functionalit...There are couple of issues found by my testing:
1. BIND 9.11 and BIND 9.12 fails on DigestUpdate, as Utimaco HSM requires user to be authenticated before any crypto operation is executed and our code checks for MD5 and SHA1 functionality before the login is even attempted
2. ~~BIND 9.13 is broken in some other way (I'll add more info later)~~BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/654lame-servers due to qname-minimization2018-11-05T10:14:09ZTony Finchlame-servers due to qname-minimizationAfter the recent qmin refactoring, I noticed a *lot* of lame-servers warnings in my logs, listing the gtld-servers.net IP addresses. These warnings go away if I set `qname-minimization disabled;`
If I turn up the trace level, I can see ...After the recent qmin refactoring, I noticed a *lot* of lame-servers warnings in my logs, listing the gtld-servers.net IP addresses. These warnings go away if I set `qname-minimization disabled;`
If I turn up the trace level, I can see it sending (e.g.) `motherboard.vice.com. AAAA ?` to the gtld-servers then complaining when it gets a referral.
Earlier in the logs (in the space of about 1ms) it logs about doing a `createfind` for *every* gtld-server for this one query. This seems to be much too much! It then goes to find the vice.com NS and DS records, then sends the motherboard.vice.com queries to the gtld-servers. It all seems very confused.BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/648Windows - !901/!916 Issues2018-11-16T13:56:58ZThomas JachWindows - !901/!916 IssuesThe following changes address the issues.
Add
```
/* Define to 1 if you have the `CRYPTO_zalloc' function. */
@HAVE_CRYPTO_ZALLOC@
/* Define to 1 if you have the `EVP_CIPHER_CTX_free' function. */
@HAVE_EVP_CIPHER_CTX_FREE@
/* Define ...The following changes address the issues.
Add
```
/* Define to 1 if you have the `CRYPTO_zalloc' function. */
@HAVE_CRYPTO_ZALLOC@
/* Define to 1 if you have the `EVP_CIPHER_CTX_free' function. */
@HAVE_EVP_CIPHER_CTX_FREE@
/* Define to 1 if you have the `EVP_CIPHER_CTX_new' function. */
@HAVE_EVP_CIPHER_CTX_NEW@
/* Define to 1 if you have the `EVP_MD_CTX_free' function. */
@HAVE_EVP_MD_CTX_FREE@
/* Define to 1 if you have the `EVP_MD_CTX_new' function. */
@HAVE_EVP_MD_CTX_NEW@
/* Define to 1 if you have the `EVP_MD_CTX_reset' function. */
@HAVE_EVP_MD_CTX_RESET@
/* Define to 1 if you have the `HMAC_CTX_free' function. */
@HAVE_HMAC_CTX_FREE@
/* Define to 1 if you have the `HMAC_CTX_get_md' function. */
@HAVE_HMAC_CTX_GET_MD@
/* Define to 1 if you have the `HMAC_CTX_new' function. */
@HAVE_HMAC_CTX_NEW@
/* Define to 1 if you have the `HMAC_CTX_reset' function. */
@HAVE_HMAC_CTX_RESET@
```
to config.h.win32.
Replace
```
"HAVE_RSA_SET0_KEY",
```
with
```
"HAVE_RSA_SET0_KEY",
"HAVE_CRYPTO_ZALLOC",
"HAVE_EVP_CIPHER_CTX_FREE",
"HAVE_EVP_CIPHER_CTX_NEW",
"HAVE_EVP_MD_CTX_FREE",
"HAVE_EVP_MD_CTX_NEW",
"HAVE_EVP_MD_CTX_RESET",
"HAVE_HMAC_CTX_FREE",
"HAVE_HMAC_CTX_GET_MD",
"HAVE_HMAC_CTX_NEW",
"HAVE_HMAC_CTX_RESET",
```
Replace
```
# check OpenSSL built-in support for DH/DSA/ECDSA/RSA functions
```
with
```
# check OpenSSL built-in support for DH/ECDSA/RSA/CRYPTO_ZALLOC/EVP_CIPHER_CTX/EVP_MD_CTX/HMAC_CTX functions
```
Replace
```
printf "checking OpenSSL built-in support for DH/DSA/ECDSA/RSA functions\n";
```
with
```
printf "checking OpenSSL built-in support for DH/ECDSA/RSA/CRYPTO_ZALLOC/EVP_CIPHER_CTX/EVP_MD_CTX/HMAC_CTX functions\n";
```
Replace
```
printf("This version has no built-in support for DH/ECDSA/RSA functions.\n\n");
```
with
```
printf("This version has no built-in support for DH/ECDSA/RSA/CRYPTO_ZALLOC/EVP_CIPHER_CTX/EVP_MD_CTX/HMAC_CTX functions.\n\n");
```
Replace
```
$configdefh{"HAVE_RSA_SET0_KEY"} = 1;
```
with
```
$configdefh{"HAVE_RSA_SET0_KEY"} = 1;
$configdefh{"HAVE_CRYPTO_ZALLOC"} = 1;
$configdefh{"HAVE_EVP_CIPHER_CTX_FREE"} = 1;
$configdefh{"HAVE_EVP_CIPHER_CTX_NEW"} = 1;
$configdefh{"HAVE_EVP_MD_CTX_FREE"} = 1;
$configdefh{"HAVE_EVP_MD_CTX_NEW"} = 1;
$configdefh{"HAVE_EVP_MD_CTX_RESET"} = 1;
$configdefh{"HAVE_HMAC_CTX_FREE"} = 1;
$configdefh{"HAVE_HMAC_CTX_GET_MD"} = 1;
$configdefh{"HAVE_HMAC_CTX_NEW"} = 1;
$configdefh{"HAVE_HMAC_CTX_RESET"} = 1;
```
in win32utils\Configure.BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/644isc_buffer_copyregion() is broken for auto-reallocated buffers2018-10-30T12:52:26ZMichał Kępieńisc_buffer_copyregion() is broken for auto-reallocated buffersWhile `isc_buffer_copyregion()` calls `isc_buffer_reserve()` to ensure the target buffer will have enough available space to append the contents of the source region to it, the variables used for subsequently checking available space are...While `isc_buffer_copyregion()` calls `isc_buffer_reserve()` to ensure the target buffer will have enough available space to append the contents of the source region to it, the variables used for subsequently checking available space are not updated accordingly after that call. This prevents `isc_buffer_copyregion()` from working as expected for auto-reallocated buffers: `ISC_R_NOSPACE` will be returned if enough space is not already available in the target buffer before it is reallocated.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/620CMOCKA conversions2018-11-15T05:19:01ZEvan HuntCMOCKA conversionsConversion of existing ATF unit tests to CMOCKA framework.Conversion of existing ATF unit tests to CMOCKA framework.BIND-9.13.4Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/587statistics-channels /xml/v2 is removed but still documented2018-11-13T19:07:18ZPetr Menšíkstatistics-channels /xml/v2 is removed but still documented<!--
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
ARM contains documentation of statistics-channels format of /xml/v2. But code does not allow such format anymore. Only /xml/v3 and /json/v1 are supported in code.
### BIND version used
BIND 9.11.4-RedHat-9.11.4-2.fc27
It seems present also in devel version
### Steps to reproduce
grep '/v2' -r doc
doc/arm/Bv9ARM.ch05.html: <a class="link" href="http://127.0.0.1:8888/xml/v2" target="_top">http://127.0.0.1:8888/xml/v2</a> for version 2
doc/arm/Bv9ARM-book.xml: <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v2">http://127.0.0.1:8888/xml/v2</link> for version 2
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
Documents statistics format that cannot be configured.
### What is the expected *correct* behavior?
Do not mention format that is not available.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/583Regression: Forward queries with forward only is no longer working2018-10-29T19:31:03ZGhost UserRegression: Forward queries with forward only is no longer working### Summary
Running the latest bind version (9.13.3) forwarding queries with the `forward only` option is no longer working.
Basically I have a split horizon DNS, using multiple bind instances running on multiple hosts. But I was able ...### Summary
Running the latest bind version (9.13.3) forwarding queries with the `forward only` option is no longer working.
Basically I have a split horizon DNS, using multiple bind instances running on multiple hosts. But I was able to identify the culprit to be the resolver, which was configured to forward queries for specific zones to an internal authoritative server, while answering all other queries the usual way.
This used to work fine with `9.13.1`, but when upgrading to `9.13.2`, this no longer works. It is still broken in `9.13.3`.
### BIND version used
Broken version (`9.13.2`):
```
BIND 9.13.2 (Development Release) <id:4f6ef2f>
running on Linux x86_64 4.14.72-1-lts #1 SMP Wed Sep 26 12:31:03 CEST 2018
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-ipv6' '--enable-filter-aaaa' '--enable-fixed-rrset' '--enable-seccomp' '--enable-full-report' '--with-python=/usr/bin/python' '--with-geoip' '--with-idn' '--with-openssl' '--with-libjson' '--with-libxml2' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 8.2.1 20180831
compiled with OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 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
```
Last version that used to work (`9.13.1`):
```
BIND 9.13.1 (Development Release) <id:5b71025>
running on Linux x86_64 4.14.72-1-lts #1 SMP Wed Sep 26 12:31:03 CEST 2018
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-ipv6' '--enable-filter-aaaa' '--enable-fixed-rrset' '--enable-seccomp' '--enable-full-report' '--with-python=/usr/bin/python' '--with-geoip' '--with-idn' '--with-openssl' '--with-libjson' '--with-libxml2' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 8.2.1 20180831
compiled with OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 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
- Configure bind in a way where queries for a particular zone are forwarded to a dedicated authoritative nameserver. Use the `forward only` option for this. I'm attaching my `named.conf` further down below in this bug report.
- Issue an query to the forwarded zone
- Bind will return with a `SERVFAIL`
### What is the current *bug* behavior?
Any queries for the `babioch.de` zone are answered with `SERVFAIL`, for instance:
```
dig @10.24.0.1 mail.babioch.de
; <<>> DiG 9.13.2 <<>> @10.24.0.1 mail.babioch.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10792
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d4edf146ddd092808c7e71535bb8bbfc46eaa07e7d222dfe (good)
;; QUESTION SECTION:
;mail.babioch.de. IN A
;; Query time: 18 msec
;; SERVER: 10.24.0.1#53(10.24.0.1)
;; WHEN: Sa Okt 06 15:43:24 CEST 2018
;; MSG SIZE rcvd: 72
```
### What is the expected *correct* behavior?
Queries for the `babioch.de` zone are correctly answered:
```
dig @10.24.0.1 mail.babioch.de
; <<>> DiG 9.13.1 <<>> @10.24.0.1 mail.babioch.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59672
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ce6833cdc8a7f26af62c368d5bb8bc443c63c9ba62ea9a7d (good)
;; QUESTION SECTION:
;mail.babioch.de. IN A
;; ANSWER SECTION:
mail.babioch.de. 300 IN A 10.24.0.20
;; Query time: 1 msec
;; SERVER: 10.24.0.1#53(10.24.0.1)
;; WHEN: Sa Okt 06 15:44:36 CEST 2018
;; MSG SIZE rcvd: 88
```
### Relevant configuration files
The stripped down version of my configuration, which still will trigger this regression, looks like this:
```
options {
listen-on port 53 { 127.0.0.1; 10.24.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
pid-file "/run/named/named.pid";
recursion yes;
allow-query { localhost; 10.24.0.0/16; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.zone";
zone "babioch.de" IN {
type forward;
forward only;
forwarders { 10.24.0.10; };
};
```
### Relevant logs and/or screenshots
The query log contains this:
```
Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670 127.0.0.1#51022 (mail.babioch.de): query: mail.babioch.de IN A +E(0)K (127.0.0.1)
Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670 127.0.0.1#51022 (mail.babioch.de): query failed (SERVFAIL) for mail.babioch.de/IN/A at query.c:10672
```
### Possible fixes
The line in question is handling stale answers [1]. I'm not entirely sure how this applies to my use-case, since nothing should be stale here.
Interestingly enough I can get it working, when I'm removing the
"forward only" directive from my configuration. This looks like this:
I was able to work around this with commenting out the `forward only` option, effectively falling back to `forward first`. This works in my case, but there might be setups, where this is not an option.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/v9_13_3/lib/ns/query.c#L10672BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/579EdDSA support does not work with the final version of OpenSSL 1.1.12018-10-04T10:54:04ZMichał KępieńEdDSA support does not work with the final version of OpenSSL 1.1.1The `eddsa` system test consistently fails on any platform with OpenSSL 1.1.1 installed:
```
S:eddsa:Thu Oct 4 11:24:57 CEST 2018
T:eddsa:1:A
A:eddsa:System test eddsa
I:eddsa:PORTRANGE:5300 - 5399
dnssec-signzone: warning: EVP_DigestS...The `eddsa` system test consistently fails on any platform with OpenSSL 1.1.1 installed:
```
S:eddsa:Thu Oct 4 11:24:57 CEST 2018
T:eddsa:1:A
A:eddsa:System test eddsa
I:eddsa:PORTRANGE:5300 - 5399
dnssec-signzone: warning: EVP_DigestSignInit failed (failure)
dnssec-signzone: fatal: dnskey './ED25519/30149' failed to sign data: failure
dnssec-signzone: warning: EVP_DigestSignInit failed (failure)
dnssec-signzone: fatal: dnskey 'example.com/ED25519/3613' failed to sign data: failure
I:checking that positive validation works (0)
I:failed
I:checking that test vectors match (1)
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
I:failed
I:exit status: 2
R:eddsa:FAIL
E:eddsa:Thu Oct 4 11:24:59 CEST 2018
```
Since this [includes current Debian sid][1], the `eddsa` system test should first be disabled so that CI pipelines can pass and then BIND's EdDSA code should be fixed to work with the final version of OpenSSL 1.1.1.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/63060BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/574BIND 9.13.4 Release Checklist2018-11-22T14:28:48ZVicky Riskvicky@isc.orgBIND 9.13.4 Release Checklist## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generatio...## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generation
- [x] Change software version and library versions in configure.in
- [x] Update CHANGES
- [x] Ensure the release notes are correct for this release
- [x] Ensure the metainformation is correct for this release
- [x] Make sure the tests are passing
- [x] Create a tag (name vX_Y_Z[-alphatag], content BIND X.Y.Z[-alphatag], signed with a developer's GPG key): git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z
- [x] Push the changes and tag
- [x] Create the tarball
- [x] Create the Windows zips
- [x] Ask QA to sanity check the tarball and zips
- [x] Request the signature on the tarballs
- [x] Make tarballs and signatures available to download
- [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
- [ ] Update DEB and RPM packages
## Support
- [x] Inform support to upload to the web site (nice to give them a heads-up in advance)
- Write release e-mail to bind9-announce, bind-users in case of a major release
- Update tickets in case of waiting support customers
## Marketing
- [ ] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND (mktg)
- Blog post if a major releaseBIND-9.13.42018-10-10https://gitlab.isc.org/isc-projects/bind9/-/issues/572Improve accuracy of query error logging2018-10-08T11:01:44ZMichał KępieńImprove accuracy of query error loggingThere are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`]...There are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`][1] generates a SERVFAIL response. When serve-stale was implemented in BIND 9.12, it was done in a way which causes that `default:` branch to only [set a flag (`want_stale`) in the query context][2] for such queries, effectively moving the `QUERY_ERROR()` call for such queries [to `query_done()`][3] (and making `query_done()` call itself recursively, which hinders readability). This may be a source of confusion[^1] as the "query failed" log messages now point at a line in `query_done()` which appears to have something to do with serve-stale (`if (qctx->want_stale)`) even if the latter is not enabled.
2. Apparently we are setting `qctx->result` to `DNS_R_SERVFAIL` for a lot of different failure modes:
```sh
$ sed -n 's|.*\(QUERY_ERROR([^)]*);\)$|\1|p;' lib/ns/query.c | sort | uniq -c | sort
2 QUERY_ERROR(qctx, DNS_R_DROP);
2 QUERY_ERROR(qctx, DNS_R_REFUSED);
4 QUERY_ERROR(qctx, result);
19 QUERY_ERROR(qctx, DNS_R_SERVFAIL);
```
In some situations, this really is the only sensible thing to do (e.g. when the root key sentinel mechanism overrides the RCODE or when the SERVFAIL cache is hit) but in most others, doing this feels like replacing potentially useful diagnostic information with a rather less useful "oops, something went wrong" type of message:
```
client @0x7fa62c0403b0 ::1#52563 (servfail.nl): query failed (SERVFAIL) for servfail.nl/IN/A at query.c:10681
```
While in some cases the root cause of failed queries is indicated by the preceding log messages, troubleshooting others requires recompiling BIND with `--enable-querytrace`, which is not always a viable option for the user.
I think we can improve `named`'s behavior in this regard. Note that the response message's RCODE is derived from `qctx->result` using `dns_result_torcode()`, which handles a number of possible `isc_result_t` values and returns SERVFAIL for anything not explicitly listed. If we used `QUERY_ERROR(qctx, result);` instead of `QUERY_ERROR(qctx, DNS_R_SERVFAIL);` where possible, the specific error could be logged by `query_error()` and the response's RCODE would still be SERVFAIL. The win here would be that some light could be shed on the less obvious query errors just by bumping the debug level using `rndc trace` (or enabling query logging) rather than recompiling with `--enable-querytrace`.
[^1]: see e.g. https://lists.isc.org/pipermail/bind-users/2018-September/100868.html, though the issue caught me by surprise a couple of times as well while debugging
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/c635b3175620ea085a8d2402afd446dfd95422bd/bin/named/query.c#L8571-8580
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L6675-6679
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L10644BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/564Mirror zone configuration tweaks and cleanups2018-10-24T18:51:39ZMichał KępieńMirror zone configuration tweaks and cleanupsVarious discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone con...Various discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone configuration could use some tweaks:
* `type secondary; mirror yes;` should be replaced with `type mirror;`
* it should be clearly documented that:
* mirror zones are supposed to *replace* the configuration example provided by [RFC 7706](https://tools.ietf.org/html/rfc7706#appendix-B.1) rather than *augment* it,
* mirror zones only work the intended way if recursion is available in the view they are configured in,
* by default, outgoing transfers of mirror zones are disabled.
Furthermore:
* the list of valid mirror zone options should be trimmed down,
* NOTIFY configuration for mirror zones is a bit too hacky and could use some love,
* we currently do not test whether mirror zones can be added and removed dynamically (using `rndc`).
The above concerns need to be addressed before we release BIND 9.14 and since configuration changes are involved, BIND 9.13.4 would be the more appropriate target.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/556Race condition in timer creation2018-09-27T19:59:31ZOndřej SurýRace condition in timer creationOriginally reported here: https://github.com/isc-projects/bind9/pull/2
```
A crash happened with the following call trace:
(gdb) thread 4
[Switching to thread 4 (LWP 1827)]
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lo...Originally reported here: https://github.com/isc-projects/bind9/pull/2
```
A crash happened with the following call trace:
(gdb) thread 4
[Switching to thread 4 (LWP 1827)]
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:371
371 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) bt
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:371
#1 0x00007f792dfe61f4 in __pthread_mutex_unlock_usercnt (mutex=mutex@entry=0x7f792f045028, decr=decr@entry=1) at pthread_mutex_unlock.c:55
#2 0x00007f792dfe62aa in __GI___pthread_mutex_unlock (mutex=mutex@entry=0x7f792f045028) at pthread_mutex_unlock.c:324
#3 0x00007f792e234f3e in isc__timer_create (manager0=0x7f792f045010, type=, expires=, interval=, task=,
action=, arg=0x55a04c063a50, timerp=0x55a04c063a88) at ../../../bind-9.10.3-P3/lib/isc/timer.c:485
#4 0x000055a04ac16610 in add_timeout (when=0x7ffea6082f90, where=0x7ffea6082fa0, what=0x0, ref=0xffffffff, unref=0x7f792f045028) at ../../dhcp-4.3.4/common/dispatch.c:354
#5 0x000055a04ac01cf1 in send_discover (cpp=0x55a04c063db0) at ../../dhcp-4.3.4/client/dhclient.c:2315
#6 0x000055a04abf8ac8 in main (argc=, argv=) at ../../dhcp-4.3.4/client/dhclient.c:795
(gdb) thread 1
[Switching to thread 1 (LWP 1828)]
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1 0x00007f792dc713fa in __GI_abort () at abort.c:89
#2 0x00007f792e20c7af in isc_assertion_failed (file=file@entry=0x7f792e252b60 "../../../bind-9.10.3-P3/lib/isc/timer.c", line=line@entry=1163,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7f792e2531f0 "timerp != ((void *)0) && ((*timerp) != ((void *)0) && (*timerp)->magic == (('A') << 24 | ('t') << 16 | ('m') << 8 | ('r')))")
at ../../../bind-9.10.3-P3/lib/isc/assertions.c:59
#3 0x00007f792e2358c1 in isc_timer_detach (timerp=timerp@entry=0x55a04c063a88) at ../../../bind-9.10.3-P3/lib/isc/timer.c:1163
#4 0x000055a04ac1625b in isclib_timer_callback (taskp=, eventp=0x7f792f04e130) at ../../dhcp-4.3.4/common/dispatch.c:179
#5 0x00007f792e22f64c in dispatch (manager=0x7f792f042010) at ../../../bind-9.10.3-P3/lib/isc/task.c:1130
#6 run (uap=0x7f792f042010) at ../../../bind-9.10.3-P3/lib/isc/task.c:1302
#7 0x00007f792dfe2464 in start_thread (arg=0x7f792d1d3700) at pthread_create.c:456
#8 0x00007f792dd24cef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
(gdb) print *(struct isc_timer **) 0x55a04c063a88
$15 = (struct isc_timer *) 0x0
```
The race condition is the timer elapses before isc__timer_create() returns the pointer to the caller.
Assigning the return pointer before enabling the timer will fix it.BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/525Cleanup platform.h for stuff not exposed to the headers2019-07-01T15:12:44ZOndřej SurýCleanup platform.h for stuff not exposed to the headersThe `platform.h` header contains some defines that are actually not exposed to the outside, but used only internally. Those should be moved into `config.h`.The `platform.h` header contains some defines that are actually not exposed to the outside, but used only internally. Those should be moved into `config.h`.BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/427Zones are not listed in the web interface2018-10-25T08:39:27ZMichał KępieńZones are not listed in the web interfaceThe XSL stylesheet used by the web interface does not currently include any element which would cause a list of zones configured in each view to be displayed, making the *"Zones"* section of the web interface empty unless some zone has b...The XSL stylesheet used by the web interface does not currently include any element which would cause a list of zones configured in each view to be displayed, making the *"Zones"* section of the web interface empty unless some zone has been configured with `zone-statistics full;` and queried. This can be confusing.BIND-9.13.4Michał KępieńMichał Kępień