Guide d`intégration technique

Transcription

GUIDE D’INTÉGRATION TECHNIQUE – 25 février 2013
1
Guide d'intégration
technique
- Version 2.7 25 février 2013
Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]
Twitter : @AFNIC | Facebook : afnic.fr
2
Ta 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.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
Pas d’implémentation des objets "host" (RFC 5732) .................................................................. 10
Cas des opérations avec code retour 1000 et comportement du serveur en cas de problème ...... 11
Gestion du auth_info ................................................................................................................... 11
Choix d’implémentation de la liste des messages de notification ............................................... 11
Support de DNSSEC ................................................................................................................... 12
3.3. Commandes implémentées ........................................................................ 13
3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.
Le <greeting> .............................................................................................................................. 13
La commande <hello> ................................................................................................................. 13
Les commandes de gestion de session......................................................................................... 14
Les commandes d’interrogation .................................................................................................. 17
Les commandes de mise à jour d’objets ...................................................................................... 19
3.4. Gérer un nom de domaine .......................................................................... 20
3.4.1.
3.4.2.
3.4.3.
3.4.4.
3.4.5.
3.4.6.
3.4.7.
Create - créer un nom de domaine ............................................................................................... 20
Update - modifier les attributs du domaine ................................................................................. 24
Delete - Supprimer un domaine................................................................................................... 32
Restore - Restaurer un domaine .................................................................................................. 33
Transfer – Changement de bureau d’enregistrement ................................................................... 34
Trade - Transmettre un domaine ................................................................................................. 44
Recover - Transmission forcée d’un nom de domaine ................................................................ 51
3
3.4.8. Vérifier la disponibilité d'un domaine ......................................................................................... 54
3.4.9. Récupérer les données d'un domaine ........................................................................................... 57
3.5. Gérer un contact .......................................................................................... 63
3.5.1.
3.5.2.
3.5.3.
3.5.4.
3.5.5.
Créer un contact .......................................................................................................................... 63
Modifier un contact ..................................................................................................................... 70
Supprimer un contact................................................................................................................... 71
Qualification d’un contact titulaire .............................................................................................. 71
Récupérer les données d'un contact ............................................................................................. 72
3.6. Notifications ................................................................................................. 74
3.6.1. Gestion de la file de notification ................................................................................................. 74
3.6.2. Notifications asynchrones ........................................................................................................... 75
3.6.3. Notifications exogènes ................................................................................................................ 80
3.7. Codes retours et messages d'erreurs ........................................................ 97
3.7.1. Les codes retour .......................................................................................................................... 97
3.7.2. Les messages d’erreurs .............................................................................................................. 100
3.8. RFCs ........................................................................................................... 102
4. Interface Web : le système de tickets ...........................................103
4.1. Généralités sur les tickets ........................................................................ 103
4.2. Format du ticket ......................................................................................... 103
4.3. Description de l’ensemble des tickets ..................................................... 103
5. Les opérations gérables uniquement par mail/fax .......................111
5.1. Génération de code d’autorisation ........................................................... 111
5.2. Validation de trade ..................................................................................... 112
5.3. Notification de suivi de la procédure de qualification ............................ 112
5.4. Notification de gel, blocage et suppression du portefeuille de
domaines ....................................................................................................... 113
5.5. Mail de Justification................................................................................... 113
6. Service DAS (Domain Availability Service) ..................................115
6.1. Paramètres pour interroger le service ..................................................... 115
6.2. Les informations disponibles ................................................................... 115
6.2.1.
6.2.2.
6.2.3.
6.2.4.
6.2.5.
Validité du nom de domaine testé ............................................................................................. 115
Disponibilité du nom de domaine.............................................................................................. 115
État de la publication DNS ........................................................................................................ 116
Informations sur les restrictions liées à ce nom de domaine ..................................................... 116
Des dates clés sur des domaines existants ................................................................................. 116
4
6.3. DAS et IDN .................................................................................................. 116
6.4. Exemples .................................................................................................... 117
6.4.1.
6.4.2.
6.4.3.
6.4.4.
6.4.5.
6.4.6.
6.4.7.
6.4.8.
6.4.9.
Nom de domaine qui n'existe pas et qui ne fait l'objet d'aucune restriction .............................. 117
Nom de domaine soumis à examen préalable ........................................................................... 118
Nom de domaine fantaisiste ...................................................................................................... 118
Nom de domaine qui existe et qui ne fait l'objet d'aucune restriction ....................................... 119
Nom de domaine qui est supprimé et en période de rédemption ............................................... 119
Nom de domaine qui existe mais qui est aussi un terme soumis à examen préalable ............... 120
Requête sur différents noms de domaine aux propriétés différentes ......................................... 121
Interrogation d'un IDN sous sa forme Unicode ......................................................................... 122
Interrogation d'un IDN sous sa forme ACE............................................................................... 122
5
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/documentstechniques/guide-des-procedures-pour-les-bureaux-d-enregistrement.html ) ni
La Charte de Nommage (http://www.afnic.fr/fr/ressources/documents-dereference/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
04/02/2011 – V 1.5 - Ajout du support DNSSEC en EPP dans le serveur version 1.1
6
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.
17/12/2012 – V2.6 – Suppression de ZoneCheck
25/02/2013 – V2.7 – Suppression de serverRestoreProhibited et màj de l’adresse epp.sandbox.nic.fr
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).
7
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
•
•
•
•
8
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.
#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Point de
Glyphe
code
U+002D
U+0030
U+0031
U+0032
U+0033
U+0034
U+0035
U+0036
U+0037
U+0038
U+0039
U+0061
U+0062
U+0063
U+0064
U+0065
U+0066
U+0067
U+0068
U+0069
U+006A
U+006B
U+006C
U+006D
U+006E
U+006F
U+0070
U+0071
0
1
2
3
4
5
6
7
8
9
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
Nom
TRAIT D'UNION-SIGNE MOINS
CHIFFRE ZÉRO
CHIFFRE UN
CHIFFRE DEUX
CHIFFRE TROIS
CHIFFRE QUATRE
CHIFFRE CINQ
CHIFFRE SIX
CHIFFRE SEPT
CHIFFRE HUIT
CHIFFRE NEUF
LETTRE MINUSCULE LATINE A
LETTRE MINUSCULE LATINE B
LETTRE MINUSCULE LATINE C
LETTRE MINUSCULE LATINE D
LETTRE MINUSCULE LATINE E
LETTRE MINUSCULE LATINE F
LETTRE MINUSCULE LATINE G
LETTRE MINUSCULE LATINE H
LETTRE MINUSCULE LATINE I
LETTRE MINUSCULE LATINE J
LETTRE MINUSCULE LATINE K
LETTRE MINUSCULE LATINE L
LETTRE MINUSCULE LATINE M
LETTRE MINUSCULE LATINE N
LETTRE MINUSCULE LATINE O
LETTRE MINUSCULE LATINE P
LETTRE MINUSCULE LATINE Q
Équivalence
ASCII
0
1
2
3
4
5
6
7
8
9
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
U+0072
U+0073
U+0074
U+0075
U+0076
U+0077
U+0078
U+0079
U+007A
U+00DF
U+00E0
U+00E1
U+00E2
U+00E3
U+00E4
U+00E5
U+00E6
U+00E7
U+00E8
U+00E9
U+00EA
U+00EB
U+00EC
U+00ED
U+00EE
U+00EF
U+00F1
U+00F2
U+00F3
U+00F4
U+00F5
U+00F6
U+00F9
U+00FA
U+00FB
U+00FC
U+00FD
U+00FF
U+0153
r
s
t
u
v
w
x
y
z
ß
à
á
â
ã
ä
å
æ
ç
è
é
ê
ë
ì
í
î
ï
ñ
ò
ó
ô
õ
ö
ù
ú
û
ü
ý
ÿ
œ
LETTRE MINUSCULE LATINE R
LETTRE MINUSCULE LATINE S
LETTRE MINUSCULE LATINE T
LETTRE MINUSCULE LATINE U
LETTRE MINUSCULE LATINE V
LETTRE MINUSCULE LATINE W
LETTRE MINUSCULE LATINE X
LETTRE MINUSCULE LATINE Y
LETTRE MINUSCULE LATINE Z
LETTRE MINUSCULE LATINE S DUR
LETTRE MINUSCULE LATINE A ACCENT GRAVE
LETTRE MINUSCULE LATINE A ACCENT AIGU
LETTRE MINUSCULE LATINE A ACCENT CIRCONFLEXE
LETTRE MINUSCULE LATINE A TILDE
LETTRE MINUSCULE LATINE A TRÉMA
LETTRE MINUSCULE LATINE A ROND EN CHEF
LETTRE MINUSCULE LATINE AE
LETTRE MINUSCULE LATINE C CÉDILLE
LETTRE MINUSCULE LATINE E ACCENT GRAVE
LETTRE MINUSCULE LATINE E ACCENT AIGU
LETTRE MINUSCULE LATINE E ACCENT CIRCONFLEXE
LETTRE MINUSCULE LATINE E TRÉMA
LETTRE MINUSCULE LATINE I ACCENT GRAVE
LETTRE MINUSCULE LATINE I ACCENT AIGU
LETTRE MINUSCULE LATINE I ACCENT CIRCONFLEXE
LETTRE MINUSCULE LATINE I TRÉMA
LETTRE MINUSCULE LATINE N TILDE
LETTRE MINUSCULE LATINE O ACCENT GRAVE
LETTRE MINUSCULE LATINE O ACCENT AIGU
LETTRE MINUSCULE LATINE O ACCENT CIRCONFLEXE
LETTRE MINUSCULE LATINE O TILDE
LETTRE MINUSCULE LATINE O TRÉMA
LETTRE MINUSCULE LATINE U ACCENT GRAVE
LETTRE MINUSCULE LATINE U ACCENT AIGU
LETTRE MINUSCULE LATINE U ACCENT CIRCONFLEXE
LETTRE MINUSCULE LATINE U TRÉMA
LETTRE MINUSCULE LATINE Y ACCENT AIGU
LETTRE MINUSCULE LATINE Y TRÉMA
DIGRAMME SOUDÉ MINUSCULE LATIN OE
9
r
s
t
u
v
w
x
y
z
ss
a
a
a
a
a
a
ae
c
e
e
e
e
i
i
i
i
n
o
o
o
o
o
u
u
u
u
y
y
oe
10
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.sandbox.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)
11
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>
12
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.
13
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>
3.3.2. La commande <hello>
14
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,
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
15
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: <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 :
•
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.
•
•
16
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: <command>
C:
<logout/>
C:
C: </command>
C:</epp>
17
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>
18
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).
19
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>
20
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, XX12345FRNIC 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.
Nom de l’élément
<domain:name>
<domain:period>
<domain:registrant>
<domain:contact type="admin">
<domain:contact type="tech">
<domain:authInfo>
<domain:pw>
<clTRID>
•
•
Nombre d’occurrences
1
0-1
1
1
1-3
1
1
0-1
<domain:name> contient le nom de domaine complet (exemple-nddepp.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>
•
•
•
•
•
21
•
Soit <domain:period unit="m">12</domain:period>
<domain:registrant> contient l’identifiant du titulaire déduit du nichandle 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.
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:
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.
22
À 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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:creData
S:
S:
S:
S:
S:
</domain:creData>
S:
</resData>
S:
<trID>
S:
S:
<svTRID>frnic-00000001</svTRID>
S:
</trID>
S: </response>
S:</epp>
Exemple de code retour 1001 envoyé par le serveur :
S: <response>
S:
S:
<msg>Command completed successfully; action pending</msg>
S:
</result>
S:
<resData>
S:
<domain:creData
S:
S:
<domain:name>dom-epp-wytxubuz.fr</domain:name>
S:
S:
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-dereference/documents-techniques/guide-des-procedures-pour-lesbureaux-d-enregistrement.html ).
Rappelons que celui-ci est associé au triplet (bureau d’enregistrement, nom
de domaine, nic-handle du titulaire).
23
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).
C: <command>
C:
<create>
C:
<domain:create
C:
C:
<domain:name>ndd-reserve-0001.fr</domain:name>
C:
<domain:period unit="m">12</domain:period>
C:
C:
C:
C:
C:
<domain:authInfo>
C:
<domain:pw>NDCR20080229T173000.123456789</domain:pw>
C:
</domain:authInfo>
C:
</domain:create>
C:
</create>
C:
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.
24
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
start
Whois :
reachstatus
pending
Whois :
eligstatus
pending
Opérations
refusées
contact:update
Statut du domaine
-
contact:update
problem (gel)
ok/-
ok/-
domain:trade
serverTransferProhibited +
serverTradeProhibited
domain:transfer
contact:update
domain:trade
domain:transfer
problem (blocage)
ok/-
ok/-
domain:restore
serverHold +
serverUpdateProhibited +
serverDeleteProhibited +
serverTransferProhibited +
serverTradeProhibited +
domain:delete
domain:update
domain:create
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
25
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: <command>
C:
<update>
C:
<domain:update
C:
C:
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:
C:
</domain:rem>
C:
</domain:update>
C:
</update>
C:
C: </command>
C:</epp>
26
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: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
Exemple de réponse en cas de code retour 1001 :
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">S: <response>
S:
S:
S:
</result>
S:
<msgQ count="1" id="63480"/>
S:
<trID>
S:
S:
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 1000.
La configuration 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).
27
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 ceuxci 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.
Nombre d’occurences
<domain:hostName>
1
<domain:hostAddr ip="v4">
0-n
<domain:hostAddr ip="v6">
0-n
•
•
•
<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
28
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>
<secDNS:dsData>.
contient
un
ou
plusieurs
éléments
Chaque élément <secDNS:dsData> possède les sous-éléments suivants :
<secDNS:keyTag>
<secDNS:alg>
<secDNS:digestType>
<secDNS:digest>
1
1
1
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.
29
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: <command>
C:
<update>
C:
<domain:update
C:
C:
C:
<domain:add>
C:
<domain:ns>
C:
<domain:hostAttr>
C:
<domain:hostName>ns1.nic.fr</domain:hostName>
C:
</domain:hostAttr>
C:
<domain:hostAttr>
C:
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:
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: <command>
C:
<update>
C:
<domain:update
C:
C:
C:
<domain:add>
C:
<domain:ns>
C:
<domain:hostAttr>
C:
C:
</domain:hostAttr>
C:
<domain:hostAttr>
C:
C:
</domain:hostAttr>
C:
<domain:hostAttr>
C:
C:
C:
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:
C: </command>
C:</epp>
30
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, ne sera pas annoncé dans le DNS. 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.
<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
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) :
31
C: <command>
C:
<update>
C:
<domain:update
C:
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:
C: </command>
C:</epp>
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: <response>
S:
S:
S:
</result>
S:
<msgQ count="1" id="50001"/>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
Exemple de réponse en cas de code retour 1001 (serveur dégradé) :
S: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
32
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: <command>
C:
<delete>
C:
<domain:delete
C:
C:
C:
</domain:delete>
C:
</delete>
C:
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: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
33
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.
<rgp:restore op="request">
1
Exemple de la requête de restauration de notre domaine de test :
C: <command>
C:
<update>
C:
<domain:update
C:
C:
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:
C: </command>
C:</epp>
34
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: <response>
S:
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
Exemple de réponse en cas de code retour 1001 (serveur dégradé)
S: <response>
S:
S:
S:
</result>
S:
<trID>
S:
S:
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.
35
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.
<domain:pw>
<frnic:domain keepDS="0">
<frnic:contact type="admin">
<frnic:contact type="tech">
1
1
1
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.
36
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: <command>
C:
<transfer op="request">
C:
<domain:transfer
C:
C:
C:
<domain:period unit="y">1</domain:period>
C:
<domain:authInfo>
C:
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:
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:
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.
<domain:name>
<domain:trStatus>
<domain:reID>
<domain:reDate>
<domain:acID>
<domain:acDate >
•
•
•
•
1
1
1
1
1
1
<domain:name> contient le nom de domaine complet (exemplendd-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.
•
•
37
<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.
code retour est toujours 1001) :
S: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:trnData
S:
S:
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:
S:
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".
38
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: <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: <response>
S:
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:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
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.
39
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: <command>
C:
<transfer op="approve">
C:
<domain:transfer
C:
C:
C:
<domain:authInfo>
C:
C:
</domain:authInfo>
C:
</domain:transfer>
C:
</transfer>
C:
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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
<domain:trStatus>clientApproved</domain:trStatus>
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
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
40
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: <command>
C:
<transfer op="reject">
C:
<domain:transfer
C:
C:
C:
<domain:authInfo>
C:
C:
</domain:authInfo>
C:
</domain:transfer>
C:
</transfer>
C:
C: </command>
C :</epp>
Exemple de réponse du serveur dans le cas d’un refus :
S: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
<domain:trStatus>clientRejected</domain:trStatus>
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
<svTRID>frnic-000000009-bis</svTRID>
S:
</trID>
S: </response>
S:</epp>
41
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
<msg>Transfer approved.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
42
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:01:00.0Z</qDate>
S:
<msg>Transfer completed.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
<domain:name paResult="1">ndd-de-test-0001.fr</domain:name>
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
<domain:paDate>2008-12-26T00:01:00.0Z</domain:paDate>
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
<msg>Transfer rejected.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
43
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.
44
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.
<frnic:name>
<frnic:registrant>
<frnic:contact type="admin">
<frnic:contact type="tech">
1
1
1
1
1-3
45
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-test0001.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: <extension>
C:
<frnic:ext
C:
C:
<frnic:command>
C:
<frnic:trade op="request">
C:
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:
C:
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
46
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 :
<frnic:name>
<frnic:trStatus>
<frnic:reID>
<frnic:reDate>
<frnic:reHldID>
<frnic:rhDate>
<frnic:acID>
<frnic:acHldID>
<frnic:ahDate>
•
•
•
•
•
•
•
•
1
1
1
1
1
1
1
0-1
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).
•
47
<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.
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: <response>
S:
S:
S:
</result>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
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:
S:
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
48
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-12-25T00:02:00.0Z</qDate>
S:
<msg>Trade requested.</msg>
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
S:
<frnic:reID>BEdemandeurID</frnic:reID>
S:
S:
S:
<frnic:acID>BEactuelID</frnic:acID>
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
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
49
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-02T00:00:01.0Z</qDate>
S:
<msg>Trade in progress.</msg>
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>oldHolderApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
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".
50
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>holdersApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
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: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
<msg>Trade completed.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
51
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>.
52
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: <extension>
C:
<frnic:ext
C:
xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.2"
C:
C:
<frnic:command>
C:
<frnic:recover op="request">
C:
C:
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:
C:
C:
</frnic:domain>
C:
</frnic:recover>
C:
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) :
<frnic:name>
<frnic:reID>
<frnic:reDate>
<frnic:reHldID>
<frnic:acID>
<frnic:acHldID>
1
1
1
0-1
1
0-1
•
•
•
•
•
•
53
<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.
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: <response>
S:
S:
S:
</result>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:recData>
S:
<frnic:domain>
S:
S:
<frnic:reID>BEentrantID</frnic:reID>
S:
S:
<frnic:reHldID>PR1249</frnic:reHldID>
S:
<frnic:acID>BEsortantID</frnic:acID>
S:
S:
</frnic:domain>
S:
</frnic:recData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
54
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
In use
Zone not opened
Zone unknown
Bad syntax
Registry bad syntax
Equivalent name in use
Forbidden name
Détails
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).
Le nom de domaine est libre, mais
appartient à une zone gérée par l’AFNIC qui
n’est pas ouverte à l’enregistrement.
Le nom de domaine n’est pas dans une zone
gérée par l’AFNIC.
L’argument passé en paramètre n’est pas un
nom de domaine.
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, …).
Un nom de domaine "équivalent" existe déjà
et empêche le dépôt de ce nom de domaine.
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
55
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: <command>
C:
<check>
C:
<domain:check
C:
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:
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 :
<frnic:name reserved="" forbidden="">
<frnic:rsvReason>
<frnic:fbdReason>
•
•
•
1
0-n
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
56
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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:chkData
S:
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:
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:
S:
af-1234-nic.fr
S:
</frnic:name>
S:
</frnic:cd>
S:
<frnic:cd>
S:
S:
bois-guillaume.fr
S:
</frnic:name>
57
S:
<frnic:rsvReason>City name</frnic:rsvReason>
S:
</frnic:cd>
S:
<frnic:cd>
S:
S:
paris.fr
S:
</frnic:name>
S:
<frnic:rsvReason>City name</frnic:rsvReason>
S:
</frnic:cd>
S:
<frnic:cd>
S:
S:
trafiquants.fr
S:
</frnic:name>
S:
<frnic:fbdReason>Legal issue</frnic:fbdReason>
S:
</frnic:cd>
S:
<frnic:cd>
S:
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:
S:
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
58
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: <command>
C:
<info>
C:
<domain:info
C:
C:
<domain:name hosts="all">ndd-de-test-0001.fr</domain:name>
C:
</domain:info>
C:
</info>
C:
C: </command>
C:</epp>
Requête envoyée sur un domaine n’appartenant pas au portefeuille du bureau
d'enregistrement :
C: <command>
C:
<info>
C:
<domain:info
C:
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:
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 recréé 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.
59
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 :
<domain:name>
<domain:roid>
<domain:status s="">
<domain:registrant>
<domain:contact type="admin">
<domain:contact type="tech">
<domain :ns>
<domain :host>
<domain:clID>
<domain:crDate>
<domain:exDate>
<domain:upDate>
<domain:authInfo>
•
•
•
•
•
•
•
•
1
1
0-n
1
1
1-3
0-1
0-n
1
1
1
1
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 nichandle 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
•
•
•
•
•
60
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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<domain:infData
S:
S:
S:
S:
<domain:status s="ok"/>
S:
S:
S:
S:
S:
<domain:ns>
S:
<domain:hostAttr>
S:
S:
</domain:hostAttr>
S:
<domain:hostAttr>
S:
S:
</domain:hostAttr>
S:
<domain:hostAttr>
S:
S:
S:
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:
S:
S:
<domain:update>2009-01-10T00:00:00.0Z</domain:update>
S:
<domain:authInfo>
S:
S:
</domain:authInfo>
S:
</domain:infData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
C:</epp>
3.4.9.2.Détails des extensions possibles de la réponse
61
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:
<resData>
S:
<domain:infData
S:
S:
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:
S:
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:
<resData>
S:
<domain:infData
S:
S:
S:
<domain:status s="serverTransferProhibited"/>
[…]
S:
</resData>
S:
<extension>
S:
<frnic:ext
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
62
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:
<resData>
S:
<domain:infData
S:
S:
S:
[…]
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:
S:
S:
</trID>
S: </response>
S:</epp>
63
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
64
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.
<frnic:birthDate>
<frnic:birthCity>
<frnic:birthPc>
<frnic:birthCc>
•
•
•
•
1
0-1
0-1
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 :
65
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:
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:
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.
<frnic:idStatus>
<frnic:nhStatus new="">
•
•
66
0-1
1
<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">).
67
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: <response>
S:
S:
S:
</result>
S:
<resData>
S:
<contact:creData
S:
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:
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:
S:
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 :
<frnic:legalStatus s="">
<frnic:siren>
<frnic:VAT>
<frnic:trademark>
<frnic:asso>
<frnic:waldec>
<frnic:decl>
<frnic:publ announce="" page="">
<frnic:DUNS>
<frnic:local>
•
1
0-1
0-1
0-1
0-1
0-1
1 si <frnic:waldec> est absent
1 si <frnic:waldec> est absent
0-1
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>).
•
•
•
•
•
•
68
<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: <command>
C:
<create>
C:
<contact:create
C:
C:
C:
C:
<contact:name>AFNIC</contact:name>
C:
<contact:addr>
C:
C:
C:
C:
<contact:city>Saint Quentin en Yvelines
Cedex</contact:city>
C:
C:
C:
</contact:addr>
C:
C:
C:
C:
C:
<contact:authInfo>
C:
C:
</contact:authInfo>
C:
</contact:create>
C:
</create>
C:
<extension>
C:
<frnic:ext
C:
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:
C: </command>
C:</epp>
69
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.
<frnic:idStatus>
<frnic:reachable>
0-1
0-1
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:
C:
C:
<contact:name>Levigneron</contact:name>
C:
<contact:org>AFNIC</contact:org>
C:
<contact:addr>
C:
C:
C:
C:
<contact:city>Saint Quentin en Yvelines Cedex</contact:city>
C:
C:
C:
</contact:addr>
C:
C:
C:
C:
<contact:email>vincent.levigneron\@nic.fr</contact:email>
C:
<contact:authInfo>
C:
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:
C:
<frnic:idStatus>ok</frnic:idStatus>
C:
C:
C:
C:
<frnic:reachable media="email">1</frnic:reachable>
C:
</frnic:contact>
C:
</frnic:create>
C:
</frnic:ext>
C:
</extension>
C:
C: </command>
C:</epp>
70
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: <command>
C:
<update>
C:
<contact:update
C:
C:
C:
</contact:update>
C:
</update>
C:
<extension>
C:
<frnic:ext
C:
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:
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é.
71
C:<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
C: <command>
C:
<update>
C:
<contact:update
C:
C:
C:
</contact:update>
C:
</update>
C:
<extension>
C:
<frnic:ext
C:
C:
<frnic:update>
C:
<frnic:contact>
C:
<frnic:add>
C:
C:
<frnic:reachable media="email">1</frnic:reachable>
C:
</frnic:add>
C:
</frnic:contact>
C:
</frnic:update>
C:
</frnic:ext>
C:
</extension>
C:
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 "offline". L’impact de l’état de qualification d’un titulaire sur les opérations
possibles est décrit dans le guide des procédures.
72
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: <command>
C:
<info>
C:
<contact:info
C:
C:
<contact:id>MO666</contact:id>
C:
</contact:info>
C:
</info>
C:
C: </command>
C:</epp>
73
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>
<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:name>Mobibus Outlaws</contact:name>
<contact:addr>
<contact:street>7, avenue monchignon</contact:street>
<contact:city>la Baule Escoublac</contact:city>
</contact:addr>
<contact:clID>-wuhgejav499-.fr</contact:clID>
<contact:crID>-wuhgejav499-.fr</contact:crID>
<contact:upDate>2011-07-08T16:41:17.0Z</contact:upDate>
</contact:infData>
</resData>
<extension>
<frnic:resData>
<frnic:infData>
<frnic:contact>
<frnic:idStatus when="2011-06-21T05:30:36"
source="registry">ok</frnic:idStatus>
<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é.
74
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: <command>
C:
<poll op="req"/>
C:
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: <command>
C:
<poll op="ack" msgID="50001"/>
C:
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: <response>
S:
S:
S:
</result>
S:
<msgQ count="0" id="50001"/>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
75
3.6.2. Notifications asynchrones
Dans ce chapitre seront donnés des exemples de notification pour :
•
•
•
•
•
•
•
•
•
•
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
Transfer accord (bureau d'enregistrement entrant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
76
Transfer fini (bureau d'enregistrement entrant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:01:00.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
Transfer rejeté (bureau d'enregistrement entrant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-26T00:00:01.0Z</qDate>
S:
<msg>Transfer rejected.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
77
Trade fini (bureau d'enregistrement entrant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:panData
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
Delete fini
S: <response>
S:
S:
S:
</result>
S:
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:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
<svTRID>TEST-kenobi-6435-29-1254926575.803</svTRID>
S:
</trID>
S: </response>
S:</epp>
•
78
Restore fini
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
<msg>Deletion aborted. Domain successfully restored.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
<clTRID>FooBar</clTRID>
S:
S:
</trID>
S: </response>
S:</epp>
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-06-04T09:11:27.0Z</qDate>
S:
<msg>Pending update (restore) completed successfully.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
79
Create fini
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-06-03T15:23:23.0Z</qDate>
S:
<msg>Pending creation completed successfully.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name paResult="1">dom-epp-wytxubuz.fr</domain:name>
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Update [admin] fini
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-06-04T10:30:28.0Z</qDate>
S:
<msg>Pending update (contacts) completed successfully.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name paResult="1">dom-epp-hyclebod.fr</domain:name>
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
80
Update [context] fini
S: <response>
S:
S:
S:
</result>
S:
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:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
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
•
81
Transfer demandé (bureau d'enregistrement sortant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2008-12-25T00:02:00.0Z</qDate>
S:
<msg>Transfer requested.</msg>
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Transfer accord (bureau d’enregistrement entrant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-10-06T16:27:19.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:trnData
S:
S:
S:
S:
S:
S:
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
82
Transfer fini (bureau d’enregistrement sortant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-10-06T16:27:20.0Z</qDate>
S:
S:
</msgQ>
S:
<resData>
S:
<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:
S:
S:
<domain:reID>TEST_2</domain:reID>
S:
S:
<domain:acID>TEST</domain:acID>
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Transfer annulé (bureau d’enregistrement sortant)
S: <response>
S:
S:
S:
</result>
S:
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:
S:
<domain:trStatus>clientCancelled</domain:trStatus>
S:
<domain:reID>-huqlycuw772-.fr</domain:reID>
S:
S:
<domain:acID>-huqlycuw772-.fr</domain:acID>
S:
S:
</domain:trnData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Transfer annulé (bureau d’enregistrement entrant)
83
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-10-07T14:18:33.0Z</qDate>
S:
<msg>Transfer aborted.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
S:
<domain:paTRID>
S:
S:
S:
</domain:paTRID>
S:
S:
</domain:panData>
S:
</resData>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Trade initié (bureau d’enregistrement sortant)
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-12-25T00:02:00.0Z</qDate>
S:
<msg>Trade requested.</msg>
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Trade titulaire sortant accord
84
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-02T00:00:01.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>oldHolderApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
85
Trade titulaire entrant accord
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2010-05-28T16:06:25.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
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:
S:
<frnic:reHldID>IP649</frnic:reHldID>
S:
S:
<frnic:acID>TEST</frnic:acID>
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
86
Trade titulaire sortant et entrant accord
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-01-03T00:00:00.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
<frnic:ext
S:
S:
<frnic:resData>
S:
<frnic:trdData>
S:
<frnic:domain>
S:
S:
<frnic:trStatus>holdersApproved</frnic:trStatus>
S:
S:
S:
S:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
Trade fini (bureau d'enregistrement sortant)
S: <response>
S:
S:
S:
</result>
S:
<msgQ count="1" id="423754">
S:
<qDate>2009-08-28T14:49:55.0Z</qDate>
S:
S:
</msgQ>
S:
<extension>
S:
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:
S:
<frnic:acID>-vycfazur780-.fr</frnic:acID>
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
Trade annulé (bureau d'enregistrement sortant)
87
S: <response>
S:
S:
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:
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:
S:
S:
S:
</frnic:domain>
S:
</frnic:trdData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
Recover fini (bureau d'enregistrement sortant)
S: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:recData>
S:
<frnic:domain>
S:
<frnic:name>identification-histo-problem-11271298006685.fr</frnic:name>
S:
<frnic:reID>-hexfyreg992-.fr</frnic:reID>
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
•
88
Notification d'entrée en procédure de qualification
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
<frnic:id>ZNE51</frnic:id>
S:
<frnic:qualificationProcess s="start"/>
S:
S:
<frnic:idStatus>pending</frnic:idStatus>
S:
<frnic:legalStatus s="association"/>
S:
S:
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:
S:
</trID>
S: </response>
S:</epp>
•
89
Notification de clôture de qualification
Cas où la joignabilité et l’éligibilité ont pu aboutir
S: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
S:
<frnic:qualificationProcess s="finished"/>
S:
S:
S:
S:
S:
S:
S:
<frnic:reStatus>ok</frnic:reStatus>
S:
S:
S:
</frnic:contact>
S:
</frnic:quaData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
90
Cas où la joignabilité et/ou l’éligibilité n’ont pu aboutir
S: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
S:
<frnic:qualificationProcess s="finished"/>
S:
S:
<frnic:idStatus>ko</frnic:idStatus>
S:
S:
S:
S:
S:
S:
S:
S:
</frnic:contact>
S:
</frnic:quaData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
91
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: <response>
S:
S:
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:
S:
<frnic:resData>
S:
<frnic:quaData>
S:
<frnic:contact>
S:
S:
<frnic:qualificationProcess s="problem"/>
S:
S:
<frnic:idStatus>ko</frnic:idStatus>
S:
S:
S:
S:
S:
S:
S:
S:
</frnic:contact>
S:
</frnic:quaData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
</trID>
S: </response>
S:</epp>
•
92
Notification de gel d’un nom de domaine
ATTENTION : cette notification est envoyée autant de fois que de
domaines gelés.
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-05-05T07:52:50.0Z</qDate>
S:
<msg>Holder qualification status prevents some operations.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name>nic.fr</domain:name>
S:
S:
S:
<domain:registrant>XXX1234</domain:registrant>
S:
<domain:clID>-rocfisor895-.fr</domain:clID>
S:
</domain:infData>
S:
</resData>
S:
<extension>
S:
S:
<frnic:resData>
S:
<frnic:infData>
S:
<frnic:domain>
S:
S:
</frnic:domain>
S:
</frnic:infData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
93
Notification de blocage d’un nom de domaine
domaines bloqués.
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-05-05T07:52:50.0Z</qDate>
S:
<msg>Holder qualification status prevents some operations.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name>nic.fr</domain:name>
S:
S:
<domain:status s="serverHold"/>
S:
<domain:status s="serverDeleteProhibited"/>
S:
<domain:status s="serverUpdateProhibited"/>
S:
S:
<domain:registrant>XXX1234</domain:registrant>
S:
<domain:clID>-rocfisor895-.fr</domain:clID>
S:
</domain:infData>
S:
</resData>
S:
<extension>
S:
S:
<frnic:resData>
S:
<frnic:infData>
S:
<frnic:domain>
S:
S:
</frnic:domain>
S:
</frnic:infData>
S:
</frnic:resData>
S:
</frnic:ext>
S:
</extension>
S:
<trID>
S:
S:
S:
</trID>
S: </response>
S:</epp>
•
94
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).
domaines.
S: <response>
S:
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:
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>
•
95
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...
domaines.
S: <response>
S:
S:
S:
</result>
S:
S:
<qDate>2009-05-05T07:52:50.0Z</qDate>
S:
<msg>Domain deletion after failure in qualification
process.</msg>
S:
</msgQ>
S:
<resData>
S:
S:
<domain:name>nomdomaine1.fr</domain:name>
S:
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:
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:
S:
S:
</trID>
S: </response>
S:</epp>
•
96
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: <response>
S:
S:
S:
</result>
S:
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:
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:
S:
S:
</contact:addr>
S:
S:
S:
S:
<contact:clID>-huqlycuw772-.fr</contact:clID>
S:
<contact:crID>-huqlycuw772-.fr</contact:crID>
S:
S:
<contact:upDate>2009-10-21T09:40:34.0Z</contact:upDate>
S:
</contact:infData>
S:
</resData>
S:
<extension>
S:
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:
S:
S:
</trID>
S: </response>
S:</epp>
97
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: <response>
S:
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:
S:
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">).
98
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 celleci 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.
•
•
•
•
•
•
•
•
•
•
•
•
•
99
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’étatcivil (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
•
•
•
100
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 »
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
101
« 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' »
•
•
•
•
•
•
102
« '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) :
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 :
RFC 5910 - Domain Name System (DNS) Security Extensions Mapping
: http://www.ietf.org/rfc/rfc5910.txt
103
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
S
Opération S : Suppression d’un domaine
É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]
T
104
Opération T : Modification technique d’un domaine
É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.........:
| 1b. Code du bureau d'enregistrement...............:
| 1c. Mot de passe du bureau d'enregistrement.......:
| 1e. Référence client..............................:
| 1f. Version formulaire............................:
|
| Infos sur le nom de domaine
| 2a. Nom de domaine complet........................:
domaine-concerne.fr
| [../..]
| Serveur de nom primaire pour le domaine
| 6a. Serveur primaire..............................:
| 6b. Adresse(s) IP du primaire.....................:
|
| Serveur(s) de nom secondaire pour le domaine
| 7a. Serveur secondaire............................:
| 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...................:
T
CODEBE
xxxxxxxx
refclient
2.5.0
nom-de-
ns.exemple.fr
nt.exemple.fr
Bonjour,
ZONE
NS
NS
: nom-de-domaine-concerne.fr
: ns.exemple.fr
: nt.exemple.fr
==> SUCCESS
[Texte conclusif]
T - Abandonné
105
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-dedomaine-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-domaineconcerne.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]
P
Opération P : Transmission volontaire
106
É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 !
-----------------------------------------------------------------------------Association Française pour le Nommage Internet en Coopération | www.afnic.fr | [email protected]
107
- Acceptez cette transmission:
http://...
- Refusez cette transmission:
http://...
Faute de réponse avant 15 jours, la demande sera abandonnée.
[...]
P – Attente Mail
Subject: FR-NIC, nom-de-domaine-concerne.fr: Attente Mail
[NIC000012345678]
To: noc
[Texte introductif]
OPERATION=Transmission
ETAT=Attente Mail
TICKET=NIC000012345678/123456
FORMULAIRE=1234567
REFERENCE=REFCLIENT
NUMEROSEQUENCE=1
La transmission demandée est en 'Attente Mail'.
P – Abandonné
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 >)
ETAT=Abandonne
TICKET=NIC000012345678/123456
FORMULAIRE=1234567
REFERENCE=REFCLIENT
NUMEROSEQUENCE=2
Opération abandonnée.
Expiration Delai 15 jours
108
P - Fini
[NIC000012345678]
To: noc
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]
P
Opération P : Transmission forcée
États existants : Attente Vérification, Fini
P - Fini
[NIC000012345678]
To: noc
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]
D
109
Opération D : Changement de bureau d'enregistrement
États existants : Attente Opposition, Attente Accord, Abandonne,
Attente Verification, Fini
D – Attente Opposition
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
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 :
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
110
[------------------------------------------------------------------]
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
[NIC00001234567]
To: noc bureau d’enregistrement entrant
[Texte introductif]
OPERATION=Changement P
ETAT=Fini
TICKET=NIC00001234567/484934
FORMULAIRE=4869185
REFERENCE=
NUMEROSEQUENCE=3
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-domaineconcerne.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.
111
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 :
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 :
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}
Cordialement,
AFNIC
Notification de génération d'un code d'autorisation :
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}
pour le nom de domaine ${domaine} a été acceptée.
Votre code d'autorisation est :
${code}
112
Cordialement,
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é.
Cordialement,
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 :
Subject: AFNIC - Qualification ET1323-FRNIC - STATUS=finished
To: noc
[Texte introductif]
HOLDER=ET1323-FRNIC
STATUS= finished
ELIG=valeur_de_l_identifiant ou KO
REACH=valeur_du_media_joignable (EMAIL/PHONE)
[...]
113
[Texte conclusif]
Format de la notification mail pour un passage en statut « problem » :
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 :
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]
5.5. Mail de Justification
114
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.
115
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).
116
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
117
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
<iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
<iris:resultSet>
<iris:answer/>
<iris:nameNotFound/>
</iris:resultSet>
</iris:response>
118
6.4.2. Nom de domaine soumis à examen préalable
Requête :
> dchk nazis.fr
<iris1:searchSet>
entityName="nazis.fr"/>
</iris1:searchSet>
</iris1:request>
Réponse :
nazis.fr: policyNoncompliant
<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
<iris1:searchSet>
entityName="nic_france.fr"/>
</iris1:searchSet>
</iris1:request>
Réponse :
nic_france.fr: invalid
<iris:resultSet>
<iris:answer/>
<iris:invalidName/>
</iris:resultSet>
</iris:response>
119
6.4.4. Nom de domaine qui existe et qui ne fait l'objet d'aucune
restriction
Requête :
> dchk nic.fr
<iris1:searchSet>
entityName="nic.fr"/>
</iris1:searchSet>
</iris1:request>
Réponse :
nic.fr: active [2011-01-21T22:24:31.0Z]
<iris:resultSet>
<iris:answer>
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-0121T22: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
<iris1:searchSet>
entityName="ouais-okay-super.fr"/>
</iris1:searchSet>
</iris1:request>
120
Réponse :
ouais-okay-super.fr: redemptionPeriod [2011-04-04T09:21:04.0Z]
<iris:resultSet>
<iris:answer>
<domain
xmlns="urn:ietf:params:xml:ns:dchk1"
authority="fr"
registryType="dchk1" entityClass="domain-name" entityName="ouais-okaysuper.fr">
<domainName>ouais-okay-super.fr</domainName>
<status>
<inactive/>
<redemptionPeriod/>
</status>
<expirationDateTime>2011-05-04T09:21:04.0Z</expirationDateTime>
</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
<iris1:searchSet>
entityName="paris.fr"/>
</iris1:searchSet>
</iris1:request>
Réponse :
paris.fr: reserved [2006-10-05T15:58:33.0Z]
<iris:resultSet>
<iris:answer>
<domain
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>
</domain>
</iris:answer>
</iris:resultSet>
</iris:response>
121
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
<iris1:searchSet>
entityName="nic007.fr"/>
</iris1:searchSet>
<iris1:searchSet>
entityName="afnic.fr"/>
</iris1:searchSet>
<iris1:searchSet>
entityName="--nic--.fr"/>
</iris1:searchSet>
</iris1:request>
Réponse :
nic007.fr: free
afnic.fr: active [2009-11-09T15:47:45.0Z]
--nic--.fr: invalid]
<iris:resultSet>
<iris:answer/>
<iris:nameNotFound/>
</iris:resultSet>
<iris:resultSet>
<iris:answer>
<domain
authority="fr"
registryType="dchk1" entityClass="domain-name" entityName="afnic.fr">
<domainName>afnic.fr</domainName>
<status>
<active/>
</status>
</domain>
</iris:answer>
</iris:resultSet>
<iris:resultSet>
<iris:answer/>
<iris:invalidName/>
</iris:resultSet>
</iris:response>
122
6.4.8. Interrogation d'un IDN sous sa forme Unicode
Requête :
> dchk àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr
<iris1:searchSet>
<iris1:lookupEntity registryType="dchk1" entityClass="idn"
entityName="àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr"/>
</iris1:searchSet>
</iris1:request>
Réponse :
àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr: active [2012-0120T13:16:24.0Z]
<iris:resultSet>
<iris:answer>
registryType="dchk1" entityClass="idn" entityName="
àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr">
<domainName> xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr
</domainName>
<idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn>
<status>
<active/>
</status>
</domain>
</iris:answer>
</iris:resultSet>
</iris:response>
6.4.9. Interrogation d'un IDN sous sa forme ACE
Requête :
> dchk xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr
<iris1:searchSet>
entityName=" xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr"/>
</iris1:searchSet>
</iris1:request>
123
Réponse :
xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr: active [201201-20T13:16:24.0Z]
<iris:resultSet>
<iris:answer>
registryType="dchk1" entityClass="domain-name" entityName=" xn-zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr">
<domainName> xn--zcabdefghijklmnopqr0btuvwx7eza0a1a2a2dx0o.fr
</domainName>
<idn>àáâãäåæçèéêëìíîïñòóôõöœßùúûüýÿ.fr</idn>
<status>
<inactive/>
</status>
</domain>
</iris:answer>
</iris:resultSet>
</iris:response>

Guide d`intégration technique

Transcription

Documents pareils

Molding / Automobile Molding / Automobile

18 août 2011 - Canadian IT Law Association

11 décembre 2008 - Canadian IT Law Association

ICANN 45 TORONTO – RECENT DEVELOPMENTS IN DOMAIN

Conditions Générales de vente

Télécharger en PDF - Virgo

IT.Can Newsletter/Bulletin, June 9, 2005/9 juin 2005

Recent Developments in Domain Name Space Filiz Yilmaz: Donc

Télécharger - Académie Médicale Montaigne

Télécharger la version PDF