Pas dy vitesh zhvillimi, konsorciumi ISC ka lëshuar lëshimin e parë të qëndrueshëm të një dege të re kryesore të serverit BIND 9.18 DNS. Mbështetja për degën 9.18 do të ofrohet për tre vjet deri në tremujorin e dytë të vitit 2 si pjesë e një cikli të zgjatur mbështetjeje. Mbështetja për degën 2025 do të përfundojë në mars dhe mbështetja për degën 9.11 në mesin e 9.16. Për të zhvilluar funksionalitetin e versionit të ardhshëm të qëndrueshëm të BIND, është formuar një degë eksperimentale BIND 2023.
Lëshimi i BIND 9.18.0 është i dukshëm për zbatimin e mbështetjes për DNS mbi HTTPS (DoH, DNS mbi HTTPS) dhe DNS mbi TLS (DoT, DNS mbi TLS), si dhe mekanizmin XoT (XFR-mbi-TLS). për transferim të sigurt të përmbajtjes DNS.zona ndërmjet serverëve (mbështeten si zonat dërguese ashtu edhe ato të marrjes nëpërmjet XoT). Me cilësimet e duhura, një proces i vetëm me emër tani mund të shërbejë jo vetëm pyetje tradicionale DNS, por edhe pyetje të dërguara duke përdorur DNS-mbi-HTTPS dhe DNS-mbi-TLS. Mbështetja e klientit për DNS-over-TLS është e integruar në programin dig, i cili mund të përdoret për të dërguar kërkesa përmes TLS kur specifikohet flamuri "+tls".
Zbatimi i protokollit HTTP/2 i përdorur në DoH bazohet në përdorimin e bibliotekës nghttp2, e cila përfshihet si një varësi opsionale e montimit. Certifikatat për DoH dhe DoT mund të sigurohen nga përdoruesi ose të gjenerohen automatikisht në kohën e fillimit.
Përpunimi i kërkesave duke përdorur DoH dhe DoT aktivizohet duke shtuar opsionet "http" dhe "tls" në direktivën e dëgjimit. Për të mbështetur DNS-mbi-HTTP të pakriptuar, duhet të specifikoni "tls none" në cilësimet. Çelësat përcaktohen në seksionin "tls". Portat e paracaktuar të rrjetit 853 për DoT, 443 për DoH dhe 80 për DNS-mbi-HTTP mund të anashkalohen përmes parametrave tls-port, https-port dhe http-port. Për shembull:
tls local-tls { key-file "/path/to/priv_key.pem"; cert-skedar "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; opsionet { https-port 443; porta e dëgjimit 443 tls local-tls http myserver {any;}; }
Një nga veçoritë e zbatimit të DoH në BIND është aftësia për të zhvendosur operacionet e enkriptimit për TLS në një server tjetër, i cili mund të jetë i nevojshëm në kushtet kur certifikatat TLS ruhen në një sistem tjetër (për shembull, në një infrastrukturë me serverë ueb) dhe mirëmbahen. nga personeli tjetër. Mbështetja për DNS-mbi-HTTP të pakriptuar zbatohet për të thjeshtuar korrigjimin dhe si një shtresë për përcjelljen në një server tjetër në rrjetin e brendshëm (për zhvendosjen e kriptimit në një server të veçantë). Në një server të largët, nginx mund të përdoret për të gjeneruar trafik TLS, ngjashëm me mënyrën se si organizohet lidhja HTTPS për faqet e internetit.
Një veçori tjetër është integrimi i DoH si një transport i përgjithshëm që mund të përdoret jo vetëm për të trajtuar kërkesat e klientit ndaj zgjidhësit, por edhe kur komunikoni midis serverëve, kur transferoni zona nga një server autoritar DNS dhe kur përpunoni çdo pyetje të mbështetur nga DNS të tjera transportet.
Ndër mangësitë që mund të kompensohen duke çaktivizuar ndërtimin me DoH/DoT ose duke lëvizur enkriptimin në një server tjetër, spikat ndërlikimi i përgjithshëm i bazës së kodit - shtohet një server HTTP i integruar dhe një bibliotekë TLS, e cila mund të përmbajë potencialisht dobësi. dhe veprojnë si vektorë shtesë të sulmit. Gjithashtu, kur përdorni DoH, trafiku rritet.
Le të kujtojmë se DNS-mbi-HTTPS mund të jetë i dobishëm për parandalimin e rrjedhjeve të informacionit në lidhje me emrat e kërkuar të pritësve përmes serverëve DNS të ofruesve, për të luftuar sulmet MITM dhe mashtrimin e trafikut DNS (për shembull, kur lidheni me Wi-Fi publik), kundërvënien bllokimi në nivel DNS (DNS-mbi-HTTPS nuk mund të zëvendësojë një VPN në anashkalimin e bllokimit të zbatuar në nivelin DPI) ose për organizimin e punës kur është e pamundur të aksesosh drejtpërdrejt serverët DNS (për shembull, kur punoni përmes një përfaqësuesi). Nëse në një situatë normale kërkesat DNS dërgohen drejtpërdrejt te serverët DNS të përcaktuar në konfigurimin e sistemit, atëherë në rastin e DNS-mbi-HTTPS kërkesa për të përcaktuar adresën IP të hostit inkapsulohet në trafikun HTTPS dhe dërgohet në serverin HTTP, ku zgjidhësi përpunon kërkesat nëpërmjet Web API.
"DNS mbi TLS" ndryshon nga "DNS mbi HTTPS" në përdorimin e protokollit standard DNS (përdoret zakonisht porta e rrjetit 853), e mbështjellë në një kanal komunikimi të koduar të organizuar duke përdorur protokollin TLS me kontrollimin e vlefshmërisë së hostit përmes certifikatave TLS/SSL të certifikuara nga një autoritet certifikues. Standardi ekzistues DNSSEC përdor enkriptimin vetëm për të vërtetuar klientin dhe serverin, por nuk mbron trafikun nga përgjimi dhe nuk garanton konfidencialitetin e kërkesave.
Disa risi të tjera:
- U shtuan cilësimet tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer dhe udp-send-buffer për të vendosur madhësitë e buferëve të përdorur kur dërgoni dhe merrni kërkesa përmes TCP dhe UDP. Në serverët e zënë, rritja e buferëve në hyrje do të ndihmojë në shmangien e rënies së paketave gjatë pikut të trafikut dhe ulja e tyre do të ndihmojë në heqjen e bllokimit të kujtesës me kërkesat e vjetra.
- Është shtuar një kategori e re e regjistrit "rpz-passthru", e cila ju lejon të regjistroni veçmas veprimet e përcjelljes RPZ (Zonat e Politikave të Përgjigjes).
- Në seksionin e politikës së përgjigjes, opsioni "nsdname-prit-recurse" është shtuar, kur vendoset në "jo", rregullat RPZ NSDNAME zbatohen vetëm nëse serverët autoritativë të emrave të pranishëm në cache gjenden për kërkesën, përndryshe Rregulli RPZ NSDNAME shpërfillet, por informacioni merret në sfond dhe zbatohet për kërkesat pasuese.
- Për regjistrimet me lloje HTTPS dhe SVCB, është zbatuar përpunimi i seksionit "SHTESË".
- Llojet e rregullave të politikave të përditësimit të personalizuara të shtuara - krb5-subdomain-self-rhs dhe ms-subdomain-self-rhs, të cilat ju lejojnë të kufizoni përditësimin e të dhënave SRV dhe PTR. Blloqet e politikave të përditësimit shtojnë gjithashtu mundësinë për të vendosur kufizime në numrin e regjistrimeve, individuale për çdo lloj.
- U shtua informacion në lidhje me protokollin e transportit (UDP, TCP, TLS, HTTPS) dhe prefikset DNS64 në daljen e mjetit dig. Për qëllime korrigjimi, dig ka shtuar aftësinë për të specifikuar një identifikues specifik të kërkesës (dig +qid= ).
- Mbështetje e shtuar për bibliotekën OpenSSL 3.0.
- Për të adresuar problemet me fragmentimin e IP-së kur përpunohen mesazhe të mëdha DNS të identifikuara nga Dita e Flamurit DNS 2020, kodi që rregullon madhësinë e buferit EDNS kur nuk ka përgjigje ndaj një kërkese është hequr nga zgjidhësi. Madhësia e buferit EDNS tani është vendosur në konstante (edns-udp-size) për të gjitha kërkesat dalëse.
- Sistemi i ndërtimit është kaluar në përdorimin e një kombinimi të autoconf, automake dhe libtool.
- Mbështetja për skedarët e zonës në formatin "map" (masterfile-format map) është ndërprerë. Përdoruesve të këtij formati rekomandohet të konvertojnë zonat në format të papërpunuar duke përdorur mjetin e emërtuar-compilezone.
- Mbështetja për drejtuesit e vjetër DLZ (Zonat e ngarkueshme dinamike) është ndërprerë, duke u zëvendësuar nga modulet DLZ.
- Mbështetja e ndërtimit dhe ekzekutimit për platformën Windows është ndërprerë. Dega e fundit që mund të instalohet në Windows është BIND 9.16.
Burimi: opennet.ru