BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-08T11:17:37Zhttps://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/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/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/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/4523dnstap support for new transport protocols2024-03-08T09:03:02ZPeter Daviesdnstap support for new transport protocols### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS ...### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS and DNS over HTTPS, users may wish to
differentiate between these transports in dnstap output.
### Links / references
The current dnstap protobuf lists support for DoT, DoH:
see https://github.com/dnstap/dnstap.pb/blob/master/dnstap.protoAydın MercanAydın Mercanhttps://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/4489dnssec-guide should mention use of validate-except2023-12-13T12:29:01ZStacey Marshalldnssec-guide should mention use of validate-except### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentione...### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentioned in the DNSSEC guide (bind9/doc/dnssec-guide) within the ARM.
### Request
Within DNSSEC guide where `dnssec-validation` is discussed for troubleshooting, add some information about the use of `validate-except { string; }` with some examples.
Suggest too that dnssec-validation](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-dnssec-validation) statement also mention `validate-except`. Yes I see [validate-except](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-validate-except) is immediately below it, but without the dotted line it may not be seen.
### Links / references
https://lists.isc.org/pipermail/bind-users/2023-December/108172.htmlhttps://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/4470ns_interfacemgr_t listenon queue set incorrectly2024-03-28T08:28:47Zliu chaofengns_interfacemgr_t listenon queue set incorrectly<!--
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!
-->
### Summary
ns_interfacemgr_t listenon queue set incorrectly
### BIND version used
master branch
### Steps to reproduce
1. config named.conf like below
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
2. then start the named process
3. run "netstat -lpn|grep named" found the 53 and 10053 has already listened.
4. the ns_interfacemgr_t has a listenon queue
struct ns_interfacemgr {
...
ISC_LIST(isc_sockaddr_t) listenon;
....
}
5. I dump the listenon queue, found that there is only 127.0.0.1#53,
127.0.0.1#10053 is not in the listenon queue.
### What is the current *bug* behavior?
I think this behavior maybe a bug,
### What is the expected *correct* behavior?
the listenon should contain 127.0.0.1#53 and 127.0.0.1#10053
### Relevant configuration files
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://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/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/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/4352inline-signing breaks nsdiff2024-02-24T07:55:39ZBjörn Perssoninline-signing breaks nsdiff### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value o...### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value of inline-signing, the method in RFC 2136 section 5.7 will stop working on upgrade to BIND 9.20, as inline-signing will then be switched on by default, if I understand correctly.
### BIND version used
```
$ named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-25-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16)
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' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.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
Here I start from a working state with serial number 2023091800. The prerequisite matches the reply to the SOA query, and the update is answered with NOERROR. This is correct as far as I understand:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23595
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
```
Later, the server has automatically increased the serial number to 2023091802. I use the new serial number in the prerequisite, so it looks identical to the new SOA value, but this time the update is rejected with NXRRSET:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65052
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 52912
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NXRRSET, id: 52912
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
```
Now I change the prerequisite back to 2023091800. The SOA hasn't changed again. The serial number is still 2023091802. This update should be rejected as the prerequisite contains an outdated serial number, but is in fact answered with NOERROR:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6226
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
```
### What is the current *bug* behavior?
It seems that a serial number specified in a prerequisite of an update is compared to the unsigned version of the zone, but the serial number retrieved with a SOA or AXFR query is from the signed version. As far as I know a client can't look up the unsigned serial number, and thus can't specify it in the prerequisite. Thus the update fails when the two serial numbers differ.
### What is the expected *correct* behavior?
It seems to me that a prerequisite that specifies a SOA record should be checked against the same record that a client gets in response to a SOA or AXFR query. I don't know what other usecases that might break though.
### Relevant excerpts from the configuration file
```
dnssec-policy "some_name" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
view "internal" {
allow-transfer { key internal.beorn.tag.xn--rombobjrn-67a.se.; };
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.internal";
dnssec-policy some_name;
parental-agents { ::1; };
inline-signing yes;
update-policy {
grant internal.beorn.tag.xn--rombobjrn-67a.se. zonesub ANY;
};
};
};May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4320allow shorter resolver-query-timeout configuration2023-09-15T14:18:22ZPetr Špačekpspacek@isc.orgallow shorter resolver-query-timeout configuration### Use-case
Weird network setup:
* Load balancer is listed in NS RR set like this:`example.com NS load-balancer.example.com`
* The load balancer sets RD=1 and forwards query to a BIND **resolver**
* The BIND **resolver** is then configu...### Use-case
Weird network setup:
* Load balancer is listed in NS RR set like this:`example.com NS load-balancer.example.com`
* The load balancer sets RD=1 and forwards query to a BIND **resolver**
* The BIND **resolver** is then configured to talk to backend servers which are not visible in the public NS set
### Description
If/when the auths don't keep up with load from the BIND resolver "frontend", the resolver will retry several times during [resolver-query-timeout](https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-resolver-query-timeout) interval, which currently has minimum value of 10 s.
At the same time, the client which sent the original query will timeout because it is not expecting any auth to take 10 seconds to respond. This means the frontend BIND will be doing mostly pointless work, and that the client will penalize BIND-frontend in client's ADB (address database) because it will believe the BIND frontend just times out, while it will give back SERVFAIL, but only after 10 seconds.
See https://indico.dns-oarc.net/event/47/contributions/1018/ for more details.
### Request
When BIND is used in this weird scenario it's pointless to have `resolver-query-timeout` set to 10 s. It should allow configuration to be something like 0.5 seconds because communication with backends should be really fast. With such configuration BIND-frontend can give back SERVFAIL early when backends are not available and the ultimate client will not penalize the BIND-frontend for non-response.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4313automate root.hints up-to-date check2023-09-12T13:12:02ZPetr Špačekpspacek@isc.orgautomate root.hints up-to-date check### Problem
Right now root.hints file content is hardcoded into lib/dns/rootns.c, and not checked in any automated way I know of.
### Request
Use some automated process to check content of the file. E.g. a new job in the scheduled pip...### Problem
Right now root.hints file content is hardcoded into lib/dns/rootns.c, and not checked in any automated way I know of.
### Request
Use some automated process to check content of the file. E.g. a new job in the scheduled pipeline which would check content of the file against https://www.internic.net/domain/db.cache or something like that.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4297Follow-up from "Resolve "UAF in validator logging""2023-09-06T01:05:12ZMark AndrewsFollow-up from "Resolve "UAF in validator logging""The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would...The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would be attached to the `dns_name_t` instead of just assigned to prevent this reordering issues? What would be the performance impact of such change?Long-term