Per oltre trent’anni, WINS (Windows Internet Naming Service) è rimasto lì: nascosto nelle profondità della configurazione di rete di Windows, silenzioso. Si tratta dell’eredità dei tempi in cui Internet era giovane e le reti aziendali parlavano ancora con il protocollo NetBIOS. Parliamo all’imperfetto ma WINS continua a sopravvivere negli ambienti legacy, soprattutto dove esistono applicazioni sviluppate negli anni ’90 o primi anni 2000 che dipendono da NetBIOS e sono ancora presenti vecchie condivisioni SMB 1.0 (purtroppo ancora attive in alcune realtà industriali, ospedaliere e produttive). Ora Microsoft ha deciso: Windows Server 2025 sarà l’ultima versione a supportare WINS. Dopo di essa, la storia si chiuderà.
Dal 1994 al 2034: il lungo addio a WINS
Quando WINS debuttò con Windows NT 3.5 nel 1994, le reti erano un mondo completamente diverso. Cloud, Zero Trust, IPv6 e automazione erano concetti di fatto inesistenti. Le aziende dipendevano pesantemente da NetBIOS: WINS era il meccanismo essenziale che permetteva ai dispositivi di trovarsi e comunicare.
Con annuncio ufficiale Microsoft fa presente che nessuna futura release di Windows Server includerà WINS. Il supporto continuerà solo per la durata del ciclo di vita di Windows Server 2025, fino al 14 novembre 2034. È un addio lento, ma definitivo.
Perché eliminare WINS ora?
Le ragioni non riguardano solo l’obsolescenza. Microsoft punta il dito su quattro aspetti chiave:
- DNS è lo standard universale. È scalabile, distribuito, conforme agli standard internazionali. WINS, al contrario, si basa su un modello di replica centralizzato nato per un’epoca diversa. In una rete interna è possibile avere DNS server locali (Windows Server, Linux, appliance dedicate, DNS integrati nel firewall, ecc.) che risolvono i nomi delle macchine interne, i nomi dei servizi (SMB, applicazioni, stampanti, server, ecc.), le zone private (ad esempio,
azienda.local,corp.internal,studio.lan). Il DNS locale è responsabile esclusivamente della rete interna: se un nome non appartiene alla zona interna, il DNS inoltra la richiesta verso Internet e interroga i resolver di livello superiore. - La sicurezza non è più negoziabile. DNS può essere protetto con DNSSEC. WINS no. E nel 2025, un servizio privo di mitigazioni contro attacchi spoofing e cache poisoning è semplicemente impossibile da difendere.
- Le applicazioni moderne parlano solo via DNS. Active Directory, i servizi cloud di Microsoft, le API più recenti: tutto richiede DNS. Mantenere WINS significa restare legati a software legacy che prima o poi andrà aggiornato o dismesso.
- Razionalizzazione dell’ecosistema Windows. Microsoft ha una roadmap precisa: rimuovere progressivamente tutti i componenti non più strategici. WINS è da anni indicato nei documenti ufficiali tra le funzionalità “destinate a sparire”.
Cosa scomparirà esattamente?
Quando WINS sarà rimosso, spariranno da Windows Server il ruolo di WINS Server e i file binari associati, lo snap-in MMC (Microsoft Management Console) per la gestione, le API di automazione e tutte le interfacce di gestione derivate. In pratica, non si potrà più installarlo, gestirlo o integrarlo all’interno di script e altri strumenti di automazione.
La maggior parte delle organizzazioni moderne utilizza DNS da anni. Tuttavia, il problema non sono i server moderni, ma le applicazioni e i sistemi legacy che ancora dipendono da NetBIOS. Si pensi a software verticali molto datati, applicazioni sviluppate internamente negli anni ’90/2000, condivisioni SMB basate su vecchi standard, segmenti di rete mai completamente modernizzati.
Per queste realtà, la rimozione di WINS non è un dettaglio: è un campanello d’allarme. Microsoft sottolinea che le infrastrutture IT devono liberarsi definitivamente del passato e migrare verso un ecosistema pienamente basato sul DNS.
Ad ogni modo, la rimozione definitiva del supporto per WINS arriverà soltanto con l’esaurimento del ciclo di vita di Windows Server 2025 (fatto salvo il successivo supporto ESU, Extended Security Updates). Ci sono quindi quasi 10 anni di tempo per pianificare, testare, migrare e consolidare l’infrastruttura. Il consiglio è quello di concludere la migrazione molto prima.