BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-14T14:23:14Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/211Feature Request to Allow Dynamic Addition/Removal of Forwarders (similar to r...2024-02-14T14:23:14ZCathy AlmondFeature Request to Allow Dynamic Addition/Removal of Forwarders (similar to rndc addzone)[ISC-support #12719]
Originally submitted to BUGs as https://bugs.isc.org/Ticket/Display.html?id=35890
An ISC Support customer expressed surprise at the failure, after trying, and failing (but with side-effects) to add a zone of type "forward" using rndc a...
Originally submitted to BUGs as https://bugs.isc.org/Ticket/Display.html?id=35890
An ISC Support customer expressed surprise at the failure, after trying, and failing (but with side-effects) to add a zone of type "forward" using rndc addzone.
Per discussion with engineering at the time, addzone isn't intended to support addition of zone type forward AND forward zones aren't really traditionally zone-like so it does not work. The ARM is/was incorrect to suggest that it does.
Further information around this is available on bind-users:
https://lists.isc.org/pipermail/bind-users/2016-November/098007.html
This feature is still wished-for.
Also
'"rndc addzone" does not handle zones of all types which can be defined
in named.conf. this is intended, but not documented in the ARM or elsewhere.
It would be good if the behavior were documented and clear error messages
were emitted when a zone of the wrong type was attempted'
From [Support ticket #6898](https://support.isc.org/Ticket/Display.html?id=6898)
Also from [Support ticket #12719](https://support.isc.org/Ticket/Display.html?id=12719)
And others have asked too..Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/100[Support #11240] [RT#44831] Shared zones where content is identical but zone ...2024-02-14T14:19:43ZVicky Riskvicky@isc.org[Support #11240] [RT#44831] Shared zones where content is identical but zone apex is differentThis is request to be able to have a type of 'synthesized' zone where the content isn't stored for each zone that the syntax for the content creates, but instead is held in pre-generated form so that query responses can be generated 'on ...This is request to be able to have a type of 'synthesized' zone where the content isn't stored for each zone that the syntax for the content creates, but instead is held in pre-generated form so that query responses can be generated 'on the fly' when clients request them.
This has often been requested before (e.g. that the shorthand $GENERATE is what is maintained in a zone, not the result of expanding it).
However this particular use case is not quite the same. In this instance, the zone content is identical but the domain is different for multiple zones (the requester suggested up to 1000 nearly identical zone, but actually only currently needs ~50).
On a master server, it's easy to configure this by using the same zone file for each, but taking at advantage of $ORIGIN being appended to each unqualified name in the zone data file when loading the zone.
However, this still results in 50+ copies of almost the same zone data being loaded into the server's memory.
What is being requested is:
* Only one copy of the 'shared' or 'multi' zone held in memory
* Client query responses are synthesised during preparation of the query response, using the unqualified zone data and the domain of the query name.
* The zone(s) content in this form should also be transferrable to slaves in the same way and then maintained/served similarly on the slaves as on the master.
This is the business case we received:
"Here is the main reason for us to create multiple domains with the same sub RRsets. There are 50 states in the US. Each of them is allowed, by law, to have their own domain for this wireless service. Ok, there are not 1000+ domains, but each domain contains lots records, mostly NAPTR records, and they are growing fast."
I've suggested DNAME - which may or may not be satisfactory for this scenario.
----------
comment (Evan):
If they don't need high performance, the DLZ "wildcard" module can deliver this.
------------
comment (Francis):
My personal way to do this would be to use
a $INCLUDE (after a $ORIGIN) so the content
of the zones would be the same but named and
other tools would see a different file per zone
(so for instance use different journal files).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/314Consider sanity check and warning with some "forward first" configurations2024-02-14T14:14:43ZBrian ConryConsider sanity check and warning with some "forward first" configurations### Description
The option 'forward first' is typically used with a specific forwarder or set of forwarders, presumably usually to provide better overall service, while still allowing BIND to fall back to standard iterative recursion wh...### Description
The option 'forward first' is typically used with a specific forwarder or set of forwarders, presumably usually to provide better overall service, while still allowing BIND to fall back to standard iterative recursion when/if the forwarder(s) fail.
If a forwarder is down (non-responsive) for an extended period of time the srtt will grow influencing the tiemout allowed for queries to that forwarder. The upper limit for the timeout is 9 seconds. How long this takes depends on query load, with more load driving the srtt upwards more quickly.
Because forwarders are tried in serial, this leads to a pessimal delay before attempting iterative recursion of 9 * num_forwarders, in seconds.
The default value for 'resolver-query-tiemout' is 10 seconds. In the pessimal case with one forwarder that allows only one (1) second for recursion, but it does allow recursion.
With two forwarders a 'resolver-query-timeout' of at least 19 seconds is required to guarantee that there is at least a little bit of time for iterative recursion.
An operator who chooses to use 'forward first' instead of 'forward only' is desiring the fallback to iterative recursion but may not be aware that their choice of forwarders and 'resolver-query-timeout' (especially if left at default) may not be able to guarantee that there is always time for iterative recursion.
There is currently no means of detecting this latent condition aside from manual inspection of the configuration or an extended period of non-responsiveness from the forwarders that causes resolution to fail.
### Request
After parsing the config, named should have all of the information it needs to determine whether or not the combination of 'forward first', the list of forwarders, and the 'resolver-query-timeout' as such that it's guaranteed that there's always at least some time to fall back to iterative recursion. It could issue a warning if this is not the case.
### Notes
This feature request was created in response to a customer issue but has not (yet) been requested by that customer.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4577bind 9.18.24 on Ubuntu 20.04 doesn't start due to "type=notify" in named.service2024-02-14T09:58:47ZPascal Ernsterbind 9.18.24 on Ubuntu 20.04 doesn't start due to "type=notify" in named.service### Summary
When installing `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1` from ISC's PPA on Ubuntu 20.04, the `named.service` unit hangs during the post-install phase of the package installation, and more generally, always when the `...### Summary
When installing `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1` from ISC's PPA on Ubuntu 20.04, the `named.service` unit hangs during the post-install phase of the package installation, and more generally, always when the `named.service` unit is started. This is caused by the `type=notify` line that is present in the `named.service` unit although the actual support for systemd notify is only present in bind's 9.19.x version branch. After a 90 seconds, the unit runs into a timeout, and the `bind9` package is left in an unconfigured/semi-configured state in apt/aptitude.
Note: Ubuntu's `bind` package was installed and running on my machine, and I encountered this bug today when I tried to migrate to the `bind9` package from ISC's PPA. To be sure that this is not caused by any remains from the previous installation, I have completely purged all bind-related packages, manually deleted the `bind` user and the `/etc/bind`, `/var/cache/bind` and `/var/lib/bind` directories. Even after this cleanup, I still encountered this bug when trying to install `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1`. I've used the following workaround to solve to issue for me until the bug is fixed in the PPA package:
#### Temporary workaround for other users encountering the same bug
Prior to installing the package, run `sudo systemctl edit named.service`, then enter the following two lines and save the file:
```
[Service]
Type=simple
```
You should now be able to install/reconfigure the `bind9` package and to start `named.service` without issues.
### BIND version affected
```
named -V
BIND 9.18.24-1+ubuntu20.04.1+deb.sury.org+1-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:55:07 UTC 2024
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-gw9jNu/bind9-9.18.24=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.40.0
linked to libnghttp2 version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
1. Try to install the `bind9` 9.18.24 package from ISC's Ubuntu 20.04 PPA, for example using `apt install bind9`
2. Notice that the package installation fails/aborts during the post-install phase after about 90 seconds.
3. Check the ouput of `journalctl -ru named | grep --extended-regexp '(timeout|timed out)'`
### What is the current *bug* behavior?
The systemd unit `named.service` times out after 90 seconds.
### What is the expected *correct* behavior?
The systemd unit `named.service` shouldn't time out.
### Relevant configuration files
The bug occurs even with the unchanged config that ships with the package.
### Relevant logs
Excerpt from `journalctl -u named.service`:
```
Feb 13 19:06:53 ns systemd[1]: Starting BIND Domain Name Server...
Feb 13 19:06:53 ns named[6454]: starting BIND 9.18.24-1+ubuntu20.04.1+deb.sury.org+1-Ubuntu (Extended Support Version) <id:>
Feb 13 19:06:53 ns named[6454]: running on Linux x86_64 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:55:07 UTC 2024
Feb 13 19:06:53 ns named[6454]: built with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable>
Feb 13 19:06:53 ns named[6454]: running as: named -f -u bind
Feb 13 19:06:53 ns named[6454]: compiled by GCC 9.4.0
Feb 13 19:06:53 ns named[6454]: compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Feb 13 19:06:53 ns named[6454]: linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Feb 13 19:06:53 ns named[6454]: compiled with libuv version: 1.44.2
Feb 13 19:06:53 ns named[6454]: linked to libuv version: 1.44.2
Feb 13 19:06:53 ns named[6454]: compiled with libxml2 version: 2.9.10
Feb 13 19:06:53 ns named[6454]: linked to libxml2 version: 20910
Feb 13 19:06:53 ns named[6454]: compiled with json-c version: 0.13.1
Feb 13 19:06:53 ns named[6454]: linked to json-c version: 0.13.1
Feb 13 19:06:53 ns named[6454]: compiled with zlib version: 1.2.11
Feb 13 19:06:53 ns named[6454]: linked to zlib version: 1.2.11
Feb 13 19:06:53 ns named[6454]: ----------------------------------------------------
Feb 13 19:06:53 ns named[6454]: BIND 9 is maintained by Internet Systems Consortium,
Feb 13 19:06:53 ns named[6454]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Feb 13 19:06:53 ns named[6454]: corporation. Support and training for BIND 9 are
Feb 13 19:06:53 ns named[6454]: available at https://www.isc.org/support
Feb 13 19:06:53 ns named[6454]: ----------------------------------------------------
Feb 13 19:06:53 ns named[6454]: adjusted limit on open files from 524288 to 1048576
Feb 13 19:06:53 ns named[6454]: found 1 CPU, using 1 worker thread
Feb 13 19:06:53 ns named[6454]: using 1 UDP listener per interface
Feb 13 19:06:53 ns named[6454]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
Feb 13 19:06:53 ns named[6454]: DS algorithms: SHA-1 SHA-256 SHA-384
Feb 13 19:06:53 ns named[6454]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
Feb 13 19:06:53 ns named[6454]: TKEY mode 2 support (Diffie-Hellman): yes
Feb 13 19:06:53 ns named[6454]: TKEY mode 3 support (GSS-API): yes
Feb 13 19:06:53 ns named[6454]: loading configuration from '/etc/bind/named.conf'
[…]
Feb 13 19:08:23 ns systemd[1]: named.service: start operation timed out. Terminating.
Feb 13 19:08:23 ns named[6454]: no longer listening on 127.0.0.1#53
Feb 13 19:08:23 ns named[6454]: no longer listening on […]#53
Feb 13 19:08:23 ns named[6454]: no longer listening on ::1#53
Feb 13 19:08:23 ns named[6454]: no longer listening on […]#53
Feb 13 19:08:23 ns named[6454]: shutting down
Feb 13 19:08:23 ns named[6454]: stopping command channel on 127.0.0.1#953
Feb 13 19:08:23 ns named[6454]: stopping command channel on ::1#953
Feb 13 19:08:23 ns named[6454]: exiting
Feb 13 19:08:23 ns systemd[1]: named.service: Failed with result 'timeout'.
Feb 13 19:08:23 ns systemd[1]: Failed to start BIND Domain Name Server.
Feb 13 19:08:24 ns systemd[1]: named.service: Scheduled restart job, restart counter is at 1.
Feb 13 19:08:24 ns systemd[1]: Stopped BIND Domain Name Server.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4576#error "isc/stdatomic.h does not support your compiler"2024-02-13T21:49:44ZMarcus Kool#error "isc/stdatomic.h does not support your compiler"<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
When compiling a plugin outside the bind source tree a fatal error is thrown by
#error "isc/stdatomic.h does not support your compiler"
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
all 9.18.x versions
### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. copy a plugin to outside the bind tree
2. make sure the plugin includes isc/log.h which triggers the inclusion of isc/stdatomic.h
3. use gcc 5.0 or higher
### What is the current *bug* behavior?
<!-- What actually happens. -->
The copiler issues a fatal error:
```
In file included from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/atomic.h:19,
from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/types.h:16,
from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/log.h:25,
from ufdb-bind-log.h:12,
from ufdb-bind-log.c:19:
/local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/stdatomic.h:29:2: error: #error "isc/stdatomic.h does not support your compiler"
29 | #error "isc/stdatomic.h does not support your compiler"
| ^~~~~
```
### What is the expected *correct* behavior?
<!-- What you should see instead. -->
compilation is successful
### Relevant configuration files
<!-- Paste any relevant configuration files here - 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
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/bind9/-/issues/4491Use RCU instead of rwlock in isc_log unit2024-02-09T10:56:23ZOndřej SurýUse RCU instead of rwlock in isc_log unitWhile adding some extra logging for debugging purposes, I've noticed that the RWLOCK in isc_log unit can be replaces with RCU. I think this would be a nice introductory issue for @aydin.While adding some extra logging for debugging purposes, I've noticed that the RWLOCK in isc_log unit can be replaces with RCU. I think this would be a nice introductory issue for @aydin.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Aydın MercanAydın Mercanhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4565Come up with ideas how to align rwlock and cds_wfcq_head+cds_wfcq_tail2024-02-08T11:17:37ZOndřej SurýCome up with ideas how to align rwlock and cds_wfcq_head+cds_wfcq_tailThe rwlock struct and cds_wfcq_head+cds_wfcq_tail are not aligned just padded now.
Let's record this in an issue, so perhaps someone will have smart idea about the alignment.The rwlock struct and cds_wfcq_head+cds_wfcq_tail are not aligned just padded now.
Let's record this in an issue, so perhaps someone will have smart idea about the alignment.https://gitlab.isc.org/isc-projects/bind9/-/issues/4540RFC 9471 DNS Glue Requirements in Referral Responses2024-02-08T10:27:45ZPeter DaviesRFC 9471 DNS Glue Requirements in Referral Responses[RFC 9471](https://www.rfc-editor.org/rfc/rfc9471.html) - DNS Glue Requirements in Referral Responses
It would be of help to users to implement RFC 9471 and allow BIND to reply TC=1 when
glue records would make a UDP reply larger than...[RFC 9471](https://www.rfc-editor.org/rfc/rfc9471.html) - DNS Glue Requirements in Referral Responses
It would be of help to users to implement RFC 9471 and allow BIND to reply TC=1 when
glue records would make a UDP reply larger than the maxium allowed.
3.2. Glue for Sibling Domain Name Servers
This document clarifes that when a name server generates a referral response, it
include all available glue records in the additional section. If, after adding glue for all in-domain
name servers, the glue for all sibling domain name servers does not ft due to message size
constraints, the name server set TC=1 but is not obligated to do so.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4501ccmsg.c:156: REQUIRE(((ccmsg) != ((void *)0) && ((const isc__magic_t *)(ccmsg...2024-02-08T08:25:35ZMichal Nowakccmsg.c:156: REQUIRE(((ccmsg) != ((void *)0) && ((const isc__magic_t *)(ccmsg))->magic == ((('C') << 24 | ('C') << 16 | ('m') << 8 | ('s'))))) failedThe "resolver" BIND server of the `shutdown` system test (270c51f3289ef90d11136201555e665714e9c6a4) hit this assertion failure:
```
ccmsg.c:156: REQUIRE(((ccmsg) != ((void *)0) && ((const isc__magic_t *)(ccmsg))->magic == ((('C') << 24 ...The "resolver" BIND server of the `shutdown` system test (270c51f3289ef90d11136201555e665714e9c6a4) hit this assertion failure:
```
ccmsg.c:156: REQUIRE(((ccmsg) != ((void *)0) && ((const isc__magic_t *)(ccmsg))->magic == ((('C') << 24 | ('C') << 16 | ('m') << 8 | ('s'))))) failed
```
```
Core was generated by `/home/newman/isc/ws/bind9/bin/named/.libs/named -c /home/newman/isc/ws/bind9/bi'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c
Downloading source file /usr/src/debug/glibc-2.38-14.fc39.x86_64/nptl/pthread_kill.c...
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret)
[Current thread is 1 (Thread 0x7f21e1ac5600 (LWP 2500157))]
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c
#1 0x00007f21e0e598a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c
#2 0x00007f21e0e078ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c
#3 0x00007f21e0def8ff in __GI_abort () at abort.c
#4 0x0000000000417b2a in assertion_failed (file=0x7f21e205d504 "ccmsg.c", line=156, type=isc_assertiontype_require, cond=0x7f21e205d3b8 "((ccmsg) != ((void *)0) && ((const isc__magic_t *)(ccmsg))->magic == ((('C') << 24 | ('C') << 16 | ('m') << 8 | ('s'))))") at main.c
#5 0x00007f21e20e52da in isc_assertion_failed (file=file@entry=0x7f21e205d504 "ccmsg.c", line=line@entry=156, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7f21e205d3b8 "((ccmsg) != ((void *)0) && ((const isc__magic_t *)(ccmsg))->magic == ((('C') << 24 | ('C') << 16 | ('m') << 8 | ('s'))))") at assertions.c
#6 0x00007f21e205ac35 in ccmsg_senddone (handle=<optimized out>, eresult=<optimized out>, arg=<optimized out>) at ccmsg.c
#7 0x00007f21e20d1823 in isc___nm_sendcb () at netmgr/netmgr.c
#8 0x00007f21e20f207e in isc__job_cb (handle=<optimized out>) at job.c
#9 0x00007f21e1b7c4c1 in uv__run_idle (loop=0x7f21e06d3120) at /usr/src/debug/libuv-1.47.0-3.fc39.x86_64/src/unix/loop-watcher.c
#10 uv_run (loop=loop@entry=0x7f21e06d3120, mode=mode@entry=UV_RUN_DEFAULT) at /usr/src/debug/libuv-1.47.0-3.fc39.x86_64/src/unix/core.c
#11 0x00007f21e20f7c1c in loop_thread (arg=0x7f21e06d3100) at loop.c
#12 0x0000000000418928 in main (argc=4, argv=<optimized out>) at main.c
```
[core.2500157.gz](/uploads/4df47365e82ac8b142a829aec12b33e5/core.2500157.gz)
[named.conf](/uploads/c423a777ed372280af2f955ee966409a/named.conf)
[root.db](/uploads/4da97ae339cae47d2c59759d33d725c4/root.db)
[core.2500157-backtrace.txt](/uploads/ee973ce57716d32cf5b0507d869d20f7/core.2500157-backtrace.txt)
[named.run](/uploads/7c0ee4afa30cb3d164ae679d2445b4f0/named.run)
```
/home/newman/isc/ws/bind9/bin/tests/system/shutdown/tests_shutdown.py:207: in test_named_shutdown
assert named_proc.returncode == 0, "named crashed"
E AssertionError: named crashed
E assert -6 == 0
E + where -6 = <Popen: returncode: -6 args: ['/home/newman/isc/ws/bind9/bin/named/named', '...>.returncode
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4550Resolve license aggregation for "reuse lint"2024-02-07T16:19:55ZMichal NowakResolve license aggregation for "reuse lint"`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: Pen...`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: PendingDeprecationWarning: Copyright and licensing
information for 'COPYRIGHT' has been found in both 'COPYRIGHT' and in the DEP5 file located at '.reuse/dep5'.
The information for these two sources has been aggregated. In the future this behaviour will change, and you will
need to explicitly enable aggregation. See <https://github.com/fsfe/reuse-tool/issues/779>. You need do nothing
yet. Run with `--suppress-deprecation` to hide this warning.
...
```Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4559Convert DNS_GETDB_ into struct with 1-bit long booleans2024-02-02T13:23:23ZOndřej SurýConvert DNS_GETDB_ into struct with 1-bit long booleansSee https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8683#note_433377 for details:
> Going step further, I think it can very well be a struct with booleans. It should cost nothing because compiler is not stupid nowadays and it...See https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8683#note_433377 for details:
> Going step further, I think it can very well be a struct with booleans. It should cost nothing because compiler is not stupid nowadays and it will make decoding values in coredumps easier.
>
> (To be clear - I mean something like this: !6902 (merged))https://gitlab.isc.org/isc-projects/bind9/-/issues/4557dnstap logging support for name server operator policy applied to DNS message...2024-02-02T08:32:32ZMatt Braundnstap logging support for name server operator policy applied to DNS messages like RPZ### Description
dnstap format supports since 2021 to log name server policies applied to DNS messages. Bind does not currently log RPZ policy hits via dnstap logging.
### Request
Implement RPZ policy dns message processing via dnstap....### Description
dnstap format supports since 2021 to log name server policies applied to DNS messages. Bind does not currently log RPZ policy hits via dnstap logging.
### Request
Implement RPZ policy dns message processing via dnstap.
### Links / references
https://github.com/dnstap/dnstap.pb/blob/master/dnstap.proto#L70https://gitlab.isc.org/isc-projects/bind9/-/issues/3843Remove options allowing source ports to be specified2024-01-31T08:53:45ZMichał KępieńRemove options allowing source ports to be specifiedWith the options allowing source ports to be specified being deprecated
in 9.18 & 9.19/9.20, all the code associated with those options should
subsequently be completely removed in the 9.21/9.22 cycle, as previously
announced on *bind-us...With the options allowing source ports to be specified being deprecated
in 9.18 & 9.19/9.20, all the code associated with those options should
subsequently be completely removed in the 9.21/9.22 cycle, as previously
announced on *bind-users*:
https://lists.isc.org/pipermail/bind-users/2023-January/107165.html
The following features are going to be marked as ancient and made
non-functional:
* specifying `port` in the following statements:
- `query-source`
- `query-source-v6`
- `transfer-source`
- `transfer-source-v6`
- `notify-source`
- `notify-source-v6`
- `parental-source`
- `parental-source-v6`
* the following statements as a whole:
- `use-v4-udp-ports`
- `use-v6-udp-ports`
- `avoid-v4-udp-ports`
- `avoid-v6-udp-ports`
See #3781 for the corresponding option deprecation issue.Not plannedMichał KępieńMichał Kępień2024-03-01https://gitlab.isc.org/isc-projects/bind9/-/issues/3141Remove artificial limit on number of pipelined TCP queries2024-01-25T10:59:49ZOndřej SurýRemove artificial limit on number of pipelined TCP queriesThere's a artificial limit (`23`) on the number of pipelined TCP queries processed at the same time. We need to remove the limit and test the impact.There's a artificial limit (`23`) on the number of pipelined TCP queries processed at the same time. We need to remove the limit and test the impact.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4547Add support for nginx load balancing with “X-Real-IP”2024-01-24T11:56:31ZMr BenAdd support for nginx load balancing with “X-Real-IP”### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supp...### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supported. Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Request
Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4546Cannot Compile - Invalid Regex Prevents Generation of Parsetab Module2024-01-23T22:35:43ZOleg SCannot Compile - Invalid Regex Prevents Generation of Parsetab Module<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
The Bind project (version 9.16.23) cannot be compiled due to regex
issues in the `bin/python/isc/policy.py` file.
Here is the output generated when running `make`:
### BIND version affected
9.16.23
### Steps to reproduce
1. On a Fedora 39 system (this probably applies beyond Fedora 39, too), with Python 3.12.1 installed,
simply clone the source code of the repo corresponding to
version 9.16.23.
2. Run `./configure` and ensure that it completes successfully
3. Run `make`
### What is the current *bug* behavior?
Make finishes prematurely because it cannot find the `parsetab` module.
### What is the expected *correct* behavior?
Make should be able to run the Python script and generate the `parsetab` module
successfully.
### Relevant configuration files
n/a
### Relevant logs
Here is the output of `make`:
```
/usr/bin/python policy.py parse /dev/null > /dev/null
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:63: Invalid regular expression for rule 't_DATESUFFIX'. missing -, : or ) at position 20
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:68: Invalid regular expression for rule 't_KEYTYPE'. global flags not at the start of the expression at position 14
ERROR: /home/olegs/Programming/cve-gen-ai/FixMorph/experiments/bind-backports/bind/bind-9.16.23/bin/python/isc/policy.py:73: Invalid regular expression for rule 't_ALGNAME'. global flags not at the start of the expression at position 14
PYTHONPATH=. /usr/bin/python -m parsetab
/usr/bin/python: No module named parsetab
make[3]: *** [Makefile:457: parsetab.py] Error 1
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4544"primaries" block documentation issues2024-01-23T15:27:16ZRay Bellis"primaries" block documentation issuesI'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years ...I'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years within the `also-notify` section of primary zones.
There's no direct mention of `primaries` in the grammar of an `also-notify` block. I _suspect_ that it's covered by `<remote-servers>` but the only link between `primaries` and `remote-servers` is this text in the glossary:
> remote-servers: A named list of one or more ip_addresses with optional tls_id, server_key, and/or port. A remote-servers list may include other remote-servers lists. See primaries block.
If in fact a `<remote-servers>` reference _is_ a (named) `primaries` list, then that ought to be spelled out more explicitly, and the documentation updated to reflect that this can be used in *any* `allow-notify` block in any applicable zone type.
I'd also suggest that the top level grammar ought to actually be called `xfer-servers` instead of `masters` and then that term used in place of `remote-servers` in the ARM. In the NOTIFY case the listed servers are secondaries, not primaries, and it makes no sense to call them primaries.
[`remote-servers` also causes confusion with `server <prefix> { }` used to specify per-server EDNS overrides, etc]Long-termMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4235Flamethrower instance #3 stops querying BIND in RPZ mode2024-01-22T16:24:31ZMichal NowakFlamethrower instance #3 stops querying BIND in RPZ modeJob [#3554059](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3554059) failed for 2086be9bcafb6985e4bdd79421fe9fb44ff5c9b5.
The `stress:rpz:fedora:38:amd64` "stress" test often fails on BIND 9.16 (and -S) because the Flamethrower no. ...Job [#3554059](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3554059) failed for 2086be9bcafb6985e4bdd79421fe9fb44ff5c9b5.
The `stress:rpz:fedora:38:amd64` "stress" test often fails on BIND 9.16 (and -S) because the Flamethrower no. 3 stops sending queries over TCP. The other TCP Flamethrower (no. 4) and two UDP Flamethrowers keep working as they should. The issue is limited to BIND 9.16 and the amd64 RPZ job. The Fedora 38 image has Flamethrower 0.11.0 from Fedora repos.
This issue is close to isc-projects/bind9#2395, but not quite. I wonder if the https://gitlab.isc.org/isc-projects/bind9/-/issues/2395#note_187991 fix or bumping to Flamethrower `master` would work.
The first occurrence of this issue seems to be https://gitlab.isc.org/isc-projects/bind9/-/jobs/3435489 from 2 June 2023, between 9.16.41 and 9.16.42 releases. I could not reproduce the problem when manually triggering the job in the CI.
```
2023-07-30:13:27:29 INFO: Server 'ns4' (rpz) received 5,386,242 TCP queries
2023-07-30:13:27:29 INFO: About 10,800,000 TCP queries were expected
2023-07-30:13:27:29 INFO: Minimum number of TCP queries required to pass is 9,720,000
2023-07-30:13:27:29 ERROR: BIND did not process enough TCP queries
```
IPv4 TCP Flamethrower: [generator.log](/uploads/86f30e615716be3e60bbb0472eb82c60/generator.log)
```
45.4845s: send: 1760, avg send: 1406, recv: 1772, avg recv: 1386, min/avg/max resp: 120.112/462.365/2886.94ms, in flight: 587, timeouts: 11
46.4852s: send: 100, avg send: 1378, recv: 633, avg recv: 1369, min/avg/max resp: 52.8356/730.897/1950.99ms, in flight: 50, timeouts: 6
47.4848s: send: 0, avg send: 1378, recv: 7, avg recv: 1340, min/avg/max resp: 1175.22/2074.78/2833.18ms, in flight: 33, timeouts: 6
48.4851s: send: 0, avg send: 1378, recv: 2, avg recv: 1312, min/avg/max resp: 2511.72/2554.51/2597.29ms, in flight: 12, timeouts: 10
49.486s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
...
3599.61s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
3600.61s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
3600.87s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
...
runtime : 3600.87 s
total sent : 65289
total rcvd : 64877
```
About 5 million TCP queries should have been sent.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2518IPv4 Flamethrower quit abruptly on FreeBSD 122024-01-22T16:23:03ZMichal NowakIPv4 Flamethrower quit abruptly on FreeBSD 12IPv4 Flamethrower quit abruptly in [stress:recursive:freebsd12:amd64](https://gitlab.isc.org/isc-private/bind9/-/jobs/1517463) CI job over the `v9_11_sub` branch:
```
2021-02-23:03:31:55 INFO: starting TCP generators
2021-02-23:03:31:55 ...IPv4 Flamethrower quit abruptly in [stress:recursive:freebsd12:amd64](https://gitlab.isc.org/isc-private/bind9/-/jobs/1517463) CI job over the `v9_11_sub` branch:
```
2021-02-23:03:31:55 INFO: starting TCP generators
2021-02-23:03:31:55 INFO: starting generator #3 (tcp) on 10.53.0.3 in /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator3
2021-02-23:03:31:55 INFO: (using query file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile)
2021-02-23:03:31:55 INFO: starting generator #4 (tcp) on [fd92:7065:b8e:ffff::3] in /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator4
2021-02-23:03:31:55 INFO: (using query file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile)
2021-02-23:03:31:55 INFO: checking processes, 1 hours 0 minutes left
2021-02-23:03:32:56 INFO: checking processes, 59 minutes left
2021-02-23:03:32:56 ERROR: process with PID file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator3/generator.pid (pid = 60111) is no longer running
```
`generator3/generator.log` does hot have the usual final summary when it exits correctly:
```
--class: "IN"
--dnssec: true
--help: false
--qps-flow: null
--targets: null
--version: false
-F: "inet"
-M: "GET"
-P: "tcp"
-Q: "10000"
-R: false
-T: "A"
-b: null
-c: "10"
-d: "1"
-f: "/var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile"
-g: "file"
-l: "0"
-n: "0"
-o: null
-p: "5300"
-q: "10"
-r: "test.com"
-t: "3"
-v: "99"
GENOPTS: []
TARGET: "10.53.0.3"
file: push "091195.test.example.."
file: push "099598.test.example.."
file: push "011761.test.example.."
file: push "097867.test.example.."
file: push "025447.test.example.."
file: push "037011.test.example.."
file: push "050838.test.example.."
file: push "022788.test.example.."
file: push "093318.test.example.."
file: push "076772.test.example.."
0 key/value generator arguments
binding to 0.0.0.0
flaming target(s) [10.53.0.3] on port 5300 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol tcp
query generator [file] contains 105000 record(s)
rate limit @ 10000 QPS (333.333 QPS per concurrent sender)
0.00130632s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/nan/0ms, in flight: 0, timeouts: 0
1.01032s: send: 3000, avg send: 3000, recv: 2200, avg recv: 2200, min/avg/max resp: 39.3282/225.582/593.608ms, in flight: 822, timeouts: 0
```
There's no core dump file in the artifact archive.
According to logs `named` instances appear to be working at the time when generator #3 quit.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4542XoT: Primaries should be able to have different allow-transfer acls per trans...2024-01-22T13:10:56ZDave KnightXoT: Primaries should be able to have different allow-transfer acls per transport or ACLs should be extended with port and transport options### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per tr...### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per transport.
I want to require XoT for transfers over the Internet, but allow insecure AXFR to localnets.
It's not possible to have multiple allow-transfer definitions, i.e. this
allow-transfer port 53 transport tcp { acl_for_nonxot_clients; };
allow-transfer port 853 transport tls { acl_for_xot_clients; };
results in
'allow-transfer' redefined near 'allow-transfer'
And my understanding is that we can't refer to ports or transport in an acl.
### Request
Either allow multiple allow-transfer clauses, treating "allow transfer transport tcp" and "allow transfer transport tls" as different things, which can have their own acl specification, or add port and transport to the acl so that this can be controlled there.
### Links / referencesLong-termArtem BoldarievArtem Boldariev