BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-01-23T15:27:16Zhttps://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/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 Boldarievhttps://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/4532An option to not have bind9/dnssec-settime (possibly other tools) reset permi...2024-01-16T20:30:36ZDan MahoneyAn option to not have bind9/dnssec-settime (possibly other tools) reset permissions on a .private file.### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using gi...### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using git, with a group-shared repository.
Typical permissions on .private files are bind:bind with mode 660, but because a normal user (in the bind group) diffs/commits/pushes the repository, these keys can also be user:bind mode 660.
(Noting as well that our tooling is not more comfortable running git tasks as root, complaining of other permissions issues. Also, the less we can do as root, the better.)
With bind's usual permissions model, one cannot do a git diff/git log if the file is owned by bind. If the file is owned by user:bind, bind loses access to it on the permissions change.
Changing the umask under which the process runs doesn't seem to fix this, we tried.
Running a periodic cron job to fix this is a possible workaround, but feels like it shouldn't be necessary.
### Request
For command line tools, an option to not do this.
For `named, an `options` statement that lets us turn this off.
Both retaining the current behavior by default.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4525bind acl doesn't respect interface identifier (in ipv6 link local address)2024-01-09T06:15:55Zelmaimbobind acl doesn't respect interface identifier (in ipv6 link local address)### Summary
Although BIND allows you to configure an IPv6 address with an interface identifier (e.g. fe80::1%ne0) in an "acl" statement, when it tests if an address satisfies the acl, it seems to only look at the address and ignores the...### Summary
Although BIND allows you to configure an IPv6 address with an interface identifier (e.g. fe80::1%ne0) in an "acl" statement, when it tests if an address satisfies the acl, it seems to only look at the address and ignores the interface identifier when performing the check.
### BIND version affected
```
# named -V
BIND 9.18.18-0ubuntu2-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023
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-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--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' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-UHPUkp/bind9-9.18.18=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/bind9-UHPUkp/bind9-9.18.18=/usr/src/bind9-1:9.18.18-0ubuntu2 -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 13.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.55.1
linked to libnghttp2 version: 1.55.1
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.17
linked to json-c version: 0.17
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
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
These steps require access to two machines, each having an IPv6 link-local address on a shared network segment. One of the machines needs to have an operational installation of BIND. The other machine needs the dig utility, or a similar tool that allows a DNS query to be sent to a specific IPv6 address.
1. On the BIND machine (server A), run `ip -6 address` and verify that the server has a loopback interface (lo) with IPv6 address `::1`, and at least one other network interface that has a link-local address `fe80::xxxx:xxxx:xxxx:xxxx/64`. Make a note of the name of the interface name and the link-local address.
2. On the other machine (server B), run `ip -6 address` and make a note of the interface name that is on the same network as the BIND machine.
3. Verify connectivity between the servers by pinging from server B to the link-local address of server A -- including server B's interface identifier. E.g.: `ping fe80::1e69:7aff:fe6c:2ab0%eno1`
4. On server A, edit the BIND configuration and add `acl testing { fe80::/64; };`, and also include "testing;" at the start of both `allow-query` and `allow-recursion` options. Run `rndc reload` to apply the configuration changes.
5. On server B, verify that you can use dig (or similar) to successfully query a DNS name using the the same link-local address used in the ping test above. E.g.: `dig google.com @fe80::1e69:7aff:fe6c:2ab0%eno1`
6. Now change the "acl testing" block to `acl testing { !fe80::%lo/64; fe80::/64; };`. The idea here is that we are disallowing queries coming from link-local addresses on the loopback interface. In theory this should make no difference to our test, since our query isn't coming in the loopback interface. Run `rndc reload` to apply the configuration changes.
7. Repeat the "dig" test, and you will find that the BIND server will now refuse the request. This shows that BIND considers that the request satisfies "!fe80::%lo/64;" when in fact it shouldn't because it doesn't originate from the loopback interface.
### What is the current *bug* behavior?
BIND seems to ignore the interface identifier for IPv6 addresses when applying acls.
### What is the expected *correct* behavior?
BIND should observe the interface identifier as described in the [documentation](https://bind9.readthedocs.io/en/latest/reference.html#term-ipv6_address). Please note that interface identifiers may also contain VLAN IDs - e.g. "eno1.20".
### Relevant configuration files
FYI I am trying to use ACLs similar to the following, to differentiate between requests originating on link-local addresses from different interfaces, so that the queries are handled by different views:
```
acl trusted-networks {
127.0.0.0/8;
::1;
fe80::%eno1.20/64;
fe80::%eno1.160/64;
fe80::%tun1/64;
};
acl dmz-networks {
fe80::%eno1.192/64;
};
```
### Relevant logs
All my logs show is that the wrong view is being used, due to this bug.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4505Implement kTLS support in BIND2024-02-14T17:13:53ZArtem BoldarievImplement kTLS support in BIND
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user sp...
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user space, including offloading TLS encryption to the NICs that support that (e.g. [NVIDIA Mellanox ConnectX-6 Dx](https://www.nvidia.com/en-us/networking/ethernet/connectx-6-dx/)), almost completely freeing the CPU from this task, because even in the case of hardware acceleration of encryption within the CPU, it still requires some cycles from it. Also, using it might reduce memory copying in some cases.
Of course, kernel space encryption is more limited compared to the one provided by OpenSSL and its derivatives in the user space: these limitations are imposed by hardware - e.g. NICs might not support anything but AES 128 (aka `TLS_AES_128_GCM_SHA256`), as it is the only cipher mandatory for TLS v1.3). If it is good enough for WEB servers, it should be good enough for DNS, too.
Even when kTLS is used, the handshake itself happens in the user space (e.g. using OpenSSL) with negotiated parameters passed to the kernel using `setsockopt()` calls on a TCP socket descriptor.
OpenSSL provides support for kTLS encryption natively since version 3.X (see `SSL_OP_ENABLE_KTLS` [option](https://www.openssl.org/docs/manmaster/man3/SSL_set_options.html)) but, as far as I understand it, it does so only when OpenSSL manages the underlying TCP socket file descriptor natively: not our case, as we are using LibUV for that. However, considering that the idea of kTLS is that with it enabled, we are supposed to pass unencrypted data to `send()` and `recv()`, that is kTLS-enabled socket from the higher level perspective works (mostly) as a TCP socket, we might try the following approach to implement kTLS, that *might* work:
1. We use our existing code (`tlsstream.c`) to handle handshake, just like we do now;
2. After completing the handshake, we pass the negotiated information to the kernel. OpenSSL might have some interfaces for that. In the worst case, we might need to do that by hand using. `setsockopt()`;
3. Then, we add new code paths to `tlsstream.c` to bypass TLS connection objects (`isc_tls_t`) and use the underlying TCP connection directly, which, by now, works in "kTLS-mode", providing transparent TLS encryption;
4. Control messages, like TLS shutdown, will require additional care.
That is how I see the initial plan that might or might not work. There can (and, likely, will) be unforeseen obstacles that might turn out to overcomplicate the code base so much that it might make it unfeasible to implement, like adding a kTLS-only transport. Furthermore, that might require some assistance from LibUV. That will require some trial and error.
That is mostly written with Linux in mind. If the kTLS interface in FreeBSD is similar enough (it seems so at the first glance), we should support both platforms.
The issue is created mostly to dump the information from my mind and keep kTLS under our radar: we might want to do that, as at least `dnsdist` has experimental support for it. It will be even more important in the future, as it seems now that encrypted DNS transport will be even more important to the point of replacing the good ol' Do53 at some point.
For sure, it is not a 9.20 material - rather 9.21-9.22 if we are lucky, as it is a big feature. Also, I foresee a similar concept eventually appearing for QUIC, too (kQUIC?). Also, I am aquiet certain that we *will* need #3504 for this (implemented here: !8576).
See also:
1. https://docs.kernel.org/networking/tls.html
2. https://man.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html
3. https://delthas.fr/blog/2023/kernel-tls/ - mostly discusses it in the context of HTTP and `sendfile()` acceleration, but contains many references on the topic.
4. https://docs.nvidia.com/networking/display/ofedv512580/kernel+transport+layer+security+(ktls)+offloadsLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4503Possible pytest RNDC interface improvements2023-12-21T18:03:30ZŠtěpán BalážikPossible pytest RNDC interface improvementsReview of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
...Review of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
- [ ] Find a way to the the `*.in` files templating in pure Python. This is needed for the elimination of the `setup.sh` scripts. This will probably require depending on `jinja` explicitly.
- [ ] Add an "rndc null" before every reconfiguration to show which file is used (NamedInstance.add_mark_to_log() as it may be generically useful?)
- [ ] Extend `NamedInstance` with some kind of `query` method. This is needed as a replacement for the calls to `dig` which are common in system tests.
- [ ] There are now two objects representing the ports used in tests: dictionary returned by the `ports` fixture and the new `NamedPorts` class. Unify them. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411674).
- [ ] Consider switch from `NamedTuple` to `dataclass` (Python 3.7 feature, requires a external dependency on some distros we run) as discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411004).
- [ ] `NamedInstance.rndc(…)` method probably ought to be `async`. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411007)
Feel free to add others!Long-termŠtěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4485Update httppicoparser2023-12-13T16:43:09ZOndřej SurýUpdate httppicoparserThis sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78This sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4482Remove the "dnssec-must-be-secure" feature2023-12-07T10:23:58ZMichał KępieńRemove the "dnssec-must-be-secure" featureSee #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.See #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.BIND 9.21.x2024-12-01https://gitlab.isc.org/isc-projects/bind9/-/issues/4446deprecate --enable-fixed-rrset / rrset-order fixed2024-03-07T19:20:29ZPetr Špačekpspacek@isc.orgdeprecate --enable-fixed-rrset / rrset-order fixed### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I th...### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I think it will get in our way when we fix #3405.
### Proposal
Deprecate deprecate `configure --enable-fixed-rrset` / `rrset-order fixed` statement in 9.20, remove in 9.21.
### Links / referencesBIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4444TCP fallback does not happen on bind 9.18.112023-12-19T09:16:56ZShota HinoTCP fallback does not happen on bind 9.18.11
### Summary
After upgrading bind9 from v9.18.10 to v9.18.11, we found that TCP fallback no longer happens. The previous behavior on bind v9.18.10 was that after UDP queries time out, named falls back to TCP. We identified that this ch...
### Summary
After upgrading bind9 from v9.18.10 to v9.18.11, we found that TCP fallback no longer happens. The previous behavior on bind v9.18.10 was that after UDP queries time out, named falls back to TCP. We identified that this change in behavior was introduced by this change https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7212.
### BIND version used
v9.18.11
### Steps to reproduce
1. Block UDP queries.
2. Observe that named does not fall back to TCP
### What is the current *bug* behavior?
TCP fallback does not happen after UDP queries time out.
### What is the expected *correct* behavior?
After UDP timeout, named falls back to use TCP.
### Relevant configuration files
```
options {
listen-on { 192.168.4.1; 127.0.0.1; }; # see warning above before changing
version "not currently available";
forwarders {
75.75.75.75;
75.75.76.76;
8.8.8.8;
8.8.4.4;
208.67.222.222;
208.67.220.220;
};
querylog yes;
# Cache and forward
recursion yes;
forward only;
# Enable dnssec
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
max-cache-size 2m;
max-cache-ttl 3600;
# Default path is at the root directory, which is not writable by bind.
dump-file "/run/named/named_dump.db";
};
```
### Relevant logs and/or screenshots
This is the packet capture from the working version - v9.18.10. You can see that TCP fallback happens.
![Screenshot_from_2023-11-21_12-19-39](/uploads/9b85a9cac9e0b2900ac60c3baa619668/Screenshot_from_2023-11-21_12-19-39.png)
### Possible fixes
I have not fully traced the code, but TCP fallback might have been happening via the code here? https://gitlab.isc.org/isc-projects/bind9/-/blob/bind-9.18/lib/dns/resolver.c?ref_type=heads#L2600-2625.
With the said commit https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7249/diffs?commit_id=095f634f48d621da1e26e5ada5026b5427e0a0bb#23711d1cafba45a6f9e0b84f76c786435421f0e8_2631_2631, this may not happen if the retry counter never gets incremented. I could be wrong on this analysis because I did not carefully trace the code, so please take this with a grain of salt.BIND 9.21.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4426Feature request - client.bind chaos class queries2023-11-20T10:39:24ZRay BellisFeature request - client.bind chaos class queriesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4416ccmsg doesn't support multiple message read in the single TCP read2023-11-09T09:35:42ZDominik Thalhammerccmsg doesn't support multiple message read in the single TCP read### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_be...### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_beta`
```
BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2
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-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--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' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-B5s8Yi/bind9-9.18.12=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
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
Send multiple requests via rndc in rapid succession. The particular program used to initially observe the issue is closed source and tightly integrated, however the following script using `bind9-rndc-node` experiences the same behaviour.
```js
var RNDC = require('bind9-rndc');
var key = 'BzDBJ1B/JbQg9iXJYAGZLQ==';
var session = RNDC.connect('172.17.0.2', 953, key, 'md5');
var test_count = 10;
var recv_count = 0;
session.on('ready', () => {
for(var i = 0; i < test_count; i++)
session.send('status');
});
session.on('data', (obj) => {
recv_count++;
console.log("Got " + recv_count);
console.log(obj);
});
session.on('error', console.log);
```
### What is the current *bug* behavior?
Bind correctly handles some of the requests but drops others. Depending on the message size and timing the indices of the recognized messages vary and sometimes bind looses track entirely until it drops the connection with a timeout.
### What is the expected *correct* behavior?
The number of responses is equal to the number of requests (the order can vary, thats what `_ser` is for) and the stream stays in sync, regardless of the timing when sending messages. If bind can not keep up with the client it should use the tcp blocking to signal this instead of dropping data.
### Relevant configuration files
named.conf
```
key "rndc-key" {
algorithm hmac-md5;
secret "BzDBJ1B/JbQg9iXJYAGZLQ==";
};
controls {
inet 0.0.0.0 allow { any; } keys { "rndc-key"; };
};
options {
directory "/var/cache/bind";
version none;
allow-query { any; };
allow-recursion { any; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { };
listen-on { any; };
};
```
### Relevant logs and/or screenshots
Sample output of script (note theres a rather long pause before `warning: unread...`):
```
(node:10142) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Got 1
Map(0) {
type: 'status',
result: '0',
text: 'version: BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:> (version.bind/txt/ch disabled)\n' +
'running on 54d01852d58b: Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2\n' +
'boot time: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'last configured: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'configuration file: /etc/bind/named.conf\n' +
'CPUs found: 16\n' +
'worker threads: 16\n' +
'UDP listeners per interface: 16\n' +
'number of zones: 101 (99 automatic)\n' +
'debug level: 0\n' +
'xfers running: 0\n' +
'xfers deferred: 0\n' +
'soa queries in progress: 0\n' +
'query logging is OFF\n' +
'recursive clients: 0/900/1000\n' +
'tcp clients: 0/150\n' +
'TCP high-water: 0\n' +
'server is up and running'
}
warning: unread data left over
```
Relevant log output for this transaction:
`04-Nov-2023 15:12:17.519 invalid command from 172.17.0.1#40764: timed out`
### Possible fixes
I am not familiar with the bind9 source code, but I will take a look if I can find something (along with retesting on the master branch).
A fix for clients is to ensure that there is never more than one message in flight. This fixes the issue, but vastly degrades performance if the latency between server and client is huge.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4403Resolve spike in memory when named starts2023-12-05T15:58:58ZMatthijs Mekkingmatthijs@isc.orgResolve spike in memory when named starts9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory ...9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory spike exceeds available memory.
![all-groups-resmon.memory.current-docker](/uploads/b5fa63c677bb0c903ffca45b994375ac/all-groups-resmon.memory.current-docker.png)
![all-groups-resmon.cpu.usage_percent.cg-docker](/uploads/314f7c9f1c396f303bdd6397dd2dc73a/all-groups-resmon.cpu.usage_percent.cg-docker.png)
![all-groups-latency-since_0-until_150](/uploads/3ba559d2fd3a18335eaf45796874482c/all-groups-latency-since_0-until_150.png)BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4371All the things that need to be fixed before 9.202024-03-27T14:02:04ZMatthijs Mekkingmatthijs@isc.orgAll the things that need to be fixed before 9.20This is an overarching issue for keeping track on all the things that need to be completed before the 9.20.0 release.
### Features
- [ ] #1128 Offline KSK (:gear: @matthijs)
- [x] #1129 HSM support via pkcs11-provider
- [x] #4363 Enfor...This is an overarching issue for keeping track on all the things that need to be completed before the 9.20.0 release.
### Features
- [ ] #1128 Offline KSK (:gear: @matthijs)
- [x] #1129 HSM support via pkcs11-provider
- [x] #4363 Enforce stricter NSEC3 parameter limits
- [x] #4388 Accepting PROXYv2
- [x] #4241 Expose data about 'first time' zone maintenance in-progress
- [ ] #2099 Implement ZoneMD signature generation and verification. (:gear: !5217 @marka, @each)
### Config incompatibilities
- [x] #4364 named-compilezone defaults
- [x] #4373 safer "dnssec-validation yes"
- [x] #4447 "stale-answer-client-timeout" must be zero (:gear: !8699 @aram)
### Refactoring
- [x] #4411 QPDB lite (:gear: !8726 @matthijs, @each)
- [x] #4251 system test runner
### Bugs
- [x] #4340 "max-cache-size" is a no-op since BIND 9.19.16
- [x] #4213 BIND shutdown hang in checkds/ns9/ in cross-version-config-tests job
- [x] #4060 named doesn't shut down after receiving rndc stop command
- [x] #4211 AssertionError: named crashed, shutdown crash
- [ ] #4403 Resolve spike in memory at start of named (:gear: @ondrej)
- [ ] #4481 TCP issue (:gear: isc-private/bind9!639 @ondrej)
- [ ] #4475 Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove (:gear: !8645 @marka)
- [x] #4625 DNSSEC validation incompatibility
- [ ] #4652 Server crash caused by external UDP queriesBIND 9.19.x2024-05-02https://gitlab.isc.org/isc-projects/bind9/-/issues/4370Check that a zone is served by IPv6 servers if it has AAAA records2023-12-05T09:04:32ZMark AndrewsCheck that a zone is served by IPv6 servers if it has AAAA recordsOne thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking fo...One thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking for AAAA records in the zone contents, including glue AAAA records, and then checking that there are AAAA records published for some of the nameservers if any are found (in zone or elsewhere). This can also sometimes be determined by named without needing to look beyond the zone's contents, but cannot be guaranteed.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4358Randomize client address to improve security against cache poisoning2023-10-10T12:46:26ZKasper DupontRandomize client address to improve security against cache poisoning### Description
Existing solutions to increase request entropy only provide a few extra bits. Port number randomization provide at most 16 bits of entropy and randomizing casing of the name will often provide less than that. Moreover fo...### Description
Existing solutions to increase request entropy only provide a few extra bits. Port number randomization provide at most 16 bits of entropy and randomizing casing of the name will often provide less than that. Moreover for responses spanning multiple packets that extra entropy may only protect the first packet of the response.
### Request
Take advantage of the larger address space provided by IPv6 to randomize both client IP address and port. Using a /72 prefix would leave 56 bits for randomization which is more than request ID, port number, and name randomization combined. The IP address is part of each packet and will thus protect all packets of the response. It does not require the other methods of adding entropy to be disabled, combined the entropy can be even higher.
Ideally the prefix length used will be configurable. Supporting only multiples of 8 will keep the implementation simpler. A /72 prefix length will be preferred in at least some deployments. It avoids randomizing the multicast and globally unique bits of the address. Additionally it's usable with providers who only route a /64 to customers. (Use cases exist for /48, /56, /64, /72, and /104 with /72 being the best compromise if only a single prefix length is supported.)
To use this feature the server administrator would need to:
- Ensure a prefix is routed to the host
- Choose a sub-prefix of that to use for source IP randomization (could be the entire range if the routed prefix is used for nothing else)
- Add a local route for the chosen sub-prefix (this functionality exists on Linux, I don't know which other OS supports this functionality.)
- Configure the chosen sub-prefix for address randomization in the BIND configuration.
The BIND recursion code will need to do the following:
- Before calling bind on a newly created socket set the IP_FREEBIND option.
- In the arguments for bind provide not just a port number but also a local IP address constructed by combining the configured prefix with a random bitstring to produce a total of 128 bits.
- Ensure that any replies not sent to the correct local IP address are ignored either by the kernel or by BIND itself.
When using TCP IP randomization should also be used, but it should not change how long the TCP connections are kept alive. So multiple queries could be sent over a TCP connection where IP randomization was applied only once.
### Links / references
The security feature requested here already exists in Unbound and can be configured using outgoing-interface: https://nlnetlabs.nl/documentation/unbound/unbound.conf/Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4348implement QPDB databases2024-03-08T23:38:09ZEvan Huntimplement QPDB databasesCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheBIND 9.21.xEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4330Add support to parse and display DSO (opcode 6) messages2023-11-01T14:43:41ZMark AndrewsAdd support to parse and display DSO (opcode 6) messagesSee [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.See [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.Long-termMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4318Check the size of the structure passed to dns_rdata_*struct methods2024-01-03T13:35:03ZMark AndrewsCheck the size of the structure passed to dns_rdata_*struct methods#4314 made me think we should check the size of the structure being passed to dns_rdata_tostruct, dns_rdata_fromstruct, and dns_rdata_freestruct as we don't have the compiler doing type checks for us. It there is a mismatch badness coul...#4314 made me think we should check the size of the structure being passed to dns_rdata_tostruct, dns_rdata_fromstruct, and dns_rdata_freestruct as we don't have the compiler doing type checks for us. It there is a mismatch badness could happen.Not planned