BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-04-12T12:34:45Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2984ECS-IP not visible in the "rpz.log"2023-04-12T12:34:45ZThomas AmgartenECS-IP not visible in the "rpz.log"<!--
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
If an RPZ-enabled BIND is behind a proxy/loadbalancer (for example dnsdist), which injects the ECS-IP, there's actually no way to have/see the client ip address (ECS-IP) in the "rpz.log". Instead, one can correctly see only the ip address from the proxy/dnsdist itself and not the address from the effective source.
### BIND version used
Tested with BIND-9.16.21
### Steps to reproduce
- Place a proxy/dnsdist in front of BIND and inject the ECS-IP.
```
Domain Name System (response)
Transaction ID: 0x5d00
Flags: 0x8183 Standard query response, No such name
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0011 = Reply code: No such name (3)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
example.ch: type A, class IN
Name: example.ch
[Name Length: 8]
[Label Count: 2]
Type: A (Host Address) (1)
Class: IN (0x0001)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (41)
UDP payload size: 1232
Higher bits in extended RCODE: 0x00
EDNS0 version: 0
Z: 0x0000
0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
.000 0000 0000 0000 = Reserved: 0x0000
Data length: 40
Option: COOKIE
Option Code: COOKIE (10)
Option Length: 24
Option Data: faf2434380c56c3d01000000617a1b9c7be4e739ff1b30de
Client Cookie: faf2434380c56c3d
Server Cookie: 01000000617a1b9c7be4e739ff1b30de
Option: CSUBNET - Client subnet
Option Code: CSUBNET - Client subnet (8)
Option Length: 8
Option Data: 00012000c0a8ec02
Family: IPv4 (1)
Source Netmask: 32
Scope Netmask: 0
Client Subnet: 172.16.16.33 <------------------
[Request In: 13]
[Time: 0.000221000 seconds]
```
- Then query a domain via proxy, which triggers RPZ
### What is the current *bug* behavior?
- Verify the "rpz.log", which only shows the proxy-ip
```
27-Oct-2021 15:41:27.940 rpz: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): rpz QNAME NXDOMAIN rewrite example.ch/A/IN via example.ch.blacklist-rpz.test.local
```
### What is the expected *correct* behavior?
A way to see the ECS-IP, the effective client ip address, like this is already implemented, when enabling the builtin "rndc querylog on":
```
27-Oct-2021 15:41:27.940 queries: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): query: example.ch IN A +E(0)K (127.0.0.1) [ECS 172.16.16.33/32/0]
```
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
### Possible fixesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2980QNAME minimisation and check-names response fail; interact2021-10-27T08:31:37ZMark AndrewsQNAME minimisation and check-names response fail; interactI noticed `check-names failure _.clients6.google.com/A/IN` in the logs with check-names response fail set.I noticed `check-names failure _.clients6.google.com/A/IN` in the logs with check-names response fail set.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2956Change default for nsec3param to iterations 0 salt-length 02022-06-14T07:08:43ZMatthijs Mekkingmatthijs@isc.orgChange default for nsec3param to iterations 0 salt-length 0Following the guidance given in https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/
```
In short, for all zones, the recommended NSEC3 parameters are as
shown below:
; SHA-1, no extra iterations, empty salt:
;...Following the guidance given in https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/
```
In short, for all zones, the recommended NSEC3 parameters are as
shown below:
; SHA-1, no extra iterations, empty salt:
;
bcp.example. IN NSEC3PARAM 1 0 0 -
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2952Remove manual branch prediction using __builtin_expect()2021-10-27T11:44:50ZOndřej SurýRemove manual branch prediction using __builtin_expect()A recent [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5476#note_241185) on a MR has sparkled interesting question: Are the software developers better at guessing which branch is more likely to happen and does i...A recent [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5476#note_241185) on a MR has sparkled interesting question: Are the software developers better at guessing which branch is more likely to happen and does it help with performance? The GCC documentation on [`__builtin_expect()`](https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect) says:
> In general, you should prefer to use actual profile feedback for this (`-fprofile-arcs`), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.
Turns out that the documentation was right, we are notoriously bad at predicting how our program actually perform.
In the authoritative scenarios in the perflab, the (lo-hi from the last 15) results are:
| Scenario | `main` | no-expect. |
| --- | --- | --- |
| 1k zones. | 991,710 - 1,001,476 | 985,835 - 992,007 |
| 1M delegations | 918,952 - 943,186 | 953,149 - 969,046 |
| 1M RRs | 946,390 - 973,202 | 966,150 - 993,660 |
| 1M zones | 963,561 - 991,627 | 984,624 - 998,857 |
| root zone | 427,566 - 469,889 | 460,026 - 473,576 |
In the recursive scenarios, the branch with disabled `__builtin_expect()` surpases the `main` branch:
![_allruns-latency-since_30-until_60](/uploads/dcbc799e6a7e2dd2e0f2b495e7deae2a/_allruns-latency-since_30-until_60.png)
![_allruns-latency-since_30-until_60](/uploads/52914286ee3aa75db15694c06c2d7c24/_allruns-latency-since_30-until_60.png)November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2948DNSSEC signing statistics do not account for cross-algorithm key ID collisions2023-11-02T17:02:19ZMichał KępieńDNSSEC signing statistics do not account for cross-algorithm key ID collisionsIn https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-...In https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/951 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/37386 (policy manykeys)
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/23421 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/8256 (policy manykeys)
```
While this situation is not considered a key ID collision (because
different algorithms are involved), it messes up the XML/JSON statistics
because these are not keyed by the `<algorithm, ID>` tuple but rather
just by the key ID. In the `statschannel` system test, the
`zones-{json,xml}.pl` helper scripts only process *unique* key IDs,
leaving duplicate entries out of their output files. In this specific
example, this led to:
```diff
$ diff -u zones.expect.8 zones.out.x8
--- zones.expect.8 2021-10-11 23:30:21.000000000 +0200
+++ zones.out.x8 2021-10-11 23:30:23.000000000 +0200
@@ -1,12 +1,10 @@
dnssec-refresh operations 23421: 1
dnssec-refresh operations 37386: 10
dnssec-refresh operations 51742: 1
-dnssec-refresh operations 51742: 10
dnssec-refresh operations 8256: 1
dnssec-refresh operations 951: 10
dnssec-sign operations 23421: 1
dnssec-sign operations 37386: 10
dnssec-sign operations 51742: 1
-dnssec-sign operations 51742: 10
dnssec-sign operations 8256: 1
dnssec-sign operations 951: 10
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2941Implement alternative to all-at-once rehashing for real-time hash tables2022-03-15T20:59:39ZOndřej SurýImplement alternative to all-at-once rehashing for real-time hash tablesThe all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the ...The all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the linear rehashing seems too complex for our purpose) for hot-path hash tables (RBT mostly).November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2929Replace more "master" and "slave" keywords2021-10-27T11:25:17ZPeter DaviesReplace more "master" and "slave" keywordsThe following error message from the ```rndc freeze``` command:
```rndc: 'freeze' failed: not master```
It may be preferable to use the term ```primary```.
There are other instances in code and in the rndc man page.The following error message from the ```rndc freeze``` command:
```rndc: 'freeze' failed: not master```
It may be preferable to use the term ```primary```.
There are other instances in code and in the rndc man page.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2927lame servers with IPv6 unreachable make dispatch@netmgr stuck on shutdown2022-01-26T11:33:41ZOndřej Surýlame servers with IPv6 unreachable make dispatch@netmgr stuck on shutdownSo, I narrowed it down to a single query:
```
dig -p 5300 IN A mail.lab.comcor.ru. @10.10.10.20
```
which goes like this:
```
04-Oct-2021 09:25:59.507 resolver priming query complete
04-Oct-2021 09:26:16.119 network unreachable resolvi...So, I narrowed it down to a single query:
```
dig -p 5300 IN A mail.lab.comcor.ru. @10.10.10.20
```
which goes like this:
```
04-Oct-2021 09:25:59.507 resolver priming query complete
04-Oct-2021 09:26:16.119 network unreachable resolving '_.ru/A/IN': 2001:500:2f::f#53
04-Oct-2021 09:26:16.119 network unreachable resolving '_.ru/A/IN': 2001:500:12::d0d#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:15:0:193:232:142:17#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:18:0:194:190:124:17#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:17:0:193:232:128:6#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:16:0:194:85:252:62#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:14:0:193:232:156:17#53
04-Oct-2021 09:26:16.143 network unreachable resolving '_.lab.comcor.ru/A/IN': 2a02:290:0:2::5#53
04-Oct-2021 09:26:16.143 network unreachable resolving '_.lab.comcor.ru/A/IN': 2a02:290:0:1::4#53
04-Oct-2021 09:26:16.203 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:17:0:193:232:128:6#53
04-Oct-2021 09:26:16.207 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:18:0:194:190:124:17#53
04-Oct-2021 09:26:16.207 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:16:0:194:85:252:62#53
04-Oct-2021 09:26:16.251 lame server resolving 'mail.lab.comcor.ru' (in 'lab.COMCOR.ru'?): 212.45.0.3#53
04-Oct-2021 09:26:16.335 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2a02:290:0:2::5#53
04-Oct-2021 09:26:16.443 lame server resolving 'ns.lab.comcor.ru' (in 'lab.COMCOR.ru'?): 212.45.0.3#53
```
You also need to have broken IPv6 :-), it doesn't happen when I run `named -4`.
#### Edited ####
This is caused by the new dispatch code:
1. Start `named -p 5300 -g -c /dev/null`
2. Start `dnsperf -s 127.0.0.1 -p 5300 -D -d queryfile-example-10million-201202`
3. Press Ctrl-C
4. `named` doesn't stop:
```
$ eu-stack -p $(pidof named)
PID 275694 - process
TID 275694:
#0 0x00007f4b7bac9c61 clock_nanosleep@@GLIBC_2.17
#1 0x00007f4b7bacf443 __nanosleep
#2 0x00007f4b7bafa125 usleep
#3 0x00007f4b7c476f19 isc__taskmgr_destroy
#4 0x00007f4b7c45b994 isc_managers_destroy
#5 0x0000564d877b86cf destroy_managers
#6 0x0000564d877b86da cleanup
#7 0x0000564d877ba041 main
#8 0x00007f4b7ba2ad0a __libc_start_main
#9 0x0000564d877ae9ca _start
TID 275708:
#0 0x00007f4b7bb02116 epoll_wait
#1 0x00007f4b7be18b3f uv__io_poll
#2 0x00007f4b7be07714 uv_run
#3 0x00007f4b7c43c33e nm_thread
#4 0x00007f4b7c47ce50 isc__trampoline_run
#5 0x00007f4b7bbd1ea7 start_thread
#6 0x00007f4b7bb01def __clone
TID 275709:
#0 0x00007f4b7bbd8ad8 pthread_cond_timedwait@@GLIBC_2.3.2
#1 0x00007f4b7c44f081 isc_condition_waituntil
#2 0x00007f4b7c479dab run
#3 0x00007f4b7c47ce50 isc__trampoline_run
#4 0x00007f4b7bbd1ea7 start_thread
#5 0x00007f4b7bb01def __clone
TID 275710:
#0 0x00007f4b7bb02116 epoll_wait
#1 0x00007f4b7c46f6f2 netthread
#2 0x00007f4b7c47ce50 isc__trampoline_run
#3 0x00007f4b7bbd1ea7 start_thread
#4 0x00007f4b7bb01def __clone
```
+1 we are obviously missing a system test for this kind of scenario.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2916duplicate catalog-zones is fatal2021-10-27T13:24:11ZMark Andrewsduplicate catalog-zones is fatal```
options {
port 5300;
catalog-zones { zone example.com; zone example.com; };
};
zone example.com {
type primary;
file "example.com";
};
``````
options {
port 5300;
catalog-zones { zone example.com; zone example.com; };
};
zone example.com {
type primary;
file "example.com";
};
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2905autoconf check for struct stat pulls in fcntl.h not stat.h2021-10-27T11:32:33ZStuart Hendersonautoconf check for struct stat pulls in fcntl.h not stat.hhttps://gitlab.isc.org/isc-projects/bind9/-/blob/main/configure.ac#L1079 includes sys/fcntl.h when checking struct stat members to determine if nanoseconds are available. At least on OpenBSD and raspbian this is in stat.h which is not pu...https://gitlab.isc.org/isc-projects/bind9/-/blob/main/configure.ac#L1079 includes sys/fcntl.h when checking struct stat members to determine if nanoseconds are available. At least on OpenBSD and raspbian this is in stat.h which is not pulled in by fcntl.h so the test always fails.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2843EC_KEY has been deprecated on OpenSSL 3.0.02022-01-19T11:20:50ZMark AndrewsEC_KEY has been deprecated on OpenSSL 3.0.0Need to workout what the replacement code needs to be as builds fail on strict systems.Need to workout what the replacement code needs to be as builds fail on strict systems.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2828Compile fail on musl/arm32 since 9.16.82022-03-01T09:45:06ZEd WildgooseCompile fail on musl/arm32 since 9.16.8Hi, I'm building a gentoo based system on arm v7 32bit, using musl as my libc. I am hitting a compile error, that I have determined happens on 9.16.9 onwards, yet I can build fine with 9.16.8 and earlier
The specific error snippet I se...Hi, I'm building a gentoo based system on arm v7 32bit, using musl as my libc. I am hitting a compile error, that I have determined happens on 9.16.9 onwards, yet I can build fine with 9.16.8 and earlier
The specific error snippet I see is:
armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 -Wl,--as-needed -L/usr/lib -Wl,--export-dynamic -o sample-async \
sample-async.o ../dns/libdns.a ../isccfg/libisccfg.a ../isc/libisc.a -lcrypto -luv -ldl
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 -Wl,--as-needed -L/usr/lib -Wl,--export-dynamic -o resolve \
resolve.o ../irs/libirs.a ../dns/libdns.a ../isccfg/libisccfg.a ../isc/libisc.a -lcrypto -luv -ldl
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:494: sample-gai] Error 1
make[1]: *** Waiting for unfinished jobs....
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:502: sample-request] Error 1
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:490: sample-async] Error 1
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:486: resolve] Error 1
I think this is related to this change here:
--- /var/tmp/portage/net-dns/bind-tools-9.16.9/work/bind-9.16.9/lib/isc/backtrace.c 2020-11-16 14:44:37.000000000 +0000
+++ /var/tmp/portage/net-dns/bind-tools-9.16.8/work/bind-9.16.8/lib/isc/backtrace.c 2020-10-13 08:41:40.000000000 +0000
@@ -40,7 +40,7 @@
*/
#ifdef HAVE_LIBCTRACE
#define BACKTRACE_LIBC
-#elif defined(HAVE_UNWIND_BACKTRACE)
+#elif defined(__GNUC__) && (defined(__x86_64__) || defined(__ia64__))
#define BACKTRACE_GCC
#elif defined(WIN32)
#define BACKTRACE_WIN32
If I revert this change then my compile succeeds (although it may not be correct?)
I'm not really skilled enough to understand the details of gcc backtrace implementation on arm. I'm using gcc 10.3.0 to compile this, and I can see that I have a header:
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/include/unwind.h
So I'm assuming that I have gcc compiled with some kind of unwind implementation?
I use a very similar profile to compile near identical code base for both amd64 and x86 architectures and both of those have no issues compiling latest bind-tools (and previous). Also, near as I can see I have my gcc configured identically across all three systems...
Now I *can* compile bind-tools ok if I install the libunwind library, however, that then breaks (re)compiling my gcc compiler, so I'm really thinking that's the wrong route to go down?
Temporarily I'm reverting the above change locally, but I wonder if you could either guide me to a correct solution, or if someone more knowledgeable can revert or write some correct #if test for this situation please?
I'm sure I have failed to provide enough details at this stage. Please be gentle...Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2792memory trace (-m trace) overhaul2022-12-12T08:58:02ZBrian Conrymemory trace (-m trace) overhaulIn BIND there are as many as three different layers of memory management, including libc. Proper memory account and tracing will need to be able to track any allocation through all of those layers, including how the size and returned ad...In BIND there are as many as three different layers of memory management, including libc. Proper memory account and tracing will need to be able to track any allocation through all of those layers, including how the size and returned address may change through those transitions.
Original issue statement
> When `isc__mem_allocate` calls `ADD_TRACE` it uses a combination of pointer address `si` and size `si[-1].size` that is inconsistent.
>
> Specifically, the size reported (`si[-1].size`) has been modified from what was requested by `ALIGNMENT_SIZE` at least once (and `ISC_UNLIKELY` a second time) while the pointer reported (`si`) is offset from the actual base of the allocation by the same amount.
>
> This will lead to confusing `-m trace` entries such as:
> ```
> add 0x7f8f6240f018 size 104 file task.c line 1400 mctx 0x55a572544320
> ...
> add 0x7f8f6240f078 size 104 file hash.c line 159 mctx 0x55a572544320
> ```
>
> A sharp-eyed reader may notice that there are only 96 bytes between the two reported addresses even though the size reported is 104 bytes.
>
> This is only a "cosmetic error" in the `-m trace` output, so it's automatically low priority.
>
> I discovered this in 9.11 and have verified it still exists in both 9.16 and 9.17.
Edit: the merge of jemalloc support in 9.17.17 has changed things, requiring an update to all of these diagrams - consider them to be obsolete unless the comment containing them explicitly mentions being updated for 9.17.17https://gitlab.isc.org/isc-projects/bind9/-/issues/2742rndc serve-stale status output can be slightly confusing2021-10-27T13:15:11ZCathy Almondrndc serve-stale status output can be slightly confusingThe confusion is over what components of the serve-stale feature are active (or not) based on the output.
I don't think we document anywhere in the ARM how to interpret what is output.
Here are examples of what is currently output by r...The confusion is over what components of the serve-stale feature are active (or not) based on the output.
I don't think we document anywhere in the ARM how to interpret what is output.
Here are examples of what is currently output by rndc status from BIND 9.11.32-S1, and what should be understood from each:
1. Default (nothing explicitly configured)
```
$ rndc serve-stale status
my-default: off (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: off (stale-answer-ttl=1 max-stale-ttl=43200)
```
Both views have `stale-cache-enable yes;` (by default) - otherwise we would not see values for stale-answer-ttl and max-stale-ttl. Those values are the default and have not been explicitly configured. `stale-answer-enable no;` is also the default.
The `off` means that stale-answer-enable is `no` and stale answers have not been enabled using rndc.
Commentary: This is confusing when you see it for the first time, because 'off' is ambiguous and could easily be misinterpreted as meaning that both stale cache and serving of stale answers are disabled (they're not)
2. Explicitly setting `stale-cache-enable no;`
```
$ rndc serve-stale status
my-default: off (not-cached)
_bind: off (not-cached)
```
This is easier to understand because we don't display any other options actually say 'not-cached' (although this wasn't always the case in earlier versions of BIND, which used to say just `off`.
Nothing is available for serving stale. You cannot enable stale answers using rndc, and even if you added 'stale-answer-enable yes;` to named.conf, this is ignored.
3. `stale-cache-enable yes;` (default or explicitly configured) plus `stale-answer-enable yes;`
```
$ rndc serve-stale status
my-default: on (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: on (stale-answer-ttl=1 max-stale-ttl=43200)
```
This is the full monty - we have stale cache enabled AND we have have stale answers enabled (notice `on` instead of `off` as compared with example 1.
====
So what is the problem? The issue is that someone using a default configuration will issue `rndc serve-stale status`, see the output per example 1 and be confused as to whether they have serve-stale or not. Without the special knowledge that serve-stale has two components (retention of stale RRsets and serving of retained stale RRsets in specific circumstances), the existing status output can be confusing.
My suggestion for making it clearer would be something like this:
1. Default (nothing explicitly configured = `stale-cache-enable yes;` and `stale-answer-enable no;`
```
$ rndc serve-stale status
my-default: stale cache enabled; stale answers disabled (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: stale cache enabled; stale answers disabled (stale-answer-ttl=1 max-stale-ttl=43200)
```
2. Explicitly setting `stale-cache-enable no;` (the setting of `stale-answer-enable` is irrelevant, it is overridden)
```
$ rndc serve-stale status
my-default: stale cache disabled; (stale answers unavailable)
_bind: stale cache disabled; (stale answers unavailable)
```
3. `stale-cache-enable yes;` (default or explicitly configured) plus `stale-answer-enable yes;`
```
$ rndc serve-stale status
my-default: stale cache enabled; stale answers enabled (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: stale cache enabled; stale answers enabled (stale-answer-ttl=1 max-stale-ttl=43200)0)
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2530Bind 9.16.11 segfault on DLZ with mysql2022-03-01T09:45:37ZjpsollieBind 9.16.11 segfault on DLZ with mysql### Summary
When running bind with DLZ against a mysql database, the system aborts with segfault
This database is set up to answer all spam domains
### BIND version used
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 ...### Summary
When running bind with DLZ against a mysql database, the system aborts with segfault
This database is set up to answer all spam domains
### BIND version used
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 5.10.17+ #8 SMP Mon Feb 22 18:54:47 CET 2021
built by make with '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--docdir=/usr/share/doc/bind-9.16.11' '--htmldir=/usr/share/doc/bind-9.16.11/html' '--with-sysroot=/' '--libdir=/usr/lib64' 'AR=/usr/bin/x86_64-pc-linux-gnu-ar' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--without-readline' '--with-openssl=/usr' '--without-cmocka' '--enable-linux-caps' '--disable-dnsrps' '--disable-dnstap' '--disable-fixed-rrset' '--without-dlz-bdb' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--without-gssapi' '--without-json-c' '--without-dlz-ldap' '--with-dlz-mysql' '--without-dlz-odbc' '--without-dlz-postgres' '--without-lmdb' '--without-libxml2' '--with-zlib' '--without-python' '--with-maxminddb' '--enable-geoip' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=znver1 -O3 -ggdb3 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.0
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
### Steps to reproduce
1. install BIND 9.16.11 with DLZ support
2. install mariadb 10.5.8
3. install DLZ converted spam domain list (view attachment)
4. install DLZ connector
### What is the current *bug* behavior?
Bind crashes with segfaults, when using file instead of dlz, everything is OK.
### What is the expected *correct* behavior?
Bind loads zones + runs correctly
### Relevant configuration files
DLZ connector:
```
dlz "null_dlz" {
database "mysql
{host=127.0.0.1 port=3306 dbname=dlz_null ssl=false user=named pass=named}
{select '$zone$' AS zone from dns_records where zone = 'null' OR zone = '$zone$' LIMIT 1}
{select ttl, type, mx_priority, case when lower(type)='txt' then concat('\"', data, '\"')
else data end from dns_records where (zone = 'null' OR zone = '$zone$') and (host = '*' OR host = '$record$') AND NOT (type = 'SOA' or type='NS')}
{select ttl, type, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum
from dns_records where (zone = 'null' OR zone = '$zone$') AND (type = 'SOA' or type='NS')}
{select ttl, type, host, mx_priority, data, resp_person, serial, refresh, retry, expire,
minimum from dns_records where (zone = 'null' OR zone = '$zone$') and NOT (type = 'SOA' or type = 'NS')}
{select '$zone$' AS zone from xfr_table where (zone = 'null' OR zone = '$zone$') and client = '$client$'}
{update data_count set count = count + 1 where (zone ='null' OR zone = '$zone$') AND client = '$client$'}";
search no;
};
include "blacklist.inc.dlz"
```
SQL database dump:
```
Enter password:
-- MariaDB dump 10.18 Distrib 10.5.8-MariaDB, for Linux (x86_64)
--
-- Host: localhost Database: dlz_null
-- ------------------------------------------------------
-- Server version 10.5.8-MariaDB-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `data_count`
--
DROP TABLE IF EXISTS `data_count`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `data_count` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`count` bigint(20) unsigned NOT NULL DEFAULT 0,
`zone` varchar(255) DEFAULT 'null',
`client` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `zone` (`zone`)
) ENGINE=Aria AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `data_count`
--
LOCK TABLES `data_count` WRITE;
/*!40000 ALTER TABLE `data_count` DISABLE KEYS */;
INSERT INTO `data_count` VALUES (1,0,'null','');
/*!40000 ALTER TABLE `data_count` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `dns_records`
--
DROP TABLE IF EXISTS `dns_records`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `dns_records` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`zone` varchar(255) NOT NULL,
`host` varchar(255) NOT NULL DEFAULT '@',
`type` varchar(255) NOT NULL,
`data` text DEFAULT NULL,
`ttl` int(11) NOT NULL DEFAULT 86400,
`mx_priority` int(11) DEFAULT NULL,
`refresh` int(11) DEFAULT NULL,
`retry` int(11) DEFAULT NULL,
`expire` int(11) DEFAULT NULL,
`minimum` int(11) DEFAULT NULL,
`serial` bigint(20) DEFAULT NULL,
`resp_person` varchar(255) DEFAULT NULL,
`primary_ns` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `type` (`type`),
KEY `host` (`host`),
KEY `zone` (`zone`),
KEY `zone_host_index` (`zone`(30),`host`(30)),
KEY `type_index` (`type`(8))
) ENGINE=Aria AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `dns_records`
--
LOCK TABLES `dns_records` WRITE;
/*!40000 ALTER TABLE `dns_records` DISABLE KEYS */;
INSERT INTO `dns_records` VALUES (1,'null','@','SOA',NULL,180,NULL,10800,7200,604800,86400,2011091101,'localhost.','admin.localhost.'),(2,'null','@','NS','localhost',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(3,'null','@','A','0.0.0.0',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(4,'null','*','A','0.0.0.0',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL),(5,'null','*','AAAA','::',180,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
/*!40000 ALTER TABLE `dns_records` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `xfr_table`
--
DROP TABLE IF EXISTS `xfr_table`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `xfr_table` (
`zone` varchar(255) NOT NULL,
`client` varchar(255) NOT NULL,
KEY `zone` (`zone`),
KEY `client` (`client`),
KEY `zone_client_index` (`zone`(30),`client`(30))
) ENGINE=Aria DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `xfr_table`
--
LOCK TABLES `xfr_table` WRITE;
/*!40000 ALTER TABLE `xfr_table` DISABLE KEYS */;
INSERT INTO `xfr_table` VALUES ('null','*');
/*!40000 ALTER TABLE `xfr_table` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2021-02-25 10:21:58
```
GDB backtrace:
```
(gdb) setargs -d 1 -u named -n 1 -g -c /etc/named/named2.conf
(gdb) run
... -- truncated
Query String: select 'paczkonnat.app' AS zone from dns_records where zone = 'null' OR zone = 'paczkonnat.app' LIMIT 1
Thread 3 "isc-worker0000" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6211640 (LWP 20149)]
0x00007ffff7116746 in strlen () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7116746 in strlen () from /lib64/libc.so.6
#1 0x00005555555ab3bd in sdlzh_build_querystring (mctx=mctx@entry=0x5555555eb090, querylist=0x7fffd6acd210) at ../../contrib/dlz/drivers/sdlz_helper.c:287
#2 0x00005555555ac8ac in mysql_get_resultset (zone=<optimized out>, record=<optimized out>, client=<optimized out>, query=5, dbdata=0x7fffd6adfd68, rs=0x0) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:276
#3 0x00005555555ad5f7 in mysql_findzone (driverarg=<optimized out>, methods=<optimized out>, clientinfo=<optimized out>, name=0x7ffff6210740 "paczkonnat.app", dbdata=0x7fffd6adfd68) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:508
#4 mysql_findzone (driverarg=<optimized out>, dbdata=0x7fffd6adfd68, name=0x7ffff6210740 "paczkonnat.app", methods=<optimized out>, clientinfo=<optimized out>) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:478
#5 0x00007ffff7e70cc6 in dns_sdlzfindzone (driverarg=0x7ffff6b552e0, dbdata=0x7fffd6adfd68, mctx=0x5555555eb090, rdclass=<optimized out>, name=0x7fffde822720, methods=0x0, clientinfo=0x0, dbp=0x7ffff6210bd8) at sdlz.c:1681
#6 0x00007ffff7ed2c84 in zone_load (zone=0x7fffde8225e0, flags=<optimized out>, locked=locked@entry=true) at zone.c:2159
#7 0x00007ffff7ed3141 in zone_asyncload (task=0x7ffff091f220, event=<optimized out>) at zone.c:2303
#8 0x00007ffff7c91150 in dispatch (threadid=<optimized out>, manager=0x7ffff6b60010) at task.c:1152
#9 run (queuep=<optimized out>) at task.c:1344
#10 0x00007ffff7574fde in start_thread () from /lib64/libpthread.so.0
#11 0x00007ffff717973f in clone () from /lib64/libc.so.6
(gdb)
```
[blacklist.inc.dlz](/uploads/ce48ba8e26a6e4e5657c4a5d22e12d98/blacklist.inc.dlz)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1732"rndc loadkeys" and "rndc sign" provide no feedback on missing or unreadable ...2023-11-02T16:51:56ZMichael Graff"rndc loadkeys" and "rndc sign" provide no feedback on missing or unreadable keysWhen using inline-signing, issuing a "rndc loadkeys" where there are no keys, the key directory specified in the config is unreadable, or the key files themselves are unreadable due to permission issues, no error is logged.
This made de...When using inline-signing, issuing a "rndc loadkeys" where there are no keys, the key directory specified in the config is unreadable, or the key files themselves are unreadable due to permission issues, no error is logged.
This made debugging fairly difficult.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1639rndc zonestatus should report active signing keys2023-11-02T16:51:54ZEvan Huntrndc zonestatus should report active signing keysThere's no straightforward way to see which keys are currently actively signing a zone - looking at the DNSKEY RRset doesn't necessarily tell you that, because some of them may be standby keys, or a key may no longer be active but still ...There's no straightforward way to see which keys are currently actively signing a zone - looking at the DNSKEY RRset doesn't necessarily tell you that, because some of them may be standby keys, or a key may no longer be active but still have signatures in the zone, or a key may be pre-signing before it's published. It would be nice if `named` could report this, either with `rndc zonestatus` or some other `rndc` command.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1634Simplify adding CDS and CDNSKEY deletion records to a inline zone.2023-11-02T16:51:54ZMark AndrewsSimplify adding CDS and CDNSKEY deletion records to a inline zone.From bind-users.
```
There are no DNSKEY records in that zone. CDS and CDNSKEY must be signed for the
parent to accept them. There must be DNSKEY records present for them to be signed.
Add a DNSKEY record to that test zone and it will...From bind-users.
```
There are no DNSKEY records in that zone. CDS and CDNSKEY must be signed for the
parent to accept them. There must be DNSKEY records present for them to be signed.
Add a DNSKEY record to that test zone and it will load.
For inline zone just copy the final DNSKEY RRset from the signed version of the
zone to the raw zone when adding the deletion CDS and CDNSKEY records. Wait for
the parent zone to remove the DS records, then remove the CDS, CDNSKEY, and DNSKEY
records from the raw zone.
```
Possibly extend `rndc signing` to add and remove CDS and CDNSKEY deletion records
from the zone signed zone.
If the DNSKEY RRset becomes empty as a result of key timings remove CDS and CDNSKEY
records from the zone.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1631kasp system test failed (bad number of keys)2022-04-28T19:13:15ZMichał Kępieńkasp system test failed (bad number of keys)https://gitlab.isc.org/isc-projects/bind9/-/jobs/700050
```
I:kasp:check number of keys with algorithm 5 for zone legacy-keys.kasp in dir ns3 (56)
I:kasp:error: bad number (2) of key files for zone legacy-keys.kasp (expected 3)
I:kasp:f...https://gitlab.isc.org/isc-projects/bind9/-/jobs/700050
```
I:kasp:check number of keys with algorithm 5 for zone legacy-keys.kasp in dir ns3 (56)
I:kasp:error: bad number (2) of key files for zone legacy-keys.kasp (expected 3)
I:kasp:failed
I:kasp:check key 24906
I:kasp:check key 38941
I:kasp:error: No KEY2 found for zone legacy-keys.kasp
I:kasp:failed
I:kasp:check DNSKEY rrset is signed correctly for zone legacy-keys.kasp (57)
I:kasp:check SOA rrset is signed correctly for zone legacy-keys.kasp (58)
I:kasp:error: SOA RRset not signed with key no
I:kasp:failed
I:kasp:check CDS and CDNSKEY rrset are signed correctly for zone legacy-keys.kasp (59)
I:kasp:check A a.legacy-keys.kasp rrset is signed correctly for zone legacy-keys.kasp (60)
I:kasp:error: A RRset not signed with key no
I:kasp:failed
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1610dig: Incorrect encoding to punycode2022-04-26T13:22:14ZGhost Userdig: Incorrect encoding to punycode### Summary
Incorrect/invalid output when trying to encode the domain: ☺.unicode.
It appears the punycode encoder generates a domain label that includes a space. Several punycode generators do this, including dnspython and Python's ...### Summary
Incorrect/invalid output when trying to encode the domain: ☺.unicode.
It appears the punycode encoder generates a domain label that includes a space. Several punycode generators do this, including dnspython and Python's IDNA encoding built-in.
This came up while performing testing ahead of migrating towards a new system of handling DNS records which uses Python, however, we've subsequently identified that it affects dig as well.
### BIND version used
9.11.5-P4-5.1-Debian (From Debian Buster)
### Steps to reproduce
```
$ dig ☺.unicode
```
### What is the current *bug* behavior?
```
dig: 'xn--\032o-oia59s.unicode.' is not a legal IDNA2008 name (string contains a disallowed character), use +noidnout
```
### What is the expected *correct* behavior?
I'd expect dig to look up the A record for the correctly encoded domain.
I'm not sure what the correctly encoded domain is, although my suspicion is that it should be xn--xba3f15e.unicode.
### Relevant configuration files
Not sure that any config files are actually relevant - if there are, please let me know.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)