OpenVPN 2.7 accelera con DCO e ridisegna DNS, IPFire DBL porta il blocco domini community-driven

Nel 2026 la sicurezza di rete sta diventando una partita giocata su due livelli. Da un lato c’è la VPN che deve smettere di essere “solo cifratura” e diventare performance, flessibilità e controllo fine su routing e DNS, soprattutto in ambienti ibridi. Dall’altro c’è il filtraggio a livello dominio che, per reggere la scala delle minacce, deve essere aggiornato spesso, interoperabile e abbastanza semplice da integrare in infrastrutture reali, dai resolver enterprise fino ai setup domestici.

È in questo contesto che arrivano OpenVPN 2.7 e IPFire DBL. La prima release spinge sull’accelerazione nel kernel e su un modello di gestione più moderno delle configurazioni dinamiche. La seconda introduce una lista domini “viva”, guidata dalla community, pensata per entrare in DNS e proxy senza reinventare la ruota.

OpenVPN 2.7: DCO nel kernel Linux e un cambio di passo su performance e architettura

Il titolo tecnico di OpenVPN 2.7 è il supporto al modulo DCO (Data Channel Offload) su Linux, affiancato dall’integrazione di mbedTLS 4. DCO è rilevante perché sposta parte del lavoro del canale dati nel kernel, con l’obiettivo pratico di ridurre overhead e aumentare throughput, senza cambiare l’idea di base di OpenVPN. In parallelo, l’allineamento a mbedTLS 4 consolida una base crittografica più moderna e coerente con TLS contemporaneo.

Il punto, però, non è solo la “velocità”: OpenVPN 2.7 prova a risolvere un problema strutturale tipico delle VPN classiche, cioè la gestione di scenari complessi senza moltiplicare istanze e file di configurazione.

Server multi-socket: più indirizzi, porte e protocolli con una sola istanza

OpenVPN 2.7 potenzia il modello multi-socket, permettendo a un singolo server di gestire indirizzi, porte e protocolli multipli. È un dettaglio che pesa molto in ambienti reali: gateway con più IP, transizioni di servizio, coexistence TCP/UDP, segmentazioni interne, o semplicemente esigenze di compatibilità con client diversi. Invece di mantenere più processi con logiche duplicate, il server può accorpare e orchestrare meglio.

Questo riduce complessità operativa e, spesso, riduce anche errori: meno istanze significa meno configurazioni fuori sync e meno casi in cui una modifica viene applicata “solo” a metà infrastruttura.

DNS più serio su tutte le piattaforme: split DNS e DNSSEC come pezzi centrali

OpenVPN 2.7 estende il supporto DNS su Linux, BSD, macOS e Windows, introducendo un impianto più ricco che include split DNS e DNSSEC. Split DNS è il classico elemento che separa un tunnel “funziona” da un tunnel “è usabile”: alcune zone devono risolvere dentro la rete aziendale o in un resolver specifico, mentre il resto può restare sul resolver locale o su un resolver pubblico controllato.

Il supporto a DNSSEC aggiunge un livello di garanzia sull’integrità della risoluzione, riducendo spazio per attacchi di manipolazione o MITM su percorsi DNS fragili. In un contesto in cui molti endpoint passano da Wi-Fi pubblico a hotspot, la qualità del DNS non è più un dettaglio.

PUSH_UPDATE: routing e DNS cambiano senza riconnessioni

Una novità chiave è l’uso di PUSH_UPDATE, che consente al client di ricevere aggiornamenti dinamici di routing e DNS senza dover disconnettere e riconnettere la VPN. In pratica, OpenVPN 2.7 prova a portare nel suo mondo un concetto “da rete moderna”: lo stato può cambiare e l’endpoint deve adattarsi in modo controllato.

Il server può inviare PUSH_UPDATE tramite interfaccia management, sia in modo “broad” sia mirato a specifici client. Questo è particolarmente utile per policy che cambiano nel tempo, split routing per risorse temporanee, migrazioni di DNS interni o rotazioni di infrastruttura.

Windows: block-local più robusto, adattatori on-demand e servizi meno privilegiati

La parte Windows è quella che cambia più visibilmente “sotto il cofano”. OpenVPN 2.7 rafforza il flag block-local usando filtri WFP (Windows Filtering Platform), quindi con una logica più aderente al firewalling di Windows e più efficace nel prevenire fughe di traffico verso la rete locale quando non dovrebbe.

Inoltre, l’architettura genera adattatori di rete on-demand, e introduce un modello di servizi che possono girare non privilegiati. È un passaggio importante perché sposta la postura di sicurezza da “servizio amministrativo permanente” a “componenti che minimizzano privilegi”, riducendo impatto potenziale se qualcosa va storto.

Sul fronte DCO, il driver win-dco arriva a supportare anche la modalità server, mentre alcune deprecazioni puliscono il quadro: viene indicata l’eliminazione del driver wintun, con win-dco come default e tap-windows6 come fallback. In parallelo vengono aggiornati e riposizionati elementi come licenze e componenti installer in repository dedicati, segnale di una filiera più ordinata.

Canale dati: limiti AES-GCM, epoch keys e formato pacchetti aggiornato

OpenVPN 2.7 introduce modifiche al data channel con limiti su AES-GCM, uso di chiavi epoch e un formato pacchetti aggiornato. L’idea operativa è ridurre rischi legati a riuso o gestione non ottimale di chiavi e parametri crittografici, con un impianto più “moderno” anche lato trasporto.

Routing ricorsivo più granulare: drop solo quando serve davvero

Altro punto pratico: il controllo di routing ricorsivo diventa più granulare e scarta pacchetti tunnel solo se combaciano IP, protocollo e porta del server VPN. Questo riduce i casi in cui un meccanismo di protezione finisce per essere troppo aggressivo e interrompe traffico che non dovrebbe essere toccato, un problema che in certe reti complesse può trasformarsi in disservizio.

IPFire DBL: blocco domini community-driven e integrabile come “strato di policy”

Sul fronte firewall e DNS filtering, IPFire introduce DBL, una lista di blocco domini guidata dalla community, con un impianto pensato per l’adozione: milioni di domini categorizzati e un set di formati che puntano a essere subito consumabili da resolver e proxy.

Categorie e obiettivo: dal malware al DNS-over-HTTPS

DBL categorizza domini in classi come malware, phishing, advertising, pornography, gambling, games e DNS-over-HTTPS. La presenza della categoria DoH è un segnale chiaro: molte policy di rete saltano quando i client bypassano i resolver aziendali usando DoH, riducendo visibilità e enforcement. Inserire DoH come categoria vuol dire trattarlo come un problema di governance, non come “feature privacy” neutra.

Standard aperti e integrazioni: RPZ, AXFR/IXFR, SquidGuard, Adblock syntax

DBL è pensato per stare in ambienti diversi. Supporta integrazione via RPZ (Response Policy Zone) con trasferimenti AXFR/IXFR, quindi con un modello da “zona DNS” che si aggiorna in modo efficiente. Per chi usa proxy, viene citato SquidGuard. Esistono anche modalità di download via HTTPS in formato plaintext e compatibilità con sintassi Adblock Plus, utile per estensioni browser o tooling di filtraggio.

Il valore qui è l’interoperabilità: DBL non chiede di adottare “il mondo IPFire”, ma di usare meccanismi che già esistono in molti stack.

Aggiornamenti orari e reporting: la lista vive, non è un file statico

DBL aggiorna i dati ogni ora, e include un tool di reporting online per segnalare falsi positivi o domini malevoli non ancora inclusi. Questo è il cuore del modello community-driven: la lista deve reagire rapidamente, ma deve anche ridurre l’inevitabile attrito del blocco per categorie, che altrimenti diventa ingestibile in contesti business.

Licenze e sostenibilità: GPLv3+ e CC BY-SA 4.0 per favorire contributi

IPFire posiziona DBL con licenze aperte: GPLv3+ per il codice e CC BY-SA 4.0 per le liste. È una scelta che spinge al riuso e alla contribuzione, e viene supportata anche da un fundraiser che punta a sviluppi come l’integrazione RPZ più profonda.

Integrazione in Core Update 200: URL Filter e Suricata per enforcement e visibilità

DBL entra in IPFire tramite Core Update 200, con integrazione attraverso URL Filter e riferimenti a Suricata per aumentare visibilità di rete ed enforcement. Il messaggio è che DBL non vuole essere solo “adblock di rete”, ma una parte del framework di policy.

Nel testo viene citata la facilità di adozione su resolver e tool diffusi come BIND, Unbound, PowerDNS, Pi-hole, oltre a estensioni browser. In pratica, DBL tenta di diventare un mattone riutilizzabile in qualunque rete, non solo su IPFire.

OpenVPN 2.7 e IPFire DBL: cosa cambia davvero per chi gestisce reti

OpenVPN 2.7 spinge verso una VPN più moderna: DCO per performance, multi-socket per architetture meno frammentate, PUSH_UPDATE per configurazioni dinamiche, e un lavoro profondo su DNS e Windows security posture. IPFire DBL, invece, porta un livello di difesa “a monte” che blocca domini su scala, con un impianto aggiornato ogni ora e integrabile in infrastrutture DNS e proxy già esistenti. Il punto comune è che entrambi cercano di ridurre attriti operativi: OpenVPN elimina riconnessioni e semplifica topologie, DBL riduce il tempo tra comparsa di una minaccia e blocco effettivo.