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 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\u00e0 a marzo, mentre quello della versione 9.16 a met\u00e0 2023. Per sviluppare le funzionalit\u00e0 della prossima versione stabile, \u00e8 stata creata una versione sperimentale di BIND 9.19.0. <\/p>\n
Il rilascio di BIND 9.18.0 \u00e8 significativo per l'implementazione del supporto per le tecnologie \u00abDNS su HTTPS\u00bb (DoH, DNS over HTTPS) e DNS su TLS (DoT, DNS over TLS), cos\u00ec come per il meccanismo XoT (XFR-over-TLS) per la trasmissione sicura dei contenuti delle zone DNS tra i server (supportato sia per l'invio che per la ricezione delle zone tramite XoT). Con le configurazioni appropriate, un processo named pu\u00f2 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 \u00e8 integrato nell'utilit\u00e0 dig, che pu\u00f2 essere utilizzata per inviare richieste sopra TLS utilizzando l'opzione \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 build opzionali. I certificati per DoH e DoT possono essere forniti dall'utente o generati automaticamente al momento dell'avvio. <\/p>\n
La gestione delle richieste utilizzando DoH e DoT viene attivata aggiungendo le opzioni \u00abhttp\u00bb e \u00abtls\u00bb nella direttiva listen-on. Per supportare il DNS-over-HTTP non crittografato, le impostazioni devono 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 ; cert-file ; }; http local-http-server { endpoints { ; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
Una delle caratteristiche dell'implementazione di DoH in BIND \u00e8 la possibilit\u00e0 di spostare le operazioni di crittografia per TLS su un altro server. Questo pu\u00f2 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 \u00e8 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\u00f2 essere utilizzato per generare il traffico TLS, analogamente a come viene strutturato il binding HTTPS per i siti web. <\/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 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. <\/p>\n
Tra i difetti che possono essere compensati disabilitando la build con DoH\/DoT o trasferendo la crittografia su un altro server, spicca la complessit\u00e0 generale del codice \u2014 la base comprende un server HTTP integrato e una libreria TLS, che possono potenzialmente contenere vulnerabilit\u00e0 e costituire ulteriori vettori per attacchi. Inoltre, l'uso di DoH aumenta il traffico. <\/p>\n
Ricordiamo che DNS-over-HTTPS pu\u00f2 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\u00f2 sostituire VPN<\/a> nel campo dell'aggiramento delle restrizioni implementate a livello DPI) o per organizzare il funzionamento nel caso di impossibilit\u00e0 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<\/a> del host \u00e8 incapsulata nel traffico HTTPS e inviata a un server HTTP, dove il risolutore elabora le richieste tramite un'API Web. <\/p>\n \u00abDNS over TLS\u00bb si differenzia da \u00abDNS over HTTPS\u00bb per l'utilizzo del protocollo DNS standard (solitamente sulla porta di rete 853), incapsulato in un canale di comunicazione crittografato tramite il protocollo TLS, con verifica della validit\u00e0 dell'host tramite certificati TLS\/SSL rilasciati da un'autorit\u00e0 di certificazione. Lo standard esistente 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 query. <\/p>\n Alcune altre novit\u00e0: <\/p>\n\n