Guide des procÃ©dures du .fr - Afnic

Guide 

des 

procédures 

du .fr 

– version 3.2 – 

7 février 2011 

En vigueur à partir du 5 avril 2011 

Le guide des procédures s'adresse aux 

bureaux d’enregistrement de l'AFNIC 

ou, pour information uniquement, à 

ceux qui souhaiteraient le devenir. 

www.afnic.fr 

afnic@afnic.fr - 1 - 

Guide des procédures du .fr 


En vigueur à partir du 4 avril 2011

Table des matières 

1. Généralités ......................................................................................... 3 

2. Glossaire ............................................................................................ 5 

3. Disponibilité des opérations en fonction de l’interface 

d’enregistrement ............................................................................... 7 

4. Les Opérations .................................................................................. 8 

4.1. Contacts.............................................................................................................8 

4.1.1. Create (création d’un contact) ................................................................10 

4.1.2. Update (mise à jour d’un contact)...........................................................10 

4.1.3. Delete (suppression d’un contact) ..........................................................11 

4.2. Domaines.........................................................................................................12 

4.2.1. Create (création d’un domaine) ..............................................................13 

4.2.2. Delete (suppression d’un domaine) et période de rédemption ...............15 

4.2.3. Restore (restauration d’un domaine) ......................................................16 

4.2.4. Transfer (changement de bureau d'enregistrement) ..............................17 

4.2.5. Trade (transmission volontaire vers un nouveau titulaire) ......................20 

4.2.6. Recover (transmission forcée vers un nouveau titulaire)........................23 

4.2.7. Update [admin] (mise à jour administrative) ...........................................25 

4.2.8. Update [tech] (mise à jour technique).....................................................26 

4.2.9. Update [context] (mise à jour du hold et du auth_info) ...........................27 

4.2.9.1. Mise à jour du hold................................................................................................... 27 

4.2.9.2. Mise à jour du auth_info........................................................................................... 28 

4.3. Opérations diverses et suppléments.............................................................29 

4.3.1. Notifications............................................................................................29 

4.3.2. Cancel (abandon d’opérations) ..............................................................30 

4.3.3. Auth_info ................................................................................................31 

4.3.4. Statuts : status[EPP] et status[Whois] ....................................................31 

5. Procédures manuelles .................................................................... 33 

5.1. Documents types ............................................................................................33 

5.1.1. En-tête....................................................................................................33 

5.1.2. DOA........................................................................................................33 

5.2. Détail des opérations concernées .................................................................34 

5.2.1. Trade ......................................................................................................34 

5.2.2. Create avec code d’autorisation .............................................................34 

5.2.3. Recover ..................................................................................................35 

5.2.4. Identification ...........................................................................................35 

5.2.4.1. Statut d’identification du titulaire : idstatus.......................................................................... 36 

5.2.4.2. Les principes de l’identification............................................................................................ 38 






Guide des procédures 

du .fr 

1. Généralités 

On considère que sont connues : 

les règles de nommage qui déterminent l’acceptation ou non d’une opération 

donnée en fonction du nom de domaine impacté. Ces règles sont définies 

dans La Charte de Nommage AFNIC (http://www.afnic.fr/obtenir/chartes) 

et la description précise de l’implémentation de ces règles est faite dans le 

Guide d’intégration (http://www.afnic.fr/doc/interface/epp). 

les politiques techniques dont le non-respect peut entraîner l’échec de 

certaines opérations. Ces dernières sont définies dans Les politiques 

techniques du registre ( à venir). 

Les opérations décrites sont celles correspondant au cycle de vie d’un domaine. 

Elles ne peuvent être opérées que par un bureau d’enregistrement ayant un contrat 

d’enregistrement avec l’AFNIC. 

L’AFNIC offre trois interfaces d’enregistrement : mail, web et EPP. Ces interfaces 

permettent différents niveaux d’intégration qui sont décrits dans Le guide 

d’intégration. 

Attention : l’interface mail va disparaître en fin d’année 2011, elle est donc 

totalement déconseillée aux bureaux d'enregistrement qui commencent une nouvelle 

implémentation. 






Pour chacune des opérations, on indiquera : 

• La disponibilité de l’opération en fonction de l’interface. 

Exemple : 

Disponibilité : EPP Mail Web 

• La durée globale de l’opération (immédiat signifie une réponse directe du 

serveur de quelques secondes, le temps exact dépendant de la performance 

de la chaîne d’enregistrement et des infrastructures mail et réseau). 

Exemple : 

Durée : < 3 semaines 

• Les dépendances inter-opérations. 

Exemple : 

Identification en état problème sur l’objet contact 

Non autorisée si : 

titulaire 

• Les éléments à fournir en entrée d’une opération. Le côté obligatoire / 

facultatif d’un élément est décrit dans le Guide d’intégration 

(http://www.afnic.fr/doc/interface/epp). 

Exemple : 

Nom, prénom, date de naissance, lieu de naissance, 

Éléments à fournir : 

ville, code postal, pays, téléphone, fax, mail 

• Les éléments recueillis en sortie. 

Exemple : 

Éléments recueillis en sortie : Nom de domaine 

• Les entités notifiées. 

Exemple : 

Notification : Bureau d’enregistrement entrant 

• Si l’opération est facturée ou non. 

Exemple : 

Facturation : Non 

• Si l’opération change la date anniversaire du domaine. 

Exemple : 

Changement date anniversaire : Oui 

 

Les obligations éventuelles du bureau d'enregistrement signalées par 

. Le non respect de ces obligations peut entraîner l’application de 

sanctions conformément au contrat d’enregistrement. 






2. Glossaire 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Bureau d’enregistrement entrant : nouveau bureau d'enregistrement qui 

prend en charge la gestion d’un domaine ou d’un contact. 

Bureau d’enregistrement sortant : ancien bureau d’enregistrement qui 

perd la gestion d’un domaine. 

Titulaire : personne physique ou morale qui a procédé à l'enregistrement ou 

au maintien d'un ou de plusieurs noms de domaine auprès d'un ou de 

plusieurs bureau d'enregistrement. 

Titulaire entrant : nouveau titulaire qui procède à l’enregistrement d’un 

domaine (appelé aussi titulaire demandeur). 

Titulaire sortant : ancien titulaire qui perd un domaine. 

Personne Physique (PP) : titulaire d'un domaine à titre personnel identifié 

notamment par son état civil (nom, prénom, date et lieu de naissance). 

Personne Morale (PM) : titulaire d'un domaine au titre de personne morale 

identifié notamment par ses données sociales (numéros RCS, siren, marque, 

dénomination ou raison sociale ou désignation etc.). 

Status[Whois] : état du domaine tel qu’il apparaît dans le Whois. 

Hold[Whois] : label apparaissant dans le Whois positionné sur oui ou non 

permettant de suspendre la publication d’un domaine dans le DNS. 

Status[EPP] : état de l’opération ou du domaine tel qu’il apparaît dans le 

flux EPP. 

Pending : état marquant une opération en cours d’exécution. 

Nic-handle : chaîne de caractères qui identifie un contact. Il est généré par 

l’AFNIC et maintenu par un bureau d'enregistrement unique. 

Auth_info : mot de passe associé à un domaine et utilisé pour valider 

l’implication du titulaire dans certaines opérations, notamment l’opération 

transfer (changement de bureau d’enregistrement). Dans la plupart des cas, 

le auth_info est généré par le bureau d'enregistrement et transmis au titulaire. 

Code d’autorisation : code généré par l’AFNIC dans le cadre d’opérations 

spéciales nécessitant une vérification (création sous des domaines de second 

niveau, transmission forcée etc.). Le code d’autorisation sert de auth_info 

« imposé ». 

Garbage collector : Outil interne de l’AFNIC qui gère et efface entre autres 

les contacts non-utilisés. 

Notification immédiate : message reçu très rapidement soit en temps réel 

via la connexion au serveur EPP soit en léger différé lorsqu’il s’agit d’un 

message envoyé par mail. 

Notification différée : message émis par l’AFNIC à l’issue d’un processus 

interne dont la durée est significative soit sur la file de polling EPP soit par 

mail. 






Condensat : calcul cryptographique irréversible pour obtenir une valeur de 

taille fixe en sortie pour tout message en entrée. 

DS : enregistrement 'Delegation Signer' dans le DNS composé à partir du 

condensat d'une clef. 

KSK : (Key Signing Key), clef utilisée pour signer d'autres clefs. 






3. Disponibilité des opérations en fonction de 

l’interface d’enregistrement 

EPP Mail Web 

Domaine 

Create - Création d’un domaine sans code d’autorisation x x x 

Create - Création d’un domaine avec code d’autorisation x x x 

Delete – Suppression d’un domaine x x x 

Restore – Restauration du domaine supprimé x x x 

Update [admin] - Mise à jour administrative x x x 

Update [tech] - Mise à jour technique des serveurs x x x 

Update [tech] - Mise à jour technique des signatures x x 

Update [context] - Mise à jour du statut hold d’un domaine x x x 

Update [context] - Mise à jour du auth_info x x x 

Transfer - Changement de bureau d’enregistrement x x x 

Transfer - avec conservation de la signature x x 

Trade - Transmission volontaire entre deux titulaires x x x 

Trade - …avec conservation de la signature x x 

Recover – Transmission forcée vers un nouveau titulaire x x x 

Recover - …avec conservation de la signature x x 

Abandon du transfer 

Abandon du trade 

x 

x 

Check - Disponibilité du nom de domaine x x 

Récupération du auth_info x x 

Info sur le domaine x x 

Contact 

Create - Création d’un contact x x x 

Update - Mise à jour d’un contact x x 

Delete - Suppression d’un contact 

Information sur un contact x x 

Notification (au bureau d’enregistrement 

– hors notification de fin d’opérations) 

Transfer sortant x x x 

Recover sortant x x x 

Trade sortant x x x 

Identification d’un titulaire x x x 

Suppression de contact par le Garbage Collector 

x 

Génération de Code d’autorisation x x x 






4. Les Opérations 

Un bureau d’enregistrement peut effectuer des opérations sur trois catégories 

d’objets : 

opérations sur les contacts, 

opérations sur les domaines, 

opérations diverses : notifications/commandes/code d’autorisation. 

4.1. Contacts 

Les objets contacts représentent des entités qui seront utilisées comme contact 

administratif, contact technique ou titulaire d’un domaine. 

Il existe deux types de contacts, les contacts de type PP (Personne Physique) et 

de type PM (Personne Morale) qui obéissent à des règles différentes décrites 

dans chacune des opérations. 

Les opérations disponibles sont : 

 

 

 

 

create (création), 

update (mise à jour), 

delete (suppression), 

info (information) 

Un contact est systématiquement identifié par un code public appelé nic-handle 

(ex : PR1249-FRNIC) généré par l’AFNIC et maintenu par un bureau 

d’enregistrement unique. 

Il ne peut y avoir deux contacts strictement identiques maintenus par le même 

bureau d’enregistrement avec des nic-handles distincts. 






Important : un contact de type PM utilisé comme titulaire sera soumis à des 

phases d’identification (cf. Identification § 5.2.4) pouvant avoir des 

conséquences importantes sur le portefeuille de domaines du titulaire. 

Un contact de type PP peut être en diffusion restreinte lorsqu’il est utilisé 

comme titulaire ou contact administratif ce qui aura pour effet de le masquer 

dans les différents services de publication, 

notamment le service Whois. 

Les mises à jour ultérieures de l’objet 

contact créé seront étroitement liées à 

l’usage qui est fait de cet objet : titulaire, 

contact administratif ou technique. Les 

contraintes associées à chaque usage sont 

décrites dans la Charte de Nommage de 

l’AFNIC 

(http://www.afnic.fr/obtenir/chartes). 

Nota : les objets Rôles existant avant 

le 20 octobre 2008 restent valides et 

peuvent être utilisés dans les 

opérations sur les noms de domaines 

mais la nouvelle interface ne permet 

plus de les modifier ou d’en créer de 

nouveaux, leur usage doit à terme 

être proscris. 






4.1.1. Create (création d’un contact) 

Contact 


Durée : Immédiate 

Non autorisé si : N/A 

Nom, données d’identification, ville, code postal, 


pays, téléphone, fax, mail 

Éléments recueillis en sortie : Nic-handle du contact 

Notification : Bureau d’enregistrement 


Changement date anniversaire : Non 

4.1.2. Update (mise à jour d’un contact) 

Contact 

Disponibilité : EPP Web 


Non autorisé si : N/A 

Éléments à fournir : ville, adresse, code postal, pays, téléphone, fax, mail 

Éléments recueillis en sortie : Accusé de réception 

Notification : Non 








Un contact peut être mis à jour en respectant ces quelques principes : 

Pour les contacts de type PP (Personne Physique) : les champs 

nom, prénom, date et lieu de naissance ne sont pas modifiables. 

Pour les contacts de type PM (Personne Morale) : les champs 

Raison sociale/nom/prénom et les identifiants (siren, marque etc.) ne 

sont pas modifiables. 

Dès lors qu’un contact (PP ou PM) est utilisé en tant que contact 

administratif, le pays ne peut être modifié que par un territoire 

français. 

4.1.3. Delete (suppression d’un contact) 

Les objets contacts sont automatiquement détruits par l’AFNIC de façon 

quotidienne selon la politique suivante : 

mise en obsolescence des contacts dont le nic-handle n’est pas 

référencé dans un autre objet depuis 3 mois. Ces contacts ne peuvent 

plus être utilisés dans une nouvelle opération. 

supprime les contacts obsolètes depuis 15 jours. 






4.2. Domaines 

Les objets domaines ont un cycle de vie qui les amène à être associés à un 

bureau d’enregistrement ainsi qu’à différents objets contacts : titulaire, contact 

administratif, contact technique (cf. la Charte de Nommage de l’AFNIC 

http://www.afnic.fr/obtenir/chartes). 

On différencie l’enregistrement du domaine qui mène à sa publication dans le 

Whois de l’activation du domaine qui mène à sa publication dans le DNS. 

Un domaine ne peut être activé que s’il est enregistré. 






Un domaine est tacitement renouvelé tous les ans et pour un an à compter de sa 

date anniversaire. 

Les opérations disponibles sont : 

create (création), 

delete (suppression), 

restore (restauration), 

transfer (changement de bureau d’enregistrement), 

trade (transmission volontaire entre deux titulaires), 

recover (transmission forcée vers un nouveau titulaire), 

update [admin] (mise à jour administrative), 

update [tech] (mise à jour technique), 

update [context] (mise à jour du hold et/ou du auth_info), 

info (information sur le domaine), 

check (vérification de disponibilité). 

Les opérations venant modifier la date anniversaire sont : 

create (création d’un domaine), 

transfer (changement de bureau d’enregistrement), 

trade/recover (transmission du domaine vers un nouveau titulaire), 

restore (restauration du domaine en rédemption). 

Certaines opérations déclenchées par l’AFNIC peuvent impacter le cycle de vie 

du domaine et notamment l’identification (cf. identification § 5.3) qui peut 

mener à la suppression du domaine. 

4.2.1. Create (création d’un domaine) 

Create 



Identification en état problème sur l’objet contact 

Non autorisé si : 

titulaire 

Nom de domaine, nic-handle du contact titulaire, nichandle 

du contact administratif, nic-handles des 


contacts techniques, auth_info 

Éléments recueillis en sortie : Nom de domaine, date de création, date d’expiration 


Facturation : Oui 


Il existe deux types de créations, avec ou sans code d’autorisation. Ce code est 

nécessaire pour permettre la création de certaines catégories de noms de 

domaine 

(cf. la Charte de Nommage de l’AFNIC http://www.afnic.fr/obtenir/chartes). 






L’élément auth_info présente quelques particularités : 

pour une création sans code d’autorisation il est librement rempli par 

le bureau d’enregistrement 

pour une création avec code d’autorisation il doit correspondre 

exactement au code d’autorisation généré par l’AFNIC et transmis au 

bureau d’enregistrement lors de la procédure de génération du code 

d’autorisation (cf. § 5.2). 

Le auth_info sera nécessaire au titulaire pour qu’il puisse procéder à un 

changement de bureau d’enregistrement ultérieurement. 

Important : le bureau d’enregistrement doit donner l’accès au auth_info 

au titulaire du nom de domaine (et uniquement à lui) dès la fin de la création 

et à l’issue de toute opération amenant la mise à jour du auth_info déjà 

transmis. 

Tout manquement à cette phase de la procédure peut donner lieu à sanction 

de la part de l’AFNIC 

(cf. Contrat d’enregistrement http://www.afnic.fr/afnic/contrat). 

Dans le cadre de la création avec code d’autorisation, le bureau 

d’enregistrement a l’obligation de mettre à jour par une opération d’update 

[context] le auth_info pour sécuriser le domaine ainsi que de donner accès 

au nouveau auth_info généré au titulaire (et à lui seul). 






Une opération de création effectuée avec un objet contact titulaire dont les 

états d’identification (cf. identification § 5.2.4) sont not identified ou 

deprecated déclenche immédiatement une identification sur l’objet contact 

titulaire en question. 

4.2.2. Delete (suppression d’un domaine) et période de 

rédemption 

Delete 


Durée : 30 jours 

• Transfer en cours (PendingTransfer) 

Non autorisé si : • Trade en cours (PendingTrade) 

• Update[tech] en cours (PendingUpdate) 

Éléments à fournir : Nom de domaine 





La suppression d’un nom de domaine déclenche automatiquement une 

période de rédemption fixée à 30 jours. Pendant cette période, seul le bureau 

d’enregistrement qui avait la gestion de ce domaine peut récupérer le 

domaine avant sa suppression définitive (restore - restauration d’un 

domaine). Les autres bureaux d’enregistrement doivent attendre la fin de la 

période de rédemption pour avoir le droit de l’enregistrer. 






Dans le Whois, le domaine supprimé apparaît toujours mais le 

status[Whois] passe à redemption et le pending[Whois] à delete. Par 

ailleurs, la date de demande de suppression y apparaît avec une précision au 

jour. 

Cas particuliers : 

• La procédure de suppression en cascade : la suppression peut-être 

refusée dans le cas particulier où le domaine est encore utilisé dans le 

nommage de serveurs de noms pour d’autres domaines en .fr. Le 

support doit être contacté et une procédure manuelle est enclenchée 

afin de faire disparaître les interdépendances bloquantes. 

• Une suppression émise par l’AFNIC ne déclenche pas de période 

de rédemption. Pour des raisons techniques, l'opération de 

suppression par l’AFNIC se déroulera en deux étapes : 

Recover des noms de domaine par l'AFNIC vers son compte. 

Dans la base Whois, ces noms de domaine apparaîtront sous 

le nom du bureau d'enregistrement : "AFNIC -Opération- 

Interne". 

Suppression définitive des noms de domaine par l'AFNIC. 

Cette opération n’est pas facturée par l’AFNIC. 

4.2.3. Restore (restauration d’un domaine) 

Restore 


Durée : Immédiat 

État du domaine (status[Whois]) autre que 

redemption 


Identification en état problème sur l’objet 

contact titulaire 




Facturation : Oui 


Seul le bureau d’enregistrement qui a supprimé le nom de domaine peut le 

restaurer pendant la période de rédemption. Tous les autres bureaux 

d’enregistrement doivent attendre la fin de la période de rédemption pour 

avoir le droit de l’enregistrer. 

Il est impossible de déclencher un restore lorsque l’objet contact titulaire est 

en état problème suite à une identification. 






L’opération de restauration conserve à l’identique l’ensemble des 

informations Whois du nom de domaine telles qu’elles existaient avant la 

demande de suppression. Elle n’est pas soumise aux contraintes de nommage 

(pas de nécessité d’obtenir un code d’autorisation) ni aux contraintes 

techniques (pas de passage du ZoneCheck). 

L’opération restauration est une opération facturée qui modifie la date 

anniversaire du nom de domaine. 

4.2.4. Transfer (changement de bureau d'enregistrement) 

Transfer 


Durée : < 22 jours 

• Identification en état problème sur l’objet 

contact titulaire 

• statut[Whois]=redemption 



• Trade en cours (PendingTrade) 

• Update [tech] en cours (PendingUpdate) 

Nom de domaine, nic-handle du contact administratif, 


nic-handle des contacts techniques, auth_info, keepDS 

Nom de domaine, statut, id du bureau 

d’enregistrement sortant, id du bureau 

Éléments recueillis en sortie : 

d'enregistrement entrant, date d’émission du transfer, 

date de fin d’opération 

Notification : Bureau d’enregistrement entrant et sortant 

Facturation : Oui au bureau d’enregistrement entrant 







La demande de changement de bureau d’enregistrement est faite par le 

nouveau bureau d’enregistrement. C’est le auth_info fourni par le titulaire au 

bureau d’enregistrement entrant qui valide cette demande. 

Le bureau d’enregistrement sortant reçoit une notification de changement de 

bureau d’enregistrement : 

Si le bureau d’enregistrement sortant répond favorablement dans les 

8 jours, le changement de bureau d’enregistrement se réalise 

immédiatement 

Si le bureau d’enregistrement sortant s’oppose dans les 8 jours, la 

durée totale du changement de bureau d’enregistrement est étendue à 

22 jours avant que ce dernier soit réalisé. Le bureau d’enregistrement 

sortant peut malgré tout revenir sur sa décision et donner son accord 

au transfer avant la fin des 22 jours. 

Si le bureau d’enregistrement sortant ne réagit pas dans les 8 jours, le 

changement de bureau d’enregistrement se réalise immédiatement à 

la fin des 8 jours. 






Le changement de bureau d’enregistrement est possible même si le label 

hold[Whois] du domaine est positionné sur oui. 

Si le label hold[Whois] du domaine est positionné sur oui avant le 

changement de bureau d'enregistrement, à la sortie de l’opération il se trouve 

positionné sur non. 

Les données du titulaire sont clonées et un nouveau nic-handle est attribué. 

Les nic-handles des contacts administratif et techniques doivent être 

renseignés. 

L’opération transfer (changement de bureau d’enregistrement) se fait à 

serveurs de noms constants et sans vérification technique (pas de passage du 

ZoneCheck). 

Le bureau d’enregistrement peut décider de maintenir ou de ne pas maintenir 

la signature du domaine (si elle existe) pendant l’opération de transfer. Il 

utilise pour cela l’attribut keepDS qui sera positionné à 1 ou 0. En l’absence 

de cet attribut keepDS, la signature n’est pas maintenue. L’attribut keepDS 

est présent dans la version 1.1 du serveur EPP, il est absent de la version 1.0 

et du formulaire mail 2.5.0 (cf. § 6. Annexe 1 du Guide d’intégration 

technique). 






Important : Le bureau d’enregistrement entrant a l’obligation de mettre à 

jour la liste des serveurs de noms si le nom doit être activé sur des serveurs 

différents ou de remettre cette liste à zéro si le nom de domaine n’est 

qu’enregistré (update [tech]). 

L’opération transfer se fait sans générer de nouveau auth_info. Le bureau 

d’enregistrement entrant a l’obligation de mettre à jour par une opération 

d’update [context] ce auth_info pour sécuriser le domaine ainsi que de 

donner l’accès au auth_info au titulaire. 

Après la validation finale du transfer, le bureau d’enregistrement sortant a 

l’obligation de maintenir la configuration technique ainsi que les signatures 

du domaine et les enregistrements DNSKEY pendant un délai qui sera 

précisé d’ici le 5 avril 2011. 

Pendant une opération transfer, aucune autre opération ne peut être saisie 

(status[EPP] pendingTransfer). L’opération transfer peut-être abandonnée 

par le bureau d’enregistrement entrant sans facturation de la part de l’AFNIC 

(cf. § 4.3.2). Les deux bureaux d’enregistrement impliqués en seront alors 

notifiés. 

L’opération transfer est une opération facturée qui modifie la date 


4.2.5. Trade (transmission volontaire vers un nouveau titulaire) 

Trade 


Durée : < 15 jours 


contact titulaire sortant 


contact titulaire entrant 


• Statut[Whois]=redemption 




Nom de domaine, nic-handle du contact administratif, 

Éléments à fournir : nic-handles des contacts techniques, nic-handle du 

titulaire, keepDS 

Nom de domaine, nic-handle du titulaire sortant, du 

titulaire entrant, id du bureau d'enregistrement entrant, 


id du bureau d'enregistrement sortant, date de fin 

d’opération 

Notification : Bureau d’enregistrement entrant et sortant 








On parle de transmission volontaire si le titulaire sortant et le titulaire entrant 

ont toujours une existence légale. Si le titulaire sortant n’existe plus, en cas 

de décision judiciaire ou décision prise dans le cadre d’une procédure de 

résolution de litige (PRL) ou si le trade concerne un nom de domaine 

soumis à un enregistrement sous conditions (génération de code 

d’autorisation) on utilise l’opération recover (transmission forcée). 

L’opération trade déclenche l’émission de mails de validation vers les deux 

titulaires (entrant et sortant) et des mails d’information à l’intention du 

bureau d’enregistrement sortant et du contact administratif sortant. 

Les deux titulaires ont 15 jours pour donner leur accord en cliquant sur le 

lien prévu à cet effet dans le mail de notification. Ils ont également la 

possibilité de valider la transmission par l’envoi d’un fax (ou d’une pièce 

jointe) cosigné des deux parties (cf. § 5. Procédures manuelles). Si au bout 

de 15 jours le double accord n’est pas obtenu, l’opération est abandonnée. Si 

pendant ces 15 jours l’un des titulaires demande l’abandon de la 

transmission en cliquant sur le lien prévu à cet effet dans le mail de 

validation, la transmission est immédiatement abandonnée. 






Le trade est possible même si le label hold[Whois] du domaine est 

positionné sur oui. 

Si le label hold[Whois] du domaine est positionné sur oui avant le trade, à 

la sortie de l’opération il sera positionné sur non. 


renseignés. 

L’opération trade se fait à serveurs de noms constants et sans vérification 

technique (pas de passage du ZoneCheck). 


la signature du domaine (si elle existe) pendant l’opération de trade. Il 

utilise pour cela l’attribut keepDS qui sera positionné à 1 ou 0. En l’absence 

de cet attribut keepDS, la signature n’est pas maintenue. L’attribut keepDS 

est présent dans la version 1.1 du serveur EPP, il est absent de la version 1.0 

et du formulaire mail 2.5.0 (cf. § 6. Annexe 1 du Guide d’intégration 

technique). 










L’opération trade se fait sans générer de nouveau auth_info. Le bureau 

d’enregistrement entrant a l’obligation de mettre à jour par une opération 

d’update [context] ce auth_info pour sécuriser le domaine ainsi que de 

donner l’accès au auth_info généré au titulaire. 

Après la validation finale du trade, le bureau d’enregistrement sortant a 




Pendant une opération trade, aucune autre opération ne peut être saisie 

(status [EPP] pendingTrade). L’opération trade peut-être abandonnée par le 

bureau d’enregistrement entrant sans facturation de la part de l’AFNIC (cf. § 

4.3.2). Les deux bureaux d’enregistrements impliqués dans l’opération en 

seront alors notifiés. 

L’opération trade est une opération facturée qui modifie la date anniversaire 

du nom de domaine. 

4.2.6. Recover (transmission forcée vers un nouveau titulaire) 

Recover 




contact titulaire entrant 






Nom de domaine, nic-handle du contact titulaire, nichandle 

du contact administratif, nic-handles des 


contacts techniques, auth_info, keepDS 

Nom de domaine, nic-handle du titulaire sortant, du 

titulaire entrant, id du bureau d'enregistrement entrant, 


id du bureau d'enregistrement sortant, date de fin 

d’opération 

Notification : Bureaux d'enregistrement entrant et sortant 



On parle de transmission forcée si le titulaire sortant n’existe plus (fusion, 

rachat…), en cas de décision judiciaire ou décision prise dans le cadre d’une 

procédure de résolution de litige (PRL) ou si la transmission concerne un 

nom de domaine soumis à un enregistrement sous condition (génération de 

code d’autorisation). 






L’opération recover nécessite l’obtention d’un code d’autorisation auprès de 

l’AFNIC (cf. § 5.2). Ce code d’autorisation devient le nouvel auth_info 

nécessaire à la transmission. 

L’opération est ensuite immédiate. 

Les bureaux d’enregistrement entrant et sortant sont notifiés de l’issue de 

cette opération. 

L’opération recover est possible même si le label hold[Whois] du domaine 

est positionné sur oui. 

Si le label hold[Whois] du domaine est positionné sur oui avant le recover, 

à la sortie de l’opération il est positionné sur non. 


renseignés. 


la signature du domaine (si elle existe) pendant l’opération de recover. Il 

utilise pour cela l’attribut facultatif keepDS qui sera positionné à 1 ou 0. En 

l’absence de cet attribut keepDS, la signature n’est pas maintenue. L’attribut 

keepDS est présent dans la version 1.1 du serveur EPP, il est absent de la 

version 1.0 et du formulaire mail 2.5.0 (cf. § 6. Annexe 1 du Guide 

d’intégration technique). 

L’opération recover se fait à serveurs de noms constants et sans vérification 

technique (pas de passage du ZoneCheck). 










À l’issue du recover, le bureau d’enregistrement a l’obligation de mettre à 

jour par une opération d’update [context] le auth_info pour sécuriser le 

domaine ainsi que de donner l’accès au auth_info généré au titulaire 

Après la validation finale du recover, le bureau d’enregistrement sortant a 




L’opération recover est une opération facturée qui modifie la date 


4.2.7. Update [admin] (mise à jour administrative) 

Recover 




contact titulaire du domaine 






Nom de domaine, nic-handles des contacts techniques 


et administratif à appliquer 


Notification : Bureau d'enregistrement 



L’opération update [admin] (mise à jour administrative) consiste à modifier 

les contacts administratif et/ou techniques pour un domaine. Le contact 

titulaire ne peut pas être modifié par cette opération car il s’agit alors d’un 

trade (transmission). 

Un domaine doit avoir un et un seul contact administratif résidant en France, 

et au moins un contact technique sans contraintes particulières. L’utilisation 

d’un contact comme contact administratif ou technique ne déclenche pas de 

phase d’identification. 

L’opération update [admin] est une opération non facturée qui ne modifie 

pas la date anniversaire du nom de domaine. 






4.2.8. Update [tech] (mise à jour technique) 

Update [tech] 


Durée :

Pendant l’opération update [tech], aucune autre opération ne peut être saisie 

(status[EPP] pendingUpdate). L’opération d’update [tech] ne peut pas être 

abandonnée par le bureau d’enregistrement. 

L’opération update [tech] est une opération non facturée qui ne modifie pas 

la date anniversaire du nom de domaine. 

4.2.9. Update [context] (mise à jour du hold et du auth_info) 

Update [context] 








Éléments à fournir : Nom de domaine, hold, auth_info 


Notification : Bureau d'enregistrement 



Cette opération permet deux sous-opérations distinctes. 

4.2.9.1. Mise à jour du hold 

La mise à jour du hold permet de basculer le label hold[Whois] entre les 

valeurs oui et non. 

• Hold[Whois] oui : les serveurs de noms du domaine, si présents, 

ne sont pas publiés dans le DNS. Le domaine n’est donc pas 

activé. 






• Hold[Whois] non : les serveurs de noms du domaine, si présents, 

sont publiés dans le DNS. 

Cette opération de mise à jour ne déclenche pas de passage du 

ZoneCheck. 

4.2.9.2. Mise à jour du auth_info 

Cette opération permet au bureau d’enregistrement de renseigner un 

nouvel auth_info pour le domaine. 

Cette opération n’est pas facturée. 

le bureau d’enregistrement doit donner l’accès au auth_info au 

titulaire du nom de domaine (et uniquement à lui) dès la fin de la mise à 

jour du auth_info. Tout manquement à cette phase de la procédure peut 

donner lieu à sanction de la part de l’AFNIC 


Cette opération doit être effectuée par le bureau d’enregistrement entrant 

après un transfer, un trade, un recover ou un create avec code 

d’autorisation. 






4.3. Opérations diverses et suppléments 

4.3.1. Notifications 

La plupart des opérations sur les contacts et les domaines produisent un 

certain nombre de notifications émises de façon différentes suivant 

l’interface de travail choisie par le bureau d’enregistrement. 

On peut différencier les notifications immédiates qui sont des résultats 

obtenus directement à l’issue d’une opération et les notifications 

asynchrones qui sont émises par l’AFNIC à l’issue d’un processus de gestion 

plus ou moins long. 

Chaque opération produit au minimum une notification immédiate de fin 

d’opération donnant le statut final de réussite, d’échec ou de bonne réception 

de la demande. 

Au-delà de ces notifications systématiques, la liste des notifications 

asynchrones que peut recevoir un bureau d’enregistrement est la suivante : 

 

 

 

 

 

 

fin de rédemption : à l’issue des 30 jours de rédemption l’AFNIC 

émet une notification au bureau d’enregistrement gestionnaire du 

domaine. 

demande d’approbation de transfer : après la saisie d’un transfer 

par un bureau d’enregistrement entrant, le bureau d’enregistrement 

sortant reçoit une demande d’accord au transfer 

approbation/rejet de transfer : après l’approbation ou le rejet par le 

bureau d’enregistrement sortant du transfer du domaine, le bureau 

d’enregistrement entrant reçoit la notification de cette décision. 

trade en cours sur un domaine : lorsqu’un trade est déclenché par 

un titulaire via le bureau d’enregistrement entrant, le bureau 

d’enregistrement encore gestionnaire est notifié de cette action en 

cours. 

validation/rejet de trade titulaire entrant/sortant : après action de 

l’un des deux titulaires en faveur ou contre le trade, les bureaux 

d’enregistrement entrant et sortant sont notifiés de ces actions. 

succès/échec d’update [tech] : à l’issue du passage du ZoneCheck le 

résultat de l’opération est notifié au bureau d’enregistrement 

gestionnaire du domaine. 






perte d’un domaine par recover : en cas de recover par le bureau 

d’enregistrement entrant, le bureau d’enregistrement sortant est 

notifié de la perte du domaine. 

 

abandon d’un transfer/trade : en cas d’abandon de la procédure par 

le bureau d’enregistrement ou par l’AFNIC, les bureaux 

d’enregistrement acteurs de l’opération sont notifiés de cette action. 

 

ouverture d’une identification sur un titulaire : lors du lancement 

d’une identification sur un titulaire, le bureau d’enregistrement est 

notifié. 

 

mise en problème d’une identification sur un titulaire : lorsque 

l’identification est en cours mais qu’elle a rencontré un problème, le 

bureau d’enregistrement est notifié. 

 

réussite/échec de l’identification sur un titulaire : lorsque 

l’identification a été définitivement validée ou refusée, le bureau 

d’enregistrement est notifié. 

 

passage en deprecated d’un titulaire de plus d’un an : lorsque 

l’identification d’un titulaire n’est plus valable (>1 an), le bureau 

d’enregistrement en est notifié. 

 

suppression d’un contact par le Garbage Collector : le bureau 

d'enregistrement gérant un contact supprimé par le Garbage Collector 

est notifié. 

4.3.2. Cancel (abandon d’opérations) 

Cancel 

Disponibilité : EPP Mail 


Status[EPP] différent de pendingTransfer ou 


pendingTrade 



Notification : Bureaux d'enregistrement entrant et sortant 



Les opérations de transfer et de trade peuvent être abandonnées directement 

par le bureau d’enregistrement entrant. 

L’abandon peut être décidé et effectué par l’AFNIC dans certains cas. Dans 

tous les cas les opérations initiales ne sont pas facturées et des notifications 

sont effectuées aux différentes parties prenantes. 






4.3.3. Auth_info 

Le auth_info est un mot de passe associé au domaine et qui permet de 

sécuriser l’opération de transfer. 

Le auth_info est un champ qui est obligatoirement renseigné par le bureau 

d’enregistrement entrant (lors d’un create, un transfer, ou un recover). 

 

 

 

Il est librement choisi par le bureau d’enregistrement dans le cas du 

create sans code d’autorisation. 

Il doit être égal au code d’autorisation généré par l’AFNIC dans les 

opérations de create avec code d’autorisation et de recover. 

Il doit être égal au auth_info déjà existant pour le domaine dans le 

cas d’un transfer. 

Certaines contraintes syntaxiques sont imposées et sont détaillées dans le 

Guide d’intégration ( à venir). 

Important : le bureau d’enregistrement doit donner l’accès au auth_info 

au titulaire du nom de domaine (et uniquement à lui) à la fin de toute 

opération le modifiant : create, update [context]. Tout manquement à cette 

phase de la procédure peut donner lieu à sanction de la part de l’AFNIC 


Un auth_info qui découle d’un code d’autorisation généré par l’AFNIC doit 

impérativement être modifié à la suite de l’opération nécessitant 

l’autorisation via un update [context]. 

4.3.4. Statuts : status[EPP] et status[Whois] 

Un nouvel ensemble de labels Whois et de statuts présents dans EPP sur les 

objets domaines vient offrir une plus grande finesse de lecture de l’état des 

objets créés. 

Le protocole EPP permet de cumuler plusieurs valeurs de status. 

Trois labels Whois ont été définis pour offrir l’information la plus pertinente 

possible : 

• status[Whois] : active, registered, redemption 

• pending[Whois] : delete, recover, transfer, update, trade, restore 

• hold[Whois] : oui, non. 






Nous vous présentons ci-dessous un tableau de correspondances entre ces 

différents labels. 

Status[EPP] 

Whois 

hold[Whois] 

Opération 

non 

autorisé 

client hold oui create 

Status[EPP] 

status[Whois] 

Whois 

pending[Whois] 

Opération(s) 

non 

autorisée(s) 

ok active ø create 

inactive registered ø create 

(pendingCreate, 

pendingRecover) 

ø 

create, 

recover 

* 

pendingDelete redemption delete * - restore 

pendingTransfer ø transfer * - cancel 

pendingUpdate ø update * 

pendingTrade ø trade * - cancel 

serverTransferProhibited ø ø 

transfer, 

create 

serverTradeProhibited ø ø trade, create 

pendingRestore redemption restore * 

* : toutes opérations 

* - xxx : toutes opérations sauf xxx 






5. Procédures manuelles 

Au-delà de l’automatisation des opérations, certaines procédures nécessitent une 

analyse basée sur des données externes à l’opération : documents d’entreprise, bases 

de données publiques etc. 

Ces procédures passent par des équipes dédiées de l’AFNIC : l’équipe Support 

comme point d’entrée et l’équipe Gestion Des Domaines (GDD) pour le traitement 

manuel de vos dossiers. 

Les délais standards de l’AFNIC sont de 48 heures ouvrées pour le traitement 

(validation, rejet ou demande d’information complémentaire) d’une procédure non 

automatisée. 

5.1. Documents types 

L’envoi de documents supplémentaires nécessaires au bon déroulement de 

certaines opérations devra se faire par fax au 01.39.30.83.83. 

Par ailleurs, les documents envoyés devront être précédés d’un en-tête et parfois 

d’un document type : la DOA (Demande d’Opérations AFNIC). 

5.1.1. En-tête 

Afin d’optimiser les traitements de part et d’autre, un système de page d’entête 

précisant l’ensemble du contexte opérationnel à des fins de tri 

automatique avant envoi d’un document en pièce jointe ou par fax est mis en 

place. 

Cette page d’en-tête sera générée depuis l’extranet dans la rubrique 

Opérations sous le label « Génération d’en-tête » : 

http://www.afnic.fr/extranet 

Accessible pour chaque bureau d’enregistrement, il permettra de générer un 

fichier PDF comprenant de manière formatée les informations suivantes : 

nom de domaine 

nic-handle du titulaire entrant 

opération : create, trade, recover, identification 

login du bureau d’enregistrement 

Les documents reçus ayant cette page d’en-tête correctement remplie seront 

assurés d’un traitement dans les délais standards de 48h. 

5.1.2. DOA 

La DOA signée par le titulaire est nécessaire afin de valider les opérations 

suivantes : 

 

 

demandes de génération de code d’autorisation (create, recover) 

trade sans passer par les validations mail 






La DOA est téléchargeable ici : 

http://www.afnic.fr/data/formulaires/prive.isp/doa.pdf 

5.2. Détail des opérations concernées 

5.2.1. Trade 

Le trade peut passer par une procédure manuelle si le bureau 

d'enregistrement décide de ne pas utiliser la validation par mail par les deux 

titulaires (sortant et entrant) mais d’envoyer une DOA cosignée des deux 

parties. 

L’envoi d’une DOA précédée de la page d’en-tête adéquate déclenche 

l’analyse du document par le GDD. 

En cas d’analyse positive, le trade est validé. 

En cas d’analyse négative, une réponse est émise vers le bureau 

d'enregistrement qui peut débloquer la situation en répondant au mail si cela 

est suffisant ou bien enrichir son dossier de nouvelles pièces demandées par 

le GDD en faisant précéder celle-ci de l’en-tête adéquat afin qu’elles 

s’ajoutent automatiquement au dossier. 

Si le dossier ne trouve pas une issue positive dans les 15 jours qui suivent la 

saisie du trade, l’opération est abandonnée. 

5.2.2. Create avec code d’autorisation 

Le create avec code d’autorisation passe nécessairement par une procédure 

manuelle de génération de code d’autorisation. Les enregistrements 

concernés sont exposés dans la Charte de Nommage dans l’article 

Enregistrement sous conditions. 



En cas d’analyse positive, le code d’autorisation est généré avec une durée 

de validité de quinze jours pour saisir le create correspondant au triplet 

(titulaire, nom de domaine, bureau d'enregistrement) autorisé. 


d'enregistrement annonçant le rejet de la demande ou bien demandant une 

action complémentaire. Ce dernier peut alors débloquer la situation en 

répondant au mail si cela est suffisant ou bien enrichir son dossier de 

nouvelles pièces demandées par le GDD en faisant précéder celle-ci de l’entête 

adéquat afin qu’elles s’ajoutent automatiquement au dossier. 

Si le dossier ne trouve pas d’issue positive dans les 15 jours qui suivent la 

demande de génération de code, l’ensemble du dossier est abandonné. 






5.2.3. Recover 

Le recover passe nécessairement par une procédure manuelle de génération 

de code d’autorisation. 



En cas d’analyse positive, le code d’autorisation est généré avec une durée 

de validité de quinze jours pour saisir le recover correspondant au triplet 

(titulaire, nom de domaine, bureau d'enregistrement) autorisé. 


d'enregistrement annonçant le rejet de la demande ou bien demandant une 

action complémentaire. Ce dernier peut alors débloquer la situation en 

répondant au mail si cela est suffisant ou bien enrichir son dossier de 

nouvelles pièces demandées par le GDD en faisant précéder celle-ci de l’entête 

adéquat afin qu’elles s’ajoutent automatiquement au dossier. 

Si un dossier n’a pas pu converger vers une décision positive dans les 15 

jours qui suivent la demande de génération de code, l’ensemble du dossier 

est abandonné. 

5.2.4. Identification 

L’identification n’est pas une opération déclenchée par le bureau 

d'enregistrement. Il s’agit d’une opération déclenchée par l’AFNIC. 

L’identification porte sur un objet contact Titulaire et a des conséquences sur 

le portefeuille de domaines qui lui est associé. 

Une identification dans les 30 jours suivant la première utilisation d’un 

contact de type personne morale comme titulaire entrant dans une opération 

sur un nom de domaine. Le processus d’identification est décrit plus bas. 

Pour les personnes physiques il n’y a pas de phase d’identification mais une 

vérification d’éligibilité du titulaire peut avoir lieu sur sollicitation d’un tiers. 

Ce processus peut déboucher sur une identification réussie : le contact 

titulaire est alors identifié positivement pour une durée de un an et ne subit 

plus de contrôles ultérieurs pendant toute cette année quelle que soit son 

utilisation sauf dans les cas prévus par la charte. À l’issue de cette année 

toute opération utilisant à nouveau ce titulaire redéclenche une identification. 

Ce processus peut déboucher sur une identification en échec ce qui 

déclenche à terme la suppression de l’ensemble de son portefeuille de 

domaines. 






5.2.4.1. Statut d’identification du titulaire : idstatus 

Un contact titulaire peut avoir 8 états d’identification qui apparaissent 

dans le Whois : 

idstatus Description : 

NI 

not 

identified 

DE deprecated 

PE 

CL 

DY 

PB 

OK 

KO 

pending 

control 

delayed 

problem 

OK 

KO 

contact créé mais non encore référencé 

comme titulaire d’un nom de domaine 

contact dont l’identification positive date d’il 

y a plus d’un an 

contact ayant une identification en cours 

déclenchée par une opération 

contact ayant une identification en cours 

déclenchée par l’AFNIC. 

contact normalement en état pending dont la 

phase d’identification est reportée pour des 

raisons techniques. 

contact dont l’identification déclenchée par 

l’AFNIC a rencontré une incohérence 

contact identifié positivement depuis moins 

d’un an 

contact dont l’identification n’a pu aboutir 

dans le délai des deux mois. Cet état 

déclenche la suppression du portefeuille (sauf 

risque en terme de sécurité ou de stabilité) et 

la mise en obsolescence du contact 

idstatus 

Opérations refusées au 

titulaire entrant 

Opérations refusées au 

titulaire sortant 

NI aucune aucune 

DE aucune aucune 

PE 

CL 

aucune 

aucune 

• transfer 

• trade 

• transfer 

• trade 

DY aucune aucune 

PB 

toutes 

• transfer 

• trade 

OK aucune aucune 

KO 

toutes 

• transfer 

• trade 






Rappel : le titulaire sortant est un ancien titulaire qui perd un domaine et 

ne peut donc intervenir que dans les opérations trade, transfer et 

recover. 

Ces états reflètent donc exactement les opérations possibles avec ce 

contact ainsi que l’avancement de la procédure d’identification ou de 

contrôle ponctuel. 






5.2.4.2. Les principes de l’identification 

Dans cette phase d’identification l’AFNIC procède à une série de tests 

basés sur les identifiants fournis (RCS, siren pour les sociétés, numéro de 

marque pour les titulaires de marque, …). 

 

vérification de l’existence légale de l’organisation basée sur son 

identifiant 

• en cas de non–existence de l’entité liée à l’identifiant (absence 

d’entrée dans les bases publiques, plan de cession en cours ou 

radiation), l’idstatus passe en état PB et 

• Si le contact était en NI (première identification en cours) 

le bureau d’enregistrement peut soumettre un nouvel 

identifiant, qui deviendra titulaire du nom de domaine 

avec la dénomination ou raison sociale ou désignation 

correspondant dans les bases publiques ou bien soumettre 

des documents attestant la cohérence des données 

fournies. 

• Si le contact était en DE (deuxième identification ou plus) 

le portefeuille de domaines est supprimé à l’issue des 

deux mois sauf réception de document attestant la 

cohérence des données fournies. 

Rappel : la suppression émise par l’AFNIC ne déclenche 

pas de période de rédemption. Pour des raisons 

techniques, l'opération de suppression par l’AFNIC se 

déroulera en deux étapes : 

o Recover des noms de domaine par l'AFNIC vers 

son compte. Dans la base Whois, ces noms de 

domaine apparaîtront sous le nom du bureau 

d'enregistrement : "AFNIC -Opération-Interne". 

o Suppression définitive des noms de domaine par 

l'AFNIC. 

 

vérification de la dénomination ou raison sociale ou désignation 

• en cas de correspondance exacte entre la dénomination ou 

raison sociale ou désignation fournie et celle trouvée sur les 

bases publiques, le whois est renseigné avec la dénomination ou 

raison sociale ou désignation fournie 

• en cas de lien perceptible entre la dénomination ou raison 

sociale ou désignation fournie et celle trouvée sur les bases 

publiques, le whois est renseigné avec la dénomination ou 

raison sociale ou désignation trouvée sur les bases publiques 

• en cas de non concordance entre la dénomination ou raison 

sociale ou désignation fournie et celle trouvée sur les bases 






publiques, l’idstatus passe en état PB et le bureau 

d’enregistrement est notifié 

• si le contact était en NI (première identification en cours) 

le bureau d’enregistrement peut soumettre un nouvel 

identifiant, qui deviendra titulaire du nom de domaine 

avec la dénomination ou raison sociale ou désignation 

correspondant dans les bases publiques ou bien soumettre 

des documents attestant la cohérence des données 

fournies. 

• Si le contact était en DE (deuxième identification ou plus) 

le whois est renseigné avec la dénomination ou raison 

sociale ou désignation trouvée sur les bases publiques sauf 

réception de document attestant la cohérence des données 

fournies. 

 

vérification des données de contact titulaire 

• si le téléphone ou l’adresse du contact titulaire semblent fictifs 

ou ne pas correspondre aux critères d’éligibilité le bureau 

d'enregistrement dispose de deux mois pour mettre à jour ces 

données avec des données adéquates. 

Le transfert de documents justificatifs dans ces différentes étapes se fait 

par l’envoi d’un fax avec la page d’en-tête adéquate qui déclenchera 


En cas d’analyse positive l’identification passe en idstatus OK et le 

titulaire sera positivement identifié pour une durée d’un an. 


d'enregistrement qui peut débloquer la situation en répondant au mail si 

cela est suffisant ou bien enrichir son dossier de nouvelles pièces 

demandées par le GDD en faisant précéder celle-ci de l’en-tête adéquat 

afin qu’elles s’ajoutent automatiquement au dossier. 

Si un dossier ne trouve pas d’issue positive dans le premier mois qui suit 

le passage en PB de l’identification, le domaine est bloqué (désactivation 

du DNS), puis le portefeuille du titulaire est supprimé si à l’issue du mois 

suivant aucune solution n’a été trouvée. 

Rappel : la suppression émise par l’AFNIC ne déclenche pas de période 

de rédemption. Pour des raisons techniques, l'opération de suppression 

par l’AFNIC se déroulera en deux étapes : 

o Recover des noms de domaine par l'AFNIC vers son compte. 

Dans la base Whois, ces noms de domaine apparaîtront sous le 

nom du bureau d'enregistrement : "AFNIC -Opération-Interne". 

o Suppression définitive des noms de domaine par l'AFNIC. 

À toutes les phases du processus, le bureau d'enregistrement concerné est 

notifié. 






Annexe 






Demande d’Opérations AFNIC (DOA) 

Titulaire : merci de retourner ce document rempli à votre bureau d’enregistrement 

Bureau d’enregistrement : à faxer précédée de l’en-tête de fax AFNIC (disponible sur www.afnic.fr/extranet) 

Nom de domaine : 

Bureau d’enregistrement uniquement 

▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼ 

Bureau d’enregistrement : n° de contrat AFNIC : 

Opération demandée (cocher la case correspondante) : 

Transmission 

volontaire (trade) 

Titulaire entrant 

► Nic handle : 

Transmission forcée 

(recover) 

Identité des parties 

Création avec code 

d’autorisation (create) 

Titulaire sortant 

(seulement pour la transmission volontaire - trade) 

► Nic handle : 

Bureau d’enregistrement uniquement 

▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼ 

► Pour une personne physique : 

• Nom et prénom : 

• Date et lieu de naissance : 

► Pour une personne morale : 

• Raison sociale : 

• Identification (Siren/RCS/n° de marque) : 

► Pour une personne physique : 


• Date et lieu de naissance : 

► Pour une personne morale : 

• Raison sociale : 

• Identification (Siren/RCS/n° de 

marque) : 

• ………………………………………………….. 

• ………………………………………………….. 

Justificatifs transmis 

• …………………………………………………… 

• …………………………………………………… 

pour le titulaire entrant 


• À le 

• Signature (+ cachet de l’entreprise) : 

Signatures (1) 

- www.afnic.fr - 

pour le titulaire sortant 


• À le 

• Signature (+ cachet de l’entreprise) : 

(1) J'atteste avoir tout pouvoir pour représenter et agir au nom du titulaire entrant ou du titulaire sortant. 

Je déclare avoir pris connaissance des termes de la charte de nommage ainsi que tous les documents annexes, et déclare y adhérer sans 

réserve. Cette demande est réalisée sous ma seule responsabilité étant entendu que toutes informations erronées ou toute violation des 

termes de la charte ou d'un des règlements pourra entrainer le gel, le blocage ou la suppression du nom de domaine. 

Les informations recueillies font l’objet d’un traitement informatique par l’Association française pour le nommage internet en coopération (AFNIC), 

responsable du traitement afin de lui permettre de procéder aux opérations demandées dans de bonnes conditions, conformément aux articles 24 des 

chartes de nommage du .fr et du .re. Le destinataire des données est le service des Opérations de l’AFNIC. Conformément à la loi Informatique et 

Libertés du 6 janvier 1978 modifiée, vous bénéficiez d’un droit d’opposition pour motifs légitimes, d’accès et de rectification aux informations qui vous 

concernent. Si vous souhaitez obtenir communication des informations vous concernant, veuillez vous adresser à AFNIC, Immeuble International, 

78181 Saint Quentin en Yvelines, France. 

© AFNIC 2009 – version 22 septembre 2009

Guide des procÃ©dures du .fr - Afnic

Create successful ePaper yourself

Delete template?

Save as template?