La Public Suffix List (PSL), un elenco mantenuto dalla comunità Mozilla e incorporato in browser e librerie software, è tornata al centro del dibattito sulla sicurezza del web. In un commento pubblicato il 15 ottobre su CircleID, Ben Gibbs, CEO di Last Mile Labs, sostiene che la lista sia diventata una dipendenza troppo ampia per un file statico aggiornato da volontari e chiede di superarla con strumenti più automatici e controllabili dagli operatori.
La proposta è radicale e va letta per quello che è: una posizione dell’autore, non una decisione di Mozilla, dell’IETF o di ICANN. Il tema però ha conseguenze concrete per chi gestisce domini, registry, servizi multi-tenant e infrastrutture di posta, perché la PSL è usata per stabilire dove finiscono i confini amministrativi tra un dominio e i suoi sottodomini.
Leggi anche: DNSSEC, il dossier ICANN sull’automazione dei record DS
Un elenco diventato infrastruttura condivisa
La PSL associa regole a suffissi come .com e .co.uk, ma anche a spazi privati nei quali una piattaforma assegna sottodomini ai propri utenti, come github.io. In quest’ultimo caso, per esempio, distinguere alice.github.io da bob.github.io aiuta un browser a non trattare i due account come se appartenessero allo stesso sito. ICANN, in una guida tecnica per gli amministratori dei TLD, descrive la lista come un componente utile a browser e applicazioni, cita l’isolamento dei cookie e dei processi e spiega che le regole possono incidere anche sull’individuazione del dominio organizzativo usata da alcuni software.
Gibbs concentra la critica sul divario tra questa diffusione e il modello operativo della lista: un file testuale replicato in prodotti software, con versioni diverse distribuite nei diversi cicli di aggiornamento e criteri d’inclusione che, secondo l’autore, possono penalizzare i servizi più piccoli. Da qui la sua richiesta di sostituire la PSL con primitive tecniche definite dagli operatori e coordinamento tra browser, autorità di certificazione e comunità DNS. Queste valutazioni sono argomentazioni dell’autore: non costituiscono una misurazione indipendente dei rischi né dimostrano che tutti i consumatori della PSL abbiano gli stessi problemi.
Che cosa cambia per registrar e registry
La questione non riguarda soltanto i browser. Quando un software deve capire se shop.example.co.uk appartiene all’organizzazione che controlla example.co.uk, deve applicare una regola coerente con la struttura dei suffissi. Lo stesso tipo di distinzione interessa servizi di autenticazione email, piattaforme che ospitano siti di terzi e strumenti che classificano domini. Un errore può portare sistemi diversi a raggruppare o separare nomi in modo divergente; un aggiornamento mancato può inoltre creare differenze tra versioni di un’applicazione.
Per gli operatori di registry il punto pratico è la qualità dei dati e il modo in cui un cambiamento delle regole di registrazione arriva ai software che dipendono dalla lista. La guida ICANN invita gli amministratori dei TLD a controllare che le informazioni relative al proprio spazio siano accurate e descrive il flusso di aggiornamento tramite repository. Il documento chiarisce anche un limite istituzionale: la PSL è gestita da manutentori esterni e non è sotto il controllo diretto di ICANN, IANA o IETF. Per i registrar e per chi vende domini, questo rende l’aggiornamento delle regole del registro e la loro rappresentazione nei sistemi a valle un tema di interoperabilità, non un semplice dettaglio editoriale.
Leggi anche: Sicurezza dei domini e continuità operativa: perché DNS e accessi contano
Il caso DMARC mostra un’evoluzione possibile
Un elemento concreto del dibattito è il nuovo standard DMARC. L’RFC 9989, pubblicato dall’IETF nel maggio 2026, ha sostituito RFC 7489 e cambiato il metodo usato per individuare il dominio organizzativo: al posto della dipendenza dalla PSL definisce una procedura di interrogazioni DNS chiamata “DNS Tree Walk”. L’RFC spiega che la specifica precedente non imponeva ai ricevitori di posta una particolare copia della lista né una frequenza di aggiornamento, circostanza che poteva contribuire a differenze d’interoperabilità.
È un precedente significativo, ma circoscritto. La nuova procedura riguarda DMARC e non sostituisce la PSL per le altre funzioni che browser, librerie o servizi possono ricavarne. La presenza di una soluzione standardizzata per un caso d’uso dimostra che si può ridurre una dipendenza specifica; non prova che l’intera lista sia pronta per la dismissione o che esista già un’alternativa universale. Servirebbero accordo tra i diversi utilizzatori, compatibilità durante la transizione e una gestione esplicita delle regole relative ai suffissi pubblici e privati.
Una transizione che richiede coordinamento
Abbandonare una base dati incorporata in browser, software e servizi non è un intervento che un singolo operatore può completare da solo. Una soluzione distribuita via DNS, per esempio, dovrebbe affrontare latenza, affidabilità, integrità delle risposte e comportamento quando un resolver o un’autorità non è raggiungibile. Una lista aggiornata in modo più dinamico potrebbe ridurre il ritardo tra cambiamento e adozione, ma richiederebbe regole condivise su chi può pubblicare le informazioni, come verificarle e come trattare gli errori o le contestazioni.
La proposta di Gibbs è utile soprattutto perché sposta l’attenzione dalla manutenzione del file alla governance di una dipendenza tecnica trasversale. Anche mantenere la PSL senza modifiche comporta scelte: chi contribuisce, quali richieste vengono accolte e come si riducono le differenze tra le implementazioni. Un percorso realistico potrebbe partire da casi d’uso ben delimitati, misurare le divergenze e definire standard interoperabili prima di modificare i comportamenti consolidati dei browser.
La lettura Webinvest
Il dibattito sulla PSL riguarda la prevedibilità dei confini digitali: registrar e registry pubblicano regole di registrazione, mentre browser e servizi devono trasformarle in decisioni tecniche coerenti. L’RFC 9989 dimostra che un singolo utilizzo può essere riprogettato con un metodo standard; non chiude però la discussione sugli altri impieghi della lista. Per il settore dei domini, la priorità è seguire gli sviluppi tecnici e preservare compatibilità e sicurezza durante ogni eventuale migrazione, senza confondere una critica autorevole con una decisione già presa.
← Tutte le news