După doi ani de dezvoltare, consorțiul ISC a prezentat prima versiune stabilă a noului releases semnificativ al serverului DNS BIND 9.18. Suportul pentru ramura 9.18 va fi oferit timp de trei ani, până în trimestrul al doilea al anului 2025, în cadrul ciclului extins de suport. Suportul pentru ramura 9.11 va înceta în martie, iar pentru ramura 9.16 la mijlocul anului 2023. Pentru dezvoltarea funcționalității următoarei versiuni stabile BIND, a fost creată o ramură experimentală BIND 9.19.0.
Lansarea BIND 9.18.0 se remarcă prin implementarea suportului pentru tehnologiile „DNS peste HTTPS” (DoH, DNS over HTTPS) și DNS peste TLS (DoT, DNS over TLS), precum și prin mecanismul XoT (XFR-over-TLS) pentru transferul sigur al conținutului zonelor DNS între servere (se suportă atât livrarea, cât și primirea zonelor prin XoT). Cu setările corespunzătoare, un proces named poate acum să gestioneze nu doar cererile DNS tradiționale, ci și cererile trimise folosind DNS-over-HTTPS și DNS-over-TLS. Suportul client pentru DNS-over-TLS este încorporat în utilitarul dig, care poate fi folosit pentru a trimite cereri prin TLS specificând falia „+tls”.
Implementarea protocolului HTTP/2, utilizat în DoH, se bazează pe utilizarea bibliotecii nghttp2, care este inclusă în dependențele de compilare opționale. Certificatele pentru DoH și DoT pot fi furnizate de utilizator sau generate automat în timpul pornirii.
Procesarea cererilor utilizând DoH și DoT se activează prin adăugarea opțiunilor „http” și „tls” în directiva listen-on. Pentru a sprijini DNS-over-HTTP necriptat, setările trebuie să specifice „tls none”. Cheile sunt definite în secțiunea „tls”. Porturile standard de rețea 853 pentru DoT, 443 pentru DoH și 80 pentru DNS-over-HTTP pot fi suprascrise prin parametrii tls-port, https-port și http-port. De exemplu:
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;}; }
O caracteristică a implementării DoH în BIND este posibilitatea de a muta operațiunile de criptare pentru TLS pe un alt server, ceea ce poate fi necesar în condițiile în care certificatul TLS este stocat pe un alt sistem (de exemplu, într-o infrastructură cu servere web) și este întreținut de personal diferit. Suportul pentru DNS-over-HTTP necriptat este implementat pentru a simplifica depanarea și ca un nivel pentru redirecționarea către un alt server în rețeaua internă (pentru a muta criptarea pe un server separat). Pe serverul extern, pentru generarea traficului TLS, poate fi utilizat nginx, similar cu modul în care este organizată legătura HTTPS pentru site-uri.
O altă caracteristică este integrarea DoH ca transport comun, care poate fi utilizat nu doar pentru gestionarea cererilor clienților către rezolvare, ci și în schimbul de date între servere, la transferul zonelor de către serverul DNS autoritar și la procesarea oricăror cereri acceptate de celelalte transporturi DNS.
Printre dezavantajele care pot fi compensate prin dezactivarea compilării cu DoH/DoT sau mutarea criptării pe un alt server se numără complexitatea generală a bazei de cod — se adaugă un server HTTP încorporat și o bibliotecă TLS, care pot conține vulnerabilități și reprezenta vectori suplimentari pentru atacuri. De asemenea, utilizarea DoH crește traficul.
Reamintim că DNS-over-HTTPS poate fi util pentru a evita scurgerile de informații despre numele gazdelor solicitate prin serverele DNS ale furnizorilor, pentru a combate atacurile MITM și modificarea traficului DNS (de exemplu, atunci când te conectezi la Wi-Fi public), fiind o soluție pentru blocajele la nivel de DNS (DNS-over-HTTPS nu poate înlocui VPN în domeniul ocolirii blocajelor implementate la nivel DPI) sau pentru a asigura funcționarea în cazul în care accesul direct la serverele DNS nu este posibil (de exemplu, când se lucrează printr-un proxy). Dacă într-o situație normală, cererile DNS sunt trimise direct la serverele DNS specificate în configurația sistemului, în cazul DNS-over-HTTPS, cererea pentru determinarea adrese IP gazdei este încapsulată în traficul HTTPS și trimisă către un server HTTP, pe care rezolvatorul procesează cererile prin intermediul API-ului Web.
„DNS over TLS” se deosebește de „DNS over HTTPS” prin utilizarea protocolului standard DNS (care folosește, de obicei, portul de rețea 853), fiind înglobat într-un canal de comunicare criptat, organizat prin protocolul TLS cu verificarea validității gazdei prin certificatele TLS/SSL emise de o autoritate de certificare. Standardul existent DNSSEC folosește criptarea doar pentru autentificarea clientului și serverului, dar nu protejează traficul de interceptare și nu garantează confidențialitatea cererilor.
Alte inovații:
- Au fost adăugate setările tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer și udp-send-buffer pentru a stabili dimensiunile bufferelor utilizate la trimiteri și primiri de cereri pe TCP și UDP. Pe serverele aglomerate, creșterea bufferelor de intrare va preveni eliminarea pachetelor în momentele de vârf ale traficului, iar micșorarea va ajuta la evitarea aglomerării memoriei cu cereri vechi.
- A fost adăugată o nouă categorie de log-uri „rpz-passthru”, care permite jurnalizarea separată a acțiunilor de redirecționare a RPZ (Zone de Politică de Răspuns).
- În secțiunea politică de răspuns a fost adăugată opțiunea „nsdname-wait-recurse”, care, atunci când este setată la „nu”, aplică regulile RPZ NSDNAME numai dacă pentru cerere sunt găsite servere de nume autoritare în cache, altfel regula RPZ NSDNAME este ignorată, dar informația este extrasă în fundal și aplicată cererilor următoare.
- Pentru înregistrările de tip HTTPS și SVCB a fost implementată gestionarea secțiunii „ADDITIONAL”.
- Au fost adăugate tipuri de reguli update-policy personalizate — krb5-subdomain-self-rhs și ms-subdomain-self-rhs, care permit restricționarea actualizării înregistrărilor SRV și PTR. În blocurile update-policy a fost adăugată, de asemenea, posibilitatea de a stabili restricții privind numărul de înregistrări, separate pentru fiecare tip.
- În outputul utilitarului dig au fost adăugate informații despre protocolul de transport (UDP, TCP, TLS, HTTPS) și prefixele DNS64. Pentru scopuri de depanare, în dig a fost adăugată posibilitatea de a specifica un identificator de cerere concret (dig +qid=).
- A fost adăugat suport pentru biblioteca OpenSSL 3.0.
- Pentru a rezolva problemele legate de fragmentarea IP la procesarea mesajelor DNS de mari dimensiuni, desemnate prin inițiativa DNS Flag Day 2020, codul care ajusta dimensiunea tamponului EDNS în cazul în care nu exista un răspuns la cerere a fost eliminat din rezolver. Dimensiunea tamponului EDNS este acum setată constant (edns-udp-size) pentru toate cererile de ieșire.
- Sistemul de construire a fost transferat la utilizarea unui pachet format din autoconf, automake și libtool.
- Suportul pentru fișierele de zonă în format «map» (masterfile-format map) a fost oprit. Utilizatorilor acestui format li se recomandă să convertească zonele în format raw folosind utilitarul named-compilezone.
- Suportul pentru vechile drivere DLZ (Dynamically Loadable Zones) a fost oprit, fiind înlocuite de module DLZ.
- Suportul pentru construirea și rularea pe platforma Windows a fost oprit. Ultima ramură care poate fi instalată pe Windows rămâne BIND 9.16.
Sursa: opennet.ro
