After two years of development, the ISC has released the first stable release of a major new branch of the BIND 9.18 DNS server. Branch 9.18 will be supported for three years until Q2 2025 as part of an extended maintenance cycle. Support for the 9.11 branch will end in March, and the 9.16 branch in mid-2023. An experimental branch of BIND 9.19.0 has been formed to develop the functionality of the next stable version of BIND.
The release of BIND 9.18.0 is notable for the implementation of support for DNS over HTTPS (DoH, DNS over HTTPS) and DNS over TLS (DoT, DNS over TLS) technologies, as well as the XoT mechanism (XFR-over-TLS) for secure transmission of DNS-over-TLS content. zones between servers (both sending and receiving zones via XoT is supported). With appropriate settings, a single named process can now serve not only traditional DNS requests, but also requests sent using DNS-over-HTTPS and DNS-over-TLS. DNS-over-TLS client support is built into the dig utility, which can be used to send queries over TLS when the "+tls" flag is specified.
The implementation of the HTTP/2 protocol used in DoH is based on the use of the nghttp2 library, which is included in the optional build dependencies. Certificates for DoH and DoT can be provided by the user or generated automatically during startup.
Processing requests using DoH and DoT is enabled by adding the "http" and "tls" options to the listen-on directive. To support unencrypted DNS-over-HTTP, you must specify "tls none" in the settings. The keys are defined in the "tls" section. The default network ports 853 for DoT, 443 for DoH, and 80 for DNS-over-HTTP can be overridden via the tls-port, https-port, and http-port options. For example:
tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
Among the features of the implementation of DoH in BIND, the possibility of transferring encryption operations for TLS to another server is noted, which may be necessary in conditions where TLS certificates are stored on another system (for example, in an infrastructure with web servers) and serviced by other personnel. Support for unencrypted DNS-over-HTTP is implemented to simplify debugging and as a layer for forwarding to another server on the internal network (to move encryption to a separate server). On a remote server, nginx can be used to generate TLS traffic, similar to how HTTPS binding is organized for sites.
Another feature is the integration of DoH as a common transport, which can be used not only to process client requests to a resolver, but also in server-to-server communication, zone transfers by an authoritative DNS server, and any queries supported by other DNS transports.
Among the shortcomings that can be compensated by disabling the assembly with DoH / DoT or moving encryption to another server, the general complication of the code base stands out - a built-in HTTP server and a TLS library are added to the composition, which can potentially contain vulnerabilities and act as additional vectors for attacks. Also, when using DoH, traffic increases.
Recall that DNS-over-HTTPS can be useful to prevent leaks of information about the requested host names through the DNS servers of providers, combat MITM attacks and DNS traffic spoofing (for example, when connecting to public Wi-Fi), counter blocking on DNS level (DNS-over-HTTPS cannot replace VPN in the area of ββbypassing blocking implemented at the DPI level) or to organize work if it is impossible to directly access DNS servers (for example, when working through a proxy). While normally DNS requests are sent directly to the DNS servers defined in the system configuration, in the case of DNS-over-HTTPS, the request to determine the host IP address is encapsulated in HTTPS traffic and sent to the HTTP server, on which the resolver processes requests through web API.
"DNS over TLS" differs from "DNS over HTTPS" by using the standard DNS protocol (network port 853 is usually used), wrapped in an encrypted communication channel organized using the TLS protocol with host validity check through TLS/SSL certificates certified by a certification authority. The current DNSSEC standard uses encryption only to authenticate the client and server, but does not protect traffic from interception and does not guarantee the confidentiality of requests.
Some other innovations:
- Added settings tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer and udp-send-buffer to set buffer sizes used when sending and receiving requests over TCP and UDP. On busy servers, increasing incoming buffers will avoid dropping packets at the time of traffic peaks, and decreasing them will help get rid of memory clogging with old requests.
- A new category of logs "rpz-passthru" has been added, which allows you to separately log RPZ forwarding actions (Response Policy Zones).
- Added "nsdname-wait-recurse" option to response-policy section, when set to "no", RPZ NSDNAME rules are applied only if authoritative nameservers present in the cache are found for the request, otherwise the RPZ NSDNAME rule is ignored, but the information is retrieved in the background and applied to subsequent requests.
- For records with HTTPS and SVCB types, processing of the "ADDITIONAL" section is implemented.
- Added custom update-policy rule types krb5-subdomain-self-rhs and ms-subdomain-self-rhs to restrict updates to SRV and PTR records. In update-policy blocks, the ability to set limits on the number of records, separate for each type, has also been added.
- Added information about the transport protocol (UDP, TCP, TLS, HTTPS) and DNS64 prefixes to the output of the dig utility. For debugging purposes, the ability to specify a specific request ID has been added to dig (dig +qid= ).
- Added support for the OpenSSL 3.0 library.
- To address issues with IP fragmentation when handling large DNS messages, identified by the DNS Flag Day 2020 initiative, code has been removed from the resolver that adjusts the size of the EDNS buffer in the absence of a response to a query. The EDNS buffer size is now set constant (edns-udp-size) for all outgoing requests.
- The build system has been switched to use a bunch of autoconf, automake and libtool.
- Support for zone files in the "map" format (masterfile-format map) has been discontinued. Users of this format are advised to convert zones to raw format using the named-compilezone utility.
- Support has been dropped for the old DLZ (Dynamically Loadable Zones) drivers, which were replaced by DLZ modules.
- Build and run support has been dropped for the Windows platform. The last branch that can be installed on Windows is BIND 9.16.
Source: opennet.ru