Dezvoltatorii serverului DNS BIND au anunțat adăugarea în ramura experimentală 9.17 a implementării suportului pentru tehnologiile „DNS peste HTTPS” (DoH, DNS over HTTPS) și DNS peste TLS (DoT, DNS over TLS), precum și a mecanismului XFR-over-TLS pentru transmiterea în siguranță a conținutului zonelor DNS între servere. DoH este disponibil pentru testare în versiunea 9.17.10, iar suportul DoT este prezent începând cu versiunea 9.17.7. După stabilizare, suportul pentru DoT și DoH va fi backportat în ramura stabilă 9.16.
Implementarea protocolului HTTP/2, utilizat în DoH, se bazează pe utilizarea bibliotecii nghttp2, care este inclusă în numărul de dependențe de construcție (în viitor, biblioteca va fi planificată să fie transformată în dependențe opționale). Se susțin atât conexiuni criptate (TLS), cât și necriptate prin HTTP/2. Cu configurațiile corespunzătoare, un proces named poate acum să gestioneze nu doar cererile DNS tradiționale, ci și cererile trimise folosind DoH (DNS-over-HTTPS) și DoT (DNS-over-TLS). Suportul HTTPS pe partea clientului (dig) nu este încă implementat. Suportul pentru XFR-over-TLS este disponibil atât pentru cererile de intrare, cât și pentru cele de ieșire.
Procesarea cererilor utilizând DoH și DoT se activează prin adăugarea opțiunilor http și tls în directivele listen-on. Pentru a susține DNS-over-HTTP necriptat, în setări ar trebui specificat „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;}; }
Printre caracteristicile implementării DoH în BIND se remarcă integrarea ca transport comun, care poate fi aplicat nu doar pentru procesarea cererilor clienților către rezolvator, ci și în schimbul de date între servere, la transmiterea zonelor de către serverul DNS autoritar și la procesarea oricăror cereri susținute de alte transporturi DNS.
O altă caracteristică este capacitatea de a externaliza operațiunile de criptare pentru TLS către un alt server, ceea ce poate fi necesar în condiții în care certificatele TLS sunt stocate pe un alt sistem (de exemplu, în infrastructuri cu servere web) și sunt gestionate de un alt personal. Suportul pentru DNS nesecurizat prin HTTP a fost implementat pentru a simplifica depanarea și ca un strat pentru tunelarea în rețeaua internă, pe baza căruia pe un alt server poate fi organizată criptarea. Pe serverul extern pentru generarea traficului TLS se poate utiliza nginx, în mod similar cu modul în care este organizată legătura HTTPS pentru site-uri.
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.
Sursa: opennet.ro
