The developers of the BIND DNS server announced the addition of server-side support for DNS over HTTPS (DoH, DNS over HTTPS) and DNS over TLS (DoT, DNS over TLS) technologies, as well as the XFR-over-TLS mechanism for secure transferring the contents of DNS zones between servers. DoH is available for testing in release 9.17, and support for DoT has been present since release 9.17.10. Once stabilized, DoT and DoH support will be backported to the 9.17.7 stable branch.
The implementation of the HTTP / 2 protocol used in DoH is based on the use of the nghttp2 library, which is included in the assembly dependencies (in the future, the library is planned to be transferred to the list of optional dependencies). Both encrypted (TLS) and unencrypted connections over HTTP/2 are supported. With appropriate settings, a single named process can now serve not only traditional DNS requests, but also requests sent using DoH (DNS-over-HTTPS) and DoT (DNS-over-TLS). HTTPS support on the client side (dig) is not implemented yet. XFR-over-TLS support is available for both incoming and outgoing requests.
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;}; }
Of the features of the implementation of DoH in BIND, integration as a common transport is noted, which can be used not only to process client requests to the resolver, but also when exchanging data between servers, when transferring zones by an authoritative DNS server, and when processing any requests supported by other DNS transports .
Another feature is the possibility of transferring encryption operations for TLS to another server, 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 forwarding layer in the internal network, on the basis of which encryption can be organized on another server. On a remote server, nginx can be used to generate TLS traffic, similar to how HTTPS binding is organized for sites.
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.
Source: opennet.ru