Gli sviluppatori del server DNS BIND hanno annunciato l'aggiunta nel ramo sperimentale 9.17 dell'implementazione del supporto server per le tecnologie "DNS over HTTPS" (DoH, DNS sopra HTTPS) e DNS sopra TLS (DoT, DNS sopra TLS), nonché il meccanismo XFR-over-TLS per la trasmissione sicura dei contenuti delle zone DNS tra server. DoH è disponibile per il test nella release 9.17.10, mentre il supporto per DoT è presente a partire dalla release 9.17.7. Dopo la stabilizzazione, il supporto per DoT e DoH sarà retroportato nel ramo stabile 9.16.
L'implementazione del protocollo HTTP/2, utilizzato in DoH, si basa sull'uso della libreria nghttp2, che è inclusa tra le dipendenze di build (in futuro, la libreria è prevista per essere spostata tra le dipendenze opzionali). Sono supportate connessioni sia crittografate (TLS) che non crittografate tramite HTTP/2. Con le impostazioni appropriate, un processo named ora può gestire non solo le tradizionali richieste DNS, ma anche le richieste inviate utilizzando DoH (DNS-over-HTTPS) e DoT (DNS-over-TLS). Il supporto HTTPS lato client (dig) non è ancora implementato. Il supporto per XFR-over-TLS è disponibile sia per richieste in entrata che in uscita.
La gestione delle richieste utilizzando DoH e DoT viene attivata aggiungendo le opzioni http e tls nella direttiva listen-on. Per supportare il DNS-over-HTTP non crittografato, nelle impostazioni dovrebbe essere specificato "tls none". Le chiavi sono definite nella sezione "tls". Le porte di rete standard 853 per DoT, 443 per DoH e 80 per DNS-over-HTTP possono essere sovrascritte tramite i parametri tls-port, https-port e http-port. Ad esempio: 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;}; }
Tra le caratteristiche dell'implementazione di DoH in BIND si segnala l'integrazione come trasporto comune, che può essere utilizzato non solo per gestire le richieste dei clienti verso il resolutore, ma anche durante lo scambio di dati tra server, durante la trasmissione delle zone da un server DNS autorevole e nella gestione di qualsiasi richiesta supportata da altri trasporti DNS.
Un'altra funzionalità è la possibilità di spostare le operazioni di crittografia TLS su un altro server, che può essere necessaria in situazioni in cui la memorizzazione dei certificati TLS avviene su un altro sistema (ad esempio, in un'infrastruttura con server web) e gestita da altro personale. Il supporto per DNS-over-HTTP non crittografato è stato implementato per semplificare il debug e come livello per il passaggio nella rete interna, sulla base del quale su un altro server può essere organizzata la crittografia. Su un server esterno, nginx può essere utilizzato per generare il traffico TLS, analogamente a come viene organizzato il wrapper HTTPS per i siti web.
Ricordiamo che il DNS-over-HTTPS può essere utile per escludere la fuga di informazioni sui nomi host richiesti tramite i server DNS dei fornitori, combattere gli attacchi MITM e la sostituzione del traffico DNS (ad esempio, quando ci si connette a Wi-Fi pubblici), contrastare i blocchi a livello DNS (il DNS-over-HTTPS non può sostituire VPN nell'area di elusione dei blocchi implementati a livello DPI) o per organizzare il lavoro nel caso in cui non sia possibile un accesso diretto ai server DNS (ad esempio, quando si lavora tramite proxy). In una situazione normale, le richieste DNS vengono inviate direttamente ai server DNS definiti nella configurazione del sistema, mentre nel caso di DNS-over-HTTPS una richiesta per determinare Indirizzi IP l'host è incapsulata nel traffico HTTPS e inviata a un server HTTP, dove il resolver gestisce le richieste tramite Web API.
«DNS over TLS» si distingue da «DNS over HTTPS» per l'uso del protocollo DNS standard (solitamente sulla porta di rete 853), incapsulato in un canale di comunicazione crittografato realizzato tramite il protocollo TLS, con verifica dell'identità dell'host tramite certificati TLS/SSL emessi da un'autorità di certificazione. Lo standard esistente DNSSEC utilizza la crittografia solo per l'autenticazione del cliente e del server, ma non protegge il traffico dall'intercettazione e non garantisce la riservatezza delle richieste.
Fonte: opennet.ru
