After two years of development, the ISC consortium has released the first stable version of the new significant branch of the DNS server BIND 9.18. Support for the 9.18 branch will continue for three years until Q2 2025 as part of an extended support cycle. Support for the 9.11 branch will end in March, and the 9.16 branch in mid-2023. An experimental branch BIND 9.19.0 has been created to develop features for the next stable version.
The release of BIND 9.18.0 is notable for implementing support for 'DNS over HTTPS' (DoH) and 'DNS over TLS' (DoT), as well as the XoT (XFR-over-TLS) mechanism for secure transfer of DNS zone contents between servers (supporting both sending and receiving zones via XoT). With appropriate configuration, a single named process can now handle not only traditional DNS queries but also queries sent using DNS-over-HTTPS and DNS-over-TLS. Client support for DNS-over-TLS is built into the dig utility, which can be used to send requests over TLS by specifying the '+tls' flag.
The implementation of the HTTP/2 protocol used in DoH is based on the use of the nghttp2 library, which is included among the optional build dependencies. Certificates for DoH and DoT can be provided by the user or generated automatically at startup.
Request handling using DoH and DoT is enabled by adding 'http' and 'tls' options in the listen-on directive. To support unencrypted DNS-over-HTTP in configurations, 'tls none' should be specified. Keys are defined in the 'tls' section. The standard 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 parameters. 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;}; }
One of the features of implementing DoH in BIND is the ability to offload TLS encryption operations to another server. This may be necessary in situations where TLS certificates are stored on a different system (for instance, in infrastructure with web servers) and are managed by other personnel. Support for unencrypted DNS-over-HTTP has been implemented for debugging simplicity and as a means to forward requests to another server within the internal network (for offloading encryption to a separate server). Nginx can be used on the external server to generate TLS traffic, similar to how HTTPS binding is organized for websites.
Another feature is the integration of DoH as a general transport that can be used not only for processing client requests to the resolver but also for data exchange between servers, for zone transfers by authoritative DNS servers, and for handling any requests supported by other DNS transports.
Among the drawbacks that can be mitigated by disabling the DoH/DoT build or offloading encryption to another server is the overall complexity of the codebase — it now includes a built-in HTTP server and TLS library, which could potentially contain vulnerabilities and serve as additional attack vectors. Additionally, using DoH increases traffic.
It's worth noting that DNS-over-HTTPS can be beneficial to prevent leaks of information about queried hostnames through provider DNS servers, combat MITM attacks and DNS traffic spoofing (for example, when connecting to public Wi-Fi), and to counter DNS-level blocks (DNS-over-HTTPS cannot replace VPN in the area of bypassing blocks implemented at the DPI level) or for enabling functionality when direct access to DNS servers is impossible (for instance, while working through a proxy). In a typical situation, DNS queries are directly sent to designated DNS servers configured in the system, but in the case of DNS-over-HTTPS, the hostname request is encapsulated in HTTPS traffic and sent to an HTTP server, where the resolver processes requests via the Web API. an IP address The difference between 'DNS over TLS' and 'DNS over HTTPS' lies in the use of the standard DNS protocol (typically using network port 853), wrapped in an encrypted communication channel established by the TLS protocol, with host validity verified through TLS/SSL certificates issued by a certification authority. The existing DNSSEC standard uses encryption solely for client and server authentication but does not protect traffic from interception and does not ensure the confidentiality of queries.
Developers of the BIND DNS server reported the addition of server support for 'DNS over HTTPS' (DoH) and 'DNS over TLS' (DoT) technologies in the experimental branch 9.17, as well as.
Some other innovations include:
- Settings for tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer, and udp-send-buffer have been added to specify the sizes of buffers used for sending and receiving requests over TCP and UDP. On heavily loaded servers, increasing incoming buffers will help avoid packet drops during peak traffic, while decreasing them will help clear memory from old requests.
- A new log category "rpz-passthru" has been added, allowing for separate logging of RPZ (Response Policy Zones) passthru actions.
- In the response-policy section, the option "nsdname-wait-recurse" has been added, which, when set to "no," ensures that RPZ NSDNAME rules are only applied if authoritative name servers present in the cache are found for the request; otherwise, the RPZ NSDNAME rule is ignored, but information is extracted in the background and applied to subsequent requests.
- For records with types HTTPS and SVCB, processing of the "ADDITIONAL" section has been implemented.
- Custom update-policy rule types — krb5-subdomain-self-rhs and ms-subdomain-self-rhs have been added, allowing for restrictions on updating SRV and PTR records. The update-policy blocks also now include the ability to set limits on the number of records, specific to each type.
- The dig utility output has been enhanced to include information on the transport protocol (UDP, TCP, TLS, HTTPS) and DNS64 prefixes. For debugging purposes, a specific query identifier can now be specified in dig (dig +qid=).
- Support for OpenSSL 3.0 has been added.
- To address issues with IP fragmentation when processing large DNS messages, as designated by the DNS Flag Day 2020 initiative, the resolver has removed the code that adjusted the EDNS buffer size in the absence of a response to a query. The EDNS buffer size is now set to a constant (edns-udp-size) for all outgoing requests.
- The build system has transitioned to using a combination of autoconf, automake, and libtool.
- Support for zone files in 'map' format (masterfile-format map) has been discontinued. Users of this format are recommended to convert zones to raw format using the named-compilezone utility.
- Support for old DLZ (Dynamically Loadable Zones) drivers has been discontinued, replaced by DLZ modules.
- Support for building and running on the Windows platform has been discontinued. The last branch available for installation on Windows remains BIND 9.16.
Source: opennet.ru
