Svelati gli sviluppatori del server BIND DNS diversi giorni fa entrare nel ramo sperimentale 9.17, l'implementazione di supporto di server per le tecnologie DNS su HTTPS (DoH, DNS su HTTPS) e DNS su TLS (DoT, DNS over TLS), nonché XFR.
L'implementazione del protocollo HTTP / 2 utilizzato in DoH si basa sull'uso della libreria nghttp2, che è incluso nelle dipendenze di compilazione (in futuro si prevede di trasferire la libreria alle dipendenze opzionali).
Con una corretta configurazione, un singolo processo con nome può ora servire non solo le richieste DNS tradizionali, ma anche le richieste inviate utilizzando DoH (DNS su HTTPS) e DoT (DNS su TLS).
Il supporto lato client HTTPS (dig) non è ancora implementato, mentre il supporto XFR-over-TLS è disponibile per le richieste in entrata e in uscita.
Elaborazione delle richieste utilizzando DoH e DoT è abilitato aggiungendo le opzioni http e tls alla direttiva di ascolto. Per supportare DNS su HTTP non crittografato, è necessario specificare "tls none" nella configurazione. Le chiavi sono definite nella sezione "tls". Le porte di rete standard 853 per DoT, 443 per DoH e 80 per DNS su HTTP possono essere sovrascritte tramite i parametri tls-port, https-port e http-port.
Tra le caratteristiche dell'implementazione di DoH in BIND, si noti che è possibile trasferire le operazioni di crittografia per TLS su un altro server, Ciò può essere necessario in condizioni in cui l'archiviazione dei certificati TLS avvenga su un altro sistema (ad esempio, in un'infrastruttura con web server) e sia presidiata da altro personale.
Supporto per Viene implementato DNS su HTTP non crittografato per semplificare il debug e come livello per l'inoltro sulla rete interna, in base al quale è possibile disporre la crittografia su un altro server. Su un server remoto, nginx può essere utilizzato per generare traffico TLS, in analogia con il modo in cui è organizzato il binding HTTPS per i siti.
Un'altra caratteristica è l'integrazione di DoH come trasporto generale, che può essere utilizzato non solo per elaborare le richieste dei client al resolver, ma anche durante lo scambio di dati tra i server, il trasferimento di zone utilizzando un server DNS autorevole e l'elaborazione di eventuali richieste supportate da altri trasporti DNS.
Tra le carenze che si possono ovviare disabilitando la compilazione con DoH / DoT o spostando la crittografia su un altro server, viene evidenziata la complicazione generale del codebase- Un server HTTP integrato e una libreria TLS vengono aggiunti alla composizione, che può potenzialmente contenere vulnerabilità e agire come vettori di attacco aggiuntivi. Inoltre, quando viene utilizzato DoH, il traffico aumenta.
Devi ricordarlo DNS-over-HTTPS può essere utile per evitare fughe di informazionilavorare sui nomi host richiesti attraverso i server DNS dei provider, combattere gli attacchi MITM e falsificare il traffico DNS, contrastare il blocco a livello DNS o organizzare il lavoro in caso di impossibilità di accesso diretto ai server DNS.
Si, in una situazione normale, le richieste DNS vengono inviate direttamente ai server DNS definiti nella configurazione del sistema, quindi, nel caso di DNS su HTTPS, la richiesta di determinare l'indirizzo IP dell'host è incapsulato nel traffico HTTPS e inviato al server HTTP, in cui il resolver elabora le richieste tramite l'API web.
"DNS su TLS" differisce da "DNS su HTTPS" utilizzando il protocollo DNS standard (in genere viene utilizzata la porta di rete 853) avvolto in un canale di comunicazione crittografato organizzato utilizzando il protocollo TLS con convalida dell'host tramite certificati TLS / SSL certificato da una certificazione. autorità.
Infine, si è detto che DoH è disponibile per i test nella versione 9.17.10 e il supporto DoT è attivo dalla 9.17.7, inoltre una volta stabilizzato, il supporto per DoT e DoH si sposterà nel ramo stabile 9.16.