Dopo due anni di sviluppo, il consorzio ISC ha rilasciato la prima versione stabile di un nuovo importante ramo del server DNS BIND 9.18. Il supporto per il ramo 9.18 sarà fornito per tre anni fino al 2° trimestre del 2025 come parte di un ciclo di supporto esteso. Il supporto per il ramo 9.11 terminerà a marzo, mentre il supporto per il ramo 9.16 a metà del 2023. Per sviluppare le funzionalità della prossima versione stabile di BIND è stato creato il ramo sperimentale BIND 9.19.0.
Il rilascio di BIND 9.18.0 si distingue per l'implementazione del supporto per DNS over HTTPS (DoH, DNS over HTTPS) e DNS over TLS (DoT, DNS over TLS), nonché per il meccanismo XoT (XFR-over-TLS) per il trasferimento sicuro di contenuti DNS tra server (sono supportate sia le zone di invio che quelle di ricezione tramite XoT). Con le impostazioni appropriate, un singolo processo denominato può ora servire non solo le query DNS tradizionali, ma anche le query inviate utilizzando DNS-over-HTTPS e DNS-over-TLS. Il supporto client per DNS-over-TLS è integrato nell'utilità dig, che può essere utilizzata per inviare richieste su TLS quando viene specificato il flag "+tls".
L'implementazione del protocollo HTTP/2 utilizzato in DoH si basa sull'uso della libreria nghttp2, inclusa come dipendenza dell'assembly opzionale. I certificati per DoH e DoT possono essere forniti dall'utente o generati automaticamente al momento dell'avvio.
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. Per esempio:
tls local-tls { file-chiave "/percorso/della/chiave_priv.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;}; }
Una delle caratteristiche dell'implementazione DoH in BIND è la possibilità di spostare le operazioni di crittografia per TLS su un altro server, che potrebbe 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 a un altro server sulla rete interna (per spostare la crittografia su un server separato). 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.
Un'altra caratteristica è l'integrazione di DoH come trasporto generale che può essere utilizzato non solo per gestire le richieste del client al risolutore, ma anche durante la comunicazione tra server, durante il trasferimento di zone tramite un server DNS autorevole e durante l'elaborazione di eventuali query supportate da altri DNS. trasporti.
Tra le carenze che possono essere compensate disabilitando la build con DoH/DoT o spostando la crittografia su un altro server, spicca la complicazione generale del codice base: vengono aggiunti un server HTTP integrato e una libreria TLS, che potrebbe potenzialmente contenere vulnerabilità e fungono da vettori aggiuntivi per gli attacchi. Inoltre, quando si utilizza DoH, il traffico aumenta.
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.
Alcune altre innovazioni:
- Aggiunte le impostazioni tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer e udp-send-buffer per impostare le dimensioni dei buffer utilizzati durante l'invio e la ricezione di richieste su TCP e UDP. Sui server occupati, l'aumento dei buffer in entrata aiuterà a evitare la perdita di pacchetti durante i picchi di traffico, mentre la loro riduzione aiuterà a eliminare l'intasamento della memoria con vecchie richieste.
- È stata aggiunta una nuova categoria di registro "rpz-passthru", che consente di registrare separatamente le azioni di inoltro RPZ (Response Policy Zones).
- Nella sezione policy-risposta è stata aggiunta l'opzione “nsdname-wait-recurse”, se impostata su “no”, le regole RPZ NSDNAME vengono applicate solo se per la richiesta vengono trovati name server autorevoli presenti nella cache, altrimenti La regola RPZ NSDNAME viene ignorata, ma le informazioni vengono recuperate in background e applicate alle richieste successive.
- Per i record con tipologia HTTPS e SVCB è stata implementata l'elaborazione della sezione “ADDITIONAL”.
- Aggiunti tipi di regole di policy di aggiornamento personalizzate: krb5-subdomain-self-rhs e ms-subdomain-self-rhs, che consentono di limitare l'aggiornamento dei record SRV e PTR. I blocchi della policy di aggiornamento aggiungono anche la possibilità di impostare limiti al numero di record, individuali per ciascun tipo.
- Aggiunte informazioni sul protocollo di trasporto (UDP, TCP, TLS, HTTPS) e sui prefissi DNS64 all'output dell'utilità dig. Per scopi di debug, dig ha aggiunto la possibilità di specificare un identificatore di richiesta specifico (dig +qid= ).
- Aggiunto il supporto per la libreria OpenSSL 3.0.
- Per risolvere i problemi relativi alla frammentazione IP durante l'elaborazione di messaggi DNS di grandi dimensioni identificati dal DNS Flag Day 2020, il codice che regola la dimensione del buffer EDNS quando non c'è risposta a una richiesta è stato rimosso dal risolutore. La dimensione del buffer EDNS è ora impostata su costante (edns-udp-size) per tutte le richieste in uscita.
- Il sistema di compilazione è stato modificato utilizzando una combinazione di autoconf, automake e libtool.
- Il supporto per i file di zona nel formato "mappa" (mappa in formato masterfile) è stato interrotto. Agli utenti di questo formato si consiglia di convertire le zone in formato raw utilizzando l'utilità denominata-compilezone.
- Il supporto per i vecchi driver DLZ (Dynamically Loadable Zones) è stato interrotto e sostituito dai moduli DLZ.
- Il supporto per la creazione e l'esecuzione della piattaforma Windows è stato interrotto. L'ultimo ramo che può essere installato su Windows è BIND 9.16.
Fonte: opennet.ru