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à fornito per tre anni, fino al secondo trimestre del 2025, nell'ambito di un ciclo di supporto esteso. Il supporto per la versione 9.11 terminerà a marzo, mentre quello della versione 9.16 a metà 2023. Per sviluppare le funzionalità della prossima versione stabile, è stata creata una versione sperimentale di BIND 9.19.0.
Il rilascio di BIND 9.18.0 è notevole per l'implementazione del supporto delle tecnologie 'DNS over HTTPS' (DoH) e DNS over TLS (DoT), oltre al meccanismo XoT (XFR-over-TLS) per la trasmissione sicura dei contenuti delle zone DNS tra i server (supporta sia l'invio che la ricezione delle zone via XoT). Con le impostazioni appropriate, 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 del 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 build opzionali. I certificati per DoH e DoT possono essere forniti dall'utente o generati automaticamente al momento dell'avvio.
La gestione delle richieste utilizzando DoH e DoT viene attivata aggiungendo le opzioni «http» e «tls» nella direttiva listen-on. Per supportare il DNS-over-HTTP non crittografato, nelle impostazioni bisogna 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. Per 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 dell'implementazione di DoH in BIND è la possibilità di spostare le operazioni di crittografia per TLS su un altro server. Questo può essere necessario quando i certificati TLS sono memorizzati su un altro sistema, ad esempio in infrastrutture con server web, e gestiti da un altro personale. Il supporto per DNS-over-HTTP non crittografato è implementato per facilitare il debug e come livello per il reindirizzamento verso un altro server nella rete interna (per spostare la crittografia su un server separato). Su un server dedicato, nginx può essere utilizzato per generare il traffico TLS, analogamente a come viene strutturato il binding HTTPS per i siti web.
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 durante lo scambio di dati tra server, nella trasmissione di zone da un server DNS autorevole e nel trattamento di qualsiasi richiesta supportata da altri trasporti DNS.
Tra i difetti che possono essere compensati disattivando il montaggio con DoH/DoT o spostando la crittografia su un altro server, emerge la complessità generale del codice: viene aggiunto un server HTTP integrato e una libreria TLS, che possono contenere vulnerabilità e costituire ulteriori vettori di attacco. Inoltre, l'uso di DoH aumenta il traffico.
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.
Alcune altre novità:
- Sono state aggiunte le impostazioni tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer e udp-send-buffer per definire le dimensioni dei buffer utilizzati per inviare e ricevere richieste TCP e UDP. Su server sovraccarichi, l'aumento dei buffer in entrata consentirà di evitare la perdita di pacchetti durante i picchi di traffico, mentre la loro riduzione aiuterà a prevenire l'intasamento della memoria con richieste obsolete.
- È stata aggiunta una nuova categoria di log "rpz-passthru", che consente di registrare separatamente le azioni di passaggio delle RPZ (Response Policy Zones).
- Nella sezione response-policy è stata aggiunta l'opzione «nsdname-wait-recurse», che, se impostata su «no», fa sì che le regole RPZ NSDNAME si applichino solo se esistono server DNS autorizzati presenti nella cache per la richiesta; altrimenti, la regola RPZ NSDNAME viene ignorata, ma le informazioni vengono comunque estratte in background e applicate alle richieste successive.
- Per i record con tipi HTTPS e SVCB è stata implementata la gestione della sezione «ADDITIONAL».
- Sono stati 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 anche aggiunta la possibilità di impostare limiti sul numero di record, distinti per ciascun tipo.
- Nell'output dello strumento 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=).
- È stato aggiunto il supporto per la libreria OpenSSL 3.0.
- Per risolvere i problemi di frammentazione IP durante l'elaborazione dei messaggi DNS di grandi dimensioni, contrassegnati dall'iniziativa DNS Flag Day 2020, è stato rimosso dal resolver il codice che effettuava la correzione delle dimensioni del buffer EDNS in caso di mancata risposta alla richiesta. La dimensione del buffer EDNS è ora impostata in modo fisso (edns-udp-size) per tutte le richieste in uscita.
- Il sistema di build è stato aggiornato per utilizzare la combinazione di autoconf, automake e libtool.
- È stata interrotta la supporto per i file di zona nel formato "map" (masterfile-format map). Agli utenti di questo formato è consigliato convertire le zone nel formato raw utilizzando l'utilità named-compilezone.
- È stata interrotta la supporto per i vecchi driver DLZ (Dynamically Loadable Zones), sostituiti da moduli DLZ.
- È stata interrotta la supporto per la compilazione e l'esecuzione sulla piattaforma Windows. L'ultima branch installabile su Windows rimane BIND 9.16.
Fonte: opennet.ru
