Registrazione domini no-KYC: ancora legale con ICANN 2026?

A gennaio 2026 il Board di ICANN ha ribadito che gli emendamenti del 2024 al Registrar Accreditation Agreement — quelli che hanno introdotto la validazione obbligatoria dei dati attraverso la nuova Registration Data Accuracy Specification — restano pienamente in vigore su ogni gTLD. Il team Compliance ha già aperto oltre 140 procedimenti contro registrar che hanno gestito male i dati WHOIS, e tre registrar Tier-2 hanno perso l'accreditamento solo nel primo trimestre. Eppure un mercato silenzioso di registrazioni a tutela della privacy continua a prosperare, presentato sotto etichette come "dominio anonimo", "WHOIS privato" o semplicemente "no-KYC". La domanda quindi è netta: la registrazione di un dominio senza KYC è ancora legale sotto ICANN 2026, o la finestra per chi vuole un sito senza consegnare la scansione del passaporto si è finalmente chiusa?

La risposta è più sfumata di quanto sembri: il quadro ICANN 2026 non impone un KYC con documento fotografico nel modo in cui lo richiede un exchange regolamentato. Richiede dati di contatto accurati e assegna al registrar il dovere di validare certi campi, ma lascia spazio a strutture di proxy, contratti di trustee e ccTLD che operano del tutto al di fuori del perimetro ICANN. Per chi pianifica di pagare in Monero attraverso servizi come MoneroSwapper, l'inquadramento giuridico conta più del marketing del provider. Questa guida spiega cosa è cambiato nel 2026, quali registrar restano conformi pur raccogliendo dati minimi e come registrare un dominio senza consegnare più identità di quanta le regole effettivamente richiedano.

Il quadro normativo 2026: la nuova posizione di ICANN

Per capire cosa è consentito e cosa no occorre distinguere tre regimi che si sovrappongono e che la stampa tende a confondere: il livello contrattuale ICANN, la NIS2 europea con le eccezioni del GDPR e le policy dei singoli ccTLD nazionali. Ciascuno tratta l'"identità" in modo diverso e il "no-KYC" vive o muore proprio negli spazi che li separano.

• ICANN RAA + RDAS: la Registration Data Accuracy Specification, pienamente efficace dall'agosto 2025, obbliga i registrar a una validazione sintattica (l'email è formalmente corretta, il numero rispetta il pattern E.164) e a una validazione operativa (l'email riceve davvero posta). Non richiede controlli con documenti governativi, acquisizione biometrica o KYC finanziario.
• Recepimento della NIS2 in UE: le leggi degli Stati membri ora impongono ai registry ccTLD interni all'Unione di mantenere dati di registrazione "accurati e completi" e di renderli accessibili ai "richiedenti legittimi". È questo il regime che ha spinto .EU, .DE e .FR a stringere le prove di identità tra fine 2025 e inizio 2026.
• Regole dei singoli ccTLD: alcuni registri (.IS, .CH, .LI, .TO, .CC) accettano ancora registrazioni con poco più di un'email funzionante. Altri (.IT, .US, .CA, .CN) richiedono nesso territoriale o prove di residenza che funzionano di fatto come KYC.

Quello che ICANN nel 2026 non ha fatto è imporre una regola universale di "mostra il documento". La confusione persistente nasce dall'expedited PDP sull'abuso conclusosi a novembre 2025, che ha rafforzato gli obblighi di takedown per i domini verificabilmente malevoli. Diversi grandi registrar hanno reagito in modo eccessivo, introducendo upload del passaporto come misura difensiva e poi rivendendolo come "conformità ICANN". Non lo è — è semplice avversione al rischio. Sul piano giuridico un registrar può ancora oggi onboardare un cliente con una mail verificata, un canale di pagamento operativo e metadata di contatto accurati.

Cosa significa davvero "no-KYC" nel mondo dei domini

Nel settore dei domini "no-KYC" è un'etichetta sfocata. Può indicare almeno quattro situazioni molto diverse, e mescolarle è il modo più rapido per ritrovarsi con un dominio sospeso o un pagamento bloccato.

1. Nessun documento d'identità, piena trasparenza nel WHOIS

Il registrante fornisce nome reale, email e indirizzo ma non carica mai un documento. È lo scenario predefinito di gran parte dei registrar consumer ed è pienamente conforme a ICANN 2026. La specifica sull'accuratezza valuta se i dati siano raggiungibili, non se siano stati provati con una patente.

2. Servizi di proxy o privacy WHOIS

I dati reali del registrante sono custoditi da un servizio di privacy (per esempio il modello trustee di Njalla, l'equivalente WhoisGuard di 1API, la privacy gratuita di Porkbun). Il WHOIS pubblico mostra i recapiti del servizio. Il Registrar Accreditation Agreement 2024 di ICANN consente esplicitamente questa modalità tramite la struttura del Privacy and Proxy Services Accreditation Program, anche se il lancio effettivo del PPSAP continua a slittare.

3. Strutture con trustee o titolare effettivo

Un trustee giuridicamente costituito registra il dominio a proprio nome per conto dell'utente. È così che operano Njalla, il ramo domini di OrangeWebsite e diversi registrar islandesi. Sotto il profilo legale è il trustee a essere il registrante; il rapporto sottostante con il cliente è regolato da un contratto privato di servizio. ICANN 2026 non solleva obiezioni finché i dati del registrante pubblicati nel WHOIS sono accurati per il trustee.

4. ccTLD e alt-root fuori dal contratto ICANN

I country-code TLD negoziano le proprie policy con l'operatore di registry. .IS, .CH, .LI, .CC, .TO e diversi ccTLD del Pacifico accettano dati minimi. Sistemi di alt-root come Handshake (HNS), ENS (.eth) e Unstoppable (.crypto, .x, .nft) non sono affatto sotto giurisdizione ICANN e si basano puramente sulla titolarità crittografica.

Se un registrar pretende un documento fotografico e lo presenta come "requisito ICANN", chiedete di citare la clausola contrattuale. Non potranno farlo, perché la clausola non esiste — e un registrar che travisa le regole è esso stesso fuori conformità.

Registrar conformi che minimizzano la raccolta dati nel 2026

La tabella seguente riassume registrar e tipologie di registry che, a maggio 2026, consentono ancora la registrazione senza caricare un documento governativo restando contrattualmente in regola. I prezzi indicati riguardano TLD di fascia media (.com, .net, .org) sul rinnovo annuale e non includono gli sconti promozionali del primo anno.

Provider	Modello	Pagamento in Monero	Costo tipico annuale .com	Note
Njalla	Trustee, detiene il dominio per vostro conto	Sì, XMR nativo	~€15	Sede a Nevis; attivo dal 2017; il maggior scudo legale segnalato dagli audit 2026.
OrangeWebsite	Sede islandese, orientato ai ccTLD	Sì, tramite processor	~€18	Lunga esperienza con .IS; hosting incluso, richiede solo email.
1984 Hosting	Islanda, registrazioni gTLD senza ID	Sì, XMR nativo	~€20	Posizione pubblica contro la raccolta dati eccessiva; supporta .IS e gTLD.
Porkbun	Registrar standard + privacy WHOIS gratuita	No (solo BTC)	~$11	Prezzo mainstream; bisogna convertire XMR fuori piattaforma.
Handshake (HNS)	Root decentralizzata, ownership on-chain	Via swap DEX	Sistema ad asta	Fuori ICANN; risolve via resolver HNS-aware o estensione browser.
ENS (.eth)	Nome smart-contract su Ethereum	Via swap DEX	~$5/anno + gas	Fuori dal perimetro ICANN; risolve nativamente in Brave, MetaMask, Opera.

"Pagamento in Monero" indica che il provider accetta XMR direttamente o tramite un processor integrato che non richiede collegamento a un account. Per Porkbun e registrar simili che accettano solo fiat o BTC, gli utenti MoneroSwapper convertono in genere XMR in BTC o USDT immediatamente prima del checkout, preservando così la privacy on-chain sul lato Monero senza violare le condizioni del registrar.

Passo dopo passo: registrare un dominio con la massima privacy nel 2026

Il "come" pesa quanto il "dove". Un registrar perfettamente anonimo perde tutto il suo valore se pagate da un wallet già collegato alla vostra identità o lasciate un cookie del processor riconducibile al vostro nome reale. Ecco il flusso che consigliamo a chi vuole tenere insieme legalità e privacy sotto ICANN 2026.

1. Scegliete prima il TLD. Decidete in anticipo se vi serve un gTLD (.com, .org) sotto ICANN, un ccTLD a basso impatto identitario (.is, .ch, .li, .cc) o un nome fuori perimetro (.eth, .crypto, un nome HNS). La scelta del TLD condiziona ogni decisione successiva sulla privacy.
2. Create un'identità email pulita. Usate un provider di posta orientato alla privacy (Tutanota, Proton, Disroot o un indirizzo self-hosted su un dominio che già possedete). Verificate che funzioni inviando e ricevendo da fuori della casella; la specifica ICANN sull'accuratezza testerà la raggiungibilità.
3. Scegliete un registrar dalla tabella. Controllate due cose nei termini correnti: che non richiedano un documento governativo al signup e che dichiarino la conformità al RAA 2024 di ICANN. Entrambe le verifiche si fanno di solito senza creare un account.
4. Procuratevi Monero con uno swap senza account. Usate MoneroSwapper o un servizio di swap istantaneo equivalente per convertire un'altra criptovaluta in XMR senza registrarvi. Inviate gli XMR a un wallet nuovo — meglio se creato apposta per questo acquisto, così da non collegare il dominio alla vostra storia on-chain più ampia.
5. Se il registrar accetta XMR direttamente, pagate dal wallet appena creato. In caso contrario, fate un secondo passaggio: convertite una porzione di XMR in BTC o USDT tramite MoneroSwapper, inviate solo l'importo necessario per la fattura e pagate subito il registrar per ridurre la tracciabilità del residuo.
6. Attivate la privacy WHOIS o la modalità trustee al checkout. Anche presso i registrar che pubblicano i contatti per default, attivare la privacy in fase di registrazione evita che il primo snapshot WHOIS sia compromesso. Applicare la privacy in un secondo momento non ripulisce le copie WHOIS archiviate.
7. Conservate in privato i vostri dati di contatto reali. Tenete un registro offline di ciò che avete dichiarato. Se in seguito il registrar chiederà una verifica RDAS, potrete rispondere dalla stessa email e confermare l'indirizzo senza caricare alcun documento.

Seguendo questa sequenza restate contrattualmente in linea con ICANN 2026 — i vostri contatti sono accurati e raggiungibili — senza lasciare alcuna traccia di pagamento e senza alcuna impronta biometrica presso il registrar.

Pagare un dominio in modo anonimo con Monero

La parte del pagamento è quella in cui la maggior parte delle registrazioni "no-KYC" silenziosamente fallisce. Un registrar può non chiedere alcuna identità al signup, ma se pagate con carta di credito o con un prelievo BTC proveniente da un exchange KYC, è la transazione stessa a diventare il punto di collegamento. Monero risolve il problema a livello di protocollo: RingCT, indirizzi stealth e Bulletproofs+ impediscono al processor del registrar di risalire alla fonte dei fondi o alla storia del vostro wallet.

Nel 2026 tre classi di registrar accettano Monero senza attriti. I registrar XMR nativi (Njalla, 1984 Hosting, OrangeWebsite tramite processor) mostrano semplicemente una fattura in XMR con indirizzo stealth. I registrar a supporto bridge usano un gateway tipo BTCPay Server con plugin Monero, o un processor terzo che quota in equivalenti BTC. I registrar solo crypto-aware accettano BTC o USDT — per questi, la rotta XMR→BTC o XMR→USDT di MoneroSwapper consegna i fondi direttamente all'indirizzo di fattura del registrar, e lo swap in sé non richiede alcun account.

Vale la pena ripetere il punto giuridico: pagare in Monero non è "aggirare il KYC" in nessuna giurisdizione che conosciamo, perché ICANN 2026 non richiede alcun KYC finanziario per l'acquisto di un dominio. State semplicemente scegliendo un metodo di pagamento che rispetta la fungibilità. È una distinzione che pesa in ogni eventuale futura controversia con il registrar.

Un caso pratico: la giornalista d'inchiesta

Immaginate una giornalista che vive in una giurisdizione con leggi ostili alla stampa e che nel 2026 vuole aprire un dominio personale per pubblicare. Le servono: (a) un dominio registrato legalmente che non verrà revocato per WHOIS inaccurato, (b) nessun collegamento pubblico tra il dominio e la sua identità anagrafica e (c) una traccia di pagamento che non possa essere ricondotta a un conto corrente tramite ordine di esibizione.

Il percorso praticabile nel 2026: un ccTLD .is registrato tramite 1984 Hosting, una casella Proton come contatto, pagamento in XMR ottenuti via MoneroSwapper a partire da un piccolo saldo BTC acquistato peer-to-peer sei mesi prima. La RDAS di ICANN non si applica a .is (è un ccTLD sotto le regole ISNIC), l'email di contatto è reale e raggiungibile, il processor di pagamento vede solo un indirizzo stealth nuovo. Identità dichiarata: un'email che risponde. Documenti caricati: zero. Policy ICANN violate: zero. Costo totale nel 2026: meno di €25.

Confrontatelo con la stessa giornalista che si rivolga a un registrar statunitense il quale "richiede" il caricamento del passaporto "per conformità ICANN". Adesso esiste una scansione del passaporto in un CRM terzo, un collegamento con la carta di credito e un registrar che ha costruito da sé un obbligo di KYC che ICANN non ha mai imposto. La privacy è andata; la tutela legale non è migliorata.

Il contesto italiano ed europeo

Per chi opera dall'Italia c'è un passaggio in più. Il ccTLD .IT, gestito da Registro.it (IIT-CNR), richiede codice fiscale per le persone fisiche residenti o partita IVA per le imprese: è un requisito di accreditamento storico, non un effetto della NIS2, ma di fatto rende .IT un'opzione poco utile a chi cerca minimizzazione dell'identità. Restano pienamente accessibili dall'Italia tutti i gTLD ICANN e i ccTLD non europei che non richiedono nesso territoriale. Sul fronte fiscale, l'acquisto di un dominio attraverso una conversione XMR→fiat o XMR→BTC non genera di per sé obblighi dichiarativi finché resta in ambito uso personale; le linee guida dell'Agenzia delle Entrate sulle cripto-attività riguardano detenzione e plusvalenze, non la spesa di servizio. Il Garante per la Protezione dei Dati Personali, dal canto suo, ha più volte ricordato che la pubblicazione di dati WHOIS in chiaro deve rispettare la base giuridica del GDPR — un argomento che gioca a favore dei modelli proxy e trustee, non contro.

Domande frequenti

ICANN richiede un documento fotografico per registrare un dominio nel 2026?

No. La Registration Data Accuracy Specification di ICANN, in vigore da agosto 2025, impone ai registrar di verificare che i dati di contatto siano sintatticamente corretti e operativamente raggiungibili. Non richiede di caricare passaporto, patente o altri documenti governativi. I registrar che pretendono un documento applicano una loro policy interna, non un obbligo ICANN.

Registrare un dominio attraverso un trustee come Njalla è ancora legale nel 2026?

Sì. Il trustee è il registrante ufficiale e fornisce dati WHOIS accurati a proprio nome. Il contratto privato sottostante con il gestore effettivo del sito esula dall'ambito ICANN. A maggio 2026 nessuna policy ICANN né alcun regolatore nazionale di rilievo — incluso il Garante italiano — ha contestato il modello, e i trustee con sede a Nevis o in Islanda restano la scelta più solida per chi privilegia la robustezza giuridica.

Posso usare un nome falso per registrare un dominio se voglio un vero no-KYC?

No, ed è la trappola da evitare. La specifica sull'accuratezza riconosce ai registrar il diritto (e sempre più il dovere) di sospendere domini con dati verificabilmente falsi. "No-KYC" significa nessun caricamento di documenti, non informazioni inventate. Usare un nome reale con un'email reale e raggiungibile soddisfa le regole; inventare un'identità di contatto espone il dominio al rischio di sospensione nel giro di poche settimane.

I nomi .eth e Handshake contano come domini sotto ICANN?

No. I nomi ENS .eth e i nomi Handshake (HNS) esistono interamente al di fuori della root ICANN. Sono record di proprietà crittografica su blockchain e si risolvono solo nei browser o nei resolver che supportano quelle alt-root (Brave, Opera, MetaMask, HNSD o overlay HNS DNS). La loro legalità dipende dalla giurisdizione in cui vive il titolare, non da ICANN — e finora nessuna giurisdizione importante ha vietato la titolarità personale.

Cosa succede se il registrar mi chiede in seguito di verificare l'identità?

Sotto il quadro 2026 un registrar può richiedere una ri-verifica della raggiungibilità — confermare l'email cliccando un link, rispondere a una chiamata di validazione telefonica, aggiornare un indirizzo non più valido. È contrattualmente consentito. Può anche scalare a richiedere un documento se ha un segnale specifico di abuso sul vostro dominio. Se vi siete registrati con dati accurati su un registrar conforme e non avete cronologia di abusi, in genere si supera la verifica senza alcun caricamento.

I registrar trattano il pagamento in Monero come sospetto nel 2026?

Non quelli che già lo accettano. Njalla, 1984 Hosting, OrangeWebsite e diversi provider europei e asiatici più piccoli accettano XMR da anni e lo gestiscono come un metodo di pagamento ordinario. Presso registrar solo-fiat o solo-BTC basta convertire tramite un servizio come MoneroSwapper nella valuta supportata. La conversione in sé non viene segnalata in alcun modo, a patto di usare uno swap non-custodial e senza account.

Conclusione

La registrazione no-KYC di un dominio resta legale sotto ICANN 2026 — a condizione di capire cosa significa davvero "no-KYC". Non è il diritto di fornire informazioni false; è la libertà di registrarsi con dati accurati senza caricare documenti di identità che i contratti ICANN non hanno mai richiesto. Il giro di vite normativo del 2024-2025 ha colpito l'accuratezza dei dati e il takedown degli abusi, non il KYC finanziario. I registrar elencati permettono di restare pienamente nelle regole tenendo la vostra identità anagrafica fuori dagli hard disk del provider e fuori dal WHOIS pubblico.

Per la parte di pagamento, Monero rimane la via più pulita, e uno swap senza account tramite MoneroSwapper consente di finanziare la registrazione di un dominio senza mai aprire un account exchange. Che si tratti di proteggere un blog personale, di portare avanti un progetto di ricerca o semplicemente di preferire la separazione tra hosting e identità, il quadro 2026 lascia ancora aperta la porta — basta sapere quale porta varcare.