Inanunsyo ng mga developer ng BIND DNS server ang pagdaragdag ng suporta sa server para sa DNS over HTTPS (DoH, DNS over HTTPS) at DNS over TLS (DoT, DNS over TLS) na teknolohiya, pati na rin ang XFR-over-TLS na mekanismo para sa secure paglilipat ng mga nilalaman ng mga DNS zone sa pagitan ng mga server. Available ang DoH para sa pagsubok sa release 9.17, at ang suporta ng DoT ay naroroon na mula noong release 9.17.10. Pagkatapos ng stabilization, ang suporta ng DoT at DoH ay ibabalik sa stable 9.17.7 branch.
Ang pagpapatupad ng HTTP/2 protocol na ginamit sa DoH ay batay sa paggamit ng nghttp2 library, na kasama sa mga assembly dependencies (sa hinaharap, ang library ay binalak na ilipat sa bilang ng mga opsyonal na dependency). Parehong sinusuportahan ang naka-encrypt (TLS) at hindi naka-encrypt na HTTP/2 na koneksyon. Gamit ang mga naaangkop na setting, ang nag-iisang pinangalanang proseso ay maaari na ngayong maghatid hindi lamang sa mga tradisyonal na DNS query, kundi pati na rin sa mga query na ipinadala gamit ang DoH (DNS-over-HTTPS) at DoT (DNS-over-TLS). Hindi pa ipinapatupad ang suporta sa HTTPS sa panig ng kliyente (dig). Ang suporta sa XFR-over-TLS ay magagamit para sa parehong papasok at papalabas na mga kahilingan.
Ang pagpoproseso ng kahilingan gamit ang DoH at DoT ay pinagana sa pamamagitan ng pagdaragdag ng mga opsyon sa http at tls sa direktiba sa pakikinig. Upang suportahan ang hindi naka-encrypt na DNS-over-HTTP, dapat mong tukuyin ang "tls none" sa mga setting. Ang mga susi ay tinukoy sa seksyong "tls". Ang mga default na network port na 853 para sa DoT, 443 para sa DoH at 80 para sa DNS-over-HTTP ay maaaring ma-override sa pamamagitan ng tls-port, https-port at http-port na mga parameter. Halimbawa: tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; mga opsyon { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
Kabilang sa mga tampok ng pagpapatupad ng DoH sa BIND, ang integration ay kilala bilang isang pangkalahatang transportasyon, na maaaring gamitin hindi lamang upang iproseso ang mga kahilingan ng kliyente sa solver, kundi pati na rin kapag nagpapalitan ng data sa pagitan ng mga server, kapag naglilipat ng mga zone ng isang awtoritatibong DNS server, at kapag pinoproseso ang anumang mga kahilingan na sinusuportahan ng iba pang mga DNS transport.
Ang isa pang tampok ay ang kakayahang ilipat ang mga pagpapatakbo ng pag-encrypt para sa TLS sa isa pang server, na maaaring kailanganin sa mga kondisyon kung saan ang mga TLS certificate ay nakaimbak sa ibang system (halimbawa, sa isang imprastraktura na may mga web server) at pinapanatili ng ibang mga tauhan. Ang suporta para sa hindi naka-encrypt na DNS-over-HTTP ay ipinapatupad upang pasimplehin ang pag-debug at bilang isang layer para sa pagpapasa sa panloob na network, batay sa kung aling pag-encrypt ay maaaring isaayos sa isa pang server. Sa isang malayuang server, ang nginx ay maaaring gamitin upang makabuo ng trapiko ng TLS, katulad ng kung paano nakaayos ang HTTPS binding para sa mga website.
Alalahanin natin na ang DNS-over-HTTPS ay maaaring maging kapaki-pakinabang para sa pagpigil sa mga paglabas ng impormasyon tungkol sa hinihiling na mga pangalan ng host sa pamamagitan ng mga DNS server ng mga provider, paglaban sa mga pag-atake ng MITM at panggagaya ng trapiko ng DNS (halimbawa, kapag kumokonekta sa pampublikong Wi-Fi), pag-counter. pag-block sa antas ng DNS (Hindi maaaring palitan ng DNS-over-HTTPS ang isang VPN sa pag-bypass ng pagharang na ipinatupad sa antas ng DPI) o para sa pag-aayos ng trabaho kapag imposibleng direktang ma-access ang mga DNS server (halimbawa, kapag nagtatrabaho sa pamamagitan ng isang proxy). Kung sa isang normal na sitwasyon, ang mga kahilingan ng DNS ay direktang ipinadala sa mga DNS server na tinukoy sa pagsasaayos ng system, kung gayon sa kaso ng DNS-over-HTTPS ang kahilingan upang matukoy ang host IP address ay naka-encapsulated sa trapiko ng HTTPS at ipinadala sa HTTP server, kung saan pinoproseso ng solver ang mga kahilingan sa pamamagitan ng Web API.
Ang βDNS over TLSβ ay naiiba sa βDNS over HTTPSβ sa paggamit ng karaniwang DNS protocol (network port 853 ang kadalasang ginagamit), na nakabalot sa isang naka-encrypt na channel ng komunikasyon na nakaayos gamit ang TLS protocol na may host validity checking sa pamamagitan ng TLS/SSL certificates certified ng isang awtoridad sa sertipikasyon. Ang umiiral na pamantayan ng DNSSEC ay gumagamit lamang ng pag-encrypt upang patotohanan ang kliyente at server, ngunit hindi pinoprotektahan ang trapiko mula sa pagharang at hindi ginagarantiyahan ang pagiging kumpidensyal ng mga kahilingan.
Pinagmulan: opennet.ru