The BIND DNS server developers unveiled several days ago joining the experimental branch 9.17, the implementation of support of server for technologies DNS over HTTPS (DoH, DNS over HTTPS) and DNS over TLS (DoT, DNS over TLS), as well as XFR.
The implementation of the HTTP / 2 protocol used in DoH is based on the use of the nghttp2 library, which is included in the build dependencies (in the future it is planned to transfer the library to the optional dependencies).
With proper configuration, a single named process can now service not only traditional DNS requests, but also requests sent using DoH (DNS over HTTPS) and DoT (DNS over TLS).
HTTPS client-side support (dig) is not yet implemented, while XFR-over-TLS support is available for incoming and outgoing requests.
Processing requests using DoH and DoT it is enabled by adding the http and tls options to the listen-on directive. To support DNS over HTTP unencrypted, you must specify "tls none" in the configuration. 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 through the tls-port, https-port, and http-port parameters.
Among the features of the DoH implementation in BIND, it is noted that it is possible to transfer encryption operations for TLS to another server, This may be necessary in conditions where the storage of TLS certificates is done on another system (for example, in an infrastructure with web servers) and is attended by other personnel.
Support for DNS over HTTP unencrypted is implemented to simplify debugging and as a layer for forwarding on the internal network, on the basis of which encryption can be arranged on another server. On a remote server, nginx can be used to generate TLS traffic, by analogy with the way HTTPS binding is organized for sites.
Another feature is the integration of DoH as a general transport, which can be used not only to process client requests to the resolver, but also when exchanging data between servers, transferring zones using an authoritative DNS server, and processing any requests supported by other DNS transports.
Among the shortcomings that can be made up for by disabling compilation with DoH / DoT or moving the encryption to another server, the general complication of the codebase is highlighted- A built-in HTTP server and TLS library are added to the composition, which can potentially contain vulnerabilities and act as additional attack vectors. Also, when DoH is used, traffic increases.
You have to remember that DNS-over-HTTPS can be useful to avoid information leaks swork on requested host names through providers' DNS servers, combat MITM attacks and spoof DNS traffic, counteract DNS-level blocking or to organize work in case of impossibility of direct access to DNS servers .
Yes, in a normal situation, DNS requests are sent directly to the DNS servers defined in the system configuration, then, in the case of DNS over HTTPS, the request to determine the IP address of the host it is encapsulated in HTTPS traffic and sent to the HTTP server, in which the resolver processes requests through the web API.
"DNS over TLS" differs from "DNS over HTTPS" by using the standard DNS protocol (typically network port 853 is used) wrapped in an encrypted communication channel organized using the TLS protocol with host validation through TLS certificates / SSL certified by a certification. authority.
Finally, it is mentioned that DoH is available for testing in version 9.17.10 and DoT support has been around since 9.17.7, plus once stabilized, support for DoT and DoH will move to the 9.16 stable branch.