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\u00e0 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\u00e0 a marzo, mentre quello per la versione 9.16 a met\u00e0 del 2023. \u00c8 stata formata una versione sperimentale BIND 9.19.0 per lo sviluppo delle funzionalit\u00e0 della prossima versione stabile di BIND. <\/p>\n
La versione BIND 9.18.0 \u00e8 notevole per l'implementazione del supporto per le tecnologie \u00abDNS over HTTPS\u00bb (DoH, DNS over HTTPS) e DNS over TLS (DoT, DNS over TLS), nonch\u00e9 per il 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 tramite XoT). Con le impostazioni appropriate, un processo named ora pu\u00f2 gestire non solo le tradizionali richieste DNS, ma anche le richieste inviate utilizzando DNS-over-HTTPS e DNS-over-TLS. Il supporto client per DNS-over-TLS \u00e8 integrato nell'utilit\u00e0 dig, che pu\u00f2 essere utilizzata per inviare richieste tramite TLS specificando il flag \u00ab+tls\u00bb. <\/p>\n
L'implementazione del protocollo HTTP\/2, utilizzato in DoH, si basa sull'uso della libreria nghttp2, che \u00e8 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. <\/p>\n
L'elaborazione delle richieste utilizzando DoH e DoT \u00e8 attivata aggiungendo le opzioni \u00abhttp\u00bb e \u00abtls\u00bb nella direttiva listen-on. Per supportare DNS-over-HTTP non crittografato, nelle impostazioni \u00e8 necessario specificare \u00abtls none\u00bb. Le chiavi sono definite nella sezione \u00abtls\u00bb. 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: <\/p>\n
tls local-tls { key-file \u00ab\/path\/to\/priv_key.pem\u00bb; cert-file \u00ab\/path\/to\/cert_chain.pem\u00bb; }; http local-http-server { endpoints { \u00ab\/dns-query\u00bb; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
Una delle caratteristiche della realizzazione di DoH in BIND \u00e8 la possibilit\u00e0 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 \u00e8 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\u00f2 essere utilizzato per generare il traffico TLS, analogamente a come viene organizzato il collegamento HTTPS per i siti. <\/p>\n
Un'altra caratteristica \u00e8 l'integrazione di DoH come trasporto comune, che pu\u00f2 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. <\/p>\n
Tra gli svantaggi, che possono essere compensati disattivando il build con DoH\/DoT o trasferendo la crittografia su un altro server, si evidenzia la complessit\u00e0 generale del codice \u2014 viene inclusa un server HTTP integrato e una libreria TLS, che possono potenzialmente contenere vulnerabilit\u00e0 e fungere da ulteriori vettori di attacco. Inoltre, l'uso di DoH aumenta il traffico. <\/p>\n
Ricordiamo che il DNS-over-HTTPS pu\u00f2 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\u00f2 sostituire VPN<\/a> 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<\/a> l'host \u00e8 incapsulata nel traffico HTTPS e inviata a un server HTTP, dove il resolver gestisce le richieste tramite Web API. <\/p>\n \u00abDNS over TLS\u00bb si differenzia da \u00abDNS over HTTPS\u00bb per l'uso del protocollo DNS standard (normalmente utilizza la porta di rete 853), incapsulato in un canale di comunicazione crittografato, organizzato tramite il protocollo TLS con verifica della validit\u00e0 dell'host tramite certificati TLS\/SSL emessi da un'autorit\u00e0 di certificazione. Lo standard attuale DNSSEC utilizza la crittografia solo per l'autenticazione del client e del server, ma non protegge il traffico dall'intercettazione e non garantisce la riservatezza delle richieste. <\/p>\n Alcune altre novit\u00e0: <\/p>\n\n