Gli sviluppatori del server DNS BIND hanno annunciato l'aggiunta nella branch sperimentale 9.17 del supporto server per le tecnologie «DNS sopra HTTPS» (DoH, DNS over HTTPS) e DNS sopra TLS (DoT, DNS over TLS), così come il meccanismo XFR-over-TLS per il trasferimento sicuro dei contenuti delle zone DNS tra i server. DoH è disponibile per il test nella release 9.17.10, mentre il supporto DoT è presente dalla release 9.17.7. Dopo la stabilizzazione, il supporto per DoT e DoH sarà portato nella branch 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 sarà trasferita tra le dipendenze opzionali). Sono supportate sia le connessioni cifrate (TLS) che quelle non cifrate tramite HTTP/2. Con le impostazioni appropriate, un processo named può ora gestire non solo le tradizionali richieste DNS, ma anche quelle 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 le richieste in entrata che per quelle in uscita.
L'elaborazione delle richieste utilizzando DoH e DoT si abilita aggiungendo le opzioni http e tls alla direttiva listen-on. Per supportare DNS-over-HTTP non crittografato, è necessario specificare "tls none" nelle impostazioni. 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 ridefinite 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 elaborare le richieste dei client verso il risolutore, ma anche per lo scambio di dati tra server, durante la trasmissione delle zone da parte del server DNS autorevole e per l'elaborazione di qualsiasi richiesta supportata da altri trasporti DNS.
Un'altra caratteristica è la possibilità di delegare le operazioni di crittografia TLS su un altro server, il che può essere necessario quando i certificati TLS vengono memorizzati su un sistema diverso (ad esempio, in un'infrastruttura con server web) e gestiti da un altro personale. È supportato DNS-over-HTTP non crittografato per semplificare il debug e fungere da livello per il throughput nella rete interna, sulla base del quale può essere organizzata la crittografia su un altro server. Su un server esterno può essere utilizzato nginx per generare traffico TLS, analogamente a come viene configurato il wrapping HTTPS per i siti.
Ricordiamo che DNS-over-HTTPS può risultare utile per evitare perdite di informazioni sui nomi host richiesti attraverso i server DNS dei provider, per combattere attacchi MITM e sostituzioni del traffico DNS (ad esempio, quando ci si connette a pubbliche Wi-Fi), e per contrastare i blocchi a livello DNS (DNS-over-HTTPS non può sostituire VPN nel campo dell'aggiramento delle restrizioni implementate a livello DPI) o per organizzare il funzionamento nel caso di impossibilità di accesso diretto ai server DNS (ad esempio, quando si utilizza un proxy). In una situazione normale, le richieste DNS vengono inviate direttamente ai server DNS specificati nella configurazione del sistema, mentre nel caso di DNS-over-HTTPS la richiesta di risoluzione Indirizzi IP del host è incapsulata nel traffico HTTPS e inviata a un server HTTP, dove il risolutore elabora le richieste tramite un'API Web.
«DNS over TLS» si distingue da «DNS over HTTPS» per l'uso del protocollo DNS standard (tipicamente sulla porta di rete 853), incapsulato in un canale di comunicazione crittografato, organizzato utilizzando il protocollo TLS, con verifica dell'autenticità del host tramite certificati TLS/SSL emessi da un'autorità di certificazione. Lo standard esistente DNSSEC utilizza la crittografia solo per l'autenticazione del client e del server, ma non protegge il traffico da intercettazioni e non garantisce la riservatezza delle richieste.
Fonte: opennet.ru
