ICANN ha inviato a Fewmoretaps OU d/b/a TrustName.com un nuovo Notice of Breach datato 26 giugno 2026. Il registrar, identificato con IANA #4318, era già stato richiamato il 10 giugno; il nuovo documento mostra che la questione non è chiusa e che il tema centrale resta la gestione concreta dei report di DNS abuse.
Secondo la comunicazione ufficiale, ICANN contesta due profili: la mancata adozione di azioni rapide e appropriate per interrompere o mitigare l’uso abusivo di nomi registrati, come richiesto dalla sezione 3.18.2 del Registrar Accreditation Agreement, e la mancata gestione ragionevole e tempestiva dei report di abuso, prevista dalla sezione 3.18.1.
Leggi anche: ICANN mette in mora TrustName: il DNS abuse torna al centro del rapporto con i registrar
Perché il secondo notice pesa più del primo
La novità non è solo l’esistenza di un altro richiamo. Nel documento ICANN scrive che TrustName.com continuerebbe a mostrare comportamenti non conformi nella gestione delle segnalazioni, in modo simile a quanto già evidenziato nel notice del 10 giugno 2026. Quella prima contestazione deve essere sanata entro il 1 luglio 2026, mentre il nuovo notice del 26 giugno assegna al registrar una scadenza separata: 17 luglio 2026.
Questa sovrapposizione temporale è importante perché segnala un problema operativo, non una singola pratica isolata. ICANN chiede al registrar di dimostrare, con evidenze e date, quali passaggi siano stati svolti per investigare ciascun dominio segnalato e come sia stata valutata la documentazione ricevuta dal segnalante.
Il punto non è formale. Nei casi descritti, i report avrebbero incluso URL, nomi di istituti finanziari e di una agenzia governativa presumibilmente impersonati, oltre a screenshot di pagine di login fraudolente. ICANN sostiene che le informazioni apparissero sufficienti per concludere ragionevolmente che i domini fossero usati per DNS abuse.
Mitigazione tardiva e documentazione insufficiente
Nel notice ICANN afferma che i domini oggetto del caso sono stati sospesi solo dopo il contatto della Contractual Compliance, diverse settimane dopo l’invio dei report iniziali. Per l’ente, questa tempistica non è compatibile con l’obbligo di azione pronta quando esistono elementi utilizzabili per mitigare l’abuso.
ICANN chiede inoltre a TrustName.com di spiegare perché abbia scelto di notificare i singoli registranti e concedere loro tempo per valutare e agire, e perché abbia ritardato la mitigazione fino all’intervento della compliance. In altre parole, il registrar deve dimostrare che il percorso seguito fosse ragionevole rispetto alle circostanze specifiche di ciascun dominio.
Leggi anche: Nuovi domini e DNS abuse: nel Q1 2026 oltre 26 milioni di registrazioni sotto osservazione
Un altro passaggio rilevante riguarda le misure correttive. ICANN scrive che il registrar avrebbe indicato l’adozione di misure tra il 16 e il 22 giugno 2026 per evitare il ripetersi della non conformità, ma aggiunge che non è chiaro in cosa queste misure differiscano da quelle che il registrar aveva già dichiarato di avere implementato in precedenza.
Il rischio di terminazione RAA
La conseguenza potenziale è esplicita: se TrustName.com non sana tempestivamente le violazioni e non fornisce le informazioni richieste entro il 17 luglio 2026, ICANN può avviare il processo di terminazione del Registrar Accreditation Agreement. Non significa che la terminazione sia automatica, ma indica che la procedura è entrata in una fase più seria.
Per il mercato dei domini, questi casi vanno letti oltre il singolo registrar. Le modifiche contrattuali sul DNS abuse hanno reso più misurabili gli obblighi di risposta, ma la prova reale resta operativa: ricevere un report, valutarlo, conservare evidenze, agire in tempi coerenti con il rischio e spiegare le decisioni prese.
Leggi anche: ICANN richiama TrustName: il DNS abuse diventa un test per i registrar
La lettura Webinvest
Il secondo notice a TrustName.com conferma che la compliance sul DNS abuse si sta spostando dal principio generale alla tracciabilità delle decisioni. Non basta dire di avere processi interni: quando arrivano report con evidenze, un registrar deve poter mostrare che cosa ha controllato, quando lo ha fatto, perché ha scelto una misura invece di un’altra e in quali tempi ha interrotto l’abuso.
Per registrar e reseller, il messaggio è netto: la gestione dei reclami non può essere trattata come una coda amministrativa generica. Per gli investitori e gli operatori di portafogli, invece, cresce l’importanza della reputazione del registrar scelto. Un dominio può essere tecnicamente valido, ma se l’infrastruttura di registrazione viene associata a processi deboli contro abusi, phishing o impersonificazione, il rischio operativo si riflette su tutto l’ecosistema.
Fonte: ICANN - Notice of Breach to Fewmoretaps OU d/b/a TrustName.com, 26 giugno 2026
← Tutte le news