Verëffentlechung vum BIND DNS Server 9.18.0 mat Ënnerstëtzung fir DNS-iwwer-TLS an DNS-iwwer-HTTPS

No zwee Joer Entwécklung huet den ISC Konsortium déi éischt stabil Verëffentlechung vun enger grousser neier Branche vum BIND 9.18 DNS Server verëffentlecht. Ënnerstëtzung fir d'Branche 9.18 gëtt fir dräi Joer bis zum 2. Trimester 2025 als Deel vun engem erweiderten Ënnerstëtzungszyklus zur Verfügung gestallt. Ënnerstëtzung fir d'9.11 Branche wäert am Mäerz ophalen, an d'Ënnerstëtzung fir d'9.16 Branche Mëtt 2023. Fir d'Funktionalitéit vun der nächster stabiler Versioun vu BIND z'entwéckelen, ass eng experimentell Branche BIND 9.19.0 geformt.

D'Verëffentlechung vu BIND 9.18.0 ass bemierkenswäert fir d'Ëmsetzung vun der Ënnerstëtzung fir DNS iwwer HTTPS (DoH, DNS iwwer HTTPS) an DNS iwwer TLS (DoT, DNS iwwer TLS), souwéi den XoT (XFR-over-TLS) Mechanismus fir sécheren Transfert vum DNS Inhalt.Zonen tëscht Serveren (souwuel Schécken an Empfangszonen iwwer XoT ginn ënnerstëtzt). Mat de passenden Astellungen kann en eenzegen Numm Prozess elo net nëmmen traditionell DNS Ufroen déngen, awer och Ufroen, déi mat DNS-over-HTTPS an DNS-over-TLS geschéckt ginn. Client Ënnerstëtzung fir DNS-iwwer-TLS ass an der Dig-Utility agebaut, déi benotzt ka ginn fir Ufroen iwwer TLS ze schécken wann de "+tls" Fändel uginn ass.

D'Ëmsetzung vum HTTP/2 Protokoll, deen an DoH benotzt gëtt, baséiert op der Benotzung vun der nghttp2 Bibliothéik, déi als optional Assembléeabhängegkeet abegraff ass. Certificaten fir DoH an DoT kënne vum Benotzer geliwwert ginn oder automatesch bei der Startzäit generéiert ginn.

Ufroveraarbechtung mat DoH an DoT ass aktivéiert andeems d'Optiounen "http" an "tls" an d'Listen-on Direktiv bäigefüügt ginn. Fir onverschlësselte DNS-iwwer-HTTP z'ënnerstëtzen, sollt Dir "tls none" an den Astellunge spezifizéieren. Schlësselen sinn an der Rubrik "tls" definéiert. D'Standard Netzwierk Ports 853 fir DoT, 443 fir DoH an 80 fir DNS-iwwer-HTTP kënnen iwwer d'tls-port, https-port an http-port Parameteren iwwerschratt ginn. Zum Beispill:

tls local-tls {Schlësseldatei "/path/to/priv_key.pem"; cert-Datei "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; Optiounen { https-port 443; lauschteren Hafen 443 tls lokal-tls http myserver {all;}; }

Ee vun de Fonctiounen vun der DoH Implementatioun am BIND ass d'Fäegkeet Verschlësselungsoperatioune fir TLS op en anere Server ze réckelen, wat néideg ka sinn a Bedéngungen, wou TLS Zertifikater op engem anere System gespäichert sinn (zum Beispill an enger Infrastruktur mat Webserver) an erhale bleiwen. vun anere Personal. Ënnerstëtzung fir onverschlësselte DNS-iwwer-HTTP gëtt implementéiert fir Debugging ze vereinfachen an als Schicht fir weider op en anere Server am internen Netzwierk ze schécken (fir d'Verschlësselung op e separaten Server ze verschécken). Op engem Fernserver kann nginx benotzt ginn fir TLS Traffic ze generéieren, ähnlech wéi HTTPS Bindung fir Websäiten organiséiert gëtt.

Eng aner Feature ass d'Integratioun vum DoH als allgemengen Transport, deen net nëmme benotzt ka ginn fir Client Ufroen un de Resolver ze handhaben, awer och wann Dir tëscht Serveren kommunizéiert, wann Dir Zonen vun engem autoritären DNS Server transferéiert, a wann Dir all Ufroe veraarbecht, ënnerstëtzt vun aneren DNS. transportéiert.

Ënnert de Mängel, déi kompenséiert kënne ginn andeems de Bau mat DoH/DoT auszeschalten oder d'Verschlësselung op en anere Server beweegt, steet d'allgemeng Komplikatioun vun der Codebasis eraus - en agebaute HTTP-Server an TLS-Bibliothéik ginn derbäigesat, déi potenziell enthalen Schwachstelle a handelen als zousätzlech Vektore fir Attacken. Och wann Dir DoH benotzt, erhéicht de Traffic.

Loosst eis drun erënneren datt DNS-iwwer-HTTPS nëtzlech ka sinn fir Leckage vun Informatioun iwwer déi ugefrote Hostnumm duerch d'DNS-Server vu Fournisseuren ze vermeiden, MITM Attacken an DNS Traffic spoofing ze bekämpfen (zum Beispill wann Dir mat ëffentleche Wi-Fi verbënnt), géint op DNS-Niveau blockéieren (DNS-over-HTTPS kann net e VPN ersetzen an d'Blockéierung um DPI-Niveau ëmgoen) oder fir d'Aarbecht ze organiséieren wann et onméiglech ass direkt Zougang zu DNS-Server ze kréien (zum Beispill wann Dir duerch e Proxy schafft). Wann an enger normaler Situatioun DNS-Ufroen direkt un DNS-Server geschéckt ginn, déi an der Systemkonfiguratioun definéiert sinn, dann am Fall vun DNS-iwwer-HTTPS d'Ufro fir d'Host-IP Adress ze bestëmmen ass am HTTPS-Traffic verschlësselt an un den HTTP-Server geschéckt, wou de Resolver veraarbecht Ufroen iwwer Web API.

"DNS iwwer TLS" ënnerscheet sech vun "DNS iwwer HTTPS" an der Notzung vum Standard DNS Protokoll (Netzwierksport 853 gëtt normalerweis benotzt), gewéckelt an engem verschlësselte Kommunikatiounskanal organiséiert mam TLS Protokoll mat Hostvaliditéitskontroll duerch TLS / SSL Zertifikater zertifizéiert vun enger Zertifizéierungsautoritéit. Déi existent DNSSEC Norm benotzt Verschlësselung nëmmen fir de Client an de Server ze authentifizéieren, awer schützt de Traffic net virun der Interceptioun a garantéiert net d'Vertraulechkeet vun den Ufroen.

E puer aner Innovatiounen:

  • tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer an udp-send-buffer Astellunge bäigefüügt fir d'Gréisste vu Puffer ze setzen, déi benotzt ginn wann Dir Ufroen iwwer TCP an UDP schéckt an empfänkt. Op beschäftegt Serveren, d'Erhéijung vun erakommen Puffer hëlleft ze vermeiden datt Päckchen während Traffic Peaks falen, an d'Ofsenkung vun hinnen hëlleft d'Erënnerungsverstoppung mat alen Ufroen lass ze ginn.
  • Eng nei Logkategorie "rpz-passthru" gouf bäigefüügt, wat Iech erlaabt RPZ (Respons Policy Zones) Forwarding Aktiounen separat ze protokolléieren.
  • An der Äntwert-Politik Sektioun ass d'Optioun "nsdname-wait-recurse" bäigefüügt, wann se op "Nee" gesat ginn, ginn d'RPZ NSDNAME Regelen nëmmen applizéiert wann autoritär Nummserver, déi am Cache präsent sinn, fir d'Ufro fonnt ginn, soss gëtt de RPZ NSDNAME Regel gëtt ignoréiert, awer d'Informatioun gëtt am Hannergrond zréckgezunn a gëllt fir spéider Ufroen.
  • Fir records mat HTTPS- a SVCB-Typen ass d'Veraarbechtung vun der "ADDITIONAL" Sektioun ëmgesat ginn.
  • Dobäi personaliséiert Update-Politik Regel Zorte - krb5-subdomain-self-rhs an ms-subdomain-self-rhs, déi erlaben Iech den Update vun SRV an PTR records ze limitéieren. D'Aktualiséierungspolitikblocken addéieren och d'Fäegkeet Limiten op d'Zuel vun de Rekorder ze setzen, individuell fir all Typ.
  • Zousätzlech Informatioun iwwer den Transportprotokoll (UDP, TCP, TLS, HTTPS) an DNS64 Präfixe fir d'Ausgab vum Dig-Utility bäigefüügt. Fir Debugging Zwecker huet dig d'Fäegkeet bäigefüügt fir e spezifeschen Ufroidentifizéierer ze spezifizéieren (dig +qid= ).
  • Zousätzlech Ënnerstëtzung fir OpenSSL 3.0 Bibliothéik.
  • Fir Problemer mat IP Fragmentatioun ze adresséieren wann Dir grouss DNS Messagen veraarbecht, identifizéiert vum DNS Flag Day 2020, Code deen d'EDNS Puffergréisst upasst wann et keng Äntwert op eng Ufro gëtt, gouf vum Resolver geläscht. D'EDNS Puffergréisst ass elo op konstant gesat (edns-udp-Gréisst) fir all erausginn Ufroen.
  • De Build System gouf op eng Kombinatioun vun autoconf, automake a libtool gewiesselt.
  • Ënnerstëtzung fir Zonedateien am "Kaart" Format (Masterfile-Format Kaart) gouf gestoppt. D'Benotzer vun dësem Format ginn empfohlen fir Zonen an e raw Format ze konvertéieren mam Numm-Compilezone Utility.
  • Ënnerstëtzung fir eeler DLZ (Dynamic Loadable Zones) Chauffeuren gouf gestoppt, ersat duerch DLZ Moduler.
  • Build a lafen Ënnerstëtzung fir d'Windows Plattform gouf gestoppt. Déi lescht Branche déi op Windows installéiert ka ginn ass BIND 9.16.

Source: opennet.ru

Setzt e Commentaire