ProHoster > Blog > Lajmet e internetit > Publikimi i serverit DNS BIND 9.18.0 me mbështetje për DNS-over-TLS dhe DNS-over-HTTPS

Publikimi i serverit DNS BIND 9.18.0 me mbështetje për DNS-over-TLS dhe DNS-over-HTTPS

Pas dy vitesh zhvillimi, konsorciumi ISC paraqiti versionin e parë stabil të degës së re të serverit DNS BIND 9.18. Mbështetja për degën 9.18 do të vazhdojë për tre vjet deri në tremujorin e dytë të vitit 2025 në kuadër të ciklit të zgjeruar të mbështetjes. Mbështetja për degën 9.11 do të përfundojë në mars, ndërsa ajo për degën 9.16 në mes të vitit 2023. Për zhvillimin e funksionaliteteve në versionin e ardhshëm stabil të BIND është formuar një degë eksperimentale BIND 9.19.0.

Lancimi i BIND 9.18.0 është i rëndësishëm për implementimin e mbështetjes për teknologjitë "DNS mbi HTTPS" (DoH, DNS over HTTPS) dhe DNS mbi TLS (DoT, DNS over TLS), si dhe mekanizmin XoT (XFR-over-TLS) për transmetimin e sigurt të përmbajtjes së zoneve DNS midis serverëve (mbështetet si dërgimi ashtu edhe marrja e zonave përmes XoT). Me cilësimet e duhura, një proces named tani mund të trajtojë jo vetëm kërkesat tradicionale DNS, por edhe kërkesat e dërguara nëpërmjet DNS-over-HTTPS dhe DNS-over-TLS. Mbështetje për klientët DNS-over-TLS është e ndërtuar në utilitarin dig, i cili mund të përdoret për dërgimin e kërkesave mbi TLS duke specifikuar flag-un "+tls".

Implementimi i protokollit HTTP/2, të përdorur në DoH, bazohet në përdorimin e bibliotekës nghttp2, e cila është përfshirë në mesin e varësive të ndërtimit opsionale. Sertifikatat për DoH dhe DoT mund të sigurohen nga përdoruesi ose të gjenerohen automatikisht gjatë nisjes.

Trajtimi i kĂ«rkesave duke pĂ«rdorur DoH dhe DoT aktivizohet pĂ«rmes shtimit tĂ« opsioneve "http" dhe "tls" nĂ« direktivĂ«n listen-on. PĂ«r tĂ« mbĂ«shtetur DNS-over-HTTP tĂ« paenkriptuar, cilĂ«simet duhet tĂ« specifikojnĂ« "tls none". ÇelĂ«sat pĂ«rcaktohen nĂ« seksionin "tls". Portat standarde tĂ« rrjetit 853 pĂ«r DoT, 443 pĂ«r DoH dhe 80 pĂ«r DNS-over-HTTP mund tĂ« tejkalohen pĂ«rmes parametrave tls-port, https-port dhe http-port. PĂ«r shembull:

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;}; }

Një nga veçoritë e zbatimit të DoH në BIND është mundësia për të kaluar operacionet e enkriptimit për TLS në një server tjetër, çka mund të nevojitet kur certifikatat TLS ruhen në një sistem tjetër (p.sh., në infrastrukturën e serverëve web) dhe shërbehen nga personel tjetër. Mbështetja për DNS-over-HTTP të paenkriptuar është realizuar për të lehtësuar debugin dhe si një nivel për kalimin në një server tjetër brenda rrjetit (për të kaluar enkriptimin në një server të veçantë). Në serverin e jashtëm për formimin e trafikut TLS mund të përdoret nginx, në përputhje me mënyrën si organizohet mbështetje HTTPS për faqet.

Një veçori tjetër është integrimi i DoH si një transport i përgjithshëm, i cili mund të përdoret jo vetëm për përpunimin e kërkesave të klientëve ndaj rezolverit, por edhe për ndërrimin e të dhënave ndërmjet serverëve, për kalimin e zonave nga serverët autoritarë DNS dhe për përpunimin e çdo kërkese, të mbështetur nga transportet e tjera DNS.

Nga disavantazhet qĂ« mund tĂ« kompensohen me çaktivizimin e ndĂ«rtimit me DoH/DoT ose kalimin e enkriptimit nĂ« njĂ« server tjetĂ«r, dallohet kompleksiteti i pĂ«rgjithshĂ«m i kodit — pĂ«rbĂ«rĂ«sit e rinj pĂ«rfshijnĂ« njĂ« server HTTP tĂ« integruar dhe njĂ« bibliotekĂ« TLS, tĂ« cilat potencialisht mund tĂ« pĂ«rmbajnĂ« vulnerabilitete dhe tĂ« jenĂ« vektorĂ« shtesĂ« pĂ«r sulme. Po ashtu, pĂ«rdorimi i DoH rrit trafikun.

Kujtojmë se DNS-i mbi HTTPS mund të jetë i dobishëm për të shmangur rrjedhjet e informacionit mbi emrat e hosteve të kërkuar përmes serverëve DNS të ofruesve, për të luftuar sulmet MITM dhe për të falsifikuar trafikun DNS (p.sh., kur lidhemi me Wi-Fi publik), për të përballuar bllokimet në nivelin DNS (DNS mbi HTTPS nuk mund të zëvendësojë VPN në fushën e shmangies së bllokimeve, të realizuara në nivelin DPI) ose për të organizuar punën në rastin e pamundësisë për t'u drejtuar direkt në serverët DNS (p.sh., kur punojmë përmes një proksi). Në situatën normale, kërkesat DNS dërgohen drejtpërdrejt në serverët DNS të caktuar në konfigurimin e sistemit, ndërsa në rastin e DNS-it mbi HTTPS, kërkesa për përcaktimin Adresa IP e hostit inkapsulohet në trafik HTTPS dhe dërgohet në një server HTTP, ku rezolvuesi përpunon kërkesat përmes Web API.

"DNS mbi TLS" ndryshon nga "DNS mbi HTTPS" për shkak të përdorimit të protokollit standard DNS (zakonisht përdoret porta rrjetë 853), e cila është e mbështjellë në një kanal të enkriptuar të komunikimit, organizuar përmes protokollit TLS me verifikim të vlefshmërisë së hostit përmes certifikatave TLS/SSL të firmosur nga një qendër besimi. Standardi aktual DNSSEC përdor enkripcion vetëm për autentifikimin e klientit dhe serverit, por nuk mbron trafikun nga kapja dhe nuk garanton konfidencialitetin e kërkesave.

Disa novacione të tjera:

  • Shtohen cilĂ«simet tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer dhe udp-send-buffer pĂ«r tĂ« pĂ«rcaktuar madhĂ«sitĂ« e bufereve tĂ« pĂ«rdorura gjatĂ« dĂ«rgimit dhe marrjes sĂ« kĂ«rkesave pĂ«r TCP dhe UDP. NĂ« serverat e ngarkuar, rritja e bufereve hyrĂ«se do tĂ« ndihmojĂ« nĂ« shmangien e humbjes sĂ« paketave gjatĂ« pikave tĂ« trafikut, ndĂ«rsa zvogĂ«limi do tĂ« ndihmojĂ« nĂ« eliminimin e mbushjes sĂ« memories me kĂ«rkesa tĂ« vjetra.
  • Shtohet njĂ« kategori e re e log-ev tĂ« quajtur «rpz-passthru», e cila lejon regjistrimin e veprimeve tĂ« kalimit tĂ« RPZ (Zona e Politikat e PĂ«rgjigjes).
  • NĂ« seksionin e politikave tĂ« pĂ«rgjigjes Ă«shtĂ« shtuar opsioni «nsdname-wait-recurse», i cili kur Ă«shtĂ« vendosur nĂ« vlerĂ«n «no» aplikon rregullat RPZ NSDNAME vetĂ«m nĂ«se pĂ«r kĂ«rkesĂ«n janĂ« gjetur serverĂ« autoritarĂ« tĂ« pranishĂ«m nĂ« cache; nĂ« tĂ« kundĂ«rt, rregulli RPZ NSDNAME injorohet, por informacioni merret nĂ« sfond dhe aplikohet pĂ«r kĂ«rkesat e ardhshme.
  • PĂ«r regjistrimet me llojet HTTPS dhe SVCB, Ă«shtĂ« realizuar pĂ«rpunimi i seksionit «ADDITIONAL».
  • Shtohen tipet e reja tĂ« rregullave update-policy — krb5-subdomain-self-rhs dhe ms-subdomain-self-rhs, qĂ« lejojnĂ« kufizimin e azhurnimit tĂ« shĂ«nimeve SRV dhe PTR. NĂ« blloqet e update-policy Ă«shtĂ« shtuar gjithashtu mundĂ«sia pĂ«r tĂ« vendosur kufizime tĂ« numrit tĂ« shĂ«nimeve, tĂ« veçanta pĂ«r çdo lloj.
  • NĂ« daljen e utilitarit dig janĂ« shtuar informacionet mbi protokollin e transportit (UDP, TCP, TLS, HTTPS) dhe prefiksat DNS64. PĂ«r qĂ«llime diagnostikuese, nĂ« dig Ă«shtĂ« shtuar mundĂ«sia pĂ«r tĂ« specifikuar njĂ« identifikues tĂ« caktuar tĂ« kĂ«rkesĂ«s (dig +qid=).
  • Shtyhet mbĂ«shtetje pĂ«r bibliotekĂ«n OpenSSL 3.0.
  • PĂ«r tĂ« zgjidhur problemet me fraksionimin IP gjatĂ« procesimit tĂ« mesazheve DNS tĂ« mĂ«dha, tĂ« cilat janĂ« shĂ«nuar nga nisma DNS Flag Day 2020, Ă«shtĂ« hequr kodi nĂ« resolver qĂ« rregullonte madhĂ«sinĂ« e tamponit EDNS nĂ« rast tĂ« mungesĂ«s sĂ« pĂ«rgjigjes ndaj kĂ«rkesĂ«s. MadhĂ«sia e tamponit EDNS tani caktohet konstant (edns-udp-size) pĂ«r tĂ« gjitha kĂ«rkesat qĂ« dalin.
  • Sistemi i ndĂ«rtimit Ă«shtĂ« kaluar pĂ«r tĂ« pĂ«rdorur kombinimin e autoconf, automake dhe libtool.
  • PĂ«rkrahja pĂ«r skedarĂ«t e zonĂ«s nĂ« formatin "map" (masterfile-format map) Ă«shtĂ« ndĂ«rprerĂ«. PĂ«rdoruesve tĂ« kĂ«tij formati kĂ«shillohet tĂ« konvertojnĂ« zonat nĂ« formatin raw me ndihmĂ«n e utilitarit named-compilezone.
  • PĂ«rkrahja pĂ«r driverat e vjetĂ«r DLZ (Dynamically Loadable Zones) Ă«shtĂ« ndĂ«rprerĂ«, ndĂ«rsa janĂ« prezantuar modulat DLZ.
  • PĂ«rkrahja pĂ«r ndĂ«rtimin dhe funksionimin pĂ«r platformĂ«n Windows Ă«shtĂ« ndĂ«rprerĂ«. Dega e fundit qĂ« mund tĂ« instalohet nĂ« Windows mbetet BIND 9.16.

Burimi: opennet.ru

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster