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

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

Pas dy vjetësh zhvillim, konsorciumi ISC prezantoi versionin e parë stabil të degës së re të serverit DNS BIND 9.18. Mbështetje për degën 9.18 do të ofrohet për tre vjet deri në tremujorin e dytë të vitit 2025 si pjesë e një cikli të zgjeruar mbështetjeje. Mbështetje për degën 9.11 do të ndalojë në mars, ndërsa për degën 9.16 në mes të vitit 2023. Për zhvillimin e funksionaliteteve të versionit tjetër stabil të BIND është formuar një degë eksperimentale BIND 9.19.0.

Lëshimi 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 mekanizmit XoT (XFR-over-TLS) për transferimin e sigurt të përmbajtjes së zonave DNS midis serverëve (mbështetet si dërgimi ashtu edhe pranimi i zonave përmes XoT). Edhe me konfigurimet përkatëse, një proces named tani mund të shërbejë jo vetëm kërkesat tradicionale të DNS, por edhe kërkesat e dërguara duke përdorur DNS-over-HTTPS dhe DNS-over-TLS. Mbështetja për klientët e DNS-over-TLS është e integruar në mjetin dig, i cili mund të përdoret për të dërguar kërkesa përmes TLS duke specifikuar flakën "+tls".

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

Trajtimi i kĂ«rkesave me pĂ«rdorimin e 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Ă« pakriptuar, duhet specifikuar «tls none» nĂ« konfigurime. ÇelĂ«sat pĂ«rcaktohen nĂ« seksionin «tls». Portet standarde rrjetĂ« 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 implementimit të DoH në BIND është mundësia e transferimit të operacioneve të enkriptimit për TLS në një server tjetër, gjë që mund të jetë e nevojshme kur ruajtja e certifikatave TLS bëhet në një sistem tjetër (p.sh., në infrastrukturën me serverë web) dhe menaxhohet nga një personel tjetër. Mbështetja e DNS-over-HTTP të pa enkriptuar është realizuar për të thjeshtuar debugging-un dhe si një nivel për kalimin në një server tjetër brenda rrjetit të brendshëm (për transferimin e enkriptimit në një server të veçantë). Në serverin e veçantë për formimin e trafikut TLS mund të përdoret nginx, ngjashëm me mënyrën si organizohet mbështjellja HTTPS për faqet web.

Një veçori tjetër është integrimi i DoH si një transport i zakonshëm, i cili mund të përdoret jo vetëm për përpunimin e kërkesave të klientëve ndaj rezolverit, por edhe gjatë shkëmbimit të të dhënave midis serverëve, gjatë transferimit të zona nga serveri DNS autoritativ dhe gjatë përpunimit të çdo kërkese mbështetur nga transportet e tjera DNS.

Nga disavantazhet që mund të kompensohen duke çaktivizuar ndërtimin me DoH/DoT ose duke transferuar enkriptimin në një server tjetër, spikat komplikuar e përgjithshme e kodit - në përbërje shtohet një server HTTP i integruar dhe një bibliotekë TLS, të cilat potencialisht mund të përmbajnë dobësi dhe të shërbejnë si vektora shtesë për sulme. Gjithashtu, përdorimi i DoH rrit trafikun.

Kujtojmë se DNS-over-HTTPS mund të jetë e dobishme për të eliminuar rrjedhjen e informacioneve rreth emrave të hosteve që kërkohen përmes serverëve DNS të ofruesve, për të luftuar sulmet MITM dhe ndërrimin e trafikut DNS (për shembull, gjatë lidhjes me Wi-Fi publike), dhe për t'u përballur me bllokimet në nivel DNS (DNS-over-HTTPS nuk mund të zëvendësojë) VPN në fushën e anashkalimit të bllokimeve që zbatohen në nivelin DPI) ose për të organizuar funksionimin në rastin e pamundësisë për t'u drejtuar drejpërdrejt te serverët DNS (p.sh., kur punoni përmes një prokse). Në një situatë normale, kërkesat DNS dërgohen drejtpërdrejt te serverët DNS të caktuar në konfigurimin e sistemit, ndërsa në rastin e DNS-over-HTTPS, kërkesa për përcaktimin adresat IP e hostit inkorporohet në trafikun HTTPS dhe dërgohet në serverin HTTP, në të cilin rezolvuesi përpunon kërkesat përmes Web API.

«DNS over TLS» ndryshon nga «DNS over HTTPS» përmes përdorimit të protokollit standard DNS (zakonisht përdoret porta rrjetit 853), i futur në një kanal të enkriptuar të komunikimit, e organizuar përmes protokollit TLS me verifikimin e vlefshmërisë së hostit përmes certifikatave TLS/SSL, të verifikuara nga një autoritet certifikimi. Standarti ekzistues DNSSEC përdor enkriptimin vetëm për autentifikimin e klientit dhe serverit, por nuk mbron trafikun nga kapja dhe nuk garanton privatësinë e kërkesave.

Disa risitë e tjera:

  • JanĂ« shtuar parametrat tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer dhe udp-send-buffer pĂ«r tĂ« caktuar madhĂ«sitĂ« e bufferave qĂ« pĂ«rdoren gjatĂ« dĂ«rgimit dhe pranimit tĂ« kĂ«rkesave pĂ«r TCP dhe UDP. NĂ« serverat e ngarkuar, rritja e bufferave tĂ« hyrjes do tĂ« ndihmojĂ« nĂ« shmangien e humbjes sĂ« paketave nĂ« momentet e trafikĂ«ve maksimale, ndĂ«rsa ulja do tĂ« ndihmojĂ« nĂ« shpĂ«timin e memorjes nga kĂ«rkesat e vjetra.
  • ËshtĂ« shtuar njĂ« kategori e re log-eve "rpz-passthru", e cila lejon tĂ« regjistrohen veprimet e kalimit tĂ« RPZ (Response Policy Zones) veçmas.
  • NĂ« seksionin response-policy Ă«shtĂ« shtuar opsioni "nsdname-wait-recurse", i cili, kur vendoset nĂ« vlerĂ«n "jo", e bĂ«n rregullin RPZ NSDNAME tĂ« aplikohet vetĂ«m nĂ«se pĂ«r kĂ«rkesĂ«n janĂ« gjetur serverĂ« tĂ« autoritetit tĂ« emrave nĂ« cache, pĂ«rndryshe rregulli RPZ NSDNAME injorohet, por informacioni nxirret nĂ« sfond dhe aplikohet pĂ«r kĂ«rkesat e mĂ«vonshme.
  • PĂ«r shĂ«nimet me llojet HTTPS dhe SVCB Ă«shtĂ« realizuar pĂ«rpunimi i seksionit "ADDITIONAL".
  • JanĂ« shtuar lloje tĂ« personalizuara tĂ« rregullave update-policy — krb5-subdomain-self-rhs dhe ms-subdomain-self-rhs, qĂ« lejojnĂ« kufizimin e pĂ«rditĂ«simit tĂ« shĂ«nimeve SRV dhe PTR. NĂ« blloqet 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 tĂ« dhĂ«na mbi protokollin e transportit (UDP, TCP, TLS, HTTPS) dhe prefixet DNS64. PĂ«r qĂ«llime tĂ« defektit, nĂ« dig Ă«shtĂ« shtuar mundĂ«sia pĂ«r tĂ« specifikuar njĂ« identifikues tĂ« veçantĂ« tĂ« kĂ«rkesĂ«s (dig +qid=<num>).
  • ËshtĂ« shtetur mbĂ«shtetje pĂ«r bibliotekĂ«n OpenSSL 3.0.
  • PĂ«r tĂ« zgjidhur problemet me fraksionimin IP gjatĂ« pĂ«rpunimit tĂ« mesazheve DNS me madhĂ«si tĂ« madhe, tĂ« cilat u njoftuan nĂ« iniciativĂ«n DNS Flag Day 2020, kodi qĂ« pĂ«rmbante rregullimin e madhĂ«sisĂ« sĂ« buferit EDNS nĂ« rastet e mungesĂ«s sĂ« pĂ«rgjigjes nga kĂ«rkesa Ă«shtĂ« eliminuar nga resolveri. MadhĂ«sia e buferit EDNS tani vendoset si e pandryshueshme (edns-udp-size) pĂ«r tĂ« gjitha kĂ«rkesat dalĂ«se.
  • Sistemi i ndĂ«rtimit Ă«shtĂ« kaluar nĂ« pĂ«rdorimin e paketĂ«s nga autoconf, automake dhe libtool.
  • MbĂ«shtetja pĂ«r skedarĂ«t e zonĂ«s nĂ« formatin «map» (masterfile-format map) Ă«shtĂ« ndaluar. PĂ«rdoruesve tĂ« kĂ«tij formati u rekomandohet tĂ« konvertojnĂ« zonat nĂ« formatin raw pĂ«rmes utilitarit named-compilezone.
  • MbĂ«shtetja pĂ«r drejtuesit e vjetĂ«r DLZ (Zona e Ngarkueshme Dinamikisht) Ă«shtĂ« ndaluar, dhe nĂ« vend tĂ« tyre, janĂ« futur modulet DLZ.
  • MbĂ«shtetja pĂ«r ndĂ«rtimin dhe ekzekutimin pĂ«r platformĂ«n Windows Ă«shtĂ« ndaluar. DegĂ«n mĂ« tĂ« fundit qĂ« mund tĂ« instalohet nĂ« Windows mbetet BIND 9.16.

Burimi: opennet.ru

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster