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. <\/p>\n
The release of BIND 9.18.0 is notable for implementing support for technologies such as \u2018DNS over HTTPS\u2019 (DoH, DNS over HTTPS) and DNS over TLS (DoT, DNS over TLS), as well as the XoT (XFR-over-TLS) mechanism for secure transfer of DNS zone content between servers (supporting both zone transfer and reception via XoT). With appropriate configurations, 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 \u2018+tls\u2019 flag. <\/p>\n
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. <\/p>\n
Processing requests using DoH and DoT is enabled by adding the \u2018http\u2019 and \u2018tls\u2019 options in the listen-on directive. To support unencrypted DNS-over-HTTP in the settings, \u2018tls none\u2019 should be specified. Keys are defined in the \u2018tls\u2019 section. Standard network ports 853 for DoT, 443 for DoH, and 80 for DNS-over-HTTP can be overridden using the tls-port, https-port, and http-port parameters. For example: <\/p>\n
tls local-tls { key-file \u2018\/path\/to\/priv_key.pem\u2019; cert-file \u2018\/path\/to\/cert_chain.pem\u2019; }; http local-http-server { endpoints { \u2018\/dns-query\u2019; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
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. <\/p>\n
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. <\/p>\n
Among the drawbacks that can be mitigated by disabling DoH\/DoT support or relocating encryption to another server, the overall complexity of the codebase stands out \u2014 an embedded HTTP server and TLS library have been added, which could potentially contain vulnerabilities and act as additional attack vectors. Also, using DoH increases traffic. <\/p>\n
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<\/a> 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<\/a> 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. <\/p>\n DNS over TLS differs from DNS over HTTPS by using the standard DNS protocol (typically using network port 853), encapsulated in an encrypted communication channel established using TLS with host validation through TLS\/SSL certificates signed by a certificate authority. The existing DNSSEC standard uses encryption only for client and server authentication but does not protect traffic from interception nor guarantee the confidentiality of queries. <\/p>\n Some other innovations include: <\/p>\n\n