Afnic Guide Integration Technique PDF

126
GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012 1 Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected] Twitter : @AFNIC | Facebook : afnic.fr Guide d'intégration technique - Version 2.5 - 3 juillet 2012

description

Guide d'integration technique PDF

Transcript of Afnic Guide Integration Technique PDF

Page 1: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  1 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Guide d'intégration technique

- Version 2.5 -3 juillet 2012

Page 2: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  2 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

T a b l e d e s m a t i è r e s

1. Préface..................................................................................................5

1.1. À propos de ce document.............................................................................5

1.2. Public ciblé.....................................................................................................5

1.3. Conventions typographiques .......................................................................5

1.4. Historique des révisions ...............................................................................5

2. IDN ........................................................................................................6

2.1. Documents de référence ...............................................................................6

2.2. Rappel succinct sur la technologie des IDN ...............................................6

2.3. Avertissement ................................................................................................7

2.4. Quelques éléments de vocabulaire..............................................................7

2.5. Tableau des caractères acceptés.................................................................8

2.6. Usage des versions Unicode vs versions LDH .........................................10

3. EPP .....................................................................................................10

3.1. Configuration et paramètres.......................................................................10

3.2. Les grands principes d'intégration ............................................................10 3.2.1. Pas d’implémentation des objets "host" (RFC 5732) ..................................................................10 3.2.2. Cas des opérations avec code retour 1000 et comportement du serveur en cas de problème......11 3.2.3. Gestion du auth_info ...................................................................................................................11 3.2.4. Choix d’implémentation de la liste des messages de notification ...............................................11 3.2.5. Support de DNSSEC ...................................................................................................................12

3.3. Commandes implémentées ........................................................................13 3.3.1. Le <greeting> ..............................................................................................................................13 3.3.2. La commande <hello>.................................................................................................................14 3.3.3. Les commandes de gestion de session.........................................................................................14 3.3.4. Les commandes d’interrogation ..................................................................................................17 3.3.5. Les commandes de mise à jour d’objets......................................................................................19

3.4. Gérer un nom de domaine ..........................................................................20 3.4.1. Create - créer un nom de domaine...............................................................................................20 3.4.2. Update - modifier les attributs du domaine .................................................................................24 3.4.3. Delete - Supprimer un domaine...................................................................................................34 3.4.4. Restore - Restaurer un domaine ..................................................................................................35 3.4.5. Transfer – Changement de bureau d’enregistrement...................................................................36 3.4.6. Trade - Transmettre un domaine .................................................................................................46 3.4.7. Recover - Transmission forcée d’un nom de domaine ................................................................53

Page 3: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  3 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.8. Vérifier la disponibilité d'un domaine .........................................................................................56 3.4.9. Récupérer les données d'un domaine...........................................................................................59

3.5. Gérer un contact ..........................................................................................65 3.5.1. Créer un contact ..........................................................................................................................65 3.5.2. Modifier un contact .....................................................................................................................72 3.5.3. Supprimer un contact...................................................................................................................73 3.5.4. Qualification d’un contact titulaire..............................................................................................73 3.5.5. Récupérer les données d'un contact.............................................................................................74

3.6. Notifications .................................................................................................76 3.6.1. Gestion de la file de notification .................................................................................................76 3.6.2. Notifications asynchrones ...........................................................................................................77 3.6.3. Notifications exogènes ................................................................................................................83

3.7. Codes retours et messages d'erreurs......................................................100 3.7.1. Les codes retour ........................................................................................................................100 3.7.2. Les messages d’erreurs..............................................................................................................103

3.8. RFCs ...........................................................................................................105

4. Interface Web : le système de tickets............................................106

4.1. Généralités sur les tickets ........................................................................106

4.2. Format du ticket.........................................................................................106

4.3. Description de l’ensemble des tickets .....................................................106

5. Les opérations gérables uniquement par mail/fax .......................114

5.1. Génération de code d’autorisation...........................................................114

5.2. Validation de trade.....................................................................................115

5.3. Notification de suivi de la procédure de qualification ............................115

5.4. Notification de gel, blocage et suppression du portefeuille de domaines.......................................................................................................116

5.5. Mail de Justification...................................................................................117

6. Service DAS (Domain Availability Service) ...................................118

6.1. Paramètres pour interroger le service .....................................................118

6.2. Les informations disponibles ...................................................................118 6.2.1. Validité du nom de domaine testé .............................................................................................118 6.2.2. Disponibilité du nom de domaine..............................................................................................118 6.2.3. État de la publication DNS........................................................................................................119 6.2.4. Informations sur les restrictions liées à ce nom de domaine .....................................................119 6.2.5. Des dates clés sur des domaines existants .................................................................................119

Page 4: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  4 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

6.3. DAS et IDN..................................................................................................119

6.4. Exemples ....................................................................................................120 6.4.1. Nom de domaine qui n'existe pas et qui ne fait l'objet d'aucune restriction ..............................120 6.4.2. Nom de domaine soumis à examen préalable ...........................................................................121 6.4.3. Nom de domaine fantaisiste ......................................................................................................121 6.4.4. Nom de domaine qui existe et qui ne fait l'objet d'aucune restriction .......................................122 6.4.5. Nom de domaine qui est supprimé et en période de rédemption...............................................122 6.4.6. Nom de domaine qui existe mais qui est aussi un terme soumis à examen préalable ...............123 6.4.7. Requête sur différents noms de domaine aux propriétés différentes .........................................124 6.4.8. Interrogation d'un IDN sous sa forme Unicode .........................................................................125 6.4.9. Interrogation d'un IDN sous sa forme ACE...............................................................................125

Page 5: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  5 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Guide d’intégration technique

1. Préface

1.1. À propos de ce document

Ce guide d’intégration réunit l’ensemble des informations nécessaires à l’implémentation de l’interface applicative de gestion de domaines de l’AFNIC. Cette interface offre deux moyens d’accès :

L’interface web EPP (Extensible Provisioning Protocol) : protocole standard d’échange entre

registre et bureaux d’enregistrements. Toutes les oéprations disponibles en EPP le sont aussi sur l’interface web. En ce qui concerne EPP, l’AFNIC a respecté le standard décrit dans les RFCs (cf § 3.8 RFCs.). Ce document se contente donc de décrire les points spécifiques à l’implémentation AFNIC du protocole.

1.2. Public ciblé

Ce document est un document technique à destination des développeurs souhaitant obtenir une description détaillée de l’interface et à la recherche d’exemples facilitant leur intégration. Il ne redétaille pas les procédures (cf. Guide des procédures www.afnic.fr/fr/ressources/documents-de-reference/documents-techniques/guide-des-procedures-pour-les-bureaux-d-enregistrement.html ) ni La Charte de Nommage (http://www.afnic.fr/fr/ressources/documents-de-reference/chartes/) qui seront considérées comme connues.

1.3. Conventions typographiques

Dans l’ensemble du document on écrit : Entre < > les balises xml décrivant les trames EPP Dans un cadre sur fond bleu, les exemples de trames EPP.

1.4. Historique des révisions

24/11/2009 - V1.0 08/04/2010 - V1.1 08/06/2010 - V1.2 – Ajout de notifications EPP manquantes 31/08/2010 - V1.3 – Ajout de la notification EPP suppression portefeuille 19/11/2010 – V1.35 – lignes 5b et 5c dans le § 5.3.1 Sémantique du formulaire 2.5.0 : Optional au lieu de Mandatory

Page 6: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  6 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

04/02/2011 – V 1.5 - Ajout du support DNSSEC en EPP dans le serveur version 1.1 03/03/2011 – V1.55 – Correction de l’exemple de greeting §4.3.1 06/12/2011 – V2.0 – Suppression de l’interface mail, évolution de l’interface EPP suite à l’ouverture à l’europe et aux dom-toms – arrêt de l’identification – ouverture de la qualification. 03/07/2012 – V2.5 – Ajout du § concernant les IDN et le DAS.

2. IDN

2.1. Documents de référence

La mise en œuvre des IDN à l'AFNIC s'appuie sur la norme 2008 d'IDN (IDNA2008), dont voici les documents de référence.

Définitions et protocole :

RFC 5890 (08/2010 23 pages) : Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework

RFC 5891 (08/2010 17 pages) : Internationalized Domain Names in Applications (IDNA): Protocol

RFC 5892 (08/2010 70 pages) : The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)

RFC 5894 (08/2010 43 pages) : Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale

Algorithme d'encodage Punycode :

RFC 3492 (03/2003 35 pages) : Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)

2.2. Rappel succinct sur la technologie des IDN

À l'origine, le protocole DNS n'a pas été défini pour être restreint à un ensemble de caractères. C'est son usage et d'autres limitations de "l'époque" (le protocole a 30 ans) qui ont conduit à définir des règles syntaxiques telles que nous les connaissons aujourd'hui. Le but de la norme IDNA2008 est de concilier les besoins humains et les contraintes techniques en autorisant l'usage de toutes les écritures dans les noms de domaine. Toutes ces écritures et les caractères qui les composent sont définies et regroupées au sein d'une norme appelée Unicode. Comme les règles syntaxiques des noms de domaine imposent l'usage des seules lettres de l'alphabet latin ("a" à "z"), des chiffres, du tiret, et du point pour séparer les labels, un mécanisme de mise sous forme canonique des noms de domaine Unicode et d'encodage de ceux-ci a été mis au point afin de créer des noms compatibles avec ces règles. Alors que dans les applications comme les navigateurs web, les noms Unicode apparaîtront, leur résolution DNS se fera en utilisant la forme encodée (ceci est normalement transparent pour l'utilisateur qui ne devrait pas avoir à manipuler cette forme de nom de domaine).

Page 7: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  7 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

2.3. Avertissement

Bien que l'impact puisse paraître limité, il est important de noter que l'AFNIC met en œuvre la norme IDNA2008 qui diffère légèrement de la norme IDNA2003. Concernant le traitement des caractères pris en compte, le eszett allemand (ß) est encodé, et non pas transformé en "ss" comme dans la version précédente de la norme IDN. De plus, l'étape de canonicalisation (nameprep) a disparu ce qui aura quelques conséquences sur l'usage de nos interfaces. Chaque application AFNIC est désormais libre d'appliquer ses propres règles en la matière, outre le fait que les noms de domaine Unicode doivent être en forme normale C, nous avons choisi d'autoriser la saisie de majuscules (afin d'assurer la rétro-compatibilité avec les usages actuels) mais ce sont bien leurs minuscules équivalentes qui seront réellement prises en compte par le système (attention, le eszett est uniquement accepté dans sa version minuscule). Par exemple, le nom de domaine "Thé-ou-Café.fr" n'est pas légal selon la norme IDNA2008. Nous l'accepterons toutefois une fois qu'il aura été normalisé en "thé-ou-café.fr". Avec des alphabets plus "exotiques" que le Latin, le problème serait sans doute plus complexe, mais tant que l'AFNIC s'en tient aux caractères dont nous indiquons la liste plus loin dans ce document, cette mise sous forme canonique continuera à s'appliquer.

2.4. Quelques éléments de vocabulaire

Unicode : Norme permettant le codage de tout caractère de toutes écriture de manière unique (Unicode sur wikipedia).

UTF-8 : Un des formats de codage permettant d'encoder les caractères Unicode.

ISO-8859-15 : Une des normes de codage ISO sur 8 bits de l'alphabet latin. Connue aussi sous le nom de latin9.

LatinX : Autres noms de certaines normes ISO. Latin9 contrairement à Latin1, intègre la ligature "e dans l'o".

LDH : "LETTER-DIGIT-HYPHEN" les seuls caractères ASCII autorisés pour composer un label dans un nom de domaine.

ASCII : "American Standard Code for Information Interchange", la plus ancienne norme informatique de codage de caractères. À strictement parler sur 7 bits, il ne permet de coder que 128 caractères.

ACE : "ASCII Compatible Encoding" correspond à la version encodée d'un nom de domaine Unicode, sous sa forme LDH (xn--caf-dma en Punycode, autrement "A-label form").

IDN : "Internationalized Domain Name" ou nom de domaine internationalisé, qui contient d'autres caractères que les seuls caractères ASCII.

Canonicalisation : Mise sous forme canonique d'une chaîne de caractères. Par exemple, en latin, mettre en minuscule une chaîne de caractère, fait partie des opérations qui peuvent entrer dans un processus de canonicalisation.

Forme Normale C : Forme normale imposant que les caractères soient (pré)composés. Un caractère correspond à un point de code unique. Cela

Page 8: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  8 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

exclu les caractères obtenus par usage de signes diacritiques associés à des caractères de base.

Code point/Point de Code : Index unique associé à un caractère. Glyphe : Représentation graphique d'un caractère NAMEPREP : Définit la version mise sous forme canonique d'un nom de

domaine Unicode (fait partie de IDNA2003, n'existe plus en IDNA2008). Punycode : Algorithme réversible et unique, permettant de transformer un

IDN canonicalisé en sa forme ACE.

2.5. Tableau des caractères acceptés

Le tableau suivant représente l'ensemble des caractères qui peuvent composer un label de nom de domaine.

# Point de

code Glyphe Nom

Équivalence ASCII

1 U+002D - TRAIT D'UNION-SIGNE MOINS - 2 U+0030 0 CHIFFRE ZÉRO 0 3 U+0031 1 CHIFFRE UN 1 4 U+0032 2 CHIFFRE DEUX 2 5 U+0033 3 CHIFFRE TROIS 3 6 U+0034 4 CHIFFRE QUATRE 4 7 U+0035 5 CHIFFRE CINQ 5 8 U+0036 6 CHIFFRE SIX 6 9 U+0037 7 CHIFFRE SEPT 7 10 U+0038 8 CHIFFRE HUIT 8 11 U+0039 9 CHIFFRE NEUF 9 12 U+0061 a LETTRE MINUSCULE LATINE A a 13 U+0062 b LETTRE MINUSCULE LATINE B b 14 U+0063 c LETTRE MINUSCULE LATINE C c 15 U+0064 d LETTRE MINUSCULE LATINE D d 16 U+0065 e LETTRE MINUSCULE LATINE E e 17 U+0066 f LETTRE MINUSCULE LATINE F f 18 U+0067 g LETTRE MINUSCULE LATINE G g 19 U+0068 h LETTRE MINUSCULE LATINE H h 20 U+0069 i LETTRE MINUSCULE LATINE I i 21 U+006A j LETTRE MINUSCULE LATINE J j 22 U+006B k LETTRE MINUSCULE LATINE K k 23 U+006C l LETTRE MINUSCULE LATINE L l 24 U+006D m LETTRE MINUSCULE LATINE M m 25 U+006E n LETTRE MINUSCULE LATINE N n 26 U+006F o LETTRE MINUSCULE LATINE O o 27 U+0070 p LETTRE MINUSCULE LATINE P p 28 U+0071 q LETTRE MINUSCULE LATINE Q q

Page 9: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  9 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

29 U+0072 r LETTRE MINUSCULE LATINE R r 30 U+0073 s LETTRE MINUSCULE LATINE S s 31 U+0074 t LETTRE MINUSCULE LATINE T t 32 U+0075 u LETTRE MINUSCULE LATINE U u 33 U+0076 v LETTRE MINUSCULE LATINE V v 34 U+0077 w LETTRE MINUSCULE LATINE W w 35 U+0078 x LETTRE MINUSCULE LATINE X x 36 U+0079 y LETTRE MINUSCULE LATINE Y y 37 U+007A z LETTRE MINUSCULE LATINE Z z 38 U+00DF ß LETTRE MINUSCULE LATINE S DUR ss 39 U+00E0 à LETTRE MINUSCULE LATINE A ACCENT GRAVE a 40 U+00E1 á LETTRE MINUSCULE LATINE A ACCENT AIGU a 41 U+00E2 â LETTRE MINUSCULE LATINE A ACCENT CIRCONFLEXE a 42 U+00E3 ã LETTRE MINUSCULE LATINE A TILDE a 43 U+00E4 ä LETTRE MINUSCULE LATINE A TRÉMA a 44 U+00E5 å LETTRE MINUSCULE LATINE A ROND EN CHEF a 45 U+00E6 æ LETTRE MINUSCULE LATINE AE ae 46 U+00E7 ç LETTRE MINUSCULE LATINE C CÉDILLE c 47 U+00E8 è LETTRE MINUSCULE LATINE E ACCENT GRAVE e 48 U+00E9 é LETTRE MINUSCULE LATINE E ACCENT AIGU e 49 U+00EA ê LETTRE MINUSCULE LATINE E ACCENT CIRCONFLEXE e 50 U+00EB ë LETTRE MINUSCULE LATINE E TRÉMA e 51 U+00EC ì LETTRE MINUSCULE LATINE I ACCENT GRAVE i 52 U+00ED í LETTRE MINUSCULE LATINE I ACCENT AIGU i 53 U+00EE î LETTRE MINUSCULE LATINE I ACCENT CIRCONFLEXE i 54 U+00EF ï LETTRE MINUSCULE LATINE I TRÉMA i 55 U+00F1 ñ LETTRE MINUSCULE LATINE N TILDE n 56 U+00F2 ò LETTRE MINUSCULE LATINE O ACCENT GRAVE o 57 U+00F3 ó LETTRE MINUSCULE LATINE O ACCENT AIGU o 58 U+00F4 ô LETTRE MINUSCULE LATINE O ACCENT CIRCONFLEXE o 59 U+00F5 õ LETTRE MINUSCULE LATINE O TILDE o 60 U+00F6 ö LETTRE MINUSCULE LATINE O TRÉMA o 61 U+00F9 ù LETTRE MINUSCULE LATINE U ACCENT GRAVE u 62 U+00FA ú LETTRE MINUSCULE LATINE U ACCENT AIGU u 63 U+00FB û LETTRE MINUSCULE LATINE U ACCENT CIRCONFLEXE u 64 U+00FC ü LETTRE MINUSCULE LATINE U TRÉMA u 65 U+00FD ý LETTRE MINUSCULE LATINE Y ACCENT AIGU y 66 U+00FF ÿ LETTRE MINUSCULE LATINE Y TRÉMA y 67 U+0153 œ DIGRAMME SOUDÉ MINUSCULE LATIN OE oe

Page 10: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  10 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

2.6. Usage des versions Unicode vs versions LDH

Des noms de domaine sont présents dans les noms de serveurs, dans les URL et dans les adresses de courrier électronique, voici les formes acceptées par les interfaces à l'AFNIC. Des messages d'erreur circonstanciés seront retournés en cas de non respect de ces règles.

Nom de domaine : Interface EPP : la seule forme pour les noms de domaine

acceptable est la forme LDH c'est à dire la version ACE pour les IDN. Interface Web : les formes Unicode et LDH sont acceptées

Nom de serveur : n'est acceptable QUE la version LDH. URL : N'est acceptable QUE la version LDH. E-Mail : N'est acceptable QUE la version LDH.

3. EPP

3.1. Configuration et paramètres

Banc de production EPP : • epp.nic.fr • port : 700 • accès authentifié par certificat • nombre de connexions disponibles : 2 • adresses IP pouvant accéder au serveur : 2 • comptes disponibles : 1

Banc de test EPP :

• epp.test.nic.fr • port : 700 • accès authentifié par certificat • nombre de connexions disponibles : 4 • adresses IP pouvant accéder au serveur : illimitées • comptes disponibles : 2

3.2. Les grands principes d'intégration

Au-delà du standard EPP tel qu’il est décrit dans les RFCs, l’AFNIC a posé un certains nombres de principes d’intégration qu’il est bon de connaître avant de se lancer dans le développement d’un client EPP.

3.2.1. Pas d’implémentation des objets "host" (RFC 5732)

Page 11: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  11 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Ce concept étant assez éloigné de la gestion de l’AFNIC des serveurs de noms, nous avons choisi d’adopter la méthode où les serveurs de noms sont des attributs du nom de domaine.

3.2.2. Cas des opérations avec code retour 1000 et comportement du serveur en cas de problème

Une précaution est nécessaire lors du développement de clients qui se connectent à notre serveur EPP. En effet, nous indiquons à plusieurs reprises dans la suite du document, des opérations renvoyant un code retour 1000. Cela est le comportement attendu dans des conditions normales de fonctionnement de la chaîne d’enregistrement des noms de domaine. Nous différencions les problèmes mineurs, majeurs et bloquants. Un problème mineur ou majeur représente un problème sur la chaîne de traitement n’affectant pas la bonne réception des demandes. La chaîne de traitements est alors asynchrone le temps que le problème soit résolu. Toute opération affectée par le problème, renvoie exceptionnellement un code retour 1001 pendant cette période et des notifications seront émises. Pour un problème mineur, les opérations sur les objets "contact", les consultations des files de notifications et les opérations EPP de type "query" ne sont pas affectées. Dans le cas d’un problème bloquant, le serveur réagit de façon plus radicale et aucune opération de type "transform" sur les domaines ne peut être prise en compte. Un message d’erreur "command failed" (code 2400) est alors retourné pour toute nouvelle commande.

3.2.3. Gestion du auth_info

Le protocole EPP prévoit l’utilisation d’un auth_info, pour les noms de domaine, qui sont utilisé dans le cadre des opérations de transfer (changement de bureau d’enregistrement). Les opérations que nous décrivons par la suite permettent aux bureaux d’enregistrement qui utilisent notre serveur EPP de récupérer les auth_info de tout leur portefeuille de domaines et de modifier ceux-ci si nécessaire. De plus, compte tenu de l’utilisation obligatoire de ce auth_info pour tout changement de bureau d’enregistrement, une règle impose la mise à disposition de ce code par le bureau gestionnaire du nom de domaine. Chaque bureau est libre de choisir la meilleure méthode permettant la diffusion de cette information.

3.2.4. Choix d’implémentation de la liste des messages de notification

Nous avons choisi d’indiquer lors de n’importe quelle réponse du serveur le nombre de messages dans la file d’attente (à moins qu’il n’y ait aucun message, auquel cas, cette information ne doit pas être fournie). Le RFC 5730 n’oblige à fournir cette information que dans le cas des réponses aux commandes <poll>

Page 12: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  12 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

alors qu’elle est optionnelle pour les autres types de commandes. Concrètement, cela implique que dès qu’un message doit être notifié à un bureau d’enregistrement, celui-ci en est averti par la présence de l’élément <msgQ> présent dans les réponses à toutes les commandes envoyées au serveur. Il est vivement conseillé de prendre connaissance de ces messages au fur et à mesure que ceux-ci arrivent puisqu’au milieu des messages de suivi d’opérations de modifications techniques par exemple peuvent très bien se trouver des demandes de transfer auxquelles il pourrait être intéressant de répondre.

3.2.5. Support de DNSSEC

Le serveur EPP gère l'extension secDNS-1.1 telle que décrite dans le RFC 5910, à l'exclusion de toute autre version. Les spécificités de mise en œuvre sont les suivantes :

Le serveur supporte uniquement « l'interface données DS » (<secDNS:dsData>), section 4.1 du RFC 5910, sans informations sur la clef associée (pas d'élément <secDNS:keyData>) ; la présence d'informations relatives à la clef générera une erreur 2102.

De manière similaire aux serveurs de noms, les éléments DNSSEC ne

sont acceptés que lors d'une opération update[tech] ; leur présence lors d'un create provoquera une erreur 2103.

Un nom de domaine peut avoir au plus 6 enregistrements DS associés :

le nombre d'élements <secDNS:dsData> présents dans la section <secDNS:add> lors d'une opération update[tech] est donc limité de telle façon que l'état final du nom de domaine n'ait pas plus de 6 enregistrements DS.

L’élément maxSigLife n'est pas supporté, sa présence dans la demande

du client générera une erreur 2102. L'attribut urgent n'est pas supporté, sa présence dans la demande du

client avec la valeur 1 générera une erreur 2102. Lors d'une opération transfer, la partie extension AFNIC frnic-1.2 doit

obligatoirement comporter un drapeau keepDS qui est un booléen : s'il vaut 1, les enregistrements DS actuels du domaine sont conservés après le transfert si déjà présents, alors que s'il vaut 0 en cas de transfert réussi tout enregistrement DS existant sera supprimé.

Les opérations trade et recover fonctionnent de manière identique au

transfer évoqué au-dessus.

La présence de l'élément <secDNS:add> lors d'une opération update[tech] entraînera l'exécution de tests spécifiques à DNSSEC par ZoneCheck. Le contenu de ces tests est rappelé à l'adresse http://www.afnic.fr/fr/produits-et-services/services/zonecheck/politique-de-tests.html. Tous les algorithmes de

Page 13: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  13 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

génération de clef et de condensat sont acceptés, mais certains tests ZoneCheck sont succeptibles de remonter des erreurs fatales pour les algorithmes connus lorsque des problèmes spécifiques sont détectés, et donc in fine d'empêcher la prise en compte de l'opération update demandée.

3.3. Commandes implémentées

3.3.1. Le <greeting>

Le <greeting> n’est pas une commande que le client peut envoyer au serveur EPP mais la bannière d’accueil que ce dernier va envoyer au moment de l’établissement de la connexion. C’est aussi la réponse qui sera envoyée en réponse à une commande <hello> (cette commande est abordée au point suivant). Pourquoi s’attarder sur cette bannière si ce n’est pas une commande ? Tout simplement parce que les informations qu’elle fournit ont leur importance et sont nécessaires, entre autres, pour la commande <login>. Bien que le <greeting> qui est reproduit ci-après ne soit donné qu’à titre d’exemple et que le détail de ce qu’il peut contenir peut être trouvé dans le RFC 5730, il faut être particulièrement attentif à au moins 2 informations fournies, à savoir les versions du protocole supportées (élément <version>) et les langues acceptées (élément <lang>). Seul un choix, parmi ces valeurs, sera accepté lors de l’établissement de la session avec la commande <login>. Exemple de <greeting> pouvant être envoyé par le serveur EPP de l’AFNIC :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <greeting> S: <svID>EPP PROD Server on nergal.nic.fr (V1.1.0)<svID> S: <svDate>2010-04-01T12:34:56.0Z</svDate> S: <svcMenu> S: <version>1.0</version> S: <lang>en</lang> S: <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI> S: <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI> S: <svcExtension> S: <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI> S: <extURI>http://www.afnic.fr/xml/epp/frnic-1.2</extURI> S: <extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI> S: </svcExtension> S: </svcMenu> S: <dcp> S: <access><all/></access> S: <statement> S: <purpose><admin/><prov/></purpose> S: <recipient><ours/><public/></recipient> S: <retention><stated/></retention> S: </statement> S: </dcp> S: </greeting> S:</epp>

Page 14: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  14 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.3.2. La commande <hello>

Bien que ce ne soit pas une commande EPP à proprement parler, cette commande est particulièrement importante et utile car elle va permettre à un client EPP de vérifier que la connexion avec le serveur est correctement établie. En effet, dès lors qu’une connexion est établie avec le serveur, il est possible, à tout moment d’envoyer cette commande à laquelle le serveur répondra en envoyant la bannière d’accueil EPP (le <greeting>), et ceci, même si la phase d’authentification (<login>) n’est pas encore complétée. Dans la mesure où des mécanismes de time-out devaient être activés (pour plus de détails, se référer au document Les politiques techniques du registre en cours d’élaboration) pour clore des sessions « inactives », il est tout à fait possible de réaliser un « heartbeat » en exécutant cette commande de manière régulière afin de maintenir ouvertes des sessions peu utilisées (bien entendu, la fréquence de ce « heartbeat » devra rester raisonnable, eu égard aux paramètres de « time-out » et de rate-limiting éventuellement mis en place). Par exemple, on peut très bien imaginer qu’exécuter cette commande toutes les 2 minutes pour maintenir une connexion ouverte et s’assurer que le serveur est toujours à l’écoute est une fréquence acceptable.

Exemple de requête envoyée par le client :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <hello/> C:</epp>

3.3.3. Les commandes de gestion de session

Le protocole EPP propose 2 commandes permettant d’établir (<login>) et de terminer une session avec le serveur (<logout>). Une fois la session établie, celle-ci ne se terminera que sur demande du client (<logout>) ou si le serveur devait, pour des raisons internes la clore (« time-out » sur session inactive, problèmes technique, …) ou si le client interrompt la connexion TCP (si cette interruption se fait dans le cadre normal d’utilisation du client, il est vivement recommandé d’effectuer un <logout> avant de couper la connexion TCP).

Le nombre de sessions simultanées pouvant être limité, la gestion de celles-ci se doit d’être rigoureuse.

3.3.3.1.La commande <login>

Lors de la connexion au serveur, celui-ci envoie une bannière au client (<greeting>) indiquant, par là même, qu’il est disposé à recevoir une commande d’établissement de session. Cette commande nécessite de connaître l’identifiant EPP généré par l’AFNIC pour chacun de ses bureaux d’enregistrement ainsi que le mot de passe qui lui est associé (il a été choisi,

Page 15: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  15 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

pour des raisons de sécurité et « d’étanchéité » entre les différentes interfaces proposées par l’AFNIC, de créer de nouveaux identifiants, sans le moindre lien avec ceux qui pouvaient jusqu’à présent exister). Si ceux-ci sont correctement renseignés et que le nombre de sessions actuellement établies n’a pas atteint le nombre maximum autorisé, la session doit normalement s’établir. La commande <login> offre aussi la possibilité de modifier le mot de passe associé à cet identifiant, il n’y a aucune limitation à cet usage et il est même vivement conseillé de le modifier lors de la première ouverture de session sur le serveur EPP. Exemple de commande <login> envoyée par un client :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <login> C: <clID>-kiffucol911-.fr</clID> C: <pw>toto1</pw> C: <newPW>toto2</newPW> C: <options> C: <version>1.0</version> C: <lang>en</lang> C: </options> C: <svcs> C: <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI> C: <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI> C: <svcExtension> C: <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI> C: <extURI>http://www.afnic.fr/xml/epp/frnic-1.2</extURI> C: </svcExtension> C: </svcs> C: </login> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Le résultat de cette commande sera l’ouverture d’une session pour le bureau d’enregistrement dont l’identifiant EPP est « –kiffucol911-.fr », le mot de passe est « toto1 », et qui par mesure de sécurité décide de le changer par « toto2 » (bien entendue, c’est ce nouveau mot de passe qui devra être utilisé lors du prochain établissement de session, puisque la prise en compte de cette modification est immédiate).

3.3.3.2.Authentification stricte

Pour tout commande après le login, il est vérifié de façon stricte que les extensions EPP (espaces de noms XML) utilisées ou définies ont été effectivement annoncées par le client précédemment lors du login. Si une nouvelle extension apparaît lors d'une commande, celle-ci sera rejetée. Cela signifie donc qu'il faut au moins annoncer explicitement :

Page 16: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  16 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

l'extension frnic-1.2 pour les opérations sur les contacts et certaines

opérations sur les domaines, comme le transfer, trade, recover, etc. l'extension rgp-1.0 pour pouvoir restaurer un nom de domaine, et éventuellement l'extension secDNS-1.1 si vous souhaitez pouvoir

gérer DNSSEC. Par ailleurs, il est vérifié de façon stricte que les extensions EPP choisies par le client au moment de l'authentification font bien partie des extensions EPP annoncées par le serveur. La présence de toute autre extension "exotique" entraînera un échec d'authentification, tout comme l'absence d'une extension obligatoire. Le cumul de ces deux tests vous impose donc de vous authentifier avec l’une des deux combinaisons suivantes :

domain-1.0, contact-1.0, frnic-1.2, rgp-1.0 ou bien

domain-1.0, contact-1.0, frnic-1.2, rgp-1.0, secDNS-1.1

3.3.3.3.La commande <logout>

Nous l’avons déjà indiqué, un client souhaitant avoir une gestion propre des sessions EPP doit envoyer une commande de fin de session (<logout>) (et, dans l’idéal, attendre la réponse du serveur) avant de couper la connexion TCP avec le serveur. Bien que le serveur soit à même de détecter des déconnexions « sauvages » des clients EPP, ce type de déconnexion pourrait ne pas libérer aussi vite que désiré les ressources limitées allouées à chaque bureau d’enregistrement. Pour être tout à fait clair, si nous n’autorisons, par exemple, que N sessions simultanées par bureau d’enregistrement au serveur EPP (cf §3.1. Configuration et paramètres), que celles-ci sont toutes utilisées à un instant donné, déconnecter un client sans phase de <logout> pourrait avoir comme effet de ne pas prendre immédiatement en compte cette déconnexion. Cela empêche du même coup toute nouvelle connexion et ainsi renvoie un code retour 2502 le temps que le système détecte et gère correctement cette déconnexion. Exemple de commande <logout> envoyée par un client :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <logout/> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Page 17: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  17 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.3.4. Les commandes d’interrogation

Bien que dans les chapitres qui suivent, nous détaillons les commandes pour les différents types d’objets (contact et domain), voici un bref aperçu de ce qui est disponible et l’usage pour lequel ces commandes ont été prévues.

3.3.4.1.La commande <check>

Cette commande va permettre de connaître la disponibilité d’un objet. Compte tenu de la gestion interne que nous avons pour les « contacts », à savoir, c’est un algorithme interne qui détermine l’identifiant (Nic-handle) qui sera associé à un objet « contact », celle-ci n’est utilisable que pour les objets « domain ». Avant toute création de nom de domaine, il est vivement conseillé de vérifier la disponibilité du domaine. Pour cela, il est vivement conseillé d’utiliser le service de vérification de disponibilité de nom de domaine DAS (Domain Availability Service) IRIS D-CHK : cf § 6. Service DAS. Ce service DAS est à privilégié à la commande EPP.

3.3.4.2.La commande <info>

Lorsque vous souhaitez avoir des informations sur un nom de domaine ou sur un contact dont vous connaissez l’identifiant, c’est cette commande qu’il faut utiliser. Un bureau d’enregistrement pourra récupérer les infomations sur les contacts liés aux objets de son portefeuille, et uniquement ceux là. Pour les noms de domaine, il est possible, dès lors que l’on connaît le mot de passe associé à celui-ci (élément <authInfo>), d’avoir les informations sur des domaines gérés par un autre bureau d’enregistrement (ce mot de passe est, entre autres, transmis par le titulaire lors des opérations de <transfer>). Il est important de noter que cette commande ne devrait être utilisée que pour récupérer des infos sur les objets, et non pour vérifier la disponibilité de ceux-ci, par exemple. Cette fonction étant la raison d’être de la commande <check>. Exemple d'interrogation d'un IDN en EPP :

C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> C: <command> C: <info> C: <domain:info xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd"> C: <domain:name hosts="all">xn--strae-42-tya.fr</domain:name> C: </domain:info> C: </info> C: <clTRID>PasTerribleCommeSecret666</clTRID> C: </command> C:</epp>

Page 18: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  18 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de réponse : S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>xn--strae-42-tya.fr</domain:name> S: <domain:roid>DOM000003382455-FRNIC</domain:roid> S: <domain:status s="inactive"/> S: <domain:registrant>TGCA108</domain:registrant> S: <domain:contact type="admin">TGCA108</domain:contact> S: <domain:contact type="tech">VL0</domain:contact> S: <domain:clID>-naqjanir485-.fr</domain:clID> S: <domain:crDate>2012-01-20T13:16:24.0Z</domain:crDate> S: <domain:exDate>2013-01-20T00:00:00.0Z</domain:exDate> S: <domain:upDate>2012-01-20T13:16:24.0Z</domain:upDate> S: <domain:authInfo> S: <domain:pw>IDN2012</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>PasTerribleCommeSecret666</clTRID> S: <svTRID>DEV-vraiton-16996-14-1327418457.36048</svTRID> S: </trID> S: </response> S:</epp>

3.3.4.3.La commande <poll>

Au cours des différentes opérations qui seront réalisées sur les objets du portefeuille d’un bureau d’enregistrement, des messages de notifications auront besoin d’être transmis à celui-ci. Ces messages seront mis dans une file consultable à l’aide de la commande <poll>. Quelques exemples d’utilisation pourront être trouvés pluis loin, mais dans le principe, voici comment fonctionne cette file de messages de notifications. Chaque fois qu’une information liée à une opération (et pour laquelle il existe un message spécifique) doit être transmise, celle-ci est mise dans une file de messages. Dès lors que des messages sont prêts à être lus, l’information est indiquée dans les réponses aux commandes envoyées sur le serveur (élément <msgQ> renseigné). La commande <poll> va permettre de prendre connaissance du message le plus ancien qui se trouve dans la file. Pour que celui-ci soit supprimé de la file de message, il faut utiliser à nouveau cette commande mais en indiquant le numéro de message à supprimer qui doit correspondre à celui qui vient d’être lu (la procédure détaillée peut-être trouvée dans le RFC 5730).

Page 19: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  19 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.3.5. Les commandes de mise à jour d’objets

Ces commandes sont toutes détaillées par la suite, il est fortement conseillé de lire les RFCs suivants : 5730 (généralités sur les commandes), 5731 (spécificités liées aux objets « domain »), 5732 (spécificités liées aux objets « contact ») ainsi que le 5910 (spécificités liées à DNSSEC). En voici la liste exhaustive :

<domain:create> <domain:update> <domain:delete> <domain:transfer> <frnic:trade> et <frnic:recover> (opérations sur les domaines avec

utilisation d’une extension) <contact:create> <contact:update>

Page 20: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  20 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4. Gérer un nom de domaine

3.4.1. Create - créer un nom de domaine

Le protocole EPP (RFC 5730) permet la création de noms de domaine (RFC 5731). Il convient de distinguer deux types de dépôts, chacun ayant sa spécificité. Le premier type de dépôt, que nous qualifions de "direct", doit être utilisé pour un enregistrement standard de nom de domaine (cf. La Charte de Nommage AFNIC http://www.afnic.fr/fr/ressources/documents-de-reference/chartes/ ) Le second type de dépôt, que nous qualifions de "dépôt avec code d’autorisation", doit être utilisé pour un enregistrement sous conditions de nom de domaine (cf. La Charte de Nommage AFNIC).

3.4.1.1.Dépôt "direct" d’un nom de domaine

Ce cas représente 99,99 % des opérations de création et il n’y a pas beaucoup d’informations à fournir pour ce type d’opération. En ce qui concerne les nic-handles, d’un point de vue EPP, XX12345-FRNIC est un ROID (Repository Object Identifier) et ce n’est pas ce qui est censé être utilisé comme référence pour les objets "contact". Un objet "contact" est référencé uniquement avec la "partie gauche" du nic-handle, à savoir ce dernier sans le " -FRNIC". Voici les éléments qui doivent être présents lors de la commande et leur description succincte. L’absence d’éléments obligatoire et/ou la présence d’autres éléments renvoient une erreur.

<domain:name> contient le nom de domaine complet (exemple-ndd-

epp.fr). <domain:period> n’a pas vraiment de sens compte tenu de la gestion

actuelle des noms de domaine renouvelés par tacite reconduction. Il a été convenu de ne pas renvoyer d’erreur lorsqu’il est présent mais de n’accepter que 2 valeurs bien précises pour celui-ci.

Soit <domain:period unit="y">1</domain:period>

Nom de l’élément Nombre d’occurrences <domain:name> 1 <domain:period> 0-1 <domain:registrant> 1 <domain:contact type="admin"> 1 <domain:contact type="tech"> 1-3 <domain:authInfo> 1 <domain:pw> 1 <clTRID> 0-1

Page 21: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  21 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Soit <domain:period unit="m">12</domain:period> <domain:registrant> contient l’identifiant du titulaire déduit du nic-

handle de celui-ci auquel on aura retiré le suffixe (FRNIC) et le caractère séparateur "-".

<domain:contact type="admin"> contient l’identifiant du contact administratif.

<domain:contact type="tech"> contient l’identifiant d’un contact technique.

<domain:authInfo> contient le auth_info que le bureau d’enregistrement choisit d’associer à ce nom de domaine. Dans le cas de la création "avec code d’autorisation", ce auth_info est imposé. Il n’est pas prévu dans l’immédiat de proposer un autre mécanisme que le mot de passe (<domain:pw>). Ce dernier étant libre, il est fortement recommandé d’associer un auth_info différent pour tous ses noms de domaine. Il n’est par ailleurs pas possible d’utiliser l’attribut "roid". De manière à ne pas être ambigu à ce niveau, son utilisation a pour résultat de renvoyer une erreur.

• <clTRID> est optionnel. Il est vivement conseillé de renseigner ce champ pour un meilleur suivi des commandes et pour éventuellement effectuer des recherches et des opérations de « debugging » de vos clients EPP.

Exemple de requête envoyée par le client :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:registrant>MM4567</domain:registrant> C: <domain:contact type="admin">NFC1</domain:contact> C: <domain:contact type="tech">NFC1</domain:contact> C: <domain:contact type="tech">VIL1666</domain:contact> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Dans ce contexte de création "simple", si toutes les règles de nommage et syntaxiques sont respectées et si le nom de domaine est libre, le serveur envoie une réponse avec comme code retour 1000. Pour être plus précis, en cas de succès pour le dépôt du nom de domaine, le seul code retour possible est 1000. Il ne peut pas y avoir de code retour 1001 pour ce type de dépôt sauf problème mineur ou majeur.

Page 22: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  22 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

À noter, dans la réponse du serveur les dates de création et d’expiration (<domain:crDate> et <domain:exDate>), cette dernière étant donnée à titre indicatif et pour être cohérent avec l’élément <domain:period> lorsque celui-ci est fourni par le client. Exemple de réponse envoyée par le serveur :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:crDate>2008-12-25T00:00:00.0Z</domain:crDate> S: <domain:exDate>2009-12-25T00:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000001</svTRID> S: </trID> S: </response> S:</epp>

Exemple de code retour 1001 envoyé par le serveur :

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>dom-epp-wytxubuz.fr</domain:name> S: <domain:crDate>2010-06-03T15:22:15.0Z</domain:crDate> S: <domain:exDate>2011-06-03T00:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>FRNIC-18673-CLIENT-1275578515</clTRID> S: <svTRID>DEV-photon-18294-4-1275578517.15639</svTRID> S: </trID> S: </response> S:</epp>

3.4.1.2.Dépôt "avec code d’autorisation" d’un nom de domaine

Une telle opération nécessite d’obtenir un code d’autorisation (cf. Guide des Procédures http://www.afnic.fr/fr/ressources/documents-de-reference/documents-techniques/guide-des-procedures-pour-les-bureaux-d-enregistrement.html ). Rappelons que celui-ci est associé au triplet (bureau d’enregistrement, nom de domaine, nic-handle du titulaire).

Page 23: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  23 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Une fois que le code est créé, le dépôt du nom de domaine se fait pratiquement comme ce que nous avons décrit lors du dépôt "direct" à 2 nuances près. La première c’est que l’identifiant du titulaire n’est pas libre mais doit correspondre à celui associé au code d’autorisation, la seconde c’est que le code d’autorisation doit être utilisé en lieu et place du auth_info dans l’élément <domain:authInfo>, ce dernier n’étant donc plus libre. Par contre, il est obligatoire de procéder à la modification de celui-ci via une commande <domain:update> avant de le transmettre au client final. Il est à noter que cela ne change rien au reste de la requête et que le traitement de celle-ci est soumis aux mêmes règles que le cas précédemment décrit. Ceci impliquant, entre autres, que nous nous trouvons dans le cas où un dépôt réussi génère une réponse avec un code retour 1000 (c’est pour cette raison que la réponse du serveur n’est pas reproduite). Exemple de requête envoyée par le client :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-reserve-0001.fr</domain:name> C: <domain:period unit="m">12</domain:period> C: <domain:registrant>MM4567</domain:registrant> C: <domain:contact type="admin">NFC1</domain:contact> C: <domain:contact type="tech">NFC1</domain:contact> C: <domain:contact type="tech">VIL1666</domain:contact> C: <domain:authInfo> C: <domain:pw>NDCR20080229T173000.123456789</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

3.4.1.3.Après la création…

Une fois le domaine créé, il est consultable en utilisant la commande <domain:info> et est visible dans le Whois (un délai de propagation supplémentaire est possible compte tenu de l’architecture de réplication des bases de données mise en place, mais dans des conditions optimales, la synchronisation des données se fait en quasi temps réel et au fil de l’eau). Le processus de qualification (cf Guide des procédures) porte sur le titulaire d'un nom de domaine, mais son déroulement peut impacter l'état du nom de domaine une fois ce dernier créé. En effet, si le titulaire est en phase de demande de pièces justificatives, le domaine passera dans des états de gel puis blocage qui vont modifier les statuts EPP.

Page 24: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  24 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Tableau récapitulatif des opérations acceptées en fonction de l’état de la procédure de qualification :

Etat de la procédure de qualification

Whois : reachstatus

Whois : eligstatus

Opérations refusées

Statut du domaine

start pending pending contact:update -

contact:update

domain:trade problem (gel) ok/- ok/-

domain:transfer

serverTransferProhibited + serverTradeProhibited

contact:update

domain:trade

domain:transfer

domain:restore

domain:delete

domain:update

problem (blocage) ok/- ok/-

domain:create

serverHold + serverUpdateProhibited + serverDeleteProhibited + serverTransferProhibited + serverTradeProhibited + serverRestoreProhibited +

finished ok/- ok/- aucune -

3.4.2. Update - modifier les attributs du domaine

Nous avons choisi de définir 3 types de modifications bien distinctes via la même commande EPP, à savoir la commande <domain:update>. Dans un cas la modification porte sur les contacts associés à un nom de domaine (technique et/ou administratifs), dans un autre, uniquement sur la configuration DNS et dans le dernier cas, uniquement sur l’état du nom de domaine et le auth_info qui lui est associé.

3.4.2.1.Update [admin] - Modification de la liste des contacts

La modification de la liste des contacts associés à un nom de domaine, qu’ils soient techniques et/ou administratifs va passer par une commande <domain:update>. Bien qu’EPP et le mapping domain prévoient la modification du titulaire du nom de domaine par le biais de cette commande, nous n’autorisons pas cette action. Un changement de titulaire passe par les commandes <domain:trade> et <domain:recover> que nous traiterons un peu plus loin dans ce document. Il est important de garder à l’esprit que les modifications sur les listes de contacts ne doivent pas transgresser les règles d’occurrences indiquées dans la section sur la création d’un nom de domaine. En effet, la commande <domain:update> permettant l’utilisation de deux sous-commandes <domain:add> et <domain:rem>, toute suppression d’un contact amenant la disparition de ce type de contact pour le domaine doit s’accompagner de

Page 25: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  25 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

l’ajout d’un autre contact de ce même type. Par exemple, la règle actuelle qui veut qu’il n’y ait qu’un contact administratif pour un nom de domaine se traduit lors de la modification de celui-ci par la suppression du contact actuel et l’ajout d’un nouveau, dans la même commande EPP (l’exemple que nous donnerons plus loin reprendra ce cas). Chaque élément <domain:add> et <domain:rem> peut contenir des éléments de type <domain:contact> (déjà présentés dans la section "créer un nom de domaine"). Si un même contact est présent en même temps dans <domain:add> et <domain:rem>, la commande est acceptée, les deux opérations s’annulent et les autres modifications indiquées dans la commande sont prises en compte normalement. Concrètement, une commande indiquant l’ajout des contacts techniques VIL1666 et MIS78 ainsi que la suppression du contact technique VIL1666 est équivalente à une commande indiquant uniquement l’ajout du contact technique MIS78. Si nous reprenons l’exemple du nom de domaine précédemment créé auquel nous souhaiterions ajouter un troisième contact technique et modifier le contact administratif, voici la requête XML qui est envoyée.

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:contact type="admin">VIL1666</domain:contact> C: <domain:contact type="tech">JAP777</domain:contact> C: </domain:add> C: <domain:rem> C: <domain:contact type="admin">NFC1</domain:contact> C: </domain:rem> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Page 26: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  26 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour est toujours 1000 sauf problème mineur ou majeur) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000002</svTRID> S: </trID> S: </response> S:</epp>

Exemple de réponse en cas de code retour 1001 :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <msgQ count="1" id="63480"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000002</svTRID> S: </trID> S: </response> S:</epp>

3.4.2.2. Update [tech] - Modification de la configuration des serveurs de noms

La commande est utilisée pour indiquer une configuration DNS initiale pour un nom de domaine qui n’en a pas encore ou pour modifier une configuration DNS existante. Par modification, il faut comprendre aussi la suppression pure et simple de la liste des serveurs de noms d’un nom de domaine, ceci afin d’être cohérent avec la possibilité de réserver un nom de domaine sans lien avec la publication DNS. Cette commande est aussi utilisée pour ajouter ou supprimer des délégations signées (enregistrements DS).

La commande est envoyée par le client (pour simplifier, nous considèrons que celle-ci est syntaxiquement correcte et que les glues nécessaires sont bien présentes), le format retenu pour les serveurs de noms étant celui où ces derniers sont des attributs de l’objet "domain" et non pas des références sur des objets "host" (RFC 5732). Lorsque la commande est traitée, le serveur renvoie un code retour 1001 indiquant que celle-ci est prise en compte. Dans le même temps, l’état "pendingUpdate" est appliqué au nom de domaine. Une fois que l’outil ZoneCheck a réalisé les tests nécessaires à la validation de la configuration technique (sauf si l’on se trouve dans le cas ou la commande <domain:update> est utilisée pour "vider" une configuration

Page 27: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  27 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

existante de ses serveurs de nom, auquel cas, exécuter ZoneCheck n’a aucun sens) l’état "pendingUpdate" est supprimé et deux cas peuvent se présenter :

La configuration est OK (ce qui est forcément le cas lorsque nous sommes en présence d’une liste de serveurs "vide") et dans ce cas elle est directement visible dans le Whois et peut être publiée au prochain rechargement du fichier de zone DNS (à moins que l’état "clientHold" ou "serverHold" ne soit positionné, empêchant ainsi la publication DNS).

La configuration est KO et elle est tout simplement ignorée. Rien n’est modifié dans le Whois ou dans la zone DNS.

La commande <poll> est utilisée pour connaître le résultat de l’opération de mise à jour. Une notification est émise quel que soit le résultat final du ZoneCheck.

ATTENTION : La configuration DNS ne distingue pas un serveur comme étant le primaire et les autres comme étant des secondaires. L’ordre des serveurs envoyés n’a donc aucune importance. Même si dans les faits ceux-ci seront généralement retournés suivant le même ordre (que ce soit via le Whois ou via la réponse à une commande <domain:info>), il ne faut pas chercher derrière cet ordre une quelconque règle de priorité. La commande <domain:update> ne peut contenir que les éléments <domain:add> et/ou <domain:rem>. Le premier contenant les informations nécessaires pour ajouter un ou plusieurs serveurs de noms à la configuration existante, le second permettant de supprimer un ou plusieurs serveurs de noms. La modification d’un serveur de noms pour mettre à jour les glues qui lui sont affectées passe par sa présence dans <domain:rem> (juste le nom du serveur) et dans <domain:add> (avec les nouvelles glues à appliquer). Pour rappel, nous n’avons pas implémenté le RFC 5732, à savoir les objets de type "host" permettant de référencer les serveurs de noms. Nous préférons utiliser la possibilité de décrire les serveurs de noms comme attributs des objets "domain". Chacun des éléments <domain:add> et <domain:rem> ne peut contenir que l’unique élément <domain:ns>, toute présence d’un autre élément amenant ainsi la confusion sur le type de modification demandée entraîne une erreur. De même, chaque élément <domain:ns> n’est composé que d’une collection d’éléments <domain:hostAttr>. Voici les sous-éléments qui sont présents dans l’élément <domain:hostAttr> et leur description succincte. L’absence d’éléments obligatoire et/ou la présence d’autres éléments renvoie une erreur.

Nom de l’élément Nombre d’occurences <domain:hostName> 1 <domain:hostAddr ip="v4"> 0-n <domain:hostAddr ip="v6"> 0-n

Page 28: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  28 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

<domain:hostName> contient le nom de domaine complet du

serveur de noms. <domain:hostAddr ip="v4"> contient une adresse IPv4 à associer

au serveur de noms lorsqu’une glue est nécessaire (uniquement pour <domain:add>, interdit pour <domain:rem>).

<domain:hostAddr ip="v6"> contient une adresse IPv6 à associer au serveur de noms lorsqu’une glue est nécessaire (uniquement pour <domain:add>, interdit pour <domain:rem>).

Si la présence d’une glue s’avère nécessaire, il n’est pas obligatoire de fournir des adresses ipv4 et des adresses ipv6. Une seule adresse, quel que soit son type, est suffisante (mais rien n’empêche d’en mettre plusieurs). La commande peut être associée à une extension <secDNS:update> si des opérations DNSSEC sont souhaitées et que l'extension secDNS a été choisie par le client lors de la connexion. Dans ce cas l'extension devra contenir un élément <secDNS:rem> et/ou un élément <secDNS:add>. L'élément <secDNS:rem> contient soit le seul élément <secDNS:all> (s'il est présent avec la valeur 1 il a pour effet de supprimer tous les enregistrements DS liés au domaine) soit un ou plusieurs éléments <secDNS:dsData>. L'élément <secDNS:add> contient un ou plusieurs éléments <secDNS:dsData>. Chaque élément <secDNS:dsData> possède les sous-éléments suivants :

Nom de l’élément Nombre d’occurences <secDNS:keyTag> 1 <secDNS:alg> 1 <secDNS:digestType> 1 <secDNS:digest> 1 Il est rappelé que conformément au RFC 5910 l'ordre à une importance, le contenu de l'élément <secDNS:rem> étant pris en compte avant le contenu de l'élément <secDNS:add>. L'attribut "urgent" dans l'élément <secDNS:update> n'est pas accepté, sa présence avec la valeur 1 générera une erreur 2102. L'élément <secDNS:chg> sous <secDNS:update> n'est pas accepté non plus car le seul sous-élément autorisé sous <secDNS:chg> est <secDNS:maxSigLife> qui n'est pas supporté. Toute présence de l'élément <secDNS:chg> générera donc une erreur 2102.

Page 29: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  29 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de requête envoyée par le client après une création pour fournir la configuration initiale d’un nom de domaine :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostAttr> C: <domain:hostName>ns1.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns2.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostname> C: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> C: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> C: </domain:hostAttr> C: </domain:ns> C: </domain:add> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de requête envoyée par le client après une création pour fournir la configuration initiale d’un nom de domaine sécurisé avec DNSSEC :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostAttr> C: <domain:hostName>ns1.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns2.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostname> C: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> C: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> C: </domain:hostAttr> C: </domain:ns> C: </domain:add> C: </domain:update> C: </update> C: <extension> C: <secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:add> C: <secDNS:dsData> C: <secDNS:keyTag>12346</secDNS:keyTag> C: <secDNS:alg>3</secDNS:alg> C: <secDNS:digestType>1</secDNS:digestType> C: <secDNS:digest>38EC35D5B3A34B44C39B38EC35D5B3A34B44C39B </secDNS:digest> C: </secDNS:dsData> C: </secDNS:add> C: </secDNS:update> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Page 30: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  30 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Sur les commandes de type <domain:update>, les réponses envoyées par le serveur sont assez succinctes, c'est-à-dire qu’il n’y a pas d’élément <resData>. Par contre, le code retour est toujours égal à 1001 pour ce type de modification. Exemple de réponse envoyée par le serveur :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </trID> S: </response> S:</epp>

3.4.2.3. Update [context] - Modification de l’état du domaine et/ou du auth_info

Cette opération est complètement indépendante de la configuration DNS du nom de domaine concerné. Elle permet au bureau d’enregistrement de positionner ou retirer le flag "clientHold". S’il est positionné, un nom de domaine, même s’il est associé à une configuration DNS validée par notre outil ZoneCheck, ne sera pas annoncé dans le DNS. Quelles que soient les modifications faites sur ce flag, cela ne déclenche aucune relance des tests de vérification ZoneCheck. Les deux processus sont réellement indépendants. ATTENTION : Certaines opérations (il convient de consulter le guide des procédures pour plus de détails sur ce sujet) peuvent avoir comme conséquence de supprimer ce flag dès lors qu’elles aboutissent. Ce sont à nouveau les éléments <domain:add> et <domain:rem> qui sont utilisés pour ajouter/supprimer un flag. Ces éléments ne peuvent contenir qu’un seul élément.

Nom de l’élément Nombre d’occurences

<domain:status s="clientHold"> 1

<domain:status s="clientHold"> est envoyé tel quel.

Le RFC 5731 permet l’envoi d’un message clair associé à l’élément <domain:status> ainsi que l’utilisation d’un attribut (lang) indiquant la langue de ce message. Ce message n’étant pas traité chez nous, l’élément doit être vide. Concernant la modification du auth_info associé au nom de domaine, l’utilisation de l’élément <domain:chg> est nécessaire et bien que celui-ci

Page 31: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  31 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

puisse avoir comme éléments fils <domain:registrant> et <domain:authInfo>, seul ce dernier est accepté. La présence de l’élément <domain:registrant> entraîne un retour d’erreur de la part du serveur EPP. L’utilisation de <domain:authInfo> est tout à fait similaire à celle indiquée pour une opération de création. Exemple de requête pour interdire la publication DNS du nom de domaine précédemment créé et pour modifier son auth_info (d’autant que dans le cas présent, puisqu’il s’agissait d’une création "avec code d’autorisation", le auth_info initial a été imposé par l’AFNIC) :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-reserve-0001.fr</domain:name> C: <domain:add> C: <domain:status s="clientHold"/> C: </domain:add> C: <domain:chg> C: <domain:authInfo> C: <domain:pw>PlusFortKeWarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:chg> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour est toujours 1000 sauf en cas de serveur dégradé, on note aussi qu’un message est en attente sur le serveur, certainement le résultat de la commande de modification des serveurs de noms pour le nom de domaine ndd-de-test-0001.fr) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <msgQ count="1" id="50001"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000004</svTRID> S: </trID> S: </response> S:</epp>

Exemple de réponse en cas de code retour 1001 (serveur dégradé) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>FRNIC-27505-CLIENT-1275645007</clTRID> S: <svTRID>DEV-photon-27393-9-1275645009.72202</svTRID> S: </trID> S: </response> S:</epp>

Page 32: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  32 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.2.4.Suivre le déroulement d’une modification technique

Grâce au mécanisme de notification prévu dans EPP, nous avons la possibilité de connaître le résultat d’une demande de modification technique en utilisant la commande <poll>. Une notification est placée dans la file d’attente, que le résultat soit positif ou négatif. Ne pas en tenir compte immédiatement n’a aucun effet sur le processus de publication DNS, elle n’est là qu’à titre d’information. Une requête doit être émise pour dépiler la file de polling (cf § 3.6 Notifications)

Dans la réponse envoyée, indépendamment du résultat de la commande qui est connu grâce à l’attribut "paResult", nous fournissons le résultat du ZoneCheck dans l’élément <msg>. Une balise XML a été ajoutée à cet effet, <resZC> avec un attribut "type" qui pour le moment ne peut prendre qu’une unique valeur, à savoir "plain-text".

Exemple de réponse envoyée par le serveur pour une mise à jour technique acceptée :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50001"> S: <qDate>2008-12-25T00:01:00.0Z</qDate> S: <msg> S: <resZC type="plain-text"> S: ZONE : ndd-de-test-0001.fr. S: NS : ns1.nic.fr. S: NS : ns2.nic.fr. S: NS : ns.ndd-de-test-0001.fr. [192.93.0.1, 2001:660:3005:1::1:1] S: S: ==> SUCCESS S: </resZC> S: </msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-25T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>une-autre-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

Page 33: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  33 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de la même réponse envoyée par le serveur mais dans le cas où la mise à jour technique n’a pas pu être acceptée suite à une erreur de ZoneCheck :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50001"> S: <qDate>2008-12-25T00:01:00.0Z</qDate> S: <msg> S: <resZC type="plain-text"> S: ZONE : ndd-de-test-0001.fr. S: NS : ns1.nic.fr. S: NS : ns2.nic.fr. S: NS : ns.ndd-de-test-0001.fr. [192.93.0.1, 2001:660:3005:1::1:1] S: f> Server doesn't listen/answer on port 53 for UDP protocol S: => ns.ndd-de-test-0001.fr./192.93.0.1 S: S: ==> FAILURE S: </resZC> S: </msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="0">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-25T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>une-autre-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

Il est nécessaire de supprimer le message de la file d’attente, la consultation de celui-ci ne suffit pas à le dépiler… Un exemple de cette commande standard est disponible dans la rubrique notifications (cf. § 3.6 Notifications).

La notification, positive ou négative, pour un changement de configuration technique clos cette opération. Si pour une raison ou une autre la configuration n’a pu être validée par notre outil de vérification ZoneCheck (cas où paResult="0") et que le bureau d’enregistrement, après avoir appliqué les corrections nécessaires, souhaite que celle-ci soit prise en compte, une nouvelle demande, avec la configuration complète souhaitée, doit à nouveau être envoyée. Le système ne garde pas en mémoire les

Page 34: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  34 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

demandes qui n’ont pas réussies et ne tente pas de lancer des ZoneCheck jusqu’à ce que cela fonctionne…

3.4.3. Delete - Supprimer un domaine

La suppression d’un nom de domaine s’accompagne d’un mécanisme de restauration (restore). Ce mécanisme, bien que basé sur le RFC 3915, en limite le champ d’application en restreignant celui-ci au seul cas de l’opération de suppression. Les règles qui accompagnent cette procédure, en particulier les délais qui lui sont associés, ne font pas l’objet du présent document (cf. Guide des Procédures). La commande de suppression n’est pas modifiée par rapport à ce qui est décrit dans le RFC 5731, par contre, en cas de succès (il existe certains cas où la suppression d’un nom de domaine n’est pas possible, comme par exemple, le cas où des serveurs de nom appartenant à ce domaine sont utilisés pour d’autres noms de domaine), le code retour n’est pas 1000, mais toujours 1001. L’état "pendingDelete" étant positionné pendant toute la durée de la "période de grâce" accordée et tant que le domaine n’est pas restauré ou définitivement supprimé. Un message de notification est ajouté à la file de message à l’issue de l’opération de suppression avec paResult="0" dans le cas d’une restauration réussie, paResult="1" dans le cas d’une suppression effective du nom de domaine. Exemple de la requête de suppression de notre domaine de test :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <delete> C: <domain:delete C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: </domain:delete> C: </delete> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour est toujours 1001) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

Page 35: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  35 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.4. Restore - Restaurer un domaine

La commande de restauration passe par une extension de la commande <domain:update>. Il ne faut surtout pas confondre ce type d’opération avec les autres possibilités décrites dans le § 3.5.2 sur l’utilisation de cette commande pour modifier les contacts, la configuration DNS ou bien encore l’état d’un domaine. En effet une opération de restauration ne peut pas s’accompagner d’une quelconque autre modification sur le nom de domaine concerné. Ce problème est contourné dans le RFC en obligeant qu’un des éléments de la commande <domain:update> soit présent mais vide… Mais, ce n’est pas conforme avec le fichier XSD associé, qui lui est nominatif. Nous avons donc fait le choix de suivre ce dernier et donc, contrairement à ce qu’indique le RFC 3915, une commande <domain:update> ne contenant que l’élément <domain:name>, associée à l’extension de la commande <domain:update> est la commande correcte à utiliser. L’extension de la commande <domain:update> décrite par le RFC 3915 ne passe que par l’ajout d’un élément <rgp:restore>. Par contre celui-ci possède un attribut "op" qui peut prendre 2 valeurs. Nous n’en acceptons qu’une seule, telle qu’indiqué dans le tableau ci-après.

Nom de l’élément Nombre d’occurences <rgp:restore op="request"> 1

Exemple de la requête de restauration de notre domaine de test : C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: </domain:update> C: </update> C: <extension> C: <rgp:update C: xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> C: <rgp:restore op="request"/> C: </rgp:update> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Page 36: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  36 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour est toujours 1000 sauf en cas de serveur dégradé et comme précisé dans le RFC, en cas de succès, l’attribut "s" de l’élément <rgp:rgpStatus> de l’extension doit avoir pour valeur "pendingRestore") :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <rgp:update S: xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> S: <rgp:rgpStatus s="pendingRestore"/> S: </rgp:update> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000006</svTRID> S: </trID> S: </response> S:</epp>

Exemple de réponse en cas de code retour 1001 (serveur dégradé)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>FRNIC-27180-CLIENT-1275642432</clTRID> S: <svTRID>DEV-photon-26251-3-1275642432.11977</svTRID> S: </trID> S: </response> S:</epp>

3.4.5. Transfer – Changement de bureau d’enregistrement

La commande <transfer> proposée par EPP permet un changement de bureau d’enregistrement uniquement. Quelques modifications ont été apportées à cette commande afin de la rendre plus complète. En ce qui concerne les restrictions d’accès pour l’utilisation de cette commande, le RFC 5730 fait des recommandations, mais celles-ci ne sont pas des obligations. Pour éviter toute ambiguïté, le choix de l’AFNIC est de n‘autoriser le changement de bureau d’enregistrement d’un nom de domaine qu’aux bureaux d’enregistrement qui ne gèrent pas celui-ci. L’acceptation et le rejet d’un changement de bureau d’enregistrement ne peuvent être faits que par le bureau sortant.

Page 37: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  37 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.5.1.Demander un transfer (changement de bureau d’enregistrement)

Première petite modification par rapport au standard, l’élément <domain:pw> (lui-même sous-élément de <domain:authInfo>) ne peut pas être utilisé avec l’attribut "roid" pour indiquer que le auth_info fourni est lié au titulaire ou à un contact associé au nom de domaine plutôt qu’au nom de domaine lui-même. Dans notre cas, le auth_info ne peut être lié qu’au nom de domaine. Lors du transfer, le titulaire est cloné chez le bureau d’enregistrement entrant (à moins qu’un objet "contact" avec exactement les mêmes informations n’existe déjà chez ce bureau d’enregistrement). Attention, ce clonage intervient après que le transfer a été approuvé par le bureau d’enregistrement sortant. Bien que cela soit prévu dans le RFC, la modification de la période de validité d’un nom de domaine ne peut pas être faite et tout comme pour la création les même restrictions s’imposent sur l’élément <domain:period> toujours considéré comme un élément optionnel (dans un souci d’homogénéité, nous gardons exactement la même logique que pour l’opération de création). Par contre dans la réponse, comme le changement n’est validé qu’au terme de la procédure et donc que c’est à ce moment que la nouvelle date anniversaire est positionnée, l’élément <domain:exDate> est absent de la réponse du serveur. Dernière modification, une extension est nécessaire pour permettre d’associer au nom de domaine transféré des contacts technique et administratif liés au bureau d’enregistrement qui demande le transfer ainsi que pour spécifier si l'éventuelle configuration DNSSEC présente (enregistrements DS) doit être conservée en cas de réussite du transfer. Voici les éléments spécifiques que nous retrouvons dans la requête XML envoyée par le client.

Nom de l’élément Nombre d’occurrences

<domain:pw> 1 <frnic:domain keepDS="0"> 1 <frnic:contact type="admin"> 1 <frnic:contact type="tech"> 1-3

L'élément keepDS est un booléen XML et doit être une valeur parmi : 0, 1, true, false. Sa présence est obligatoire.

Page 38: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  38 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de la requête de transfer envoyée par un bureau d’enregistrement sur notre nom de domaine ndd-de-test-0001.fr avec conservation des enregistrements DS :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="request"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:transfer> C: <frnic:domain keepDS="1"> C: <frnic:contact type="admin">PR1249</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:transfer> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

La réponse à cette demande de transfer (si elle est syntaxiquement et sémantiquement acceptable) contient un certain nombre d’informations décrites dans le RFC 5731. Nous n’utilisons pas d’extension pour la réponse. Voici la liste des éléments qui sont présents dans la réponse.

Nom de l’élément Nombre d’occurences

<domain:name> 1 <domain:trStatus> 1 <domain:reID> 1 <domain:reDate> 1 <domain:acID> 1 <domain:acDate > 1

<domain:name> contient le nom de domaine complet (exemple-

ndd-epp.fr). <domain:trStatus> indique l’état de la requête. Ne peut contenir

que la valeur "pending". <domain:reID> contient l’ID du bureau d’enregistrement entrant. <domain:reDate> indique la date et l’heure de prise en compte de la

demande.

Page 39: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  39 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

<domain:acID> contient l’ID du bureau d’enregistrement dont la dernière action a provoqué le changement d’état de l’automate de transfert tel qu’il est indiqué dans <domain:trStatus>. En revanche, lorsque l’état indiqué est "pending", l’ID indiqué sera celui du bureau sortant.

<domain:acDate> indique, dans le cas où l’état du transfer est "pending", la date et l’heure limite de réponse attendue pour le gestionnaire sortant ("approve" ou "reject") avant que la procédure n’entre dans un processus automatique de traitement de la demande. Dans les autres états ("clientApproved", "clientRejected", …), indique la date de l’action qui a mené à cet état.

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour est toujours 1001) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </trID> S: </response> S:</epp>

Bien entendu, si le nom de domaine se trouve dans l’état "serverTransferProhibited" (c’est le cas lors de la phase dite d’identification pour le titulaire du nom de domaine), il n’est pas possible de demander un transfer. Un code erreur 2106 est alors été retourné.

La suite des opérations, à savoir l’acceptation ou le refus de la demande de changement de bureau d'enregistrement par le bureau d’enregistrement sortant, se fait en utilisant l’attribut "op" de la commande <transfer>. Tant que le transfer n’est pas terminé (quelle que soit l’issue de cette opération), le domaine apparaît dans l’état "pendingTransfer".

Page 40: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  40 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.5.2.Suite des opérations pour le bureau sortant

Un message est mis en attente et le bureau peut avoir connaissance de cet ajout lors d’une prochaine commande puisque le compteur de messages incrémenté est présent dans toute réponse du serveur à n’importe quelle requête du client. Le message ressemble à la réponse qu’a reçue le bureau qui a fait la demande de transfer. Exemple de requête pour récupérer le message en attente :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="req"/> C: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> C: </command> C:</epp>

Exemple de réponse envoyée par le serveur indiquant qu’un transfer a été demandé pour le nom de domaine ndd-de-test-0001.fr :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50002"> S: <qDate>2008-12-25T00:02:00.0Z</qDate> S: <msg>Transfer requested.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000008</svTRID> S: </trID> S: </response> S:</epp>

Le bureau sortant a 3 options, soit approuver l’opération, soit la rejeter, soit ne rien faire… Rappelons que s’il ne fait rien, dans un délai égal à <domain:acDate> moins <domain:reDate>, soit 8 jours dans le cas présent, la demande est considérée comme acceptée.

Page 41: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  41 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Pour accepter la demande de transfer de manière explicite, le bureau sortant doit envoyer la requête suivante au serveur (l‘élément <domain:period> est complètement ignoré, conformément au RFC 5731 ; de plus contrairement à la demande de transfer il n’y a pas d’extension à utiliser) :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="approve"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Comme la possibilité d’accepter ou rejeter la demande de transfer est réservée au bureau sortant, on pourrait se passer de demander le auth_info associé au domaine, mais dans un souci de cohérence celui-ci est obligatoire, quelle que soit la valeur de l’attribut "op". Exemple de réponse envoyée par le serveur indiquant que l’acceptation du transfer a bien été prise en compte (on note le code retour 1000 dans ce cas, que l’état du transfer est maintenant "clientApproved" et que la date indiquée dans <domain:acDate> permet de connaître à quel moment le bureau sortant a accepté le transfer) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000009</svTRID> S: </trID> S: </response> S:</epp>

Dans le cas où le bureau sortant souhaite refuser l’opération de transfer, il doit envoyer une requête similaire à la précédente en modifiant uniquement

Page 42: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  42 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

la valeur de l’attribut "op", celui-ci passant de "approve" à "reject". La réponse du serveur elle aussi est très semblable à ce qui a été présenté dans le cas de l’acceptation. La différence se situe au niveau de l’état du transfer qui n’est plus à "clientApprove", mais à "clientRejected". Exemple dans le cas d’un refus de transfer par le bureau sortant :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="reject"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C :</epp>

Exemple de réponse du serveur dans le cas d’un refus :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientRejected</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2009-10-07T08:13:02.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-10-07T08:13:16.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-000000009-bis</svTRID> S: </trID> S: </response> S:</epp>

Page 43: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  43 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.5.3.Suite des opérations pour le bureau entrant

Il est possible, tant que le bureau sortant n’a pas répondu (par un "approve" ou un "reject"), d’annuler la demande en cours. Cette possibilité passe par l’envoi d’une commande <transfer> avec l’attribut "op" positionné à "cancel". Une notification indiquant l’annulation de la commande est envoyée au bureau sortant (qui du coup, reste gestionnaire du nom de domaine). Si le bureau entrant ne souhaite pas annuler l’opération en cours, deux cas peuvent se présenter, soit le transfer est accepté, soit il est refusé (sic). Dans tous les cas le bureau entrant est notifié dans sa file de messages du choix du bureau sortant. En fait, un transfer accepté génère 2 entrées dans cette file d’attente (voire 3, mais nous reviendrons sur ce dernier message un peu plus loin), la première informant le bureau entrant que l’opération a été acceptée par le bureau sortant, la seconde indiquant le bon déroulement de la commande qu’il a passé. Concrètement, voici la séquence de messages qu’il faut récupérer avec la commande <poll>. Le premier message reprend le contenu de l’élément <domain:trnData> envoyé en réponse à la commande <transfer op="approve"> et que le bureau sortant a reçu. On note la valeur de <domain:acDate> par rapport à <qDate>, la seconde ne pouvant pas être postérieure à la première.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer approved.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp>

Page 44: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  44 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Le second message dans la file de d’attente est le résultat de la commande initiale à laquelle le serveur avait répondu par un code retour 1001.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2008-12-26T00:01:00.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-26T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp>

En cas de refus du bureau sortant, ce second message n’est pas présent puisque la commande n’est pas terminée. Voici le message qui est dans la file d’attente à la place de celui indiquant que le changement de bureau d’enregistrement a été accepté. On note la valeur de <domain:acDate> qui reflète l’extension du délai accordé au bureau sortant… Au cours de cette période, ce dernier peut à tout moment approuver le transfer (générant la séquence de message précédemment indiquée), le domaine étant dans l’état "pendingTransfer".

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer rejected.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientRejected</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-16T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp>

Page 45: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  45 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Nous avons évoqué précédemment la possible présence d’un autre message dans la file d’attente. En effet, nous avons indiqué que lors d’un transfer, le contact titulaire du nom de domaine est cloné si nécessaire. Dans ce cas, il est important que le bureau d’enregistrement entrant soit averti de cette création, d’autant qu’elle n’est pas demandée de manière explicite. Un message de notification est donc ajouté à sa file d’attente (semblable à celui résultant d’une création d’objet contact), celui-ci est envoyé juste après que l’opération de transfer se soit terminée avec succès. Ainsi, il est possible de différencier les cas où le titulaire est cloné (un message est envoyé) de ceux ou le titulaire est réutilisé (aucun message n’est envoyé). L’envoi de ce message doit inciter le bureau entrant à interroger le serveur pour obtenir toutes les informations sur ce nouveau contact.

3.4.5.4.Utilisation de la commande <domain:transfer> en consultation

Il est normalement prévu que cette commande puisse fournir des informations sur le transfer en cours ou sur le dernier transfer effectué sur un nom de domaine. Nous ne proposons pas cette utilisation. La bonne gestion des messages de notification doit permettre aux deux bureaux d’enregistrement impliqués de faire un suivi complet du bon déroulement de l’opération.

Page 46: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  46 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.6. Trade - Transmettre un domaine

La commande <trade> n’existe pas dans le standard EPP. À l’AFNIC, nous avons deux procédures de transmission spécifiques s’appliquant dans des cas différents, l’opération décrite ici ne correspondant qu’à ce que nous appelons trade (transmission volontaire).

3.4.6.1.Demander un trade (transmission volontaire)

Contrairement à l’opération <transfer>, la transmission n’implique pas forcément un changement de bureau d’enregistrement. En revanche, le titulaire doit changer. En ce qui concerne les autres types de contacts, si le domaine reste chez le même bureau d’enregistrement, il n’y a, a priori, aucune raison à ce que ceux-ci soient modifiés ; en revanche si la transmission s’accompagne d’un changement de bureau d’enregistrement, les contacts administratifs et techniques ont toutes les chances d’être modifiés. Dans un souci de cohérence avec, entre autres, l’opération <transfer>, nous avons décidé de rendre obligatoire la présence de tous les types de contacts, que ceux-ci soient modifiés ou non … Tout comme la commande <transfer>, la commande <trade> a un attribut "op" permettant de différentier son utilisation en mode "transform" de son utilisation en mode "query". Par contre, contrairement à la commande <transfer>, seules 3 valeurs sont possibles pour cet attribut, "request" pour demander une transmission sur un nom de domaine, "cancel" pour annuler une demande avant que les titulaires ne se soient manifestés et "query" pour consulter l’état d’avancement de cette transmission. Le trade (transmission volontaire) ne peut se faire que lorsque le titulaire sortant a été correctement identifié. Si ce n’est pas le cas, un code d’erreur est retourné lors de la demande. L’état "serverTradeProhibited" est positionné pour ce nom de domaine, cette information étant consultable en utilisant la commande <domain:info>. Comme cet état n’existe pas en standard en EPP, il se trouve dans une extension. En ce qui concerne le titulaire entrant, celui-ci peut être en cours d’identification, pas encore identifié, mais en aucun cas en état problème. Les éléments qui doivent être présents dans l’extension (dans l’élément <frnic:domain> de l’élément <frnic:trade>) sont indiqués dans le tableau ci-après.

Nom de l’élément Nombre d’occurences

<frnic:domain keepDS="0"> 1 <frnic:name> 1 <frnic:registrant> 1 <frnic:contact type="admin"> 1 <frnic:contact type="tech"> 1-3

Page 47: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  47 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

L'élément keepDS est un booléen XML et doit être une valeur parmi : 0, 1, true, false. Sa présence est obligatoire. On note que la mise en place d’une nouvelle commande via les mécanismes d’extension d’EPP empêche l’utilisation de l’élément <clTRID> (c’est un fils de l’élément <command>). Celui-ci étant important pour assurer un suivi des commandes et une synchronisation de celles-ci (il est particulièrement utile pour les commandes qui renvoient un code retour 1001), nous l’avons intégré à l’extension proposée. Bien qu’il ne soit pas au même endroit, son utilisation dans la réponse du serveur et dans les messages de notification reste la même. Par exemple, lors de la réponse du serveur à la demande de transmission que nous allons envoyer ci-après, l’élément <clTRID> est dupliqué dans l’élément <trID> et non pas dans la partie extension de la réponse.

Exemple de la requête de trade pour notre nom de domaine ndd-de-test-0001.fr (dans notre exemple, la transmission est faite à bureau d’enregistrement constant en conservant les mêmes contacts administratifs et techniques ainsi que la configuration DNSSEC) :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:command> C: <frnic:trade op="request"> C: <frnic:domain keepDS="1"> C: <frnic:name>ndd-de-test-0001.fr</frnic:name> C: <frnic:registrant>PR1249</frnic:registrant> C: <frnic:contact type="admin">VIL1666</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:trade> C: <frnic:clTRID>une-reference-client-par-exemple</frnic:clTRID> C: </frnic:command> C: </frnic:ext> C: </extension> C:</epp>

En ce qui concerne la réponse, nous nous proposons de fournir une réponse assez proche de ce qui est retourné lors d’un transfer à laquelle nous ajoutons dans une extension l’information concernant le titulaire sortant et le titulaire entrant. Même si nous avons conservé un format proche de la réponse faite dans le cas d’un transfer (mais c’est dans la partie <extension> de la réponse, plus dans <resData>), certains éléments changent un peu de sens. En effet, pour un transfer, ce sont les bureaux d’enregistrement qui réalisent les opérations nécessaires aux changements d’état du nom de domaine traité, alors que dans le cas d’un trade, ce sont les 2 titulaires concernés qui, par le biais d’un processus "off-line", vont valider ou refuser l’opération. Les éléments

Page 48: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  48 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

utilisés pour horodater des opérations ou indiquer des dates d’expiration (<domain:reDate>, <domain:acDate> et <domain:exDate>) sont complétés. En effet, nous avons besoin d’indiquer la date et l’heure de réception de la requête, le délai accordé aux 2 titulaires pour accepter ou refuser cette opération et l’heure et la date à laquelle ils ont répondu à la demande.

Le tableau suivant reprend les éléments qui sont présents dans l’extension (<frnic:trdData>) de la réponse du serveur :

Nom de l’élément Nombre d’occurences

<frnic:name> 1 <frnic:trStatus> 1 <frnic:reID> 1 <frnic:reDate> 1 <frnic:reHldID> 1 <frnic:rhDate> 1 <frnic:acID> 1 <frnic:acHldID> 0-1 <frnic:ahDate> 1

<frnic:name> nom du domaine qui est l’objet de la demande de

transmission. <frnic:trStatus> indique l’état de la transmission. Bien qu’à la

demande, la seule valeur possible soit "pending", 6 valeurs sont possibles qui seront détaillées par la suite ("pending", "newHolderApproved", "oldHolderApproved", "holdersApproved", "newHolderRejected", "oldHolderRejected").

<frnic:reID> contient l’ID du bureau d’enregistrement qui fait la demande.

<frnic:reDate> indique la date et l’heure auxquelles la commande a été prise en compte.

<frnic:reHldID> contient l’identifiant du titulaire qui demande la transmission volontaire.

<frnic:rhDate> tant que le titulaire entrant n’a effectué aucune action, indique la date et l’heure limites pour que celui-ci accepte ou refuse la transmission (<frnic:trStatus> vaut alors soit "pending", "oldHolderApproved" ou "oldHolderRejected"). Si le titulaire entrant a effectué une action (acceptation ou refus), c’est la date de cette action qui est indiquée. Dans le cas ou le titulaire entrant n’effectue aucune action et que le délai indiqué arrive à échéance, la transmission est abandonnée.

<frnic:acID> contient l’ID du bureau d’enregistrement sortant (dans la plupart des cas, la transmission se faisant à bureau constant, cette valeur sera égal à <frnic:reID>).

<frnic:acHldID> contient l’identifiant du titulaire actuel du nom de domaine. Cette information ne sera fournie que si la transmission se fait à bureau d‘enregistrement constant (ce sera le cas dans notre exemple).

Page 49: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  49 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

<frnic:ahDate> tant que le titulaire sortant n’a effectué aucune action, indique la date et l’heure limites pour que celui-ci accepte ou refuse la transmission (<frnic:trStatus> vaut alors soit "pending", "newHolderApproved" ou "newHolderRejected"). Si le titulaire sortant a effectué une action (acceptation ou refus), c’est la date de cette action qui est indiquée. Dans le cas ou le titulaire sortant n’effectue aucune action et que le délai indiqué arrive à échéance, la transmission est abandonnée. Lorsque <frnic:trStatus> est égal à "pending", <frnic:ahDate> et <frnic:reDate> auront la même valeur.

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour sera toujours 1001). Dans le cas présent, les valeurs de "BEsortantID" et "BEentrantID" sont considérées comme identiques, ce qui explique la présence conjointe des éléments <frnic:reHldID> et <frnic:acHldID> :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEentrantID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:reHldID>PR1249</frnic:reHldID> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEsortantID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-16T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </trID> S: </response> S:</epp>

3.4.6.2.Suivre un trade (transmission volontaire)

Si le trade donne lieu à un transfer, le bureau sortant et le bureau entrant recevront pratiquement les mêmes messages de service permettant de suivre l’évolution de l’opération en cours. Par contre seul le bureau par qui est passée la demande reçoit le message de conclusion indiquant le résultat de la commande <trade> et seul le bureau gestionnaire recevra le premier

Page 50: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  50 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

message de service plus ou moins équivalent au retour de la commande (mis à part le fait que <frnic:reHldID> est absent contrairement à <frnic:acHldID>). Le titulaire sortant et le titulaire entrant ont 15 jours pour valider la transmission du nom de domaine. Pour illustrer nos propos nous allons imaginer un scénario classique où le titulaire sortant valide la transmission, suivi du titulaire entrant, et ceci dans le délai imparti. Dans un premier temps, le bureau d’enregistrement sortant reçoit ce premier message de notification (on est dans le cas ou le trade s’accompagne d’un transfer, ce qui explique l’absence de l’élément <frnic:reHldID>) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50010"> S: <qDate>2009-12-25T00:02:00.0Z</qDate> S: <msg>Trade requested.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-16T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp>

Le titulaire sortant accepte le trade, ce qui aura pour effet de générer 2 messages de notification, un à chaque bureau d’enregistrement. Ceux-ci seront presque identique, la seule différence se situant au niveau de l’élément <frnic:reHldID> qui n’est présent que dans le message envoyé au bureau par qui le titulaire entrant est passé pour faire la demande de transmission et de l’élément <frnic:acHldID> qui n’est présent que dans le message envoyé au bureau d’enregistrement sortant. On note la valeur de

Page 51: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  51 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

l’élément <frnic:trStatus> qui passe de "pending" à "oldHolderApproved" (dans le cas où le titulaire entrant aurait été le premier à valider la transmission, <frnicStatus> aurait eu pour valeur "newHolderApproved"). On note aussi les valeurs de <qDate> et <frnic:ahDate>. Voici le message que reçoit le bureau sortant :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50011"> S: <qDate>2009-01-02T00:00:01.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>oldHolderApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000013</svTRID> S: </trID> S: </response> S:</epp>

Le titulaire entrant fait de même et 2 messages sont à nouveau générés avec les mêmes limitations que celles indiquées précédemment sur les éléments <frnic:reHldID> et <frnic:acHldID>. Cette fois-ci <frnic:trStatus> a pour valeur "holdersApproved".

Page 52: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  52 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50012"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>holdersApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-03T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000014</svTRID> S: </trID> S: </response> S:</epp>

Pour terminer cette opération, un message est envoyé au bureau d’enregistrement par qui la demande de transmission a été passée, et uniquement à lui. Dans notre cas, la valeur de "paResult" vaut 1 car tout c’est déroulé normalement.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000015</svTRID> S: </trID> S: </response> S:</epp>

Page 53: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  53 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.6.3.Utilisation de la commande <trade> en consultation

Tout comme pour la commande <transfer>, la commande <trade> en consultation ne donne aucune information sur le dernier trade réalisée sur un nom de domaine. Seules des informations sur les transmissions en cours, sont disponibles pour les bureaux impliqués dans cette opération.

3.4.7. Recover - Transmission forcée d’un nom de domaine

L’autre méthode de transmission, recover (transmission "forcée"), où le titulaire sortant n’existe plus, nécessite un code d’autorisation. Nous nous retrouvons donc dans une situation qui est un panaché de la création "avec code d’autorisation" et du trade (transmission volontaire).

3.4.7.1.Demander un recover (transmission forcée)

Tout comme pour le cas de la création "avec code d’autorisation", nous ne détaillerons pas dans le présent document le processus de récupération du code d’autorisation nécessaire à la demande d’un recover. Mais son obtention est un préalable à toute tentative d’utilisation de cette commande sur un nom de domaine. La logique de la commande <recover> est proche de celle des commandes <transfer> et <trade>. Par exemple, bien que cela ne soit pas utile dans cette version d’interface, nous avons choisi de conserver l’attribut "op" de la commande. Celui-ci ne peut prendre qu’une unique valeur, "request", puisque contrairement aux autres commandes dont elle s’inspire, la commande <recover> renvoie un code 1000 au lieu d’un code 1001. Mis à part le nom de la commande, ce qui différencie la requête envoyée pour <recover> de celle envoyée pour <trade> est la présence de l’élément <frnic:authInfo> qui sert à indiquer le code d’autorisation. Rappelons que le code d’autorisation est associé au triplet (bureau d’enregistrement, nom de domaine, nic-handle du titulaire). Le recover ne peut pas être demandé avec un titulaire entrant qui est en état problème. Il n’existe par contre aucune limitation sur l’état d’identification du titulaire sortant qui peut empêcher l’exécution de la commande <recover>.

Page 54: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  54 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Voici un exemple de requête envoyée par un bureau d’enregistrement qui a obtenu le code d’autorisation nécessaire au recover de notre nom de domaine d’exemple et qui ne souhaite pas conserver la configuration DNSSEC :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2" C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <frnic:command> C: <frnic:recover op="request"> C: <frnic:domain keepDS="0"> C: <frnic:name>ndd-de-test-0001.fr</frnic:name> C: <frnic:authInfo> C: <domain:pw> C: NDCR20080229T173000.123456789 C: </domain:pw> C: </frnic:authInfo> C: <frnic:registrant>PR1249</frnic:registrant> C: <frnic:contact type="admin">VIL1666</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:recover> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </frnic:command> C: </frnic:ext> C: </extension> C:</epp>

La réponse du serveur est elle aussi très proche de ce qui est proposé pour la commande <trade>, à quelques nuances près. En effet, dans ce cas, ni les titulaires, ni les bureaux d’enregistrement n’ont à intervenir pour assurer le bon déroulement de la commande. Le code retour de la commande est 1000, il n’est donc pas nécessaire de fournir d’information sur l’état du recover ou d’indiquer des dates limites d’action pour que les titulaires ou les bureaux d’enregistrements agissent sur le déroulement de la commande. Les limitations sur la présence ou non des identifiants des titulaires sortant et entrant sont les même que pour la commande <trade>. Si le bureau entrant est différent du bureau d’enregistrement sortant, un message de notification est ajouté à la file de messages de ce dernier. Le tableau suivant reprend les éléments qui sont présents dans l’extension (<frnic:recData>) de la réponse du serveur (et dans le message de notification envoyé si nécessaire) :

Nom de l’élément Nombre d’occurrences

<frnic:name> 1 <frnic:reID> 1 <frnic:reDate> 1 <frnic:reHldID> 0-1 <frnic:acID> 1 <frnic:acHldID> 0-1

Page 55: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  55 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

<frnic:name> nom du domaine qui est l’objet de la demande de transmission.

<frnic:reID> contient l’ID du bureau d’enregistrement qui fait la demande.

<frnic:reDate> indique la date et l’heure auxquelles la commande a été prise en compte.

<frnic:reHldID> contient l’identifiant du titulaire qui demande le recover. N’est pas présent dans le message de notification dans le cas d’un revover impliquant un transfer.

<frnic:acID> contient l’ID du bureau d’enregistrement gestionnaire actuel (dans la plupart des cas, il est égal à <frnic:reID>).

<frnic:acHldID> contient l’identifiant du titulaire actuel du nom de domaine. Cette information n’est fournie que si le recover se fait à bureau d‘enregistrement constant.

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour est toujours 1000). Dans le cas présent, les valeurs de "BEentrantID" et "BEsortantID" sont considérées comme identiques, ce qui explique la présence conjointe des éléments <frnic:reHldID> et <frnic:acHldID> :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:recData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:reID>BEentrantID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:reHldID>PR1249</frnic:reHldID> S: <frnic:acID>BEsortantID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: </frnic:domain> S: </frnic:recData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000016</svTRID> S: </trID> S: </response> S:</epp>

Page 56: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  56 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.8. Vérifier la disponibilité d'un domaine

La commande <domain:check> permet de vérifier la disponibilité d’un ou plusieurs noms de domaine, dans une limite de 7 noms par commande. Toute requête comportant plus de domaines que cette limite renvoie un message d’erreur. La réponse du serveur consiste pour chaque domaine à indiquer, à l’aide d’un attribut de type booléen si le nom de domaine peut-être créé et si ce n’est pas le cas, d’indiquer la raison qui empêche la création du nom de domaine. Voici une liste des messages qui sont envoyés en cas d’impossibilité de créer un nom de domaine :

Message Détails

In use

Le nom de domaine existe déjà (Quel que soit son état. Un nom de domaine en cours de suppression, par exemple, n’est pas libre).

Zone not opened Le nom de domaine est libre, mais appartient à une zone gérée par l’AFNIC qui n’est pas ouverte à l’enregistrement.

Zone unknown Le nom de domaine n’est pas dans une zone gérée par l’AFNIC.

Bad syntax L’argument passé en paramètre n’est pas un nom de domaine.

Registry bad syntax

L’argument passé en paramètre est bien un nom de domaine mais ne respecte pas une des règles syntaxiques imposées par l’AFNIC (par exemple : un seul caractère dans le label genre x.fr, …).

Equivalent name in use Un nom de domaine "équivalent" existe déjà et empêche le dépôt de ce nom de domaine.

Forbidden name Le nom de domaine fait partie d’une liste de termes dont le dépôt est soumis à examen préalable.

L’élément <frnic:name> contient le nom de domaine et l’attribut "reserved" ou, l’attribut "forbidden" qui correspondent à l’ancien statut de ces noms dans la liste des termes fondamentaux : réservés ou interdits. Depuis le 1er juillet 2011, cette liste est traitée de façon homogène et tous ces termes peuvent faire l’objet d’une demande et d’une création via l’obtention d’un code d’autorisation. Si c’est un nom de domaine "réservé", un élément <frnic:rsvReason> doit être présent pour indiquer pourquoi il se trouve catégorisé ainsi. Il en sera de même avec la présence éventuelle d’un élément <frnic:fbdReason>. On peut imaginer qu’un nom réservé le soit pour de multiples raisons, c’est pour cela que

Page 57: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  57 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

l’élément <frnic:rsvReason> peut être présent plusieurs fois pour un nom de domaine (la même règle s’appliquant bien sûr à l’élément <frnic:fbdReason>). Exemple de la requête pour vérifier la disponibilité d’une liste de noms de domaine :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <check> C: <domain:check C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>afnic.fr</domain:name> C: <domain:name>af-1234-nic.fr</domain:name> C: <domain:name>bois-guillaume.fr</domain:name> C: <domain:name>paris.fr</domain:name> C: <domain:name>trafiquants.fr</domain:name> C: <domain:name>toto.wf</domain:name> C: </domain:check> C: </check> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Le tableau suivant reprend les éléments qui sont présents dans les éléments <frnic:cd> de l’extension (<frnic:chkData>) de la réponse du serveur :

Nom de l’élément Nombre d’occurences

<frnic:name reserved="" forbidden=""> 1 <frnic:rsvReason> 0-n <frnic:fbdReason> 0-n

<frnic:name reserved="" forbidden=""> nom du domaine qui est vérifié,

"reserved" peut prendre les valeurs 0 ou 1, de même que "forbidden". <frnic:rsvReason> peut prendre les valeurs suivantes (cette liste peut

évoluer dans le temps) : City name Registry process

<frnic:fbdReason> peut prendre la valeur suivante (cette liste peut évoluer dans le temps) :

Legal issue

Page 58: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  58 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de la réponse envoyée par le serveur (pour ce type de commande, le code retour est toujours 1000, jamais 1001). Il est à noter que dans la réponse du serveur l’attribut "avail" prend les valeurs "1" ou "0", mais le protocole autorisant aussi l’utilisation de "true" et "false", il faut s’attendre à recevoir l’un ou l’autre.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:chkData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:cd> S: <domain:name avail="0">afnic.fr</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">af-1234-nic.fr</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">bois-guillaume.fr</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">paris.fr</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">trafiquants.fr</domain:name> S: <domain:reason>Forbidden name</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">toto.wf</domain:name> S: <domain:reason>Zone not opened</domain:reason> S: </domain:cd> S: </domain:chkData> S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:chkData> S: <frnic:domain> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: afnic.fr S: </frnic:name> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: af-1234-nic.fr S: </frnic:name> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="1" forbidden="0"> S: bois-guillaume.fr S: </frnic:name>

Page 59: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  59 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

S: <frnic:rsvReason>City name</frnic:rsvReason> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="1" forbidden="0"> S: paris.fr S: </frnic:name> S: <frnic:rsvReason>City name</frnic:rsvReason> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="1"> S: trafiquants.fr S: </frnic:name> S: <frnic:fbdReason>Legal issue</frnic:fbdReason> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: toto.wf S: </frnic:name> S: </frnic:cd> S: </frnic:domain> S: </frnic:chkData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000017</svTRID> S: </trID> S: </response> S:</epp>

3.4.9. Récupérer les données d'un domaine

La commande <domain:info> permet de récupérer des informations sur un nom de domaine. Bien qu’il ne s’agisse pas de remplacer la commande Whois, cette commande renvoie le même type d’information et elle est particulièrement utile pour suivre les traitements en cours pour un nom de domaine. Une requête sur un nom de domaine retourne toute l’information disponible sur celui-ci dès lors que l’interrogation est faite par le bureau d’enregistrement qui assure la gestion du nom de domaine. Dans ce cas, le auth_info n’est pas nécessaire. Le auth_info devient nécessaire lorsqu’un bureau d’enregistrement lance la requête sur un nom de domaine n’appartenant pas à son portefeuille. Par rapport à ce qui est décrit dans le RFC 5731, nous avons besoin de définir des extensions pour indiquer des états spécifiques aux nouvelles commandes que nous avons décrites, la suppression avec rédemption (RFC 3915) prévoit aussi l’utilisation d’une extension. Nous acceptons les différentes valeurs pour l’attribut "hosts", à savoir "none" pour n’avoir aucune information sur les serveurs de noms, "del" pour avoir uniquement les informations concernant la liste des serveurs de noms sur lesquels sont installés le nom de domaine interrogé, "sub" pour connaître la liste

Page 60: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  60 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

des serveurs de noms liés à ce nom de domaine et "all" pour avoir les 2 (c’est la valeur par défaut). Pour rappel, un nom de domaine peut être déposé sans avoir de configuration technique, ce qui n’empêche pas que des serveurs de noms puissent être liés à celui-ci… Requête envoyée sur un domaine du portefeuille du bureau d'enregistrement :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name hosts="all">ndd-de-test-0001.fr</domain:name> C: </domain:info> C: </info> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Requête envoyée sur un domaine n’appartenant pas au portefeuille du bureau d'enregistrement :

C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name hosts="all">ndd-de-test-0001.fr</domain:name> C: <domain:authInfo> C: <domain:pw>ALASTOR2012</domain:pw> C: </domain:authInfo> C: </domain:info> C: </info> C: <clTRID>FRNIC-10541-CLIENT-1247215792</clTRID> C: </command> C:</epp>

3.4.9.1.Détail de la partie "classique" de la réponse

La réponse que le serveur renvoie ne contient pas tous les éléments décrits dans le RFC 5731. Premier différence notable, l’élément <domain:roid>… Bien que nous ayons des identifiants uniques pour les noms de domaine dans notre base de données, ceux-ci ne répondent pas tout à fait au "cahier des charges" défini dans le RFC. En effet, un "roid" devrait être créé à chaque création d’objet dans la base ; un nom de domaine créé une première fois, supprimé et re-créé devrait, en toute logique, se voir attribuer des "roid" différents pour chaque opération de création. À l’AFNIC, un ID unique est associé à un nom de domaine lors de sa toute première insertion dans la base de données, celui-ci le suit même si il est supprimé entre temps (il n’est jamais ré-attribué). À cet ID unique nous concaténons le suffixe "–FRNIC", tout comme pour les objets contact.

Page 61: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  61 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

L’état d’un nom de domaine peut être indiqué soit dans la partie <resData> de la réponse, soit dans les extensions. Toutefois, contrairement au RFC, cette information n’est pas optionnelle. Un nom de domaine qui n’est pas dans un état particulier a forcément l’élément <domain:status s="ok"/> présent dans la partie <resData> de la réponse. De la même manière, l’absence de cet élément implique forcément qu’une information sur l’état du nom de domaine se trouve dans la partie <extension> de la réponse. Les éléments <domain:crID> (ID du bureau qui a créé pour la première fois le nom de domaine), <domain:upID> (ID du bureau qui a le dernier mis à jour le nom de domaine) et <domain:trDate> (date du dernier transfer terminé) ne sont pas présents. Le tableau suivant reprend les éléments qui seront présents dans l’élément <domain:infData> de la réponse du serveur :

Nom de l’élément Nombre d’occurences

<domain:name> 1 <domain:roid> 1 <domain:status s=""> 0-n <domain:registrant> 1 <domain:contact type="admin"> 1 <domain:contact type="tech"> 1-3 <domain :ns> 0-1 <domain :host> 0-n <domain:clID> 1 <domain:crDate> 1 <domain:exDate> 1 <domain:upDate> 1 <domain:authInfo> 1

<domain:name> nom du domaine qui est l’objet de la demande

d’informations. <domain:roid> ID unique de l’objet dans notre base de données. <domain:status s=""> permet d’indiquer l’état d’un nom de

domaine (celui-ci pouvant être dans différents états au même moment). Tout état qui ne correspond pas à la liste disponible et décrite dans le RFC 5731 doit être indiqué dans une extension adéquate.

<domain:registrant> contient l’identifiant du titulaire déduit du nic-handle de celui-ci auquel on a retiré le suffixe (FRNIC) et le caractère séparateur "-".

<domain:contact type="admin"> contient l’identifiant du contact administratif.

<domain:contact type="tech"> contient l’identifiant d’un contact technique.

<domain:ns> contient la configuration technique du nom de domaine si celui-ci en a une. Le format est le même que celui utilisé lors des modifications techniques. Cette information n’est pas présente si la valeur de l’attribut "hosts" passé lors de la requête vaut "none" ou "sub".

<domain:host> contient la liste des serveurs de noms connus de nos services utilisés comme serveurs de noms pour des domaines gérés

Page 62: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  62 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

par l’AFNIC. Cette information n’est pas présente si la valeur de l’attribut "hosts" passé lors de la requête vaut "none" ou "del".

<domain:clID> contient l’ID du bureau qui gère le nom de domaine.

<domain:crDate>… Dans la version actuelle de cette interface, les informations d’horodatage ne sont pas alignées sur leurs rôles décrits dans le RFC 5731 mais reprise du modèle "Whois". La date de création est donc la dernière date de création du nom de domaine ou de dernière transmission (volontaire ou forcée).

<domain:exDate> contient la date d’expiration supposée du nom de domaine (la date anniversaire). Nous n’avons pas implémenté la commande <domain:renew> et le mécanisme de renouvellement à l’AFNIC n’est pas le même que celui décrit dans les RFC sur EPP.

<domain:upDate> contient la date de dernière opération d’écriture dans la base concernant ce domaine. Contrairement à ce qui est indiqué dans le RFC 5731, cet élément est toujours présent, même si il n’y a pas eu de commande de mise à jour. Dans ce cas, sa valeur sera égale à celle de l’élément <domain:crDate> (une fois encore, les règles existantes dans notre modèle "Whois" ont été reconduites).

<domain:authInfo> contient le auth_info associé au nom de domaine.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:roid>DOM000000456987-FRNIC</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>MM4567</domain:registrant> S: <domain:contact type="admin">NFC1</domain:contact> S: <domain:contact type="tech">NFC1</domain:contact> S: <domain:contact type="tech">VIL1666</domain:contact> S: <domain:ns> S: <domain:hostAttr> S: <domain:hostName>ns1.nic.fr</domain:hostName> S: </domain:hostAttr> S: <domain:hostAttr> S: <domain:hostName>ns2.nic.fr</domain:hostName> S: </domain:hostAttr> S: <domain:hostAttr> S: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostname> S: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> S: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> S: </domain:hostAttr> S: </domain:ns> S: <domain:host>ns.ndd-de-test-0001.fr</domain:host> S: <domain:host>ns1234.ndd-de-test-0001.fr</domain:host> S: <domain:clID>BEactuelID</domain:clID> S: <domain:crDate>2008-12-25T00:00:00.0Z</domain:crDate> S: <domain:exDate>2009-12-25T00:00:00.0Z</domain:exDate> S: <domain:update>2009-01-10T00:00:00.0Z</domain:update> S: <domain:authInfo> S: <domain:pw>WarlordZ666</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000018</svTRID> S: </trID> S: </response> C:</epp>

Page 63: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  63 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.4.9.2.Détails des extensions possibles de la réponse

La commande <domain:info> peut contenir des informations supplémentaires dans la partie <extension> de la réponse. Parmi ces informations, il peut y avoir celles liées au processus de suppression/restauration qui correspondent au RFC 3915. Par exemple, un nom de domaine qui a été supprimé et qui se retrouve donc en période de rédemption a l’extension suivante (une partie de l’élément <resData> a aussi été reproduit) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="pendingDelete"/> […] S: </resData> S: <extension> S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> S: <rgpStatus s="pendingDelete"/> S: </rgp:infData> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000019</svTRID> S: </trID> S: </response> S:</epp>

Reprenons notre domaine, mais cette fois-ci, imaginons que le titulaire n’a pas encore passé avec succès le processus de qualification. La partie <extension> de la réponse ressemble à ceci (l’élément <domain:status> est aussi présent dans la partie <resData>) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="serverTransferProhibited"/> […] S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:domain> S: <frnic:status s="serverTradeProhibited"/> S: </frnic:domain> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000021</svTRID> S: </trID> S: </response> S:</epp>

Page 64: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  64 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

De plus, si le client a activé l'extension secDNS au login et que le domaine possède des enregistrements DS ceux-ci seront signalés dans la réponse sous forme d'extension, conformément au RFC 5910.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="serverTransferProhibited"/> […] S: </resData> S: <extension> S: <secDNS:infData S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S: <secDNS:dsData> S: <secDNS:keyTag>12345</secDNS:keyTag> S: <secDNS:alg>3</secDNS:alg> S: <secDNS:digestType>1</secDNS:digestType> S: <secDNS:digest>49FD46E6C4B45C55D4AC49FD46E6C4B45C55D4AC </secDNS:digest> S: </secDNS:dsData> S: </secDNS:infData> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000018</svTRID> S: </trID> S: </response> S:</epp>

Page 65: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  65 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.5. Gérer un contact

Quelques règles générales :

Les contacts ont tous un nic-handle utilisable pour les référencer dans les différentes opérations sur les noms de domaine. Ce nic-handle n’est JAMAIS réattribué après suppression du contact.

Les contacts titulaires doivent être créés avant d’être utilisés dans une opération sur un nom de domaine.

Les données de qualification sont liées au titulaire. Le processus de qualification se fait donc sur les contacts.

Il est à noter cette remarque d’ordre général sur la gestion des adresses postales, à savoir :

Contrairement à ce qu’il est indiqué dans le RFC 5731, un seul élément de type <contact:postalInfo> peut être fourni.

Contrairement à ce qu’il est indiqué dans le RFC 5731, seul le type "loc" pour les adresses postales est accepté.

3.5.1. Créer un contact

Pour créer un objet contact utilisés comme titulaire, l’AFNIC demande des informations qui ne sont pas proposées dans le mapping EPP standard pour les objets "contact", il est donc nécessaire de proposer une extension. Par ailleurs, pour un contact pour lequel la différenciation prénom/nom aura un sens, <contact:name> doit contenir le nom de famille alors que l’élément <frnic:firstName> de l’extension proposée contient le prénom du contact. Concrètement, pour tout contact titulaire "personne physique", cet élément est obligatoire. Autre adaptation nécessaire du mapping contact standard (RFC 5733) car non compatible avec nos procédures, l’élément <contact:id>, bien qu’obligatoire n’est pas pris en compte par notre serveur. Cela implique, que contrairement au standard EPP, le bureau d’enregistrement n’a pas le choix de l’identifiant pour le contact dont la création est demandée. L’AFNIC affecte selon ses propres algorithmes les identifiants de contacts. Bien entendu, en cas de création réalisée avec succès, l’identifiant est indiqué dans la réponse du serveur. Par contre cet identifiant peut être celui d’un contact déjà existant si le bureau d’enregistrement envoie exactement les mêmes infos que celles contenues dans ce contact. Pour ce dernier cas, nous ajoutons un élément dans une extension dans la réponse du serveur.

Autre élément qui, bien qu’obligatoire, n’est pas pris en compte car non utilisé, c’est l’élément <contact:authInfo>. Il n’est effectivement pas possible d’associer un mot de passe par objet contact, mais tout comme pour <contact:id>, nous avons choisi de le conserver dans la requête envoyée pour

Page 66: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  66 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

assurer une compatibilité plus simple avec les codes clients existants. L’élément <contact:disclose>, qui est optionnel dans le mapping contact, n’est pas non plus traité, il ne doit donc pas être présent sous peine de voir la commande retourner une erreur. En plus de l’élément <frnic:firstName>, l’extension proposée permet d’indiquer des informations nécessaires à la qualification des contacts utilisés comme titulaires de noms de domaine. Un élément <frnic:individualInfos> doit donc être présent pour les titulaires "personne physique", un élément <frnic:legalEntityInfos> pour les titulaires "personne morale". En ce qui concerne la gestion de la liste de diffusion restreinte, la méthode choisie est la présence d’un élément "générique" <frnic:list> ne pouvant prendre dans l’immédiat que la valeur "restrictedPublication" et ne s’appliquant, toujours pour le moment, qu’au objet contact de type "personne physique". Voici, dans le détail les éléments que nous retrouvons pour les titulaires personnes physiques.

Nom de l’élément Nombre d’occurences

<frnic:birthDate> 1 <frnic:birthCity> 0-1 <frnic:birthPc> 0-1 <frnic:birthCc> 1

<frnic:birthDate> contient la date de naissance du contact. <frnic:birthCity> contient la commune de naissance du contact. <frnic:birthPc> contient le code postal de la commune de naissance (au

pire le code département). <frnic:birthCc> contient le code pays du lieu de naissance.

Exemple de création d’un contact contenant des informations lui permettant d’être utilisé comme titulaire personne physique pour un nom de domaine :

Page 67: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  67 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <contact:create C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>XXXX0000</contact:id> C: <contact:postalInfo type="loc"> C: <contact:name>Levigneron</contact:name> C: <contact:org>AFNIC</contact:org> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>[email protected]</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:create> C: <frnic:contact> C: <frnic:list>restrictedPublication</frnic:list> C: <frnic:individualInfos> C: <frnic:birthDate>1968-07-20</frnic:birthDate> C: <frnic:birthCity>Rouen</frnic:birthCity> C: <frnic:birthPc>76000</frnic:birthPc> C: <frnic:birthCc>FR</frnic:birthCc> C: </frnic:individualInfos> C: <frnic:firstName>Vincent</frnic:firstName> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Dans les cas des contacts possédant des informations de qualification, une extension est nécessaire pour indiquer l’état dans lequel se trouve le contact par rapport à ce processus de qualification. Les éléments qui se trouvent dans cette extension sont indiqués dans le tableau ci-après.

Page 68: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  68 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

<frnic:idStatus> est utilisé pour indiquer le status par rapport au processus

d’identification (il n’est présent que pour les contacts créés avec un élément <frnic:individualInfos> ou <frnic:legalEntityInfos>) :

no : Le contact n’est pas encocre qualifié. pending : Le contact est en cours de qualification (dans cet état l’

opération <contact :update> n’est pas possible). ok : Le contact est qualifié positivement. problem : Problème lors du processus de qualification. Cet état à un

impact sur le statut du portefeuille de domaines associés au contact ko : Au terme du processus de qualification, le contact n’a pas pu

être qualifié positivement. <frnic:nhStatus new=""> est utilisé pour indiquer si le nic-handle vient

d’être créé (valeur de new à 1) ou bien s’il s’agit d’une ré-utilisation d’un contact existant (valeur de new à 0).

Dans la réponse à une commande de création, le RFC 5733 prévoit la présence de l’élément <contact:crDate> pour indiquer l’heure et la date de création du contact. Cette date peut par la suite être récupérée en utilisant la commande <contact:info>. Deux raisons font que cette information doit être interprétée avec précaution. La première c’est que dans notre modèle actuel (qui concerne 1,5 millions de contacts), la date de création n’a pas été conservée, la seconde c’est que cela n’est pas cohérent avec notre politique de non duplication de contacts identiques… Donc, bien que cet élément soit fourni dans la réponse du serveur, sa valeur sera peut être antérieure à la date de soumission de la commande dans le cas d’un objet ré-utilisé (<frnic:nhStatus new="0">).

Nom de l’élément Nombre d’occurences <frnic:idStatus> 0-1 <frnic:nhStatus new=""> 1

Page 69: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  69 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Exemple de réponse envoyée par le serveur (pour les objets "contact", le code retour est toujours 1000 en cas de commande traitée avec succès).

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <contact:creData S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <contact:id>VL99999</contact:id> S: <contact:crDate>2008-11-20T00:00:00.0Z</contact:crDate> S: </contact:creData> S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:creData> S: <frnic:nhStatus new="1"/> S: <frnic:idStatus>no</frnic:idStatus> S: </frnic:creData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000022</svTRID> S: </trID> S: </response> S:</epp>

Dans le cas où le contact à créer n’est pas de type "personne physique" mais de type "personne morale", il est possible de fournir un ou plusieurs identifiants. L’extension du mapping contact standard permet donc d’indiquer ces éléments. Dans l’extension, l’élément <frnic:firstName> ne doit pas être présent. Les éléments doivent respecter l’ordre du tableau ci-dessous :

Nom de l’élément Nombre d’occurences <frnic:legalStatus s=""> 1 <frnic:siren> 0-1 <frnic:VAT> 0-1 <frnic:trademark> 0-1 <frnic:asso> 0-1 <frnic:waldec> 0-1 <frnic:decl> 1 si <frnic:waldec> est absent <frnic:publ announce="" page=""> 1 si <frnic:waldec> est absent <frnic:DUNS> 0-1 <frnic:local> 0-1 <frnic:legalStatus s=""> cet élément est utilisé pour indiquer grâce à

l’attribut "s", la raison sociale de l’entité à identifier ("company", "association", "other"). L’élément est vide sauf dans le cas où l’attribut "s" vaudra "other". (Ex : <frnic:legalStatus s="other">Ambassade</frnic:legalStatus>).

Page 70: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  70 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

<frnic:siren> contient le numéro de SIREN. <frnic :VAT> contient le numéro de TVA intracommunautaire. Cette

information est optionnelle. <frnic:trademark> contient un numéro de marque. <frnic:asso> contient ces 2 éléments pour les associations.

<frnic:waldec> indique l’identifiant Waldec lié à une association. Si cet identifiant est fourni, cela est suffisant pour identifier une association.

<frnic:decl> indique la date de déclaration en préfecture. <frnic:publ announce="" page=""> contient la date de publication

au JO (l’attribut "announce" permet d’indiquer le numéro de l’annonce, l’attribut "page" le numéro de la page de cette annonce).

<frnic:DUNS> contient un numéro DUNS. <frnic:local> contient un identifiant local n’appartenant à aucune autre

catégorie.

Voici ce que cela donne comme requête avec un numéro de SIREN comme élément d’identification :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <contact:create C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>XXXX0000</contact:id> C: <contact:postalInfo type="loc"> C: <contact:name>AFNIC</contact:name> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>[email protected]</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:create> C: <frnic:contact> C: <frnic:legalEntityInfos> C: <frnic:legalStatus s="company"/> C: <frnic:siren>123456789</frnic:siren> C: </frnic:legalEntityInfos> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Page 71: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  71 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Par ailleurs, la fonction create:contact permet également de positionner directement un tag de validation par le bureau d’enregistrement sur l’éligibilité et la joignabilité (cf. Guide des procédures). Ces éléments peuvent être ajoutés aussi bien pour un contact de type PP ou de type PM.

C:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" > C: <command> C: <create> C: <contact:create xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>XXXX0000</contact:id> C: <contact:postalInfo type="loc"> C: <contact:name>Levigneron</contact:name> C: <contact:org>AFNIC</contact:org> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>vincent.levigneron\@nic.fr</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:create> C: <frnic:contact> C: <frnic:legalEntityInfos> C: <frnic:idStatus>ok</frnic:idStatus> C: <frnic:legalStatus s="company"/> C: <frnic:siren>123456789</frnic:siren> C: </frnic:legalEntityInfos> C: <frnic:reachable media="email">1</frnic:reachable> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Nom de l’élément Nombre d’occurences <frnic:idStatus> 0-1 <frnic:reachable> 0-1

Page 72: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  72 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.5.2. Modifier un contact

La mise jour des données pour un contact permet la modification de certains éléments de celui-ci mais dans le respect des règles spécifiques liées aux rôles qu’il peut être amené à jouer pour un nom de domaine, contact administratif, technique ou titulaire. Il n’est pas possible non plus de modifier le contenu d’un contact lié à un code d’autorisation non encore utilisée. Seul le bureau d’enregistrement auquel ce contact est rattaché peut demander une modification de celui-ci. Le mécanisme d’authentification via <contact:authInfo> n’a pas été mis en place pour la gestion des contacts. Les informations contenues dans les éléments <frnic:individualInfos> et <frnic:legalEntityInfos> ne peuvent pas être modifiées. Pas plus que les nom et prénom des contacts titulaire. Une extension est nécessaire pour la gestion de la liste diffusion restreinte, c’est cet exemple que nous avons choisi d’illustrer ici.. La gestion des listes se fait à l’aide des éléments <contact:add> et <contact:del>. L’élément <frnic:list>, déjà présenté, est utilisé de la même manière que lors de la création. Supprimons l’appartenance à la liste "restrictedPublication" du contact VL99999 :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <contact:update C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>VL99999</contact:id> C: </contact:update> C: </update> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:update> C: <frnic:contact> C: <frnic:rem> C: <frnic:list>restrictedPublication</frnic:list> C: </frnic:rem> C: </frnic:contact> C: </frnic:update> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

La réponse du serveur n’a rien de spécifique et est toujours avec un code retour 1000. Par ailleurs la fonction contact:update permet de positionner un tag de validation par le bureau d’enregistrement sur l’éligibilité et la joignabilité.

Page 73: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  73 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

C:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <contact:update C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>VL99999</contact:id> C: </contact:update> C: </update> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> C: <frnic:update> C: <frnic:contact> C: <frnic:add> C: <frnic:idStatus>ok</frnic:idStatus> C: <frnic:reachable media="email">1</frnic:reachable> C: </frnic:add> C: </frnic:contact> C: </frnic:update> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

3.5.3. Supprimer un contact

L’opération de suppression d’un objet "contact" n’est pas disponible dans l’interface EPP de l’AFNIC. En effet, un "garbage collector" assure la suppression des objets trop anciens et non référencés. La règle est la suivante : tout contact qui n’est plus référencé depuis plus de 3 mois dans un autre objet devient obsolète, c'est-à-dire qu’il ne peut plus être utilisé dans une quelconque opération. Un contact obsolète restera encore pendant une période de 15 jours dans notre base de données avant d’être définitivement détruit de celle-ci. Ce "garbage collector" a vocation à travailler en toute transparence et des messages de notification sont ajoutés dans la file d’attente du bureau d’enregistrement concerné par la suppression d’un objet contact (cf 2.6.3 Notification exogènes – suppression d’un contact). Ceci afin d’assurer à ce dernier d’avoir une base de données synchronisée avec celle de l’AFNIC.

3.5.4. Qualification d’un contact titulaire

Ce processus de qualification est réalisé par l’AFNIC via des procédures "off-line". L’impact de l’état de qualification d’un titulaire sur les opérations possibles est décrit dans le guide des procédures.

Page 74: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  74 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.5.5. Récupérer les données d'un contact

La commande <contact:info> permet d’obtenir les informations d’un objet "contact". Compte tenu de la gestion particulière de ces objets, un certain nombre d’éléments ne sont pas présent ou ont une signification différente de ce qui peut être décrit dans le RFC 5733 lors de la réponse envoyée par le serveur. En voici la liste : <contact:crID> (adapté), <contact:crDate> (adapté), <contact:upID> (supprimé), <contact:trDate> (supprimé), <contact:authInfo> (supprimé) et <contact:disclose> (supprimé). De plus une extension est nécessaire pour tenir compte des données d’identification. La valeur de l’élément <contact:crID> est celle du bureau d’enregistrement chez qui ils sont actuellement référencés. La valeur de l’élément <contact:crDate> est systématiquement retournée mais reste sujette à caution du fait de l’historique des contacts de l’AFNIC. Autre limitation par rapport au RFC 5733, seul le bureau d’enregistrement lié à cet objet contact peut demander des informations sur celui-ci. Par exemple pour la requête : C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <contact:info C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>MO666</contact:id> C: </contact:info> C: </info> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Page 75: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  75 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

La réponse du serveur est la suivante :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> <response> <result code="1000"> <msg>Command completed successfully</msg> </result> <resData> <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> <contact:id>MO666</contact:id> <contact:roid>MO666-FRNIC</contact:roid> <contact:status s="linked"/> <contact:postalInfo type="loc"> <contact:name>Mobibus Outlaws</contact:name> <contact:addr> <contact:street>7, avenue monchignon</contact:street> <contact:city>la Baule Escoublac</contact:city> <contact:pc>44500</contact:pc> <contact:cc>FR</contact:cc> </contact:addr> </contact:postalInfo> <contact:voice>+33.987654321</contact:voice> <contact:email>[email protected]</contact:email> <contact:clID>>-wuhgejav499-.fr</contact:clID> <contact:crID>>-wuhgejav499-.fr</contact:crID> <contact:crDate>2010-10-12T07:49:45.0Z</contact:crDate> <contact:upDate>2011-07-08T16:41:17.0Z</contact:upDate> </contact:infData> </resData> <extension> <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> <frnic:resData> <frnic:infData> <frnic:contact> <frnic:legalEntityInfos> <frnic:idStatus when="2011-06-21T05:30:36" source="registry">ok</frnic:idStatus> <frnic:legalStatus s="company"/> <frnic:siren>444158265</frnic:siren> </frnic:legalEntityInfos> <frnic:obsoleted>0</frnic:obsoleted> <frnic:reachable when="2011-06-21T05:30:36" media="email" source="registry">1</frnic:reachable> </frnic:contact> </frnic:infData> </frnic:resData> </frnic:ext> </extension> <trID> <clTRID>79105131472048712675</clTRID> <svTRID>PROD-nergal-11983-115-1314720487.7498</svTRID> </trID> </response> </epp>

On remarque que l’état dans le processus de qualification est indiqué via l’élément <frnic:idStatus> pour l’éligibilité et <frnic:reachable> pour la joignabilité.

Page 76: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  76 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.6. Notifications

3.6.1. Gestion de la file de notification

Exemple de requête pour récupérer un message en attente :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="req"/> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

La requête pour accuser réception de la prise en compte par le client du message qui se trouve dans la file d’attente est la suivante : C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="ack" msgID="50001"/> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de la réponse envoyée par le serveur (nous considérons que c’était le seul message en attente) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <msgQ count="0" id="50001"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000006</svTRID> S: </trID> S: </response> S:</epp>

Page 77: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  77 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.6.2. Notifications asynchrones

Dans ce chapitre seront donnés des exemples de notification pour :

• Update [tech] OK • Update [tech] KO • Transfer accord (bureau d'enregistrement entrant) • Transfer fini (bureau d'enregistrement entrant) • Transfer rejeté (bureau d'enregistrement entrant) • Trade fini (bureau d'enregistrement entrant) • Delete fini • Restore fini • Create fini • Update [admin] fini • Update [context] fini

• Update [tech] OK

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50001"> S: <qDate>2008-12-25T00:01:00.0Z</qDate> S: <msg> S: <resZC type="plain-text"> S: ZONE : ndd-de-test-0001.fr. S: NS : ns1.nic.fr. S: NS : ns2.nic.fr. S: NS : ns.ndd-de-test-0001.fr. [192.93.0.1, 2001:660:3005:1::1:1] S: S: ==> SUCCESS S: </resZC> S: </msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-25T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>une-autre-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

Page 78: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  78 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Update [tech] KO

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50001"> S: <qDate>2008-12-25T00:01:00.0Z</qDate> S: <msg> S: <resZC type="plain-text"> S: ZONE : ndd-de-test-0001.fr. S: NS : ns1.nic.fr. S: NS : ns2.nic.fr. S: NS : ns.ndd-de-test-0001.fr. [192.93.0.1, 2001:660:3005:1::1:1] S: f> Server doesn't listen/answer on port 53 for UDP protocol S: => ns.ndd-de-test-0001.fr./192.93.0.1 S: S: ==> FAILURE S: </resZC> S: </msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="0">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-25T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>une-autre-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

• Transfer accord (bureau d'enregistrement entrant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer approved.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp>

Page 79: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  79 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Transfer fini (bureau d'enregistrement entrant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2008-12-26T00:01:00.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-26T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp>

• Transfer rejeté (bureau d'enregistrement entrant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer rejected.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientRejected</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-16T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp>

Page 80: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  80 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Trade fini (bureau d'enregistrement entrant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000015</svTRID> S: </trID> S: </response> S:</epp>

• Delete fini

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16020"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Deletion completed.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27244-CLIENT-1254926575</clTRID> S: <svTRID>TEST-kenobi-6435-29-1254926575.803</svTRID> S: </trID> S: </response> S:</epp>

Page 81: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  81 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Restore fini

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16020"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Deletion aborted. Domain successfully restored.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="0">ndd-de-test0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FooBar</clTRID> S: <svTRID>frnic-00000025</svTRID> S: </trID> S: </response> S:</epp>

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63478"> S: <qDate>2010-06-04T09:11:27.0Z</qDate> S: <msg>Pending update (restore) completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-27195-CLIENT-1275642606</clTRID> S: <svTRID>DEV-photon-26192-3-1275642606.46913</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-04T09:10:15.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27404-CLIENT-1275643628</clTRID> S: <svTRID>DEV-photon-27325-3-1275643628.62759</svTRID> S: </trID> S: </response> S:</epp>

Page 82: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  82 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Create fini

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63263"> S: <qDate>2010-06-03T15:23:23.0Z</qDate> S: <msg>Pending creation completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">dom-epp-wytxubuz.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-18673-CLIENT-1275578515</clTRID> S: <svTRID>DEV-photon-18294-4-1275578517.15639</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-03T15:22:09.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-18687-CLIENT-1275578623</clTRID> S: <svTRID>DEV-photon-18318-12-1275578623.9696</svTRID> S: </trID> S: </response> S:</epp>

• Update [admin] fini

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63482"> S: <qDate>2010-06-04T10:30:28.0Z</qDate> S: <msg>Pending update (contacts) completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">dom-epp-hyclebod.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-27901-CLIENT-1275647287</clTRID> S: <svTRID>DEV-photon-27377-4-1275647289.31733</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-04T10:28:32.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27920-CLIENT-1275647486</clTRID> S: <svTRID>DEV-photon-27344-7-1275647486.82448</svTRID> S: </trID> S: </response> S:</epp>

Page 83: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  83 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Update [context] fini

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="63480"> S: <qDate>2010-06-04T09:52:28.0Z</qDate> S: <msg>Pending update (hold/authInfo) completed successfully.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain- 1.0"> S: <domain:name paResult="1">dom-epp-hyclebod.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-27505-CLIENT-1275645007</clTRID> S: <svTRID>DEV-photon-27393-9-1275645009.72202</svTRID> S: </domain:paTRID> S: <domain:paDate>2010-06-04T09:50:28.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27522-CLIENT-1275645283</clTRID> S: <svTRID>DEV-photon-27331-8-1275645283.06911</svTRID> S: </trID> S: </response> S:</epp>

3.6.3. Notifications exogènes

Dans ce chapitre seront donnés des exemples de notification pour :

• Transfer demandé (bureau d'enregistrement sortant) • Transfer accord (bureau d’enregistrement entrant) • Transfer fini (bureau d’enregistrement sortant) • Transfer annulé • Trade initié (bureau d’enregistrement sortant) • Trade titulaire sortant accord • Trade titulaire entrant accord • Trade titulaire entrant et sortant accord • Trade fini (bureau d'enregistrement sortant) • Trade annulé • Recover fini (bureau d'enregistrement sortant) • Notification d'entrée en procédure de qualification • Notification de clôture de qualification • Notification de passage en procédure de Justification • Notification de gel d’un nom de domaine • Notification de blocage d’un nom de domaine • Notification de déblocage de portefeuille • Notification de clôture de procédure de Justification avec suppression de

portefeuille • Notification de clôture de procédure de Justification positive avec

déblocage de portefeuille et mise à jour de base WHOIS • Suppression d’un contact

Page 84: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  84 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Transfer demandé (bureau d'enregistrement sortant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50002"> S: <qDate>2008-12-25T00:02:00.0Z</qDate> S: <msg>Transfer requested.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000008</svTRID> S: </trID> S: </response> S:</epp>

• Transfer accord (bureau d’enregistrement entrant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="28981"> S: <qDate>2009-10-06T16:27:19.0Z</qDate> S: <msg>Transfer approved.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEentrantID</domain:reID> S: <domain:reDate>2009-10-06T16:27:08.0Z</domain:reDate> S: <domain:acID>BEsortantID</domain:acID> S: <domain:acDate>2009-10-06T16:27:19.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000008</svTRID> S: </trID> S: </response> S:</epp>

Page 85: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  85 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Transfer fini (bureau d’enregistrement sortant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="28982"> S: <qDate>2009-10-06T16:27:20.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>TEST_2</domain:reID> S: <domain:reDate>2009-10-06T16:27:08.0Z</domain:reDate> S: <domain:acID>TEST</domain:acID> S: <domain:acDate>2009-10-06T16:27:20.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>FRNIC-17331-CLIENT-1254902552</clTRID> S: <svTRID>DEV-photon-17205-4-1254902552.81518</svTRID> S: </trID> S: </response> S:</epp>

• Transfer annulé (bureau d’enregistrement sortant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16022"> S: <qDate>2009-10-07T14:18:33.0Z</qDate> S: <msg>Transfer aborted.</msg> S: </msgQ> S: <resData> S: <domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-001.fr</domain:name> S: <domain:trStatus>clientCancelled</domain:trStatus> S: <domain:reID>-huqlycuw772-.fr</domain:reID> S: <domain:reDate>2009-10-07T14:18:31.0Z</domain:reDate> S: <domain:acID>-huqlycuw772-.fr</domain:acID> S: <domain:acDate>2009-10-07T14:18:33.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>FRNIC-27244-CLIENT-1254926575</clTRID> S: <svTRID>TEST-kenobi-6591-24-1254926575.49702</svTRID> S: </trID> S: </response> S:</epp>

• Transfer annulé (bureau d’enregistrement entrant)

Page 86: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  86 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="16020"> S: <qDate>2009-10-07T14:18:33.0Z</qDate> S: <msg>Transfer aborted.</msg> S: </msgQ> S: <resData> S: <domain:panData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="0">ndd-de-test-001.fr</domain:name> S: <domain:paTRID> S: <clTRID>FRNIC-25860-CLIENT-1254925111</clTRID> S: <svTRID>TEST-kenobi-5723-27-1254925111.01848</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-10-07T14:18:31.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>FRNIC-27244-CLIENT-1254926575</clTRID> S: <svTRID>TEST-kenobi-6435-29-1254926575.803</svTRID> S: </trID> S: </response> S:</epp>

• Trade initié (bureau d’enregistrement sortant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50010"> S: <qDate>2009-12-25T00:02:00.0Z</qDate> S: <msg>Trade requested.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-16T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp>

Page 87: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  87 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Trade titulaire sortant accord

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50011"> S: <qDate>2009-01-02T00:00:01.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>oldHolderApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-16T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000013</svTRID> S: </trID> S: </response> S:</epp>

Page 88: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  88 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Trade titulaire entrant accord

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="62373"> S: <qDate>2010-05-28T16:06:25.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>gateway-dev-1275062768-286.fr</frnic:name> S: <frnic:trStatus>newHolderApproved</frnic:trStatus> S: <frnic:reID>-naqjanir666-.fr</frnic:reID> S: <frnic:reDate>2010-05-28T16:06:18.0Z</frnic:reDate> S: <frnic:reHldID>IP649</frnic:reHldID> S: <frnic:rhDate>2010-05-28T16:06:25.0Z</frnic:rhDate> S: <frnic:acID>TEST</frnic:acID> S: <frnic:ahDate>2010-06-12T16:06:18.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-25057-CLIENT-1275400281</clTRID> S: <svTRID>DEV-photon-23773-7-1275400281.18398</svTRID> S: </trID> S: </response> S:</epp>

Page 89: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  89 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Trade titulaire sortant et entrant accord

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50012"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>holdersApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-03T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-02T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000014</svTRID> S: </trID> S: </response> S:</epp>

• Trade fini (bureau d'enregistrement sortant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="423754"> S: <qDate>2009-08-28T14:49:55.0Z</qDate> S: <msg>Trade completed.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ventedentreprise.fr</frnic:name> S: <frnic:trStatus>clientApproved</frnic:trStatus> S: <frnic:reID>-ryjzifyz909-.fr</frnic:reID> S: <frnic:reDate>2009-08-28T15:54:53.0Z</frnic:reDate> S: <frnic:acID>-vycfazur780-.fr</frnic:acID> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-8234-51-1251471004.60964</svTRID> S: </trID> S: </response> S:</epp>

Page 90: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  90 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Trade annulé (bureau d'enregistrement sortant)

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="97" id="80527"> S: <qDate>2009-05-13T01:10:05.0Z</qDate> S: <msg>Trade aborted.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>moskitul.fr</frnic:name> S: <frnic:trStatus>clientCancelled</frnic:trStatus> S: <frnic:reID>-xanmaqub851-.fr</frnic:reID> S: <frnic:reDate>2009-04-27T14:49:37.0Z</frnic:reDate> S: <frnic:rhDate>2009-05-12T12:49:37.0Z</frnic:rhDate> S: <frnic:ahDate>2009-05-12T12:49:37.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-6724-12-1251461542.74779</svTRID> S: </trID> S: </response> S:</epp>

• Recover fini (bureau d'enregistrement sortant)

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="207" id="59166"> S: <qDate>2010-04-15T02:20:50.0Z</qDate> S: <msg>Recover completed.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:recData> S: <frnic:domain> S: <frnic:name>identification-histo-problem-1-1271298006685.fr</frnic:name> S: <frnic:reID>-hexfyreg992-.fr</frnic:reID> S: <frnic:reDate>2010-04-15T02:20:48.0Z</frnic:reDate> S: <frnic:reHldID>NFC11</frnic:reHldID> S: <frnic:acID>TEST</frnic:acID> S: </frnic:domain> S: </frnic:recData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-25906-CLIENT-1275402635</clTRID> S: <svTRID>DEV-photon-25788-3-1275402635.52974</svTRID> S: </trID> S: </response> S:</epp>

Page 91: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  91 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification d'entrée en procédure de qualification

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="100" id="3006545"> S: <qDate>2011-08-29T15:13:00.0Z</qDate> S: <msg>Qualification process begins.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="start"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>pending</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>pending</frnic:reStatus> S: <frnic:voice>+33.123456789</frnic:voice> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-8-1914719304.12345</svTRID> S: </trID> S: </response> S:</epp>

Page 92: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  92 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification de clôture de qualification

Cas où la joignabilité et l’éligibilité ont pu aboutir

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="110" id="3006645"> S: <qDate>2011-08-29T15:14:00.0Z</qDate> S: <msg>Qualification process finished.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="finished"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>ok</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>ok</frnic:reStatus> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-8-1914719404.12345</svTRID> S: </trID> S: </response> S:</epp>

Page 93: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  93 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Cas où la joignabilité et/ou l’éligibilité n’ont pu aboutir

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="110" id="3006645"> S: <qDate>2011-08-29T15:14:00.0Z</qDate> S: <msg>Qualification process finished.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="finished"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>ko</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>ok</frnic:reStatus> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-8-1914719404.12345</svTRID> S: </trID> S: </response> S:</epp>

Page 94: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  94 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification de passage en procédure de Justification

En cas de plainte, de signalement sans avoir pu valoriser éligibilité et joignabilité ou en cas de données fantaisistes.

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="120" id="3006745"> S: <qDate>2011-08-29T15:14:00.0Z</qDate> S: <msg>Qualification process in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:quaData> S: <frnic:contact> S: <frnic:id>ZNE51</frnic:id> S: <frnic:qualificationProcess s="problem"/> S: <frnic:legalEntityInfos> S: <frnic:idStatus>ko</frnic:idStatus> S: <frnic:legalStatus s="association"/> S: <frnic:siren>493020995</frnic:siren> S: </frnic:legalEntityInfos> S: <frnic:reachability> S: <frnic:reStatus>ok</frnic:reStatus> S: <frnic:email>[email protected]</frnic:email> S: </frnic:reachability> S: </frnic:contact> S: </frnic:quaData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <svTRID>PROD-nergal-11934-9-1914819404.12345</svTRID> S: </trID> S: </response> S:</epp>

Page 95: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  95 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification de gel d’un nom de domaine

ATTENTION : cette notification est envoyée autant de fois que de domaines gelés.

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="2849"> S: <qDate>2009-05-05T07:52:50.0Z</qDate> S: <msg>Holder qualification status prevents some operations.</msg> S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nic.fr</domain:name> S: <domain:roid>DOM000002018460-FRNIC</domain:roid> S: <domain:status s="serverTransferProhibited"/> S: <domain:registrant>XXX1234</domain:registrant> S: <domain:clID>-rocfisor895-.fr</domain:clID> S: </domain:infData> S: </resData> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:domain> S: <frnic:status s="serverTradeProhibited"/> S: </frnic:domain> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-31789-CLIENT-1241510727</clTRID> S: <svTRID>DEV-photon-31648-2-1241510727.18924</svTRID> S: </trID> S: </response> S:</epp>

Page 96: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  96 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification de blocage d’un nom de domaine

ATTENTION : cette notification est envoyée autant de fois que de domaines bloqués.

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="2849"> S: <qDate>2009-05-05T07:52:50.0Z</qDate> S: <msg>Holder qualification status prevents some operations.</msg> S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nic.fr</domain:name> S: <domain:roid>DOM000002018460-FRNIC</domain:roid> S: <domain:status s="serverHold"/> S: <domain:status s="serverDeleteProhibited"/> S: <domain:status s="serverRestoreProhibited"/> S: <domain:status s="serverUpdateProhibited"/> S: <domain:status s="serverTransferProhibited"/> S: <domain:registrant>XXX1234</domain:registrant> S: <domain:clID>-rocfisor895-.fr</domain:clID> S: </domain:infData> S: </resData> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:domain> S: <frnic:status s="serverTradeProhibited"/> S: </frnic:domain> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-31789-CLIENT-1241510727</clTRID> S: <svTRID>DEV-photon-31648-2-1241510727.18924</svTRID> S: </trID> S: </response> S:</epp>

Page 97: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  97 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification de déblocage de portefeuille

Le nom de domaine passe de serverHold à ok si le déblocage correspond à la fin positive de la procédure de Justification. Le nom de domaine passe de serverHold à serverTransferProhibited + serverTradeProhibited si le déblocage correspond à un retour à l’état de gel (cas exceptionnel). ATTENTION : cette notification est envoyée autant de fois que de domaines.

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue S: </result> S: <msgQ count="15" id="198375"> S: <qDate>2011-11-10T06:42:50.0Z S: <msg>Holder qualification status doesn't prevent operations any longer. S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nomdomaine1.fr S: <domain:roid>DOM000001978303-FRNIC S: <domain:status s="inactive"/> S: <domain:registrant>BVJN1 S: <domain:contact type="admin">BLST1 S: <domain:contact type="tech">BLST1 S: <domain:clID>TEST S: <domain:crDate>2011-11-10T06:42:48.0Z S: <domain:exDate>2012-11-10T00:00:00.0Z S: <domain:upDate>2011-11-10T06:42:48.0Z S: <domain:authInfo> S: <domain:pw>authInfo S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>DOM000001978303-FRNIC S: <svTRID>DEV-photon-2257-3-1320930348.06826 S: </trID> S: </response> S:</epp>

Page 98: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  98 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification de clôture de procédure de Justification avec suppression de portefeuille

La notification de fin de procédure de qualification a déjà été présentée plus haut dans ce chapitre. A celle-ci s'ajoutent les notifications pour les domaines supprimés... ATTENTION : cette notification est envoyée autant de fois que de domaines.

S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="2849"> S: <qDate>2009-05-05T07:52:50.0Z</qDate> S: <msg>Domain deletion after failure in qualification process.</msg> S: </msgQ> S: <resData> S: <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>nomdomaine1.fr</domain:name> S: <domain:roid>DOM000001978303-FRNIC</domain:roid> S: <domain:status s="serverHold"/> S: <domain:status s="pendingDelete"/> S: <domain:registrant>ET1323</domain:registrant> S: <domain:contact type="admin">VL999</domain:contact> S: <domain:contact type="tech">VL666</domain:contact> S: <domain:clID>-wuhgejav499-.fr</domain:clID> S: <domain:authInfo> S: <domain:pw>WarlordZ666</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> S: <rgp:rgpStatus s="pendingDelete"/> S: </rgp:infData> S: </extension> S: <trID> S: <clTRID>FRNIC-31789-CLIENT-1241510727</clTRID> S: <svTRID>DEV-photon-31648-2-1241510727.18924</svTRID> S: </trID> S: </response> S:</epp>

Page 99: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  99 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• Notification de clôture de procédure de Justification positive avec déblocage de portefeuille et mise à jour de base WHOIS

Ce cas correspond à l’émission des notifications déjà présentées plus haut (« Cas où la joignabilité et l’éligibilité ont pu aboutir » et « Notification de déblocage de portefeuille »).

• Suppression d’un contact

S:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="25006"> S: <qDate>2010-02-03T11:37:46.0Z</qDate> S: <msg>Contact deletion completed</msg> S: </msgQ> S: <resData> S: <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <contact:id>BE408</contact:id> S: <contact:roid>BE408-FRNIC</contact:roid> S: <contact:status s="ok"/> S: <contact:postalInfo type="loc"> S: <contact:name>Eponge</contact:name> S: <contact:addr> S: <contact:street>1, rue de la mare</contact:street> S: <contact:city>Paris</contact:city> S: <contact:pc>75001</contact:pc> S: <contact:cc>FR</contact:cc> S: </contact:addr> S: </contact:postalInfo> S: <contact:voice>+33.654321789</contact:voice> S: <contact:email>[email protected]</contact:email> S: <contact:clID>-huqlycuw772-.fr</contact:clID> S: <contact:crID>-huqlycuw772-.fr</contact:crID> S: <contact:crDate>2009-10-21T09:40:34.0Z</contact:crDate> S: <contact:upDate>2009-10-21T09:40:34.0Z</contact:upDate> S: </contact:infData> S: </resData> S: <extension> S: <frnic:ext xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"> S: <frnic:resData> S: <frnic:infData> S: <frnic:contact> S: <frnic:firstName>Bob</frnic:firstName> S: </frnic:contact> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>FRNIC-17859-CLIENT-1267782109</clTRID> S: <svTRID>TEST-kenobi-23883-5-1267782109.19864</svTRID> S: </trID> S: </response> S:</epp>

Page 100: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  100 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

3.7. Codes retours et messages d'erreurs

Bien qu’il soit vivement recommandé de se référer au RFC 4930 qui contient la liste exhaustive de tous les codes retours qui peuvent être envoyés par un serveur EPP suite à une commande d’un client, nous indiquons ci-après ceux qui sont réellement implémentés dans notre serveur. Vous trouverez également la liste des messages d’erreur que le serveur pourra renvoyer lorsque cela sera nécessaire. Autant il est primordial d’interpréter correctement les codes retours, la liste de ceux-ci n’étant pas amenée à évoluer et leur interprétation peu sujette à ambiguïté, autant il est risqué de scripter les messages d’erreur. Ces derniers peuvent évoluer en fonction de nouvelles règles administratives, certains cas peuvent être affinés, par exemple. Ils seront le plus souvent associés à une partie de la requête cliente dont les éléments problématiques seront reproduits dans la réponse du serveur. De plus, même si au moment de la rédaction de ce document, seul l’anglais est disponible comme choix de langue, toute nouvelle langue entrainera la localisation de ceux-ci. Les codes retours, eux, ne sont pas impactés par ce « problème ». Voici un exemple de message retourné par le serveur suite à une commande qui comporte une erreur :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="2306"> S: <msg>Parameter value policy error</msg> S: <extValue> S: <value xmlns:dmn="urn:ietf:params:xml:ns:domain-1.0"> S: <dmn:name>dom-epp-defquruz-xucmexip.com</dmn:name> S: </value> S: <reason>not an AFNIC zone</reason> S: </extValue> S: </result> S: <msgQ count="3" id="28980"/> S: <trID> S: <clTRID>FRNIC-11642-CLIENT-1254846489</clTRID> S: <svTRID>DEV-photon-11442-17-1254846489.34186</svTRID> S: </trID> S: </response> S:</epp>

3.7.1. Les codes retour

Les codes retours (élément <result code="xyzz">) répondent à une logique et sont codés sur 4 chiffres. Un souci d’EPP est que la liste de ceux-ci est fixe et non extensible. Bien qu’il eu été possible d’utiliser un code retour générique et d’ajouter de nouveau codes dans l’extension AFNIC, nous avons fait le choix de faire une entorse au standard et d’ajouter 3 nouveaux codes à la liste de ceux déjà existant. La logique des codes a aussi été respectée. Pour reconnaître les codes ajoutés, il suffit de se rappeler que le troisième chiffre en partant de la gauche sera toujours le 9 (<result code="xy9z">).

Page 101: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  101 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Vous trouverez aussi dans le RFC 4930 les valeurs littérales associées à ces codes et qui sont renvoyées dans l’élément <msg>. Si le serveur devait être localisé, une traduction correspondante devra être proposée, le sens des intitulés sera toutefois conservé au plus près. La « série des 1000 » correspond aux codes retournés lorsque l’opération demandée par le client a put être prise en compte.

• 1000 : C’est le code retour normal d’une commande qui a été normalement et complètement exécutée et qui n’entre pas dans un cas prévu par un autre code retour de cette série.

• 1001 : Ce code indique que la commande a été prise en compte mais que son exécution complète est remise à plus tard. Le résultat final de celle-ci sera connu plus tard et sera envoyé dans un message placé dans la file de notification du ou des bureaux d’enregistrement concernés par cette opération. Le nombre de commande pour lesquelles ce code sera retourné systématiquement est limité mais il sera également utilisé lorsque pour une raison inhabituelle, le serveur devait remettre à plus tard l’exécution d’une commande renvoyant normalement un code 1000.

• 1300 : Ce code retour est réservé à l’usage de la commande <poll> (en mode interrogation) et indique qu’il n’y a aucun message en attente.

• 1301 : Ce code retour est aussi réservé à la commande <poll> et sera utilisé pour indiquer qu’il y a un message dans la réponse du serveur et que celui-ci est prêt à être supprimé de la file de message.

• 1500 : Ce code retour sera utilisé pour répondre à une demande de déconnexion (<logout>) qui s’est passée avec succès.

La « série des 2000 » correspond aux codes retournés lorsqu’un problème a été rencontré et que la commande n’a pu être normalement prise en compte.

• 2000 : Code retourné lorsque la commande envoyée est inconnue • 2001 : Code retourné lorsqu’une erreur de syntaxe est rencontrée. • 2002 : Code retournée lorsque la commande reçue, bien que correcte

syntaxiquement, ne peut pas être interprétée car hors contexte. Par exemple, une commande de déconnexion reçue alors même que le client n’a pas terminé la phase de connexion…

• 2003 : Code retourné lorsqu’il manque un paramètre à caractère obligatoire dans une commande. Par exemple, une commande <transfer op="query"> pour laquelle l’élément <authInfo> serait omis…

• 2004 : Code retourné lorsque la valeur d’un élément n’est pas dans les limites spécifiées par le protocole EPP. Par exemple, essayer de créer le nom de domaine "-trop-de-tirets- -et-d-espaces-.fr" renverra ce type d’erreur.

• 2101 : Ce code sera retourné lorsque le serveur recevra une commande qui est correcte d’un point de vue EPP mais qui n’est pas présente dans notre implémentation. Par exemple la commande <contact:transfer>.

• 2102 : Ce code est retourné lorsque pour une commande implémentée par notre serveur le client précise une option qui n’est pas prise en compte.

Page 102: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  102 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• 2103 : Ce code est retourné si le client envoie une commande avec une extension qui n’est pas connue par le serveur.

• 2106 : Code retourné lorsqu’une commande <domain:transfer> est réalisée sur un nom de domaine pour lequel ce n’est pas possible. Par exemple, si la demande provient du bureau d’enregistrement qui assure déjà la gestion de ce nom de domaine.

• 2190 : Code retour similaire au 2106 mais dans le cas d’une commande <trade>. (Code ajouté pour nos besoins, il n’est pas défini dans le standard EPP).

• 2200 : Code retourné lors de la vérification du login/password dans la phase de connexion au serveur EPP.

• 2201 : Code retourné lors d’une tentative d’exécution d’une commande pour lequel le bureau d’enregistrement n’a pas les droits. Par exemple, un bureau qui tenterait d’envoyer une commande "cancel" sur un nom de domaine en partance suite à une opération de transfer.

• 2202 : Code retourné lorsque le bureau d’enregistrement qui demande l’exécution d’une commande aurait pu le faire s’il avait fourni les autorisations correctes. Typiquement, ce code sera utilisé pour une demande de transfer de nom de domaine lorsque le mot de passe fourni (<authInfo>) n’est pas correct.

• 2300 : Code retourné lorsque qu’une commande de transfer de nom de domaine est envoyée et que le domaine en question est déjà en cours de transfer.

• 2304 : Code retourné lorsque l’état d’un objet n’est pas compatible avec la commande qui est envoyée au serveur. Par exemple, dans le cas de l’envoi d’une commande de mise à jour technique d’un nom de domaine alors que celui-ci est dans l’état « supprimé » et en période de rédemption.

• 2305 : Code retourné lorsque l’exécution d’une commande ne peut pas aboutir car des relations avec d’autres objets de la base l’empêchent. Par exemple, lors d’une demande de suppression d’un nom de domaine alors qu’il existe encore des noms de serveurs, dans cette zone, utilisés pour d’autres noms de domaine administré par l’AFNIC.

• 2306 : Code retourné lorsque la valeur d’un élément est syntaxiquement correcte d’un point de vue EPP mais qui ne respecte pas une règle spécifique à l’AFNIC. La plupart du temps cette erreur sera accompagnée, non seulement de l’élément problématique mais d’un message indiquant qu’elle règle pose problème. Il peut arriver que ce message d’erreur ne soit pas présent, ce code étant utilisé comme valeur par défaut. Un cas ou ce code pourra être retourné, c’est par exemple lorsqu’un contact de type personne physique avec des données d’état-civil (un titulaire potentiel de nom de domaine) sera utilisé comme contact technique dans une commande.

• 2390 : Ce code est retourné lorsqu’une commande <trade> est envoyée et que le nom de domaine en question est déjà en transmission.

• 2391 : Ce code est retourné lorsqu’une commande d’annulation de <trade> ou de demande d’information sur un <trade> est reçue alors qu’il n’y a pas de <trade> en cours pour ce nom de domaine.

• 2400 : Code retourné lorsqu’un problème interne empêche le bon déroulement d’une commande. Normalement ce code ne doit pas être

Page 103: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  103 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

envoyé souvent, sa présence indique qu’il y a des problèmes sur notre chaîne d’enregistrement. Quelque soit le cas, il peut être judicieux d’avertir les services support de l’AFNIC lorsque ce cas se produit.

• 2500 : Code retourné dans un cas similaire au code 2400. Mais dans ce cas le serveur décide de clore la session. Ce cas aussi ne doit pas se présenter souvent.

• 2501 : Ce code est retourné si la phase de <login> ne peut aboutir. • 2502 : Ce code sera retourné si, dans le cas où le nombre de sessions

était limité par bureau d’enregistrement, cette limite était déjà atteinte lorsqu’une nouvelle commande <login> est envoyée.

3.7.2. Les messages d’erreurs

La liste de messages reproduite ci-après correspond à ce qui sera indiqué dans l’élément de la réponse du serveur <reason>. Contrairement au contenu de l’élément <msg> dont la liste définitive peut-être trouvée dans le RFC 4930, cette liste peut être amenée à évoluer. Certains cas pouvant être affinés, d’autres disparaître en fonction des évolutions des politiques d’enregistrement par exemple. Pour le moment, seule une version en langue anglaise existe pour ces messages. Ils pourront à l’avenir être localisés au même titre que le reste du serveur EPP. La première liste va concerner les erreurs qui pourront être rencontrées lors d’opération sur les noms de domaines.

• « not an AFNIC zone » • « zone is not opened for registration » • « domain name in use » • « domain name doesn't exist » • « domain name in use (deletion process) » • « domain name in use (deletion process, waiting for purge) » • « bad syntax » • « registry bad syntax » • « forbidden Name » • « city name (AFNIC authinfo mandatory) » • « special request (AFNIC authinfo mandatory) » • « protected Sub Level Domain (AFNIC authinfo mandatory) » • « protected label syntax (AFNIC authinfo mandatory) » • « no operation allowed on this domain name » • « authinfo value is not correct » • « authinfo/holder/registrar/domain relationship is invalid » • « legal entity infos seems to be incorrect » • « there are still subordinate hosts » • « registrant is not a sponsored contact » • « registrant is not a "physical person" » • « registrant seems to have a bad birth date » • « registrant seems to be under 18 » • « registrant seems to be too old » • « identification data problem »

Page 104: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  104 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• « registrant is obsoleted » • « admin contact has no E-Mail address » • « admin contact has no phone number » • « admin contact is not a sponsored contact » • « admin contact doesn't exist » • « admin contact is obsoleted » • « tech contact doesn't exist » • « tech contact is not a sponsored contact » • « potential holder physical person contact can't be used as a tech

contact » • « other operation in progress » • « glue is needed for this name server » • « holder identification problem prevents it's usage » • « holder identification problem prevents operation » • « legal issue prevents operation » • « pending request prevents operation » • « mandatory admin or technical contact is missing » • « similar domain name already exists » • « domain name MUST have, at least, TWO different name servers » • « domain name MUST have either 0 or, at least, TWO different name

servers »

La seconde liste va concerner les erreurs qui pourront être rencontrées lors d’opération sur les contacts.

• « country code is illegal » • « country code is undefined » • « street is illegal » • « street is undefined » • « post code is illegal » • « post code is undefined » • « city is illegal » • « city is undefined » • « city cedex is illegal for this country » • « city cedex is illegal » • « birth place geographical check failure » • « non-profit announcePage mandatory if publishedDate present » • « non-profit publishedDate mandatory if announcePage present » • « can't update contact disclosure restriction for legal entitie holders » • « can't update contact disclosure restriction for tech class » • « can't update contact country code for tech class » • « can't update phone number » • « 'legalStatus' value is illegal » • « phone number is illegal » • « fax number is illegal » • « bogus organization contact without extended data. Should not exist.

Must not be used in operations » • « waldec ID prohibited if 'legalStatus' is set to 'company' » • « non-profit publishedDate prohibited if 'legalStatus' is set to

'company' »

Page 105: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  105 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

• « 'siren' or 'trademark' element missing while it's mandatory » • « 'trademark' element value seems to be syntaxically incorrect according

AFNIC rules » • « role objects can't be updated through EPP interface » • « 'siren' element value seems to be syntaxically incorrect according

AFNIC rules » • « contact handle is illegal » • « registrant doesn't exist »

3.8.RFCs

Nous rappelons ci-dessous les RFCs à lire impérativement et sur lesquelles est basée notre implémentation EPP :

RFC 3375 - Generic Registry-Registrar Protocol Requirements : http://www.ietf.org/rfc/rfc3375.txt

RFC 5730 – Extensible Provisioning Protocol (EPP) : http://www.ietf.org/rfc/rfc5730.txt

RFC 5731 - Domain Name Mapping : http://www.ietf.org/rfc/rfc5731.txt RFC 5732 – Host Mapping : http://www.ietf.org/rfc/rfc5732.txt RFC 5733 – Contact Mapping : http://www.ietf.org/rfc/rfc5733.txt RFC 5734 - EPP over TCP : http://www.ietf.org/rfc/rfc5734.txt RFC 3915 - Domain Registry Grace Period mapping :

http://www.ietf.org/rfc/rfc3915.txt RFC 5910 - Domain Name System (DNS) Security Extensions Mapping :

http://www.ietf.org/rfc/rfc5910.txt

Page 106: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  106 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

4. Interface Web : le système de tickets

4.1. Généralités sur les tickets

L’ensemble des opérations effectuées sur les domaines via l’interface web et entraînant une opération asynchrone (update[tech], delete, trade, transfer) peut-être suivi par un système de tickets et de messages d’information envoyés par mail. Dans le système d’information interne de l’AFNIC, un ticket est émis dès lors qu’une demande reçue via l’interface web est considérée comme valide. Un système d’état permet de suivre l’évolution et le traitement de l’opération.

4.2. Format du ticket

Un ticket porte un numéro de la forme NIC0000000xxxxx/xxxxxx. Il possède systématiquement les champs DOMAINE=XXX, TICKET=numéro du

ticket,OPERATION=XXX et ETAT=XXX.

D’autres champs peuvent apparaître suivant les opérations.

4.3. Description de l’ensemble des tickets

Opération S : Suppression d’un domaine S États existants : Fini

S - Fini

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC00001234567] To: noc [Texte introductif] DOMAINE=nom-de-domaine-concerne.fr OPERATION=Suppression ETAT=Fini TICKET=NIC00001234567/751825 FORMULAIRE=4869407 REFERENCE= NUMEROSEQUENCE=2 [Texte conclusif]

Page 107: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  107 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Opération T : Modification technique d’un domaine T États existants : Abandonné, Fini

T - Fini

From: [email protected] Subject: Re: FR-NIC, nom-de-domaine-concerne.fr: Formulaire Online [1234567] T To: noc | Infos sur l'opération et le bureau d'enregistrement | 1a. (C)réation (D)élégation (S)uppression.........: T | 1b. Code du bureau d'enregistrement...............: CODEBE | 1c. Mot de passe du bureau d'enregistrement.......: xxxxxxxx | 1e. Référence client..............................: refclient | 1f. Version formulaire............................: 2.5.0 | | Infos sur le nom de domaine | 2a. Nom de domaine complet........................: nom-de-domaine-concerne.fr | [../..] | Serveur de nom primaire pour le domaine | 6a. Serveur primaire..............................: ns.exemple.fr | 6b. Adresse(s) IP du primaire.....................: | | Serveur(s) de nom secondaire pour le domaine | 7a. Serveur secondaire............................: nt.exemple.fr | 7b. Adresse(s) IP du secondaire...................: | 7c. Serveur secondaire............................: | 7d. Adresse(s) IP du secondaire...................: | 7e. Serveur secondaire............................: | 7f. Adresse(s) IP du secondaire...................: | 7g. Serveur secondaire............................: | 7h. Adresse(s) IP du secondaire...................: | 7j. Adresse(s) IP du secondaire...................: | 7k. Serveur secondaire............................: | 7l. Adresse(s) IP du secondaire...................: | 7m. Serveur secondaire............................: | 7n. Adresse(s) IP du secondaire...................: Bonjour, ZONE : nom-de-domaine-concerne.fr NS : ns.exemple.fr NS : nt.exemple.fr ==> SUCCESS [Texte conclusif]

Page 108: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  108 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

T - Abandonné

From: [email protected] Subject: Re: FR-NIC, nom-de-domaine-concerne.fr: Formulaire Online [1234567] T To: noc | Infos sur l'opération et le bureau d'enregistrement | 1a. (C)réation (D)élégation (S)uppression.........: T | 1b. Code du bureau d'enregistrement...............: CODEBE | 1c. Mot de passe du bureau d'enregistrement.......: xxxxxxxx | 1e. Référence client..............................: refclient | | Infos sur le nom de domaine | 2a. Nom de domaine complet........................: nom-de-domaine-concerne.fr | [../..] | Serveur de nom primaire pour le domaine | 6a. Serveur primaire..............................: ns.exemple.fr | 6b. Adresse(s) IP du primaire.....................: | | Serveur(s) de nom secondaire pour le domaine | 7a. Serveur secondaire............................: nt.exemple.fr | 7b. Adresse(s) IP du secondaire...................: | 7c. Serveur secondaire............................: | 7d. Adresse(s) IP du secondaire...................: | 7e. Serveur secondaire............................: | 7f. Adresse(s) IP du secondaire...................: | 7g. Serveur secondaire............................: | 7h. Adresse(s) IP du secondaire...................: | 7i. Serveur secondaire............................: | 7j. Adresse(s) IP du secondaire...................: | 7k. Serveur secondaire............................: | 7l. Adresse(s) IP du secondaire...................: | 7m. Serveur secondaire............................: | 7n. Adresse(s) IP du secondaire...................: | Bonjour, Le zone-check ne passe pas : f> Toutes les adresses IP doivent être distinctes | Conseil: ZoneCheck | To avoid losing all connectivity with the autoritative DNS in case of | network outage it is advised to host the DNS on different networks. | | Réf: IETF RFC2182 (Abstract) | The Domain Name System requires that multiple servers exist for every | delegated domain (zone). This document discusses the selection of | secondary servers for DNS zones. Both the physical and topological | location of each server are material considerations when selecting | secondary servers. The number of servers appropriate for a zone is also | discussed, and some general secondary server maintenance issues | considered. `----- -- -- - - - : Les serveurs de noms ns.exemple.fr., nt.exemple.fr. : utilisent la même adresse IP (10.0.0.1). `..... .. .. . . . => générique ==> ÉCHEC Veuillez donc : - Verifier votre nouvelle configuration avec zone-check Pour cela vous pouvez utiliser sur l'url suivante http://www.afnic.fr/outils/zonecheck/zc.cgi?afnic&intro=t&explain=t&details=t&progress=counter&zone=nom-de-domaine-concerne.fr&ns0=ns.exemple.fr&ns1=nt.exemple.fr - REFAIRE une demande de modification (via le formulaire on-line ou via mel a l'adresse [email protected]) [Texte conclusif]

Page 109: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  109 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Opération P : Transmission volontaire P États existants : Attente Mail, Abandonné, Fini

From: NIC France Formulaire Online <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Transmission demandee / Transmission requested To: titulaire entrant [English version below] Madame, Monsieur, Nous vous informons que nous avons reçu une demande de transmission du nom de domaine 'nom-de-domaine-concerne.fr', de Titulaire-sortant vers Titulaire-entrant. Il semble que vous demandez à devenir le nouveau titulaire de ce nom de domaine. Afin d'accepter ou refuser cette transmission, veuillez cliquer l'un des liens suivants. ------------------------------------------------------------------------------- ATTENTION: une fois que vous aurez cliqué sur un lien, vous ne pourrez pas modifier votre réponse ! ------------------------------------------------------------------------------- - Acceptez cette transmission: http://... - Refusez cette transmission: http://... Faute de réponse avant 15 jours, la demande sera abandonnée. [...]

From: NIC France Formulaire Online <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Transmission demandee / Transmission requested To: titulaire sortant [English version below] Madame, Monsieur, Nous vous informons que nous avons reçu une demande de transmission du nom de domaine 'nom-de-domaine-concerne.fr', de Titulaire-sortant vers Titulaire-entrant. Il semble que vous soyez l'actuel titulaire de ce nom de domaine. Afin d'accepter ou refuser cette transmission, veuillez cliquer l'un des liens suivants. ------------------------------------------------------------------------------- ATTENTION: une fois que vous aurez cliqué sur un lien, vous ne pourrez pas modifier votre réponse !

Page 110: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  110 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

------------------------------------------------------------------------------- - Acceptez cette transmission: http://... - Refusez cette transmission: http://... Faute de réponse avant 15 jours, la demande sera abandonnée. [...]

P – Attente Mail

From: C France Tickets <[email protected]> NISubject: FR-NIC, nom-de-domaine-concerne.fr: Attente Mail [NIC000012345678] To: noc [Texte introductif] DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Attente Mail TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=1 La transmission demandée est en 'Attente Mail'.

P – Abandonné

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Abandonne [NIC000012345678] To: noc Système de gestion des tickets : (Documentation = <URL: http://www.afnic.fr/doc/interface/tickets >) DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Abandonne TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=2 Opération abandonnée. Expiration Delai 15 jours

Page 111: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  111 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

P - Fini

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC000012345678] To: noc Système de gestion des tickets : (Documentation = <URL: http://www.afnic.fr/doc/interface/tickets >) DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Fini TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=3 AUTH_INFO=XXXXX-111116ZZZZZ-00000 TITU_NH=ABC123-FRNIC TITU_KEY=ABCDEF-123 [email protected] [Texte conclusif]

Opération P : Transmission forcée P États existants : Attente Vérification, Fini

P - Fini

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC000012345678] To: noc Système de gestion des tickets : (Documentation = <URL: http://www.afnic.fr/doc/interface/tickets >) DOMAINE=nom-de-domaine-concerne.fr OPERATION=Transmission ETAT=Fini TICKET=NIC000012345678/123456 FORMULAIRE=1234567 REFERENCE=REFCLIENT NUMEROSEQUENCE=2 AUTH_INFO=XXXXX-111116ZZZZZ-00000 TITU_NH=ABC123-FRNIC TITU_KEY=ABCDEF-123 [email protected] Opération effectuée. [Texte conclusif]

Page 112: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  112 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Opération D : Changement de bureau d'enregistrement D États existants : Attente Opposition, Attente Accord, Abandonne,

Attente Verification, Fini

D – Attente Opposition

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Attente Opposition To: noc bureau d’enregistrement entrant Madame, Monsieur, Une demande de résiliation a été envoyée à l'ancien prestataire (AFNIC registry). Un délai de 8 jours lui est accordé, pour s'opposer à cette opération. En cas de réponse favorable, ou faute de réponse à cette date, la délégation sera transférée. En cas de réponse négative, le délai initial sera porte à 22 jours. Nous vous rappelons qu'il est du devoir de votre client d'informer son ancien prestataire de sa volonté de résilier la gestion de son domaine. Ceci doit être fait par lettre recommandée avec accusé de réception. Dans l'intéret de tous et pour accélérer la procédure, nous vous demandons de le rappeler à votre client. [Texte conclusif]

D – Attente Opposition

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne: Attente Opposition To: noc bureau d’enregistrement sortant Madame, Monsieur, Nous vous envoyons ce message pour vous signaler que nous avons reçu une demande de changement de prestataire sur le domaine : DOMAINE=nom-de-domaine-concerne.fr OPERATION=Changement P ETAT=Attente Opposition Il semble que ce soit votre Société (AFNIC registry) qui ait actuellement la gestion de ce domaine. En cas d'accord, veuillez renvoyer ce message à [email protected] en ne conservant que les lignes suivantes : [-------------------------------------------------------------------] AUTH=71C60595D551E2C3 ACTION=ACCORD

Page 113: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  113 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

[-------------------------------------------------------------------] Ou en cas de désaccord, veuillez renvoyer ce message à [email protected] avant le 20/11/2009 en ne conservant que les lignes suivantes : [-------------------------------------------------------------------] AUTH=71C60595D551E2C3 ACTION=OPPOSITION [-------------------------------------------------------------------] Faute de réponse dans les 8 jours suivant la saisie, la délégation sera transférée. [Texte conclusif]

D – Fini

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Fini [NIC00001234567] To: noc bureau d’enregistrement entrant [Texte introductif] DOMAINE=nom-de-domaine-concerne.fr OPERATION=Changement P ETAT=Fini TICKET=NIC00001234567/484934 FORMULAIRE=4869185 REFERENCE= NUMEROSEQUENCE=3

From: NIC France Tickets <[email protected]> Subject: FR-NIC, nom-de-domaine-concerne.fr: Delegation Resiliee To: noc bureau d’enregistrement sortant Madame, Monsieur, Nous venons de changer la délégation du domaine nom-de-domaine-concerne.fr au profit d'un nouveau prestataire. Pour que ce changement de délegation se déroule dans de bonnes conditions, nous vous demandons de rester "secondaire non officiel" le temps nécessaire à la propagation des nouvelles informations (au moins 5 jours). Si vos serveurs de nom étaient autoritaires pour le domaine sus-cité (en primaire ou secondaire), nous vous demandons de vous déclarer secondaire pour le domaine concerné et d'indiquer la machine [BUG] (DNS=[BUG] ) comme origine.

Page 114: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  114 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

5. Les opérations gérables uniquement par mail/fax

Pour les situations nécessitant une réponse mail ou fax, un mail émis de l’adresse [email protected] est émis en plus de la notification informative.

5.1. Génération de code d’autorisation

Notification de l'abandon d'une demande de code d'autorisation :

From: [email protected] Subject: AFNIC - Notification d'abandon de la demande de generation de code pour ${domaine} To: noc Bonjour, L'AFNIC vous informe que la demande de generation de code pour le titulaire ${titulaire.prenom} ${titulaire.nom} pour le nom de domaine ${domaine} a été abandonné à votre demande. Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC

Notification du rejet d'une demande de code d'autorisation :

From: [email protected] Subject: AFNIC - Notification de rejet de la demande de generation de code pour ${domaine} To : noc Bonjour, L'AFNIC vous informe que la demande de generation de code d'autorisation pour le titulaire ${titulaire.prenom} ${titulaire.nom} pour le nom de domaine ${domaine} a été rejeté pour la raison suivante: ${commentaire} Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC

Notification de génération d'un code d'autorisation :

From: [email protected] Subject: AFNIC - Notification de generation de code d'autorisation pour ${domaine} To : noc Bonjour, L'AFNIC vous informe que la demande de generation de code pour le titulaire ${titulaire.prenom} ${titulaire.nom}

Page 115: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  115 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

pour le nom de domaine ${domaine} a été acceptée. Votre code d'autorisation est : ${code} Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC

5.2. Validation de trade

Notification d'une annulation de validation de trade par fax :

From : [email protected] Subject: AFNIC - Notification d'abandon de la demande de trade sur ${domaine} To : noc Bonjour, L'AFNIC vous informe que le ticket ${ticket.id} concernant le trade du domaine ${domaine} a été abandonné. Nous restons à votre disposition pour tout autre renseignement. Cordialement, L'équipe Gestion des Domaines AFNIC

5.3. Notification de suivi de la procédure de qualification

En parallèle des notifications EPP, des notifications mails sont envoyées pour les bureaux d'enregistrement n’utilisant pas EPP. Format des notifications mail pour le lancement du processus de qualification :

From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=start To: noc [Texte introductif] HOLDER=ET1323-FRNIC STATUS=start [Texte conclusif]

Format de la notification mail pour la clôture du processus de qualification :

From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=finished To: noc [Texte introductif] HOLDER=ET1323-FRNIC STATUS= finished ELIG=valeur_de_l_identifiant ou KO

Page 116: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  116 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

REACH=valeur_du_media_joignable (EMAIL/PHONE) [...] [Texte conclusif]

Format de la notification mail pour un passage en statut « problem » :

From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=problem To: noc [Texte introductif] HOLDER=ET1323-FRNIC STATUS=problem [Texte conclusif]

5.4. Notification de gel, blocage et suppression du portefeuille de domaines

Comme explicité précédemment, dès qu’un dossier rentre en procédure de demande de pièce justificative, les domaines associés à ce portefeuille sont alors gelés. Si un dossier ne trouve aucune issue positive dans le premier mois qui suit le passage en gel, les domaines associés au titulaire sont alors bloqués. Si un dossier ne trouve aucune issue positive dans le premier mois qui suit le passage en blocage, les domaines associés au titulaire sont alors supprimés. Dans le cas du gel/blocage/suppression de portefeuille, un mail de notification est envoyé au bureau d’enregistrement ainsi qu’au titulaire des domaines concernés. Format des notifications mail pour le gel/blocage/suppression d’un portefeuille de noms de domaine :

From: AFNIC <[email protected]> Subject: AFNIC - Qualification ET1323-FRNIC – Gel/Blocage/Suppression de portefeuille de domaines To: noc [Texte introductif] HOLDER=ET1323-FRNIC STATUS=problem DOMAIN=nomdedomaine1.fr DOMAIN=nomdedomaine2.fr [...] [Texte conclusif]

Page 117: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  117 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

5.5. Mail de Justification

Que le bureau d’enregistrement travaille en EPP ou en mail, en cas de procédure de Justification, un mail est émis par [email protected] afin de demander un complément d’information permettant de résoudre le problème.

Page 118: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  118 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

6. Service DAS (Domain Availability Service)

Le service de vérification de disponibilité de nom de domaine DAS (Domain Availability Service) est à privilégier à la commande EPP <check>. Ce service s'appuie sur un standard dont les spécifications techniques peuvent être trouvées dans :

le RFC 5144 (A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)) pour une description des structures de données mises en oeuvre,

le (A Lightweight UDP Transfer Protocol for the Internet Registry Information Service) pour une desription du protocole de transport.

6.1. Paramètres pour interroger le service

en production, le nom du serveur et le numéro du port ne sont pas nécessaires grâce à la découverte automatique. Ex : dchk afnic.fr

sur le banc de test, il est nécessaire d'indiquer le serveur de test : dchk.test.nic.fr ainsi que le numéro de port : 715 Ex : dchk -h dchk.test.nic.fr -p 715 nic.fr

6.2. Les informations disponibles

6.2.1. Validité du nom de domaine testé

Les premiers tests réalisés concernent la validité du nom de domaine. Un code d'erreur spécifique sera retourné dès lors que la syntaxe du nom n'est pas correcte, que ce soit par la présence de caractères interdits ou par le fait d'une règle spécifique à l'AFNIC (noms de domaines avec une seule lettre par exemple).

6.2.2. Disponibilité du nom de domaine

C'est la fonction première de ce service. Dès lors que la réponse est "nameNotFound", le bureau d'enregistrement a la certitude absolue que le nom de domaine peut être déposé et ne fera l'objet d'aucune restriction particulière à l'enregistrement. De plus, dans le cas d'un nom de domaine existant, les états "redemptionPeriod" et "delete" indiquent respectivement que le nom de domaine est en cours de période rédemption après une opération de suppression pour le premier et que le nom de domaine va être détruit dans l'heure pour le second (période de rédemption terminée en attente du Garbage Collector).

Page 119: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  119 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

6.2.3. État de la publication DNS

Lorsqu'un nom de domaine existe dans le registre, le service discrimine le fait que le nom de domaine est publié ou non dans le DNS. Si l'état "active" est renvoyé pour un nom de domaine, cela signifie qu'il existe et qu'il est publié dans le DNS. L'état "inactive" indique, quant à lui, que le domaine existe mais qu'il n'est pas publié dans le DNS. Attention toutefois, les zones DNS ne sont mises à jour qu'une fois par heure, et pendant ce laps de temps, un nom de domaine dans l'état "active" peut ne pas encore avoir été publié et donc ne pas être trouvé suite à une requête DNS.

6.2.4. Informations sur les restrictions liées à ce nom de domaine

Qu'il soit enregistré ou non, un nom de domaine peut être sujet à certaines limitations à l'enregistrement. Certaines sont irrévocables, d'autres nécessitent des codes d'autorisation. Dans ces deux cas, nous avons été obligé d'introduire des "sous-états" spécifiques à l'AFNIC afin d'apporter plus de précision dans les informations retournées.

Noms de domaines réservés (état "reserved") pour lesquels une procédure avec code d'autorisation est nécessaire. o "city" indique que le nom est réservé pour une commune. o "special"/"sld"/"protectedLabel" relèvent de cadres juridiques

spécifiques.

Autre type de restriction (état "policyNonCompliant") o "forbidden" indique que le nom ne pourra jamais être enregistré. o "equivalentExists" indique qu'un nom de domaine avec le même

label existe déjà dans la zone.

6.2.5. Des dates clés sur des domaines existants

Jusqu'à trois dates peuvent être retournées pour un nom de domaine donné :

o La date de création (createdDateTime) du nom de domaine, o La date de dernière modification (lastDatabaseUpdateDateTime) o la date d'expiration du nom de domaine (expirationDateTime)

Il est important de noter que par soucis de cohérence, nous utilisons exactement le même format de date que pour le serveur EPP. Les dates sont au format UTC.

6.3. DAS et IDN

La prise en compte des IDNs est partie intégrante du protocole DAS existant à l'AFNIC, à savoir IRIS:DCHK (RFC 5144), en revanche ce protocole fait référence à la norme IDNA2003. Dans celle mise en œuvre à l'AFNIC (IDNA2008), l'étape NamePrep n'existe plus. Toutefois, comme nous avons pu l'indiquer dans le paragraphe consacré à IDN, compte tenu de l'alphabet utilisé et pour être cohérent

Page 120: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  120 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

avec nos autres interfaces et les usages actuellement en vigueur à l'AFNIC, nous acceptons aussi les majuscules en entrée. Il est possible d'interroger un IDN sous sa forme ASCII ou sa forme Unicode, par contre l'attribut 'entityClass' de l'élément <lookupEntity> ne sera pas le même. Dans le cas d'une forme ASCII, il faut indiquer "domain-name", dans le cas d'une forme Unicode, il faut indiquer "idn". Ceci n'est aucunement une spécificité AFNIC, si le code client respecte le RFC, il n'y a aucun changement à prévoir. La réponse, dans le cas où l'on interroge un IDN contient un élément supplémentaire, à savoir <idn> contenant la version Unicode du nom de domaine. En revanche, contrairement au nom de domaine en entrée, seuls les 67 caractères indiqués au § 2. IDN sont utilisés en sortie (pas de majuscules). L'élément <domainName> de la réponse contient toujours la forme ASCII du nom de domaine. Les valeurs des attributs 'entityClass' et 'entityName' de la réponse sont quant à eux identiques à celles de la requête.

6.4. Exemples

6.4.1. Nom de domaine qui n'existe pas et qui ne fait l'objet d'aucune restriction

Requête : > dchk nic007.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic007.fr"/> </iris1:searchSet> </iris1:request>

Réponse : nic007.fr: free <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer/> <iris:nameNotFound/> </iris:resultSet> </iris:response>

Page 121: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  121 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

6.4.2. Nom de domaine soumis à examen préalable

Requête : > dchk nazis.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nazis.fr"/> </iris1:searchSet> </iris1:request>

Réponse : nazis.fr: policyNoncompliant <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="nazis.fr"> <domainName>nazis.fr</domainName>lastDatabaseUpdateDateTime <status> <policyNoncompliant> <subStatus authority="fr">forbidden</subStatus> <description language="en">Legal issue</description> </policyNoncompliant> </status> </domain> </iris:answer> </iris:resultSet> </iris:response>

6.4.3. Nom de domaine fantaisiste

Requête : > dchk nic_france.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic_france.fr"/> </iris1:searchSet> </iris1:request>

Réponse : nic_france.fr: invalid <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer/> <iris:invalidName/> </iris:resultSet> </iris:response>

Page 122: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  122 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

6.4.4. Nom de domaine qui existe et qui ne fait l'objet d'aucune restriction

Requête : > dchk nic.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic.fr"/> </iris1:searchSet> </iris1:request>

Réponse : nic.fr: active [2011-01-21T22:24:31.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="nic.fr"> <domainName>nic.fr</domainName> <status> <active/> </status> <createdDateTime>1994-12-31T23:00:00.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2011-01-21T22:24:31.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response>

6.4.5. Nom de domaine qui est supprimé et en période de rédemption

Requête : > dchk ouais-okay-super.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="ouais-okay-super.fr"/> </iris1:searchSet> </iris1:request>

Page 123: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  123 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Réponse : ouais-okay-super.fr: redemptionPeriod [2011-04-04T09:21:04.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="ouais-okay-super.fr"> <domainName>ouais-okay-super.fr</domainName> <status> <inactive/> <redemptionPeriod/> </status> <createdDateTime>2010-03-03T16:35:07.0Z</createdDateTime> <expirationDateTime>2011-05-04T09:21:04.0Z</expirationDateTime> <lastDatabaseUpdateDateTime>2011-04-04T09:21:04.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet>

6.4.6. Nom de domaine qui existe mais qui est aussi un terme soumis à examen préalable

Requête : > dchk paris.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="paris.fr"/> </iris1:searchSet> </iris1:request>

Réponse : paris.fr: reserved [2006-10-05T15:58:33.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="paris.fr"> <domainName>paris.fr</domainName> <status> <active/> <reserved> <subStatus authority="fr">city</subStatus> <description language="en">City name</description> </reserved> </status> <createdDateTime>2001-07-11T22:00:00.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2006-10-05T15:58:33.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response>

Page 124: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  124 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

6.4.7. Requête sur différents noms de domaine aux propriétés différentes

Requête : > dchk nic007.fr afnic.fr --nic--.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="nic007.fr"/> </iris1:searchSet> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="afnic.fr"/> </iris1:searchSet> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName="--nic--.fr"/> </iris1:searchSet> </iris1:request>

Réponse : nic007.fr: free afnic.fr: active [2009-11-09T15:47:45.0Z] --nic--.fr: invalid] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer/> <iris:nameNotFound/> </iris:resultSet> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName="afnic.fr"> <domainName>afnic.fr</domainName> <status> <active/> </status> <createdDateTime>2001-12-10T23:00:00.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2009-11-09T15:47:45.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> <iris:resultSet> <iris:answer/> <iris:invalidName/> </iris:resultSet> </iris:response>

Page 125: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  125 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

6.4.8. Interrogation d'un IDN sous sa forme Unicode

Requête : > dchk àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="idn" entityName="àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr"/> </iris1:searchSet> </iris1:request>

Réponse : àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr: active [2012-01-20T13:16:24.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="idn" entityName=" àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr"> <domainName> xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr </domainName> <idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn> <status> <active/> </status> <createdDateTime>2012-01-20T13:16:24.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2012-01-20T13:16:24.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response>

6.4.9. Interrogation d'un IDN sous sa forme ACE

Requête : > dchk xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr <?xml version="1.0" encoding="UTF-8"?> <iris1:request xmlns:iris1="urn:ietf:params:xml:ns:iris1"> <iris1:searchSet> <iris1:lookupEntity registryType="dchk1" entityClass="domain-name" entityName=" xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr"/> </iris1:searchSet> </iris1:request>

Page 126: Afnic Guide Integration Technique PDF

GUIDE D’INTÉGRATION TECHNIQUE – 3 juillet 2012  126 

Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]

Twitter : @AFNIC | Facebook : afnic.fr

Réponse : xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr: active [2012-01-20T13:16:24.0Z] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> <iris:resultSet> <iris:answer> <domain xmlns="urn:ietf:params:xml:ns:dchk1" authority="fr" registryType="dchk1" entityClass="domain-name" entityName=" xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr"> <domainName> xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr </domainName> <idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn> <status> <inactive/> </status> <createdDateTime>2012-01-20T13:16:24.0Z</createdDateTime> <lastDatabaseUpdateDateTime>2012-01-20T13:16:24.0Z</lastDatabaseUpdateDateTime> </domain> </iris:answer> </iris:resultSet> </iris:response>