DNS server BIND developers have announced the addition of server support for the technologies 'DNS over HTTPS' (DoH, DNS over HTTPS) and DNS over TLS (DoT, DNS over TLS) into the experimental branch 9.17, as well as the XFR-over-TLS mechanism for secure transfer of DNS zone content between servers. DoH is available for testing in release 9.17.10, and support for DoT has been present since release 9.17.7. Once stabilized, 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 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 via HTTP\/2 are supported. With appropriate settings, a single named process can now handle not only traditional DNS requests but also requests sent using DoH (DNS-over-HTTPS) and DoT (DNS-over-TLS). Client-side HTTPS support (dig) has not yet been implemented. XFR-over-TLS support is available for both incoming and outgoing requests. <\/p>\n
Request handling 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 through the parameters tls-port, https-port, and http-port. 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
Among the features of the DoH implementation in BIND is its integration as a common transport that can be used not only for handling client requests to the resolver, but also for data exchange between servers, when transferring zones by the authoritative DNS server, and for processing any requests supported by other DNS transports. <\/p>\n
Viena no iez\u012bm\u0113m ir iesp\u0113ja p\u0101rnest \u0161ifr\u0113\u0161anas oper\u0101cijas TLS uz citu serveri, kas var b\u016bt nepiecie\u0161ams gad\u012bjumos, kad TLS sertifik\u0101ti tiek glab\u0101ti cit\u0101 sist\u0113m\u0101 (piem\u0113ram, web serveru infrastrukt\u016br\u0101) un to apkalpo cits person\u0101ls. Atbalsts ne\u0161ifr\u0113tam DNS-over-HTTP ir ieviests, lai atvieglotu atk\u013c\u016bdo\u0161anu un kalpotu k\u0101 l\u012bmenis datu p\u0101rraid\u012b\u0161anai iek\u0161\u0113j\u0101 t\u012bkl\u0101, uz kura pamata cit\u0101 server\u012b var organiz\u0113t \u0161ifr\u0113\u0161anu. Nginx var tikt izmantots \u0101r\u0113j\u0101 server\u012b TLS satiksmes veido\u0161anai, l\u012bdz\u012bgi k\u0101 tiek organiz\u0113ta HTTPS saist\u012b\u0161ana vietn\u0113m. <\/p>\n
Atg\u0101din\u0101m, ka DNS-over-HTTPS var b\u016bt noder\u012bgs, lai nov\u0113rstu inform\u0101cijas nopl\u016bdi par vaic\u0101tajiem resursdatoru v\u0101rdiem caur pakalpojumu sniedz\u0113ju DNS serveriem, c\u012bn\u012btos ar MITM uzbrukumiem un DNS datu pl\u016bsmas viltojumiem (piem\u0113ram, piesl\u0113dzoties publiskajam Wi-Fi), k\u0101 ar\u012b pretotos DNS l\u012bme\u0146a blo\u0137\u0113\u0161anai (DNS-over-HTTPS nevar aizst\u0101t VPN<\/a> blo\u0137\u0113\u0161anas apiet meh\u0101nismus, kas \u012bstenoti DPI l\u012bmen\u012b) vai nodro\u0161in\u0101tu darb\u012bbu, ja nav iesp\u0113jams tie\u0161i sazin\u0101ties ar DNS serveriem (piem\u0113ram, darbojoties caur starpniekserveri). Ja parastaj\u0101 situ\u0101cij\u0101 DNS piepras\u012bjumi tie\u0161i tiek s\u016bt\u012bti uz noteiktiem DNS serveriem, kas nor\u0101d\u012bti sist\u0113mas konfigur\u0101cij\u0101, tad DNS-over-HTTPS gad\u012bjum\u0101 piepras\u012bjums noteik\u0161anai IP adreses<\/a> resursdatora v\u0101rdi ir ieliktas HTTPS datu pl\u016bsm\u0101 un nos\u016bt\u012bta uz HTTP serveri, kur resolveris apstr\u0101d\u0101 piepras\u012bjumus caur Web API. <\/p>\n