Paglabas ng BIND DNS Server 9.18.0 na may suporta para sa DNS-over-TLS at DNS-over-HTTPS

Pagkatapos ng dalawang taon ng pag-unlad, ang ISC consortium ay naglabas ng unang matatag na pagpapalabas ng isang pangunahing bagong sangay ng BIND 9.18 DNS server. Ang suporta para sa branch 9.18 ay ipagkakaloob sa loob ng tatlong taon hanggang sa ika-2 quarter ng 2025 bilang bahagi ng pinalawig na ikot ng suporta. Ang suporta para sa 9.11 branch ay magtatapos sa Marso, at ang suporta para sa 9.16 branch sa kalagitnaan ng 2023. Para bumuo ng functionality ng susunod na stable na bersyon ng BIND, nabuo ang isang experimental branch na BIND 9.19.0.

Ang paglabas ng BIND 9.18.0 ay kapansin-pansin para sa pagpapatupad ng suporta para sa DNS over HTTPS (DoH, DNS over HTTPS) at DNS over TLS (DoT, DNS over TLS), pati na rin ang XoT (XFR-over-TLS) na mekanismo para sa secure na paglilipat ng nilalaman ng DNS. mga zone sa pagitan ng mga server (parehong sinusuportahan ang pagpapadala at pagtanggap ng mga zone sa pamamagitan ng XoT). Gamit ang mga naaangkop na setting, ang nag-iisang pinangalanang proseso ay maaari na ngayong maghatid ng hindi lamang tradisyonal na mga query sa DNS, kundi pati na rin ang mga query na ipinadala gamit ang DNS-over-HTTPS at DNS-over-TLS. Ang suporta ng kliyente para sa DNS-over-TLS ay binuo sa dig utility, na maaaring magamit upang magpadala ng mga kahilingan sa TLS kapag ang "+tls" na flag ay tinukoy.

Ang pagpapatupad ng HTTP/2 protocol na ginamit sa DoH ay batay sa paggamit ng nghttp2 library, na kasama bilang isang opsyonal na dependency sa pagpupulong. Ang mga sertipiko para sa DoH at DoT ay maaaring ibigay ng user o awtomatikong mabuo sa oras ng pagsisimula.

Ang pagpoproseso ng kahilingan gamit ang DoH at DoT ay pinagana sa pamamagitan ng pagdaragdag ng "http" at "tls" na mga opsyon sa listen-on na direktiba. 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;}; }

Ang isa sa mga tampok ng pagpapatupad ng DoH sa BIND ay ang kakayahang ilipat ang mga operasyon ng pag-encrypt para sa TLS sa ibang 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 tauhan. Ang suporta para sa hindi naka-encrypt na DNS-over-HTTP ay ipinatupad upang pasimplehin ang pag-debug at bilang isang layer para sa pagpapasa sa isa pang server sa panloob na network (para sa paglipat ng pag-encrypt sa isang hiwalay na 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.

Ang isa pang tampok ay ang pagsasama ng DoH bilang isang pangkalahatang transportasyon na maaaring magamit hindi lamang upang pangasiwaan ang mga kahilingan ng kliyente sa solver, kundi pati na rin kapag nakikipag-usap sa pagitan ng mga server, kapag naglilipat ng mga zone ng isang awtoritatibong DNS server, at kapag nagpoproseso ng anumang mga query na sinusuportahan ng ibang DNS mga sasakyan.

Kabilang sa mga pagkukulang na maaaring mabayaran sa pamamagitan ng hindi pagpapagana ng build gamit ang DoH/DoT o paglipat ng encryption sa isa pang server, namumukod-tangi ang pangkalahatang komplikasyon ng base ng code - isang built-in na HTTP server at TLS library ang idinagdag, na posibleng maglaman mga kahinaan at kumikilos bilang mga karagdagang vector para sa mga pag-atake. Gayundin, kapag gumagamit ng DoH, tumataas ang trapiko.

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.

Ilang iba pang mga inobasyon:

• Nagdagdag ng mga setting ng tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer at udp-send-buffer para itakda ang mga laki ng buffer na ginagamit kapag nagpapadala at tumatanggap ng mga kahilingan sa TCP at UDP. Sa mga abalang server, ang pagtaas ng mga papasok na buffer ay makakatulong na maiwasan ang mga packet na malaglag sa panahon ng mga peak ng trapiko, at ang pagpapababa sa mga ito ay makakatulong na maalis ang memory clogging sa mga lumang kahilingan.
• Ang isang bagong kategorya ng log na "rpz-passthru" ay idinagdag, na nagbibigay-daan sa iyong hiwalay na mag-log ng mga aksyon sa pagpapasa ng RPZ (Response Policy Zones).
• Sa seksyon ng patakaran sa pagtugon, ang opsyon na "nsdname-wait-recurse" ay idinagdag, kapag itinakda sa "hindi", ang mga panuntunan ng RPZ NSDNAME ay inilalapat lamang kung ang mga authoritative name server na nasa cache ay makikita para sa kahilingan, kung hindi, ang Binabalewala ang panuntunan ng RPZ NSDNAME, ngunit ang impormasyon ay kinukuha sa background at nalalapat sa mga kasunod na kahilingan.
• Para sa mga talaan na may mga uri ng HTTPS at SVCB, ang pagpoproseso ng seksyong “DAGDAG” ay ipinatupad.
• Nagdagdag ng mga uri ng custom na patakaran sa pag-update - krb5-subdomain-self-rhs at ms-subdomain-self-rhs, na nagbibigay-daan sa iyong limitahan ang pag-update ng mga tala ng SRV at PTR. Ang mga bloke ng patakaran sa pag-update ay nagdaragdag din ng kakayahang magtakda ng mga limitasyon sa bilang ng mga tala, indibidwal para sa bawat uri.
• Nagdagdag ng impormasyon tungkol sa transport protocol (UDP, TCP, TLS, HTTPS) at DNS64 prefix sa output ng dig utility. Para sa mga layunin ng pag-debug, idinagdag ng dig ang kakayahang tumukoy ng isang partikular na identifier ng kahilingan (dig +qid= ).
• Nagdagdag ng suporta para sa OpenSSL 3.0 library.
• Upang matugunan ang mga isyu sa fragmentation ng IP kapag nagpoproseso ng malalaking mensahe ng DNS na tinukoy ng DNS Flag Day 2020, ang code na nagsasaayos sa laki ng buffer ng EDNS kapag walang tugon sa isang kahilingan ay inalis mula sa solver. Ang laki ng buffer ng EDNS ay nakatakda na ngayon sa pare-pareho (edns-udp-size) para sa lahat ng papalabas na kahilingan.
• Ang build system ay inilipat sa paggamit ng kumbinasyon ng autoconf, automake at libtool.
• Ang suporta para sa mga zone file sa "mapa" na format (masterfile-format na mapa) ay hindi na ipinagpatuloy. Ang mga gumagamit ng format na ito ay inirerekomenda na i-convert ang mga zone sa raw na format gamit ang pinangalanang-compilezone utility.
• Ang suporta para sa mas lumang mga driver ng DLZ (Dynamically Loadable Zones) ay hindi na ipinagpatuloy, na pinalitan ng mga DLZ module.
• Ang pagbuo at pagpapatakbo ng suporta para sa platform ng Windows ay hindi na ipinagpatuloy. Ang huling sangay na maaaring mai-install sa Windows ay BIND 9.16.

Pinagmulan: opennet.ru