ProHoster > Blogs > interneta ziņas > BIND DNS servera 9.18.0 izlaiÅ”ana ar DNS-over-TLS un DNS-over-HTTPS atbalstu

BIND DNS servera 9.18.0 izlaiŔana ar DNS-over-TLS un DNS-over-HTTPS atbalstu

Pēc divu gadu izstrādes ISC konsorcijs ir izlaidis pirmo stabilo BIND 9.18 DNS servera jaunās filiāles versiju. Atbalsts 9.18.nozarei tiks nodroÅ”ināts trÄ«s gadus lÄ«dz 2.gada 2025.ceturksnim pagarinātā atbalsta cikla ietvaros. Atbalsts filiālei 9.11 beigsies martā, bet filiālei 9.16 ā€“ 2023. gada vidÅ«. Lai attÄ«stÄ«tu nākamās stabilās BIND versijas funkcionalitāti, ir izveidota eksperimentālā filiāle BIND 9.19.0.

BIND 9.18.0 izlaiÅ”ana ir ievērojama ar atbalsta ievieÅ”anu DNS, izmantojot HTTPS (DoH, DNS, izmantojot HTTPS) un DNS, izmantojot TLS (DoT, DNS, izmantojot TLS), kā arÄ« XoT (XFR-over-TLS) mehānismu. droÅ”ai DNS satura pārsÅ«tÄ«Å”anai.zonas starp serveriem (tiek atbalstÄ«tas gan nosÅ«tÄ«Å”anas, gan saņemÅ”anas zonas caur XoT). Ar atbilstoÅ”iem iestatÄ«jumiem viens nosaukts process tagad var apkalpot ne tikai tradicionālos DNS vaicājumus, bet arÄ« vaicājumus, kas nosÅ«tÄ«ti, izmantojot DNS-over-HTTPS un DNS-over-TLS. Klientu atbalsts DNS-over-TLS ir iebÅ«vēts dig utilÄ«tprogrammā, ko var izmantot, lai nosÅ«tÄ«tu pieprasÄ«jumus, izmantojot TLS, kad ir norādÄ«ts karodziņŔ "+tls".

DoH izmantotā HTTP/2 protokola ievieÅ”ana balstās uz nghttp2 bibliotēkas izmantoÅ”anu, kas ir iekļauta kā izvēles montāžas atkarÄ«ba. DoH un DoT sertifikātus var nodroÅ”ināt lietotājs vai Ä£enerēt automātiski startÄ“Å”anas laikā.

PieprasÄ«jumu apstrāde, izmantojot DoH un DoT, ir iespējota, klausÄ«Å”anās direktÄ«vai pievienojot opcijas "http" un "tls". Lai atbalstÄ«tu neÅ”ifrētu DNS-over-HTTP, iestatÄ«jumos jānorāda ā€œtls noneā€. Atslēgas ir definētas sadaļā "tls". Noklusējuma tÄ«kla portus 853 DoT, 443 DoH un 80 DNS-over-HTTP var ignorēt, izmantojot parametrus tls-port, https-port un http-port. Piemēram:

tls local-tls { atslēgas fails "/path/to/priv_key.pem"; cert-fails "/path/to/cert_chain.pem"; }; http local-http-serveris { galapunkti { "/dns-query"; }; }; opcijas { https-port 443; klausÄ«Å”anās ports 443 tls local-tls http myserver {jebkurÅ”;}; }

Viena no DoH ievieÅ”anas iezÄ«mēm BIND ir iespēja pārvietot TLS Å”ifrÄ“Å”anas darbÄ«bas uz citu serveri, kas var bÅ«t nepiecieÅ”ama apstākļos, kad TLS sertifikāti tiek glabāti citā sistēmā (piemēram, infrastruktÅ«rā ar tÄ«mekļa serveriem) un uzturēti. cits personāls. Atbalsts neÅ”ifrētam DNS-over-HTTP tiek ieviests, lai vienkārÅ”otu atkļūdoÅ”anu un kā slānis pārsÅ«tÄ«Å”anai uz citu serveri iekŔējā tÄ«klā (Å”ifrÄ“Å”anas pārvietoÅ”anai uz atseviŔķu serveri). Attālā serverÄ« nginx var izmantot, lai Ä£enerētu TLS trafiku, lÄ«dzÄ«gi kā HTTPS saistÄ«Å”ana tiek organizēta vietnēm.

Vēl viena iezīme ir DoH integrācija kā vispārējs transports, ko var izmantot ne tikai, lai apstrādātu klientu pieprasījumus atrisinātājam, bet arī sazinoties starp serveriem, pārsūtot zonas ar autoritatīvu DNS serveri un apstrādājot jebkurus vaicājumus, kurus atbalsta cits DNS. pārvadājumi.

Starp trÅ«kumiem, ko var kompensēt, atspējojot bÅ«vÄ“Å”anu ar DoH/DoT vai pārceļot Å”ifrÄ“Å”anu uz citu serveri, izceļas vispārējā koda bāzes sarežģītÄ«ba - tiek pievienots iebÅ«vēts HTTP serveris un TLS bibliotēka, kas potenciāli varētu saturēt ievainojamÄ«bas. un darbojas kā papildu uzbrukuma vektori. Turklāt, izmantojot DoH, palielinās satiksme.

Atgādināsim, ka DNS-over-HTTPS var bÅ«t noderÄ«ga, lai novērstu informācijas noplÅ«di par pieprasÄ«tajiem resursdatora nosaukumiem caur pakalpojumu sniedzēju DNS serveriem, cÄ«nÄ«tos ar MITM uzbrukumiem un DNS trafika viltoÅ”anu (piemēram, pieslēdzoties publiskajam Wi-Fi), apkarotu bloÄ·Ä“Å”ana DNS lÄ«menÄ« (DNS-over-HTTPS nevar aizstāt VPN, apejot bloÄ·Ä“Å”anu, kas ieviesta DPI lÄ«menÄ«) vai darba organizÄ“Å”anai, ja nav iespējams tieÅ”i piekļūt DNS serveriem (piemēram, strādājot caur starpniekserveri). Ja normālā situācijā DNS pieprasÄ«jumi tiek tieÅ”i nosÅ«tÄ«ti uz sistēmas konfigurācijā definētajiem DNS serveriem, tad DNS-over-HTTPS gadÄ«jumā pieprasÄ«jums noteikt resursdatora IP adresi tiek iekapsulēts HTTPS trafikā un nosÅ«tÄ«ts uz HTTP serveri, kur atrisinātājs apstrādā pieprasÄ«jumus, izmantojot Web API.

ā€œDNS, izmantojot TLSā€ atŔķiras no ā€œDNS, izmantojot HTTPSā€, izmantojot standarta DNS protokolu (parasti tiek izmantots tÄ«kla ports 853), kas ir ietÄ«ts Å”ifrētā sakaru kanālā, kas organizēts, izmantojot TLS protokolu ar resursdatora derÄ«guma pārbaudi, izmantojot sertificētus TLS/SSL sertifikātus. sertifikācijas iestāde. EsoÅ”ais DNSSEC standarts izmanto Å”ifrÄ“Å”anu tikai klienta un servera autentifikācijai, taču neaizsargā trafiku no pārtverÅ”anas un negarantē pieprasÄ«jumu konfidencialitāti.

Daži citi jauninājumi:

  • Pievienoti tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer un udp-send-buffer iestatÄ«jumi, lai iestatÄ«tu to buferu izmērus, kas tiek izmantoti, sÅ«tot un saņemot pieprasÄ«jumus, izmantojot TCP un UDP. Noslogotos serveros ienākoÅ”o buferu palielināŔana palÄ«dzēs izvairÄ«ties no pakeÅ”u nomeÅ”anas trafika maksimuma laikā, un to samazināŔana palÄ«dzēs atbrÄ«voties no atmiņas aizsērÄ“Å”anas ar veciem pieprasÄ«jumiem.
  • Pievienota jauna žurnāla kategorija ā€œrpz-passthruā€, kas ļauj atseviŔķi reÄ£istrēt RPZ (Response Policy Zones) pārsÅ«tÄ«Å”anas darbÄ«bas.
  • Sadaļā atbildes politika ir pievienota opcija ā€œnsdname-wait-recurseā€, ja iestatÄ«ta uz ā€œnēā€, RPZ NSDNAME noteikumi tiek lietoti tikai tad, ja pieprasÄ«jumam tiek atrasti autoritatÄ«vi vārdu serveri, kas atrodas keÅ”atmiņā, pretējā gadÄ«jumā RPZ NSDNAME noteikums tiek ignorēts, bet informācija tiek izgÅ«ta fonā un attiecas uz turpmākajiem pieprasÄ«jumiem.
  • Ierakstiem ar HTTPS un SVCB tipiem ir ieviesta sadaļas ā€œPAPILDUSā€ apstrāde.
  • Pievienoti pielāgoti atjaunināŔanas politikas noteikumu veidi - krb5-subdomain-self-rhs un ms-subdomain-self-rhs, kas ļauj ierobežot SRV un PTR ierakstu atjaunināŔanu. AtjaunināŔanas politikas bloki pievieno arÄ« iespēju iestatÄ«t ierakstu skaita ierobežojumus katram tipam atseviŔķi.
  • Dig utilÄ«ta izvadei pievienota informācija par transporta protokolu (UDP, TCP, TLS, HTTPS) un DNS64 prefiksiem. AtkļūdoÅ”anas nolÅ«kos programmai dig ir pievienota iespēja norādÄ«t konkrētu pieprasÄ«juma identifikatoru (dig +qid= ).
  • Pievienots OpenSSL 3.0 bibliotēkas atbalsts.
  • Lai novērstu problēmas, kas saistÄ«tas ar IP sadrumstalotÄ«bu, apstrādājot lielus DNS ziņojumus, ko identificē DNS karoga diena 2020, no atrisinātāja ir noņemts kods, kas pielāgo EDNS bufera lielumu, kad uz pieprasÄ«jumu netiek saņemta atbilde. EDNS bufera lielums tagad ir iestatÄ«ts uz nemainÄ«gu (edns-udp-size) visiem izejoÅ”ajiem pieprasÄ«jumiem.
  • BÅ«vsistēma ir pārslēgta uz autoconf, automake un libtool kombināciju.
  • Zonu failu atbalsts ā€œkartesā€ formātā (galvenā faila formāta karte) ir pārtraukts. Å Ä« formāta lietotājiem ieteicams pārveidot zonas neapstrādātā formātā, izmantojot utilÄ«tu named-compilezone.
  • Vecāku DLZ (dinamiski ielādējamo zonu) draiveru atbalsts ir pārtraukts, tos aizstāj ar DLZ moduļiem.
  • Windows platformas izveides un palaiÅ”anas atbalsts ir pārtraukts. Pēdējā filiāle, ko var instalēt sistēmā Windows, ir BIND 9.16.

Avots: opennet.ru

Pievieno komentāru