BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-06T08:38:23Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4592Improve the isc_heap resize algorithm2024-03-06T08:38:23ZOndřej SurýImprove the isc_heap resize algorithmThe current isc_heap resizing algorithm grows the array for holding the heap elements by 1024 (there's an argument to `isc_heap_create()`, but either default (1024) or explicit 1024 is used everywhere).The current isc_heap resizing algorithm grows the array for holding the heap elements by 1024 (there's an argument to `isc_heap_create()`, but either default (1024) or explicit 1024 is used everywhere).May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4586Don't count expired / future RRSIGs in verification failure quota2024-02-24T08:17:15ZMark AndrewsDon't count expired / future RRSIGs in verification failure quotaExpired / future RRSIGs don't trigger a public key verification.Expired / future RRSIGs don't trigger a public key verification.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4585Add an option to named-compilezone to retain comments2024-02-18T03:27:07ZMarco DavidsAdd an option to named-compilezone to retain comments### Description
`named-compilezone` strips comments from zone files.
### Request
There might be use cases, where `named-compilezone` is used as a cleanup tool, while any comments that are present need to be retained.
It would be gre...### Description
`named-compilezone` strips comments from zone files.
### Request
There might be use cases, where `named-compilezone` is used as a cleanup tool, while any comments that are present need to be retained.
It would be great if this could be achieved by some command-line option.
Obviously there are some caveats, but it seems that these can be addressed by defining certain conditions that must be met and by properly documenting the right way of working. For example, just as a suggestion: to have any comments on the same line in the zonefile like this:
Undefined (may fail):
```
; comment 1
www AAAA 2001:db8::1
; comment 2
```
Well defined (will work):
`www AAAA 2001:db8::1 ; comment 1`
### Links / references
n/aNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4584Feature request: streamline the behavior of 'hostname' and 'server-id'2024-02-15T15:24:10ZMarco DavidsFeature request: streamline the behavior of 'hostname' and 'server-id'### Description
`hostname` default is the hostname of the machine hosting the name server, as found by the gethostname() function.
`server-id` default is `none`.
This may lead to confusion. Especially since other vendors (Unbound, Kno...### Description
`hostname` default is the hostname of the machine hosting the name server, as found by the gethostname() function.
`server-id` default is `none`.
This may lead to confusion. Especially since other vendors (Unbound, Knot) do it differently by combining the two (via the `identity` option).
### Request
To put both option-defaults more inline with each other. And perhaps even to consider to combine them, instead of treating them as separate entities. RFC4892 seams to suggest they are alternative ways of pointing to the same thing and this is also how Knot and Unbound interpret it.
Perhaps, while at it, also consider the usefulness of SOA and NS records in the reply (in the case of `CH ANY version.bind` and `CH ANY authors.bind`), because they are still shown, even if `server-id` is undefined, while their existence is not clear.
### Links / references
RFC4892 and RFC5001 may be relevant.https://gitlab.isc.org/isc-projects/bind9/-/issues/4582Add support for QUIC and DNS over QUIC/DoQ (RFC 9250)2024-03-05T20:04:55ZArtem BoldarievAdd support for QUIC and DNS over QUIC/DoQ (RFC 9250)_This section is very likely to be changed/updated/expanded in the future._
## Overview
One of the relatively recent additions of transport protocols for DNS is QUIC (DoQ, covered by [RFC 9250](https://www.rfc-editor.org/rfc/rfc9250.ht..._This section is very likely to be changed/updated/expanded in the future._
## Overview
One of the relatively recent additions of transport protocols for DNS is QUIC (DoQ, covered by [RFC 9250](https://www.rfc-editor.org/rfc/rfc9250.html)) and HTTP/3 (DoH3), which also works on top of QUIC.
We need a generic implementation of the QUIC protocol in BIND's codebase to proceed with these new transports.
QUIC is a sophisticated transport that works on top of UDP and uses encryption on top of TLSv1.3. It is covered by multiple RFCs and is being actively worked on. The list of RFCs includes the following:
- https://www.rfc-editor.org/rfc/rfc9250.html
- https://www.rfc-editor.org/rfc/rfc8999.html
- https://www.rfc-editor.org/rfc/rfc9000.html
- https://www.rfc-editor.org/rfc/rfc9001.html
- https://www.rfc-editor.org/rfc/rfc9002.html
- https://www.rfc-editor.org/rfc/rfc9369.html
The protocol includes a lot of functionality, resembling the one from HTTP/2. Most notably, it is multiple uni- or bi-directional streams per connection. This aspect might have been influenced by the need to carry a new version of HTTP protocol (HTTP/3), which uses the multi-stream nature of QUIC instead of protocol-specific multiplexing found in HTTP/2.
Each bi-directional stream (in which we are the most interested, as these are used for DoQ) from the point of view of the higher-level code acts similarly to a TCP connection, though in the case of DNS, no more than one request/query per stream is allowed. That means that DNS pipelining is achieved by relying on the multistream nature of QUIC (again, similarly to HTTP/2). The thing is that each stream (being, effectively, a separate "connection") shares TLS parameters with others.
Another important aspect of QUIC is client connection end-point migration. That is, a client may change its location (= IP address and UDP port) while keeping the connection active. That functionality requires complete virtualisation of networking connections, which are now being identified not by IP address and port combination but by abstract connection identifiers (connection IDs). That brings a notion of a "connection path" into the picture as well as a procedure of "path migration" for a client.
Though that is my personal opinion, QUIC seems to be at least partially a result of large companies' experience of running user-space TCP/IP stacks on scale - when TCP/IP stack is implemented as a user-space library in an application which "directly" uses a dedicated network card. Indeed, in the case of QUIC, many things that we expect in-kernel TCP/IP implementation to do are brought under the control of a user-space application, including, but not limited to, such intricacies as congestion control. In this case, UDP can be seen as a portable kernel interface to the network card with the additional advantage of making it possible to run multiple applications simultaneously using a network card (which is not the case when using user-space TCP/IP stacks).
QUIC is often described as a replacement for the TCP protocol. One of the authors of "Computer Networks: A Systems Approach" [argues](https://www.theregister.com/2022/10/07/quic_tcp_replacement/) that it is, in fact, an addition to the internet protocols suite, which is meant to implement a missing paradigm - a basis for Remote Procedure Calls (RPC) protocols. That is, it might be considered a replacement of the TCP only in the cases when TCP was used due to a lack of a better alternative.
It should be noted that while QUIC is meant to be used as a universal transport for DNS, it, unlike HTTP/2 (DoH), can be used for zone transfers as well. It is [not always guaranteed](https://www.theregister.com/2021/08/04/dissecting_performance_of_production_quic/) that it will provide a significant performance boost. In fact, it might require more traffic in some cases, as even the initial QUIC message should be no less than 1200 bytes, which is a lot by common DNS measurements. However, it might compensate for that by lower latency due to 0-RTT support. Also, it seems to be more like a client-oriented protocol due to the ability to migrate client connections to new addresses (which is great for portable mobile devices). That being said, it is not clear how beneficial it would be to use it for server-to-server communications for things like zone transfers: servers do not change addresses often, and the protocol itself is more verbose than, e.g. DoT, so I fail to see the immediate benefits for this case (although it is standardised).
## The State of Open Source QUIC Implementations and the Great OpenSSL Schism
As it was stated before, QUIC includes TLSv1.3. Thus, most implementations decided to dedicate TLS-specific functionality to base the crypto-related bits to OpenSSL and its derivatives, which makes sense as these libraries are widely deployed and used. However, initially, these libraries lacked QUIC-specific parts in their TLS implementations.
As the early QUIC adopters were also QUIC implementors, they forked OpenSSL and added the missing bits. The related changes to the API ended up in multiple OpenSSL forks, namely [QuicTLS](https://quictls.github.io/) (maintained by Akamai and Microsoft), [LibreSSL](https://www.libressl.org/) (maintained by OpenBSD), and [BoringSSL](https://boringssl.googlesource.com/boringssl) (maintained by Google). These libraries only implement the low-level TLS 1.3 bits related to QUIC but do not have any internal QUIC implementations, as their early adopters developed their own.
For quite some time, the original OpenSSL had [a merge request](https://github.com/openssl/openssl/pull/8797) opened to implement the same API and remain mostly compatible with its forks, as was the case for a long time. However, OpenSSL authors decided to provide a high-level implementation of QUIC of their own making and eventually closed the MR. That caused a lot of drama, about which you can read [here](https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/) or [here](https://github.com/haproxy/haproxy/issues/680#issuecomment-1433118828) as well as in other places. Regarding OpenSSL, it is worth keeping multiple things in mind.
Firstly, [OpenSSL's implementation](https://www.openssl.org/docs/manmaster/man7/openssl-quic.html) is not ready yet, as it includes only minimal client-side implementation starting from the version of OpenSSL v3.2. The server-side support was planned for 3.3 (April 2024) according to [the project's roadmap](https://www.openssl.org/roadmap.html), but eventually, it was moved to 3.4 (October 2024), as there are [many not completed tasks](https://github.com/orgs/openssl/projects/2/views/31?pane=issue&itemId=31713456), some of them are marked as "Epic". Even after that, we most likely will have only the most basic (_Minimal Working Product_) implementation that is not as battle-tested as some others and with missing features.
Secondly, OpenSSL does not allow the use of third-party implementations of QUIC: with OpenSSL, the only option is to use the internal QUIC implementation. That was [noted by Tatsuhiro Tsujikawa](https://github.com/ngtcp2/ngtcp2/issues/898#issuecomment-1692538880), the principal author of nghttp2/ngtcp2/nghttp3.
As a result of these decisions, most QUIC implementations chose to depend on QuicTLS and other forks that provide similar API. That list includes [MS-QUIC](https://github.com/microsoft/msquic), [Quiche](https://blog.cloudflare.com/enjoy-a-slice-of-quic-and-rust/), Chromium QUIC, as well as internal (=not exposed as a redistributable library as it is very specific) implementation in HAProxy. Probably, most other libraries are likely doing the same.
There are notable exceptions to this, though.
Firstly, NGINX does not depend on a fork-related functionality to implement QUIC support, nor does it depend on the OpenSSL implementation of QUIC. One could get this impression after reading [the announcement of this functionality in NGINX](https://www.nginx.com/blog/quic-http3-support-openssl-nginx/), which discusses that they implement _only_ OpenSSL compatibility layer in order to remain compatible with both OpenSSL and its now numerous forks. It should be noted, though, that in this particular case, whoever wrote the announcement was modest, as, in fact, NGINX includes [their own in-house QUIC implementation](https://github.com/nginx/nginx/tree/master/src/event/quic). And yes, it seems that they managed to do it without relying on any QUIC-related functionality in OpenSSL or its forks (like QuicTLS, LibreSSL, and BoringTLS). Their code seems to work with basically any OpenSSL-like library with TLSv1.3 support.
Secondly, there is [ngtcp2](https://github.com/ngtcp2/ngtcp2), which itself does not depend on any cryptographic library per se. The library itself may use one of the provided backends implemented on top of QuicTLS, GnuTLS, PicoTLS or BoringSSL and implemented as separate libraries, but it does not have to, as an application can provide a custom implementation of the [ngtcp2 crypto API](https://nghttp2.org/ngtcp2/crypto_apiref.html) as described in [the programmer's guide](https://nghttp2.org/ngtcp2/programmers-guide.html). The library itself is [very complete](https://nghttp2.org/ngtcp2/apiref.html) and seems to implement all the intricacies of the QUIC protocol, unlike the OpenSSL's implementation at the time of writing (and likely, for quiet some time after that).
At this point, it is clear that as far as QUIC support goes, the OpenSSL and its numerous forks **will remain incompatible**. _That is not a technical decision and, thus, hard to resolve._
## Implementing QUIC in BIND
For the reasons given above, I think that we should choose the ngtcp2 library as a basis for our QUIC transport. Additionally, it is much more mature than the implementation that OpenSSL will initially provide as and has been considered stable for a while (1.0.0 was released Oct 15, 2023). Moreover, before implementing the final IETF QUIC, it implemented a number of drafts, so it is safe to say that the authors have been tracking the development of the protocol very closely. Considering that the most recent RFCs have been implemented as well (like [QUIC version 2](https://www.rfc-editor.org/rfc/rfc9369.html), which, in fact, is a minor update of the protocol), it appears to still be the case. We can pair it with our own crypto API implementation inspired by the code from NGINX and currently provided crypto libraries. That will ensure that BIND still remains compatible with other OpenSSL forks, in particular on the platforms that use them by default (like OpenBSD). That should give us the flexibility of NGINX without the burden of maintaining our own QUIC implementation, as I cannot justify doing that as much as depending on any of the numerous OpenSSL forks.
I cannot justify waiting for OpenSSL to have their implementation completed either, as it is not clear how good the initial implementation will be, and I am not sure if the higher-level API they intend to provide is going to be the best fit for us. Ngtcp2 already looks more promising in that regard, not to mention that we have, in my opinion, a very good experience of using [nghttp2](https://nghttp2.org/) from the same author. Also, it is worth noting that at this stage, we have an internal subsystem for managing TLS contexts used by DoT and DoH, so it is very desirable to use it for QUIC as well and having our own ngtcp2 crypto API implementation should make it possible. We can use the code [from NGINX](https://github.com/nginx/nginx/blob/master/src/event/quic/ngx_event_quic_openssl_compat.c) and existing [ngtcp2 crypto libraries](https://github.com/ngtcp2/ngtcp2/tree/main/crypto) as examples.
Apart from choosing the library which will serve as the foundation of our QUIC implementation, there are many other problems to solve, which are no less challenging and will require some thinking and trial and error, so it is better for us not to wait for OpenSSL so that we will have more time to iron out our QUIC-related code before the new release. That is, the code related to connections and stream management and, ideally, connection migration is the most challenging, in my opinion, though the choice of the library will affect its structure for sure.
I think that it would be best to use and scale the experience of structuring the transport code in a way similar to Stream DNS and PROXYv2. It is very desirable as it allows testing without direct dependence on the networking code. By such a design, I mean implementing the most important parts of the QUIC code as a black box to which we pass data, and it calls the necessary callbacks when required.
On the highest level, bi-directional QUIC streams (in which we are interested the most for now) should map well to Stream DNS or a very similar transport (a QUIC Stream based on `isc_dnsstream_assembler_t`).
QUIC has some newer characteristics not present in other transports, like an ability by both end-points to create new streams at any moment as much as a concept of a generic multiplexed transport itself. These things are likely to be resolved in a manner similar to HTTP/2 - using a virtual connection per stream. Another thing to mention is connection migration. Our code is not ready for that (and, likely, never will), so we should set a QUIC Stream end-point information at the moment of creating and then never update that (from the point of view of the higher level code for compatibility reasons - in fact, we still can do the actual connection migration with all the open streams).
So, in short, it seems that we should attempt to use ngtcp2 with custom crypto API implementation first. The initial plan was to combine the client-side support for QUIC from OpenSSL and combine it with "OpenSSL Compatibility Layer" (as they named it) from NGINX (which turned out to be a complete internal only in-house QUIC implementation), but due to the reasons given above, that will not work as it is not possible to combine QUIC-related functionality in OpenSSL with any third-party QUIC implementation at all (and likely never will). Ngtcp2 is the only crypto library agnostic implementation of QUIC at the moment.
I would rather choose to depend on OpenSSL for our QUIC implementation as a backup plan.
## Bridging the Gap: How We Could Make an Ngtcp2 Crypto API Implementation
Let's see how we can proceed with providing our own ngtcp2 crypto API implementation.
### Ngtcp2 Crypto API Implementations Structure
As it was noted above, in order to work, ngtcp2 requires a crypto API implementation. The project provides multiple of them for the crypto libraries that have explicit support for QUIC. The list of these libraries includes (at the time of writing) QuicTLS, BoringSSL, GnuTLS, WolfSSL, and PicoTLS.
Each crypto API implementation library consists of two parts.
Firstly, it is a high-level, [shared part](https://github.com/ngtcp2/ngtcp2/blob/main/crypto/shared.c). Among other things, it includes default implementations of all callbacks used by ngtcp2, and some important API calls, most notably `ngtcp2_crypto_derive_and_install_rx_key()` and `ngtcp2_crypto_derive_and_install_tx_key()`, which are mentioned in [the ngtcp2 programmers guide](https://nghttp2.org/ngtcp2/programmers-guide.html).
Secondly, a low-level part that provides a foundation for the functionality of the shared part. There is an implementation for each of the above mentioned supported crypto libraries.
The shared part and a low-level part linked together is an ngtcp2 crypto API implementation.
Of these implementations, the most interesting for us is the one for [QuicTLS](https://github.com/ngtcp2/ngtcp2/blob/main/crypto/quictls/quictls.c) and, to a somewhat lesser extent, [BoringSSL](https://github.com/ngtcp2/ngtcp2/blob/main/crypto/boringssl/boringssl.c), as both are OpenSSL forks. In fact, we can use most of the code from there without much adaptation, as QuicTLS is essentially OpenSSL + QUIC-related API (it is regularly rebased on top of the "mainline" OpenSSL).
The QuicTLS crypto API implementation does not use many QUIC-related API calls. I have identified only the following:
- `SSL_CTX_set_quic_method()` - we would be better using a very similar SSL_set_quic_method();
- `SSL_provide_quic_data()`;
- `SSL_set_quic_transport_params()`/`SSL_get_peer_quic_transport_params()`;
- `SSL_process_quic_post_handshake()` - this one appears to be optional but omitting it will leave us without 0-RTT support (at least, for now).
There is one problem with how the crypto API libraries are structured - as there is no way to use only the shared part without depending on one of the above-mentioned crypto libraries (which would not work for us anyway).
So, in our ngtcp2 crypto API implementation, we would need to provide a replacement for the shared part - at least for the callbacks and `ngtcp2_crypto_derive_and_install_rx_key()`/ `ngtcp2_crypto_derive_and_install_tx_key()`. That is doable but very unfortunate, as it includes a lot of crypto-related things, not to mention that it is extra code to maintain.
Regarding the missing QUIC API in OpenSSL, there is a solution from NGINX which might work for us as well.
### NGINX OpenSSL Compatibility Layer
As noted above, NGINX includes a compatibility layer with NGINX as a part of its QUIC implementation. It includes the implementations of the following functions:
- `SSL_set_quic_method()`
- `SSL_provide_quic_data()`
- `SSL_set_quic_transport_params()`/`SSL_get_peer_quic_transport_params()`
NGINX's [OpenSSL compatibility layer](https://github.com/nginx/nginx/blob/master/src/event/quic/ngx_event_quic_openssl_compat.c) clearly provides an internal implementation of missing parts of BoringSSL QUIC API, which is not that different from QuicTLS API.
One missing thing is `SSL_process_quic_post_handshake()`, which is needed for 0-RTT support (to be more precise - for TLS early data processing). In fact, NGINX explicitly turns off TLS early data support when using QUIC. It is not clear if we can easily provide a replacement for this function, but even if not - we can live without 0-RTT support for now. At the time of writing, it is still optional in many crypto libraries.
It is worth noting that NGINX is a server application, so the provided QUIC API implementation might need some adjustments to work for client-side code.
At this point, it seems that despite some limitations, it is possible to provide a portable ngtcp2 crypto API implementation.BIND 9.21.xArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4581CID 486476: Memory - corruptions (OVERRUN) in lib/dns/resconf.c2024-02-24T07:55:23ZMichal NowakCID 486476: Memory - corruptions (OVERRUN) in lib/dns/resconf.cAfter 371defc35753d04fa8b769b8c859630c3a76e9ed, Coverity Scan claims memory corruption in `lib/dns/resconf.c`:
```cpp
/lib/dns/resconf.c: 246 in add_server()
240
241 /* XXX: special case: treat all-0 IPv4 address as loopback *...After 371defc35753d04fa8b769b8c859630c3a76e9ed, Coverity Scan claims memory corruption in `lib/dns/resconf.c`:
```cpp
/lib/dns/resconf.c: 246 in add_server()
240
241 /* XXX: special case: treat all-0 IPv4 address as loopback */
242 v4 = &((struct sockaddr_in *)res->ai_addr)->sin_addr;
243 if (memcmp(v4, zeroaddress, 4) == 0) {
244 memmove(v4, loopaddress, 4);
245 }
>>> CID 486476: Memory - corruptions (OVERRUN)
>>> Overrunning struct type sockaddr_in of 16 bytes by passing it to a function which accesses it at byte offset 27 using argument "res->ai_addrlen" (which evaluates to 28). [Note: The source code implementation of the function has been overridden by a builtin model.]
246 memmove(&address->type.sin, res->ai_addr, res->ai_addrlen);
247 } else if (res->ai_family == AF_INET6) {
248 memmove(&address->type.sin6, res->ai_addr, res->ai_addrlen);
249 } else {
250 isc_mem_put(mctx, address, sizeof(*address));
251 UNEXPECTED_ERROR("ai_family (%d) not INET nor INET6",
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4579Restore the ability to select individual unit tests and turn on debugging2024-02-24T07:53:44ZMark AndrewsRestore the ability to select individual unit tests and turn on debugging63fe9312ff8f removed the ability to select individual tests from the command line and turn on debugging. This is useful when you want to check only parts of a unit test when developing. This restores / adds this ability.63fe9312ff8f removed the ability to select individual tests from the command line and turn on debugging. This is useful when you want to check only parts of a unit test when developing. This restores / adds this ability.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4574add an +opt display flag for dig2024-02-14T18:09:52ZMatthew Pounsettadd an +opt display flag for dig### Description
As part of providing support or education to non-experts in the DNS, I find it useful to be able to narrow the output of `dig` to just the relevant bits, while providing a simple, reproducible, easily understood command ...### Description
As part of providing support or education to non-experts in the DNS, I find it useful to be able to narrow the output of `dig` to just the relevant bits, while providing a simple, reproducible, easily understood command to the other person. For example, it's routine for me to do something like `dig +noall +answer ...` or `dig +noall +authority...`.
I recently ran into a case where it would have been useful to focus on the OPT pseudosection, but found no easy antidote to `+noall` for it. `+comments` is close, but not precise. Likewise there are a number of things I can do with `grep`, or combining `+yaml` with `/bin/yq` to limit the output, but at the expense of clarity in the command I share.
### Request
It would be helpful to have an `+opt` (or equivalent) display flag in dig, which shows only the OPT pseudo-section without any other output, similarly to flags `+answer`, `+authority`, and `+additional`.
### Links / referencesNot plannedhttps://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/4564slightly worse cold cache performance after the KeyTrap fix2024-02-24T07:52:45ZTom Krizekslightly worse cold cache performance after the KeyTrap fixThe keytrap fix (merged in isc-private/bind9!628) has a significant impact on client query latency during startup (cold cache) as well as increased memory consumption. Using `recursive-clients 1000;` yielded quite similar results to `100...The keytrap fix (merged in isc-private/bind9!628) has a significant impact on client query latency during startup (cold cache) as well as increased memory consumption. Using `recursive-clients 1000;` yielded quite similar results to `10000` (which was used for most charts in here).
## Cold cache latency
### :question: 9.18 cold cache UDP
![keytrap-cold-cache-latency-9.18](/uploads/9953460d5a50fb571f18c21ece5f7415/keytrap-cold-cache-latency-9.18.png)
#### load 15x
| | before | after |
| ------ | ------ | ----- |
| responses <2.0s | 91 % | 79 % |
| responses <100ms | 88 % | 75 % |
#### load 10x
| | before | after |
| ------ | ------ | ----- |
| responses <2.0s | 96 % | 89 % |
| responses <100ms | 92 % | 85 % |
#### load 5x
| | before | after |
| ------ | ------ | ----- |
| responses <2.0s | 99 % | 98 % |
| responses <100ms | 93 % | 92 % |
### :question: 9.16 cold cache UDP
![keytrap-cold-cache-latency-9.16](/uploads/795943f2c6c6959c15f30c9f41597976/keytrap-cold-cache-latency-9.16.png)
### :white_check_mark: 9.19 cold cache UDP
the impact for ~"v9.19" is quite minimal and I don't consider it an issue
![keytrap-cold-cache-latency-9.19](/uploads/d86be8aeb8170b8e596bd85666937a81/keytrap-cold-cache-latency-9.19.png)
### :question: 9.18 cold cache TCP
The performance drop can also be observed with TCP with much lower overall throughput.
![keytrap-hot-cache-latency-tcp-9.18](/uploads/b581e94d77c5c1cdc9e143fdfff3bac2/keytrap-hot-cache-latency-tcp-9.18.png)
## :white_check_mark: Hot cache latency
The good news is that it doesn't really affect performance with hot cache.
![keytrap-hot-cache-latency-9.18](/uploads/e1704c0c853dc5b6ab798e1821b4a7db/keytrap-hot-cache-latency-9.18.png)
## Memory consumption
### :question: 9.18 memory consumption UDP
The initial memory consumption also gets slightly higher:
![keytrap-memory-9.18](/uploads/7d89b5dbc594c64c57802e11418c03b6/keytrap-memory-9.18.png)
### :white_check_mark: 9.18 memory consumption TCP
While the memory consumption is slightly higher for TCP under load, I think this can be explained by the fact that some queries take longer time to resolve -> some connections might be open for a longer time, thus consume more resources than before.
![keytrap-memory-tcp-9.18](/uploads/88be13f12e69bb69fc7f6d917dc21e6f/keytrap-memory-tcp-9.18.png)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)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/4554Signature expiration calculation backwards compatibility bug2024-02-24T07:53:48ZMatthijs Mekkingmatthijs@isc.orgSignature expiration calculation backwards compatibility bugThe `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `sig...The `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `signatures-validity - signatures-refresh`) which is wrong: it should be using a range of 0 to `signatures-refresh`.
The `sig-validity-interval` that was used for `auto-dnssec` defined two parameters, the first being the signatures validity (same as `dnssec-policy`'s `signatures-validity`), the optional second one being the minimum bound of the signatures validity. It also serves as a signatures refresh. Basically the refresh value is the difference between the first and second parameter.
So the second parameter actually has two meanings: It serves as a jitter and a refresh value.
With `dnssec-policy` there is not yet a way to define `jitter`. The `signatures-refresh` is actually defined as the.
Two things need to be done:
- [x] Add a configuration option to `dnssec-policy` to set desired jitter.
- [x] Ensure resign interval is used correctly.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/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/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/4543Re-enable unreachable checks in dnssec system test2024-02-24T07:55:26ZTom KrizekRe-enable unreachable checks in dnssec system testIn https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been a...In https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been accidentally added to the `dnssec` test, making the remaining checks unreachable.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://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/4538duplicate TLS session tickets from BIND2024-01-17T18:01:29ZPetr Špačekpspacek@isc.orgduplicate TLS session tickets from BIND### Summary
BIND sends **two** TLS session tickets in a row, in the same TCP frame. This looks like a bug. Probably no real-world impact except consuming a bit of extra bandwidth.
### BIND version affected
* ~"Affects v9.19" : e39b5447...### Summary
BIND sends **two** TLS session tickets in a row, in the same TCP frame. This looks like a bug. Probably no real-world impact except consuming a bit of extra bandwidth.
### BIND version affected
* ~"Affects v9.19" : e39b544704b98ddd8a19e317373b84ac74597f76 - noticed while testing !8646
* ~"Affects v9.18" : 071de1b5b54c27b1291bd97e3a95a93b1996eddc - isc-private/bind9!585
### Steps to reproduce
1. SSLKEYLOGFILE=/tmp/tlskeys /tmp/4527-improve-tls-framing-for-dot/sbin/named -g -c /tmp/named.conf
2. sudo tcpdump -i lo -w /tmp/tls.pcap 'port 853'
3. dig @127.0.0.1 +tls
- [tls.pcap](/uploads/e5836a9693d76f117c9e5c80f15cf2b1/tls.pcap)
- [tlskeys](/uploads/76d398d1c33b7eb90f4c7a14ff27a644/tlskeys)
### What is the current *bug* behavior?
For some reason BIND sends **two** TLS session tickets in a row, in the same TCP frame.
<details>
```
Frame 10: 608 bytes on wire (4864 bits), 608 bytes captured (4864 bits)
Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 853, Dst Port: 46779, Seq: 766, Ack: 476, Len: 542
Transport Layer Security
TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
Opaque Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 266
[Content Type: Handshake (22)]
Handshake Protocol: New Session Ticket
Handshake Type: New Session Ticket (4)
Length: 245
TLS Session Ticket
Session Ticket Lifetime Hint: 7200 seconds (2 hours)
Session Ticket Age Add: 1399829672
Session Ticket Nonce Length: 8
Session Ticket Nonce: 0000000000000000
Session Ticket Length: 224
Session Ticket [truncated]: 5f2c5c7290f6b002e39631b54f85b14de2620e615663e5e3a2a5c5194a3e5c47d5da9fc257200fe4318de304b2471b4a1f35607e53e0a3eb04e00421e2539bcdbf486e60ec9900448831dc70c1dcb081c0890d04c337dbe4aef4806dd5004019a0a7edfabbf17de7590
Extensions Length: 0
TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
Opaque Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 266
[Content Type: Handshake (22)]
Handshake Protocol: New Session Ticket
Handshake Type: New Session Ticket (4)
Length: 245
TLS Session Ticket
Session Ticket Lifetime Hint: 7200 seconds (2 hours)
Session Ticket Age Add: 310059667
Session Ticket Nonce Length: 8
Session Ticket Nonce: 0000000000000001
Session Ticket Length: 224
Session Ticket [truncated]: 5f2c5c7290f6b002e39631b54f85b14dc423d6b1f00ccd25e30d7cf9290c0dc32d8ed4b9c72a8e3555d9ccdba4b3b6299e5306c5bf9ca48f72325e23927d1e9ae572d8937faedeb7b5846b4f8817bef5e537a5ff8e516c20f520ebb535ab37fa64996854d10dcee1291
Extensions Length: 0
```
</details>
### What is the expected *correct* behavior?
I would expect just one ticket.Artem BoldarievArtem Boldarievhttps://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 planned