Dopo due anni di sviluppo, il consorzio ISC ha presentato il primo rilascio stabile della nuova e significativa versione del server DNS BIND 9.18. Il supporto per la versione 9.18 sarà garantito per tre anni fino al secondo trimestre del 2025 nell'ambito di un ciclo prolungato di assistenza. Il supporto per la versione 9.11 terminerà a marzo, mentre quello per la versione 9.16 a metà del 2023. È stata formata una versione sperimentale BIND 9.19.0 per lo sviluppo delle funzionalità della prossima versione stabile di BIND.
Il rilascio di BIND 9.18.0 è notevole per l'implementazione del supporto delle tecnologie 'DNS over HTTPS' (DoH, DNS su HTTPS) e DNS over TLS (DoT, DNS su TLS), così come il meccanismo XoT (XFR-over-TLS) per il trasferimento sicuro dei contenuti delle zone DNS tra i server (supportato sia per l'invio che per la ricezione delle zone via XoT). Con le opportune impostazioni, un processo named può ora gestire non solo le tradizionali richieste DNS, ma anche quelle 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 specificando il flag '+tls'.
L'implementazione del protocollo HTTP/2, utilizzato in DoH, si basa sull'uso della libreria nghttp2, che è inclusa tra le dipendenze di costruzione opzionali. I certificati per DoH e DoT possono essere forniti dall'utente o generati automaticamente al momento dell'avvio.
Il trattamento delle richieste utilizzando DoH e DoT viene attivato aggiungendo le opzioni 'http' e 'tls' nella direttiva listen-on. Per supportare il DNS-over-HTTP non crittografato, nelle impostazioni si deve specificare '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;}; }
Una delle caratteristiche della realizzazione di DoH in BIND è la possibilità di spostare le operazioni di crittografia TLS su un altro server, cosa che potrebbe essere necessaria in situazioni in cui i certificati TLS sono memorizzati su un altro sistema (ad esempio, in un'infrastruttura con server web) e gestiti da un altro personale. Il supporto per DNS-over-HTTP non crittografato è implementato per semplificare il debug e come livello per inoltrare a un altro server nella rete interna (per spostare la crittografia su un server separato). Su un server esterno, nginx può essere utilizzato per generare il traffico TLS, analogamente a come viene organizzato il collegamento HTTPS per i siti.
Un'altra caratteristica è l'integrazione di DoH come trasporto comune, che può essere utilizzato non solo per elaborare le richieste dei clienti verso il resolver, ma anche nello scambio di dati tra server, per il trasferimento di zone da un server DNS autoritativo e per l'elaborazione di qualsiasi richiesta supportata da altri trasporti DNS.
Tra gli svantaggi che si possono compensare disabilitando la costruzione con DoH/DoT o spostando la crittografia su un altro server si evidenzia la complessità generale della base di codice: viene aggiunto un server HTTP integrato e una libreria TLS, che potrebbero potenzialmente contenere vulnerabilità e fungere da ulteriori vettori per attacchi. Inoltre, l'uso di DoH aumenta il traffico.
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.
Alcune altre novità:
- Aggiunti parametri tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer e udp-send-buffer per definire le dimensioni dei buffer utilizzati per l'invio e la ricezione delle richieste TCP e UDP. Su server congestionati, l'aumento dei buffer in entrata aiuterà a evitare la perdita di pacchetti durante i picchi di traffico, mentre la loro riduzione contribuirà a eliminare l'accumulo di richieste obsolete nella memoria.
- Aggiunta una nuova categoria di log «rpz-passthru», che consente di registrare separatamente le azioni di inoltro delle RPZ (Response Policy Zones).
- Nella sezione response-policy è stata aggiunta l'opzione «nsdname-wait-recurse», che, se impostata su «no», applica la regola RPZ NSDNAME solo se per la richiesta vengono trovati server di nome autorevoli presenti nella cache, altrimenti la regola RPZ NSDNAME viene ignorata, ma le informazioni vengono estratte in background e applicate alle richieste successive.
- Per i record di tipo HTTPS e SVCB è stata implementata la gestione della sezione «ADDITIONAL».
- Aggiunti tipi di regole configurabili update-policy — krb5-subdomain-self-rhs e ms-subdomain-self-rhs, che consentono di limitare l'aggiornamento dei record SRV e PTR. Nei blocchi update-policy è stata inoltre aggiunta la possibilità di impostare limiti sul numero di record, specifici per ciascun tipo.
- Nell'output dell'utilità dig sono state aggiunte informazioni sul protocollo di trasporto (UDP, TCP, TLS, HTTPS) e sui prefissi DNS64. Per scopi di debug, in dig è stata aggiunta la possibilità di specificare un identificatore di richiesta specifico (dig +qid=).
- Aggiunta la compatibilità con la libreria OpenSSL 3.0.
- Per affrontare problemi di frammentazione IP durante l'elaborazione di messaggi DNS di grandi dimensioni, come indicato dall'iniziativa DNS Flag Day 2020, il codice che eseguiva la regolazione delle dimensioni del buffer EDNS in assenza di risposta alla richiesta è stato rimosso dal resolver. La dimensione del buffer EDNS è ora impostata in modo fisso (edns-udp-size) per tutte le richieste in uscita.
- Il sistema di build è stato migrato per utilizzare una combinazione di autoconf, automake e libtool.
- Il supporto per i file di zona nel formato «map» (masterfile-format map) è stato interrotto. Si consiglia agli utenti di questo formato di convertire le zone in formato raw utilizzando l'utilità named-compilezone.
- È stata interrotta la compatibilità con i vecchi driver DLZ (Dynamically Loadable Zones), sostituiti dai moduli DLZ.
- È stato interrotto il supporto per la compilazione e l'esecuzione sulla piattaforma Windows. L'ultima versione installabile su Windows rimane BIND 9.16.
Fonte: opennet.ru
