The developers of the BIND DNS server have announced the addition of server support for DNS over HTTPS (DoH) and DNS over TLS (DoT) in the experimental branch 9.17, along with the XFR-over-TLS mechanism for securely transferring DNS zone content between servers. DoH is available for testing in release 9.17.10, while DoT support has been included since release 9.17.7. After stabilization, support for DoT and DoH will be backported to the stable branch 9.16. <\/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 build dependencies (the library is planned to be moved to optional dependencies in the future). Both encrypted (TLS) and unencrypted connections over HTTP\/2 are supported. With the appropriate settings, a single named process can now handle not only traditional DNS queries but also requests made using DoH (DNS-over-HTTPS) and DoT (DNS-over-TLS). Client-side HTTPS support (dig) is not yet implemented, and XFR-over-TLS support is available for both incoming and outgoing requests. <\/p>\n
Request processing using DoH and DoT is enabled by adding the http and tls options in the listen-on directive. To support unencrypted DNS-over-HTTP, the settings should specify 'tls none'. Keys are defined in the 'tls' section. 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;}; } <\/p>\n
A notable feature of the DoH implementation in BIND is the integration of a common transport that can be used not only for handling client requests to the resolver but also for data exchange between servers, zone transfers from authoritative DNS servers, and processing any requests supported by other DNS transports. <\/p>\n
Another feature is the ability to offload TLS encryption operations to a different server, which may be necessary when TLS certificates are stored on another system (for instance, in infrastructures with web servers) and managed by different personnel. Support for unencrypted DNS-over-HTTP is implemented to simplify debugging and as a level for tunneling within the internal network, based on which encryption can be arranged on another server. Nginx can be used on the offload server for generating TLS traffic, similar to how HTTPS wrapping is organized for websites. <\/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