BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:30:30Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3896Add the TLS SNI +[no]tls-sni option to dig for DoT and DoH2023-11-02T16:30:30ZAlexey ChernyakAdd the TLS SNI +[no]tls-sni option to dig for DoT and DoH### Description
Currently, when doing DoT or DoH lookups, `dig` does not include the Server Name Indication (SNI) extension during its TLS handshake `ClientHello` request.
This makes dig unusable as a DoT or DoH client with TLS proxies...### Description
Currently, when doing DoT or DoH lookups, `dig` does not include the Server Name Indication (SNI) extension during its TLS handshake `ClientHello` request.
This makes dig unusable as a DoT or DoH client with TLS proxies and HTTPS proxies and DoT/DoH servers that implement:
* SNI based routing of requests to the correct backends as part of name-based virtual hosting, and/or
* SNI filtering based access control.
Currently `dig` also has very poor handling of the fatal-level SNI-related TLS handshake `Alert` response from server.
Example of such TLS Alert server response:
```
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unrecognized Name)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Unrecognized Name (112)
```
Current dig behaviour is as follows when the server aborts the handshake by sending such a fatal-level `unrecognized_name(112)` alert:
```
~ $ dig +https @dns.example.com example.com A; echo $?
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
9
~ $ dig +tls @dns.example.com example.com A; echo $?
0
~ $
```
There is no dependency on implementing SNI support in `named` (which also would be nice for ACLs and for multiple views).
While `named` can be placed behind a SNI-capable proxy, there's no workarounds for `dig` other than replacing it with a SNI-capable client such as `kdig`.
### Request
Add `+[no]tls-sni=STR` option to `dig` similar to the [option](https://www.knot-dns.cz/docs/3.2/html/man_kdig.html#options) in `kdig`.
Expected behaviour is something roughly along the lines of:
```
if request is DoT or DoH
if +tls-sni option is specified
SNIHostName = option value
else if +notls-sni option is specified
SNIHostName = NULL
else if @server argument is a hostname
SNIHostName = server hostname FQDN
else if +tls-hostname option is specified
SNIHostName = option value
else
SNIHostName = NULL
if SNIHostName
remove trailing FQDN dot from SNIHostName if specified
Do IDN format conversion to ASCII if necessary
validate SNIHostName against SNI HostName format specification
if SNIHostName format is valid
include SNIHostName as a SNI in TLS ClientHello
include SNIHostName in the first line of dig query output?
else
exit with an error
else
Don't include SNI in TLS ClientHello
if ServerHello response includes "server_name" extension
include SNIHostName in SERVER line in dig query output
```
Better error handling of the fatal-level `unrecognized_name(112)` alert TLS responses from server:
* Start returning an error during DoT instead of a silent success.
* Consider a more descriptive error message than the current `TLS error`:
```
if a <SNI> value was included in ClientHello
Error message something along the lines of: `'<SNI>' SNI is unrecognised by the server`
else
Error message something along the lines of: `SNI is required by the server`
```
### Links / references
For the most recent background and guidance on SNI see [Section 3.7 of RFC 9325](https://www.rfc-editor.org/rfc/rfc9325#name-server-name-indication-sni).
For the latest SNI specification defining SNI `HostName` format and client/server behaviour see [Section 3 of RFC 6066](https://www.rfc-editor.org/rfc/rfc6066.html#section-3).
When implementing, consider application of Internationalized Domain Names (IDN) in SNI as per [RFC 5890](https://www.rfc-editor.org/rfc/rfc5890) and TLS Encrypted Client Hello (ECH) as per the latest [draft](thttps://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html).Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3231forward queries via DoH2023-11-02T17:05:04ZDaniel Mittonforward queries via DoH### Description
How do you configure bind to forward queries, regardless of initial connection type, via DoH/DoT?
### Request
Forwarder configuration that specifies that forwarded queries are to be forwarded over DoH/Dot.
### Links /...### Description
How do you configure bind to forward queries, regardless of initial connection type, via DoH/DoT?
### Request
Forwarder configuration that specifies that forwarded queries are to be forwarded over DoH/Dot.
### Links / referencesNot plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3751Extend 'allow-*' options to support extended syntax that includes 'transport'...2023-11-02T17:05:06ZArtem BoldarievExtend 'allow-*' options to support extended syntax that includes 'transport' and 'port' parameters (like 'allow-transfer')While working on XoT we extended `allow-transfer` option with `port` and `transport` parameters (see !5587). As in 9.19 we support update forwarding over TLS (see !6710) and soon will support queries forwarding over TLS (see !7199 which ...While working on XoT we extended `allow-transfer` option with `port` and `transport` parameters (see !5587). As in 9.19 we support update forwarding over TLS (see !6710) and soon will support queries forwarding over TLS (see !7199 which is being worked on by @aram ), it seems that it is time to update other related options to support the extended syntax. The low-level functionality is there, it is a matter of enabling the syntax and extending the `transport-acl` system test.
We should not forget to extend these as we are improving our support for DNS transports other than UDP and TCP, as was originally intended while adding the initial support for these extra parameters.
This might end up being a "meta" issue referencing other related issues/MRs.
We should improve the documentation on that too, but that is a different matter.Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2748Could more detail be added to the query log to show the query protocol used (...2022-03-22T09:49:26ZRichard NealCould more detail be added to the query log to show the query protocol used (eg Do53, DoT, DoH)?### Description
It would be useful if BIND could log the query protocol used by the client - e.g. Do53, DoT, DoH. This would allow system administrators to understand the proportion of different types of queries and to help determine an...### Description
It would be useful if BIND could log the query protocol used by the client - e.g. Do53, DoT, DoH. This would allow system administrators to understand the proportion of different types of queries and to help determine any additional resource overhead (e.g. the computational resource overhead of encryption for DoT or DoH)
### Request
The logging statement grammar should be enhanced to allow the system administrator to (optionally?) include the protocol type for the query. If the system administrator chooses to enable protocol logging then it may be preferable to use a simple integer value for the chosen field, eg:
1 = Do53, 2 = DoT, 3 = DoH (non-TLS, eg behind HTTPS load balancer), 4 = DoH (TLS)
This would allow for future protocols at a later date
### Links / references
I have looked in the BIND 9.17 ARM and can see no reference to BIND being able to log the query protocol used by the client, but I am happy to be corrected if this feature already exists.
Thanks,
Richard.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3958Adjust default tcp-clients value upward2023-09-12T09:09:13ZVicky Riskvicky@isc.orgAdjust default tcp-clients value upwardThe default for tcp-clients is set at 150. As more users are now supporting encrypted DNS, which sessions use TCP, it is likely that the % of overall DNS sessions using TCP will increase, and the current default quota will be too low for...The default for tcp-clients is set at 150. As more users are now supporting encrypted DNS, which sessions use TCP, it is likely that the % of overall DNS sessions using TCP will increase, and the current default quota will be too low for many users.
Although it is impossible to determine the ideal setting for all users, it seems likely that users who need to limit TCP sessions can support at least an order of magnitude more sessions, like maybe 2,000.
If we are very worried about impacting small-system users of BIND, perhaps we could just change the setting for BIND -S, which is not available to hobbyists?https://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/3094doth: RNDC reconfiguration too slow on OpenIndiana2022-01-14T11:18:06ZMichal Nowakdoth: RNDC reconfiguration too slow on OpenIndianaEven with 2e5f9a0df5e0a8a15c1cdf69f2aae55fd7a0aca3 RNDC reconfiguration in `doth` system test takes 30-60 second and `dig` invocations fail with "connection refused" on OpenIndiana (but not on Solaris 11.4). Affects `doth` tests "checkin...Even with 2e5f9a0df5e0a8a15c1cdf69f2aae55fd7a0aca3 RNDC reconfiguration in `doth` system test takes 30-60 second and `dig` invocations fail with "connection refused" on OpenIndiana (but not on Solaris 11.4). Affects `doth` tests "checking DoT query after a reconfiguration" and "checking DoH query (POST) after a reconfiguration".
Keep `named`s from `doth` system test running and issue `../../../bin/rndc/rndc -c common/rndc.conf -p 5312 -s 10.53.0.4 reconfig` command:
```
...
11-Jan-2022 16:43:49.938 calling free_rbtdb(.)
11-Jan-2022 16:43:49.938 done free_rbtdb(.)
```
Only after 30 seconds (sometimes close to 60 seconds) `named` is ready:
```
11-Jan-2022 16:44:19.082 listening on IPv4 interface lo0, 10.53.0.4#5301
11-Jan-2022 16:44:19.083 listening on IPv4 interface lo0, 10.53.0.4#5303
```
Otherwise, `../../../bin/dig/dig +tls +noadd +nosea +nostat +noquest +nocmd -p 5301 @10.53.0.4 example SOA` fails with:
```
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
```
CPU utilization of `named` looks sub 1% during the reconfiguration.Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2497Add counters for DoH queries2023-12-12T11:00:33ZVicky Riskvicky@isc.orgAdd counters for DoH queriesSince you can support DoH in addition to Do53 on the same BIND instance, it would be really nice to have some way to tell how much DoH traffic you are getting.
- [ ] Add some metric that enables the operator to tell specifically how mu...Since you can support DoH in addition to Do53 on the same BIND instance, it would be really nice to have some way to tell how much DoH traffic you are getting.
- [ ] Add some metric that enables the operator to tell specifically how much DoH traffic they are receiving.
- [ ] Please be sure to document this metric in the ARM and explain what it is measuring as specifically as possible (because we have a problem in general with not having good enough documentation of our metrics).
- [ ] Also, check to ensure that we are updating the existing counters for TCP v4 and TCP v6 queries with the DoH queries (I am told we are not entirely confident that these are always updated for DoH queries in 9.17.10)Not planned