Suportul experimental pentru DNS-over-HTTPS a fost adăugat la serverul BIND DNS

Dezvoltatorii serverului BIND DNS au anunțat adăugarea suportului de server pentru tehnologiile DNS over HTTPS (DoH, DNS over HTTPS) și DNS over TLS (DoT, DNS over TLS), precum și mecanismul XFR-over-TLS pentru securitate. transferarea conținutului zonelor DNS între servere. DoH este disponibil pentru testare în versiunea 9.17, iar suportul DoT a fost prezent de la versiunea 9.17.10. După stabilizare, suportul DoT și DoH va fi portat înapoi în ramura stabilă 9.17.7.

Implementarea protocolului HTTP/2 utilizat în DoH se bazează pe utilizarea bibliotecii nghttp2, care este inclusă printre dependențele de asamblare (în viitor, biblioteca este planificată să fie transferată la numărul de dependențe opționale). Sunt acceptate atât conexiunile criptate (TLS) cât și cele necriptate HTTP/2. Cu setările corespunzătoare, un singur proces numit poate servi acum nu numai interogări DNS tradiționale, ci și interogări trimise folosind DoH (DNS-over-HTTPS) și DoT (DNS-over-TLS). Suportul HTTPS pe partea clientului (dig) nu este încă implementat. Suportul XFR-over-TLS este disponibil atât pentru cererile de intrare, cât și pentru cele de ieșire.

Procesarea cererilor folosind DoH și DoT este activată prin adăugarea opțiunilor http și tls la directiva listen-on. Pentru a accepta DNS-over-HTTP necriptat, ar trebui să specificați „tls none” în setări. Cheile sunt definite în secțiunea „tls”. Porturile de rețea implicite 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"; fișier-cert „/path/to/cert_chain.pem”; }; http local-http-server { endpoints { "/dns-query"; }; }; opțiuni { https-port 443; portul de ascultare 443 tls local-tls http serverul meu {oricare;}; }

Printre caracteristicile implementării DoH în BIND, integrarea este remarcată ca un transport general, care poate fi folosit nu numai pentru a procesa cererile clienților către soluție, ci și la schimbul de date între servere, la transferul de zone de către un server DNS autorizat și la procesarea oricăror cereri suportate de alte transporturi DNS .

O altă caracteristică este capacitatea de a muta operațiunile de criptare pentru TLS pe ​​un alt server, ceea ce poate fi necesar în condițiile în care certificatele TLS sunt stocate pe alt sistem (de exemplu, într-o infrastructură cu servere web) și întreținute de alt personal. Suportul pentru DNS-over-HTTP necriptat este implementat pentru a simplifica depanarea și ca strat de redirecționare în rețeaua internă, pe baza căruia criptarea poate fi organizată pe un alt server. Pe un server la distanță, nginx poate fi folosit pentru a genera trafic TLS, similar modului în care este organizată legarea HTTPS pentru site-uri web.

Să reamintim că DNS-over-HTTPS poate fi util pentru prevenirea scurgerilor de informații despre numele gazdelor solicitate prin serverele DNS ale furnizorilor, combaterea atacurilor MITM și a falsării traficului DNS (de exemplu, la conectarea la Wi-Fi public), contracararea activarea blocării la nivel DNS (DNS-over-HTTPS nu poate înlocui un VPN în ocolirea blocării implementate la nivel DPI) sau pentru organizarea muncii atunci când este imposibil să accesați direct serverele DNS (de exemplu, când lucrați printr-un proxy). Dacă într-o situație normală cererile DNS sunt trimise direct către serverele DNS definite în configurația sistemului, atunci în cazul DNS-over-HTTPS cererea de determinare a adresei IP a gazdei este încapsulată în traficul HTTPS și trimisă către serverul HTTP, unde rezolutorul procesează cererile prin Web API.

„DNS over TLS” diferă de „DNS over HTTPS” prin utilizarea protocolului DNS standard (de obicei se folosește portul de rețea 853), ambalat într-un canal de comunicare criptat organizat folosind protocolul TLS cu verificarea validității gazdei prin certificate TLS/SSL certificate de către o autoritate de certificare. Standardul DNSSEC existent folosește criptarea doar pentru a autentifica clientul și serverul, dar nu protejează traficul de interceptări și nu garantează confidențialitatea solicitărilor.

Sursa: opennet.ru

Adauga un comentariu