--- id: "epp-status-codes" kind: "glossary-term" title: "codici di stato EPP" language: "it" category: "Trasferimenti ed EPP" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/it/glossario/codici-stato-epp/" translations: en: "https://tldlog.com/glossary/epp-status-codes/" es: "https://tldlog.com/es/glosario/codigos-estado-epp/" de: "https://tldlog.com/de/glossar/epp-statuscodes/" fr: "https://tldlog.com/fr/glossaire/codes-statut-epp/" pt-BR: "https://tldlog.com/pt/glossario/codigos-status-epp/" ru: "https://tldlog.com/ru/glossariy/kody-statusov-epp/" zh-Hans: "https://tldlog.com/zh/cihui/epp-zhuangtaima/" --- # codici di stato EPP Le etichette standard di un dominio che ne mostrano lo stato e quali operazioni sono consentite, come trasferimento, aggiornamento, rinnovo o cancellazione. I codici che iniziano con client sono impostati dal registrar, quelli che iniziano con server dal registro. Compaiono nei risultati RDAP. Ogni nome a dominio ha almeno un codice di stato: un'etichetta breve, come ok o clientTransferProhibited, che indica in quale stato si trova la registrazione e quali operazioni sono bloccate. I codici vengono dall'EPP, il linguaggio standard con cui i registrar comunicano con i registri. Saperli leggere spiega perché un dominio ha smesso di funzionare, se è protetto dal furto e se è vicino alla cancellazione. ## Che cosa sono i codici di stato e dove vederli I codici sono definiti nello standard EPP per i nomi a dominio, la RFC 5731, e nella sua estensione per i periodi di grazia, la RFC 3915, che aggiunge i codici del periodo di grazia per il riscatto (RGP). Per i gTLD, il posto dove controllarli è una ricerca RDAP, come ICANN Lookup o lo strumento di ricerca di un registrar. Dal 28 gennaio 2025 l'RDAP ha sostituito il WHOIS come fonte di riferimento dei dati di registrazione dei gTLD (a ottobre 2026). L'RDAP scrive i codici come parole minuscole separate da spazi: clientTransferProhibited appare come «client transfer prohibited» e ok come «active». I registrar devono mostrare ogni stato che si applica a un dominio. I ccTLD fissano regole proprie e possono mostrare gli stati in modo diverso. Questa scheda segue l'EPP e le policy per i gTLD. ## Codici client e codici server: chi li ha impostati La prima parola di un codice indica chi lo ha impostato. - I codici che iniziano con client sono impostati dal registrar che gestisce il dominio, a volte automaticamente alla registrazione, a volte su richiesta dell'assegnatario. - I codici che iniziano con server sono impostati dal registro. Prevalgono sugli altri: un registrar non può modificare un codice server, mentre un registro può scavalcare un codice client in base alle proprie policy. - I codici senza nessuno dei due prefissi, come ok, inactive e i codici pending, sono gestiti dal registro. In entrambi i casi l'assegnatario si rivolge al registrar. Per un codice server il registrar inoltra la richiesta al registro, quindi la rimozione richiede di solito più tempo. ## Codici di blocco: che cosa bloccano e perché Quattro coppie di codici bloccano ciascuna un'operazione. Finché uno è attivo, il registro respinge la richiesta corrispondente: - clientTransferProhibited e serverTransferProhibited: il trasferimento a un altro registrar. - clientUpdateProhibited e serverUpdateProhibited: le modifiche al dominio, come contatti o name server, salvo la rimozione del blocco stesso. - clientDeleteProhibited e serverDeleteProhibited: la cancellazione. - clientRenewProhibited e serverRenewProhibited: il rinnovo. I blocchi client su trasferimento, modifica e cancellazione aiutano a proteggere da furti di dominio e frodi. I blocchi sul rinnovo sono rari: compaiono di solito durante controversie legali o prima di una cancellazione. Per i gTLD, la Policy sui trasferimenti dell'ICANN, nella versione pubblicata il 21 febbraio 2024 e in vigore a ottobre 2026, pone limiti a clientTransferProhibited. Se il registrar non offre un modo per rimuoverlo in autonomia, deve rimuoverlo entro cinque giorni di calendario dalla richiesta dell'assegnatario, e non può rifiutarsi solo a causa di una controversia sui pagamenti. A ottobre 2026, alcune modifiche alla Policy sui trasferimenti sono state adottate ma non sono in vigore. Il Consiglio di amministrazione dell'ICANN le ha adottate il 7 giugno 2026 (risoluzione 2026.06.07.04) e non è stata annunciata una data di entrata in vigore. Tra queste c'è un divieto obbligatorio di trasferimento nelle prime 720 ore (30 giorni) dalla registrazione. Il registrar può confermare quali regole si applicano. I blocchi server sono poco comuni. L'ICANN indica come motivi abituali le controversie legali, la richiesta dello stesso assegnatario e un dominio in redemptionPeriod. Alcuni registri offrono un servizio di registry lock, richiesto tramite il registrar, che usa i codici server come protezione aggiuntiva. ## Codici di sospensione: perché un dominio smette di funzionare clientHold e serverHold indicano al registro di non pubblicare nel DNS la delega del dominio. Sito web ed email smettono di funzionare, ma il dominio resta registrato. clientHold è poco comune. I documenti dell'ICANN lo collegano a mancato pagamento, controversie legali, cancellazione imminente, dati di contatto non verificati e contrasto all'abuso del DNS. serverHold è impostato dal registro; le indicazioni dell'ICANN sulla conformità dicono che i registri dovrebbero di norma segnalare prima i casi di abuso al registrar. Altre due situazioni sembrano simili: - inactive: non ci sono name server collegati, quindi il dominio non si risolve, ma la registrazione è regolare. Se la situazione dura diversi giorni, l'ICANN suggerisce di contattare il registrar; alcuni TLD chiedono prima dei documenti. - Scadenza: dopo la scadenza, il registrar deve interrompere la risoluzione del dominio per una parte del periodo in cui l'assegnatario può ancora rinnovare, dove il registro lo consente. Il dominio può non mostrare alcun codice di sospensione. ## Codici pending e dei periodi di grazia I codici pending (pendingCreate, pendingUpdate, pendingRenew, pendingTransfer e pendingDelete) indicano che una richiesta è stata ricevuta ma non completata. Durante un periodo sunrise, pendingCreate può indicare che il nome sarà assegnato alla fine di quel periodo. I codici dei periodi di grazia (addPeriod, renewPeriod, autoRenewPeriod e transferPeriod) sono informativi. Se il registrar cancella il dominio durante uno di essi, il registro gli riconosce un credito pari al costo della registrazione, del rinnovo o del trasferimento. Il credito va al registrar, non all'assegnatario. Ogni registro stabilisce la durata di ciascun periodo di grazia. Nei gTLD la cancellazione segue queste fasi (a ottobre 2026): 1. Il registrar cancella il dominio. Lo stato EPP diventa pendingDelete e lo stato RGP diventa redemptionPeriod, che dura 30 giorni, tranne nei gTLD sponsorizzati. Il dominio non si risolve e non può essere trasferito. 2. Se il registrar chiede il ripristino, lo stato diventa pendingRestore mentre il registro attende un rapporto di ripristino, una finestra che l'ICANN descrive come spesso di sette giorni. Se il rapporto arriva, il dominio torna a ok o allo stato precedente. Altrimenti torna a redemptionPeriod. 3. Se il dominio non viene ripristinato, resta in pendingDelete per cinque giorni di calendario dopo la fine di redemptionPeriod, poi viene eliminato dal database del registro e diventa disponibile per la registrazione. ## Che cosa fare davanti a uno stato inatteso - Cercare il dominio su ICANN Lookup, annotare se il codice è client o server e contattare il registrar. Per i codici server è il registrar a trattare con il registro. - pendingTransfer o pendingUpdate non richiesti dall'assegnatario: contattare subito il registrar e, se si tratta di un trasferimento, chiedergli di respingere la richiesta. - redemptionPeriod: contattare subito il registrar per valutare le opzioni. Per un caso specifico, l'assegnatario dovrebbe verificare con il registrar, il registro o un avvocato. Un esempio pratico: ICANN Lookup mostra example.com come «client transfer prohibited» e l'assegnatario vuole cambiare registrar. Rimuove il blocco dal proprio account o chiede al registrar di rimuoverlo. Una volta richiesto il trasferimento, il dominio mostra pendingTransfer; se il registrar attuale non risponde entro cinque giorni di calendario, il registro lo completa. In seguito il dominio può mostrare transferPeriod, che non richiede alcuna azione. ## Fonti - [EPP Status Codes | What Do They Mean, and Why Should I Know?](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) - [Transfer Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - [Approved Resolutions | Regular Meeting of the ICANN Board | 7 June 2026](https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-06-2026-en) - [Expired Registration Recovery Policy](https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-28-02-2013-en) ## termini correlati - [EPP](https://tldlog.com/it/glossario/epp/) - [clientHold](https://tldlog.com/it/glossario/clienthold/) - [serverHold](https://tldlog.com/it/glossario/serverhold/) - [clientTransferProhibited](https://tldlog.com/it/glossario/clienttransferprohibited/) - [RDAP](https://tldlog.com/it/glossario/rdap/)