Dup\u0103 doi ani de dezvoltare, consor\u021biul ISC a prezentat prima versiune stabil\u0103 a noului releases semnificativ al serverului DNS BIND 9.18. Suportul pentru ramura 9.18 va fi oferit timp de trei ani, p\u00e2n\u0103 \u00een trimestrul al doilea al anului 2025, \u00een cadrul ciclului extins de suport. Suportul pentru ramura 9.11 va \u00eenceta \u00een martie, iar pentru ramura 9.16 la mijlocul anului 2023. Pentru dezvoltarea func\u021bionalit\u0103\u021bii urm\u0103toarei versiuni stabile BIND, a fost creat\u0103 o ramur\u0103 experimental\u0103 BIND 9.19.0. <\/p>\n
Lansarea BIND 9.18.0 este remarcabil\u0103 prin implementarea suportului pentru tehnologiile \u201eDNS peste HTTPS\u201d (DoH, DNS over HTTPS) \u0219i DNS peste TLS (DoT, DNS over TLS), precum \u0219i pentru mecanismul XoT (XFR-over-TLS) pentru transmisia sigur\u0103 a con\u021binutului zonelor DNS \u00eentre servere (suport\u0103 at\u00e2t livrarea, c\u00e2t \u0219i primirea zonelor prin XoT). Cu set\u0103rile corespunz\u0103toare, un singur proces named poate acum s\u0103 gestioneze nu doar cererile tradi\u021bionale DNS, ci \u0219i cererile trimise folosind DNS-over-HTTPS \u0219i DNS-over-TLS. Suportul clientului pentru DNS-over-TLS este integrat \u00een utilitarul dig, care poate fi utilizat pentru a trimite cereri peste TLS prin specificarea flag-ului \u201e+tls\u201d. <\/p>\n
Implementarea protocolului HTTP\/2, utilizat \u00een DoH, se bazeaz\u0103 pe utilizarea bibliotecii nghttp2, care este inclus\u0103 \u00een dependen\u021bele de compilare op\u021bionale. Certificatele pentru DoH \u0219i DoT pot fi furnizate de utilizator sau generate automat \u00een timpul pornirii. <\/p>\n
Procesarea cererilor folosind DoH \u0219i DoT se activeaz\u0103 prin ad\u0103ugarea op\u021biunilor \u201ehttp\u201d \u0219i \u201etls\u201d \u00een directiva listen-on. Pentru a suporta DNS-over-HTTP necriptat, \u00een set\u0103ri trebuie specificat\u0103 \u201etls none\u201d. Cheile sunt definite \u00een sec\u021biunea \u201etls\u201d. Porturile standard de re\u021bea 853 pentru DoT, 443 pentru DoH \u0219i 80 pentru DNS-over-HTTP pot fi suprascrise prin parametrii tls-port, https-port \u0219i http-port. De exemplu: <\/p>\n
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;}; } <\/p>\n
O caracteristic\u0103 a implement\u0103rii DoH \u00een BIND este posibilitatea de a muta opera\u021biunile de criptare pentru TLS pe un alt server, ceea ce poate fi necesar \u00een condi\u021biile \u00een care certificatul TLS este stocat pe un alt sistem (de exemplu, \u00eentr-o infrastructur\u0103 cu servere web) \u0219i este \u00eentre\u021binut de personal diferit. Suportul pentru DNS-over-HTTP necriptat este implementat pentru a simplifica depanarea \u0219i ca un nivel pentru redirec\u021bionarea c\u0103tre un alt server \u00een re\u021beaua intern\u0103 (pentru a muta criptarea pe un server separat). Pe serverul extern, pentru generarea traficului TLS, poate fi utilizat nginx, similar cu modul \u00een care este organizat\u0103 leg\u0103tura HTTPS pentru site-uri. <\/p>\n
O alt\u0103 caracteristic\u0103 este integrarea DoH ca transport comun, care poate fi utilizat nu doar pentru gestionarea cererilor clien\u021bilor c\u0103tre rezolvare, ci \u0219i \u00een schimbul de date \u00eentre servere, la transferul zonelor de c\u0103tre serverul DNS autoritar \u0219i la procesarea oric\u0103ror cereri acceptate de celelalte transporturi DNS. <\/p>\n
Printre dezavantajele care pot fi compensate prin dezactivarea compil\u0103rii cu DoH\/DoT sau transfer\u00e2nd criptarea pe un alt server, se remarc\u0103 complicarea general\u0103 a codului \u2014 se adaug\u0103 un server HTTP \u00eencorporat \u0219i o bibliotec\u0103 TLS, care pot con\u021bine poten\u021biale vulnerabilit\u0103\u021bi \u0219i pot constitui vectori suplimentari pentru atacuri. De asemenea, utilizarea DoH cre\u0219te traficul. <\/p>\n
Reamintim c\u0103 DNS-over-HTTPS poate fi util pentru a evita scurgerile de informa\u021bii despre numele gazdelor solicitate prin serverele DNS ale furnizorilor, pentru a combate atacurile MITM \u0219i modificarea traficului DNS (de exemplu, atunci c\u00e2nd te conectezi la Wi-Fi public), fiind o solu\u021bie pentru blocajele la nivel de DNS (DNS-over-HTTPS nu poate \u00eenlocui VPN<\/a> \u00een domeniul ocolirii blocajelor implementate la nivel DPI) sau pentru a asigura func\u021bionarea \u00een cazul \u00een care accesul direct la serverele DNS nu este posibil (de exemplu, c\u00e2nd se lucreaz\u0103 printr-un proxy). Dac\u0103 \u00eentr-o situa\u021bie normal\u0103, cererile DNS sunt trimise direct la serverele DNS specificate \u00een configura\u021bia sistemului, \u00een cazul DNS-over-HTTPS, cererea pentru determinarea adrese IP<\/a> gazdei este \u00eencapsulat\u0103 \u00een traficul HTTPS \u0219i trimis\u0103 c\u0103tre un server HTTP, pe care rezolvatorul proceseaz\u0103 cererile prin intermediul API-ului Web. <\/p>\n \u201eDNS peste TLS\u201d se deosebe\u0219te de \u201eDNS peste HTTPS\u201d prin utilizarea protocolului standard DNS (de obicei utilizat pe portul de re\u021bea 853), \u00eenglobat \u00eentr-un canal de comunicare criptat, organizat cu ajutorul protocolului TLS, cu validarea gazdelor prin certificate TLS\/SSL emise de un autoritate de certificare. Standardul existent DNSSEC utilizeaz\u0103 criptarea doar pentru autentificarea clientului \u0219i serverului, dar nu protejeaz\u0103 traficul de interceptare \u0219i nu garanteaz\u0103 confiden\u021bialitatea cererilor. <\/p>\n Alte inova\u021bii: <\/p>\n\n