Gli sviluppatori del server DNS BIND hanno annunciato l'aggiunta del supporto server per le tecnologie DNS over HTTPS (DoH, DNS over HTTPS) e DNS over TLS (DoT, DNS over TLS), nonché il meccanismo XFR-over-TLS per la sicurezza trasferire il contenuto delle zone DNS tra server. DoH è disponibile per i test nella versione 9.17 e il supporto DoT è presente dalla versione 9.17.10. Dopo la stabilizzazione, il supporto DoT e DoH verrà trasferito al ramo stabile 9.17.7.
L'implementazione del protocollo HTTP/2 utilizzato in DoH si basa sull'uso della libreria nghttp2, che è inclusa tra le dipendenze dell'assembly (in futuro è previsto che la libreria venga trasferita al numero di dipendenze opzionali). Sono supportate sia le connessioni HTTP/2 crittografate (TLS) che quelle non crittografate. Con le impostazioni appropriate, un singolo processo denominato può ora servire non solo le query DNS tradizionali, ma anche le query inviate utilizzando DoH (DNS-over-HTTPS) e DoT (DNS-over-TLS). Il supporto HTTPS sul lato client (dig) non è ancora implementato. Il supporto XFR-over-TLS è disponibile sia per le richieste in entrata che per quelle in uscita.
L'elaborazione delle richieste tramite DoH e DoT viene abilitata aggiungendo le opzioni http e tls alla direttiva di ascolto. Per supportare DNS-over-HTTP non crittografato, è necessario specificare "tls none" nelle impostazioni. Le chiavi sono definite nella sezione "tls". Le porte di rete predefinite 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"; file-cert "/percorso/del/cert_chain.pem"; }; http server-http locale { endpoint { "/dns-query"; }; }; opzioni { https-porta 443; porta di ascolto 443 tls local-tls http myserver {qualsiasi;}; }
Tra le caratteristiche dell'implementazione DoH in BIND, si segnala l'integrazione come trasporto generale, che può essere utilizzato non solo per elaborare le richieste del client al risolutore, ma anche quando si scambiano dati tra server, quando si trasferiscono zone tramite un server DNS autorevole e durante l'elaborazione di eventuali richieste supportate da altri trasporti DNS.
Un'altra caratteristica è la possibilità di spostare le operazioni di crittografia per TLS su un altro server, che può essere necessario in condizioni in cui i certificati TLS sono archiviati su un altro sistema (ad esempio, in un'infrastruttura con server web) e mantenuti da altro personale. Il supporto per DNS-over-HTTP non crittografato è implementato per semplificare il debug e come livello per l'inoltro nella rete interna, sulla base del quale è possibile organizzare la crittografia su un altro server. Su un server remoto, nginx può essere utilizzato per generare traffico TLS, in modo simile a come è organizzato il collegamento HTTPS per i siti web.
Ricordiamo che DNS-over-HTTPS può essere utile per prevenire fughe di informazioni sui nomi host richiesti attraverso i server DNS dei provider, contrastare gli attacchi MITM e lo spoofing del traffico DNS (ad esempio durante la connessione a Wi-Fi pubbliche), contrastare il blocco a livello DNS (DNS-over-HTTPS non può sostituire una VPN nell'aggirare il blocco implementato a livello DPI) o per organizzare il lavoro quando è impossibile accedere direttamente ai server DNS (ad esempio quando si lavora tramite proxy). Se in una situazione normale le richieste DNS vengono inviate direttamente ai server DNS definiti nella configurazione del sistema, nel caso di DNS-over-HTTPS la richiesta per determinare l'indirizzo IP dell'host viene incapsulata nel traffico HTTPS e inviata al server HTTP, dove il risolutore elabora le richieste tramite API Web.
“DNS over TLS” si differenzia da “DNS over HTTPS” nell’utilizzo del protocollo DNS standard (solitamente viene utilizzata la porta di rete 853), avvolto in un canale di comunicazione crittografato organizzato utilizzando il protocollo TLS con controllo di validità dell’host tramite certificati TLS/SSL certificati da un ente di certificazione. Lo standard DNSSEC esistente utilizza la crittografia solo per autenticare client e server, ma non protegge il traffico dalle intercettazioni e non garantisce la riservatezza delle richieste.
Fonte: opennet.ru