Les bureaux d’enregistrement accrédités par le registre du .lu bénéficient d'interfaces de programmation d’application (Application Programming Interface - API) qui leurs sont spécifiquement dédiées. 

Interface EPP

Communiquer avec le registre du .lu par le biais d'un serveur EPP.

Le serveur EPP est accessible uniquement aux bureaux d’enregistrement accrédités sur authentification préalable. Moyen primaire de communication avec le registre du .lu, il permet aux bureaux de gérer l’ensemble de leurs domaines. Il est complémentaire à l’interface web.

Protocoles ‘EPP-over-TCP’

Le serveur EPP répond à deux variantes ‘EPP sur TCP’ supportées par le protocole EPP (Extensible Provisioning Protocol) défini dans le document de référence technique RFC5730 publié par l’Internet Engineering Task Force (IETF).  

  Protocole RFC3734 Protocole .lu
Descriptif Implémentation conforme à la norme RFC3734 ‘Extensible Provisioning Protocol (EPP) Transport Over TCP’ publié par l’IETF. Protocole spécifiquement développé par et pour le registre du .lu
En-tête 4 octets, précédant chaque message EPP Aucun
Restriction de codage Aucune UTF-8, compatible avec le système Unicode  Métalangage XML (Extensible Markup Language) uniquement sur l’interface test XML
Adresses IP compatibles IPv4 et IPv6 IPv4 et IPv6
Nom d’hôte epp.dns.lu epp.dns.lu
 Ports TCP
  • 1700*  
  • 1702, tunnellisé SSL  
  • 1701*  
  • 1703, tunnellisé SSL

* Port TCP disponible mais non recommandé  

Restrictions! 

  • la connexion doit être établie depuis une adresse IPv4 ou IPv6 explicitement autorisée ;  
  • un maximum de 3 connexions simultanées par adresse IP et de 5 connexions simultanées par bureau d’enregistrement est autorisé.

Validation complémentaire

Une validation basique des données d'adresse introduites est réalisée par le registre du .lu.

Découvrir comment renseigner un code postal

Informations techniques  

  • Le serveur EPP lit la connexion jusqu'à la séquence '</epp>,' considérée comme la fin du message EPP. Après avoir traité la commande, il recommence à lire.
  • Les espaces blancs sont autorisés, avant et après un message EPP, et peuvent être utilisés comme keep-alive pour la session. Cependant, supprimez-les avant de transmettre vos messages à votre analyseur XML.  
  • Si vous avez recours à l'en-tête '<?xml’, le protocole de transport RFC3734 impose de ne jamais mettre d'espace devant cet en-tête.  
  • Pour exécuter des commandes EPP, de manière basique, le recours à une interface en lignes de commandes de style Unix est conseillé.  Exemple : La ligne ‘localhost $ cat epp_login.xml epp_command.xml epp_logout.xml \ | netcat epp-test.dns.lu 1700 > epp_responses.xml’ contient les commandes à exécuter login, logout et 'payload' ainsi que les réponses du serveur EPP.  
  • L’assemblage d’un message EPP par concaténation de segments de chaîne de caractères est déconseillé. La mise en page du métalangage XML associé peut changer sans avertissement préalable (ordre des éléments, commentaires, espaces blancs, etc.), et les espaces blancs et commentaires peuvent perturber l’analyseur XML.  
  • Le serveur EPP ne met fin à  la connexion qu’après une déconnexion (logout) réussie.  

Documentation technique liée

FAQ liées

Quels protocoles de transport le serveur EPP utilise-t-il ?

Le serveur EPP répond à deux variantes de EPP sur TCP :  

  • le protocole de transport RFC3734 ‘Extensible Provisioning Protocol (EPP) Transport Over TCP’  
  • un flux TCP encodé en UTF-8, spécifiquement développé par et pour le registre du .lu

Vous pouvez donc programmer votre client EPP selon ces deux langages.  

Pourquoi ma programmation qui fonctionne sur le serveur test échoue-t-elle sur le serveur de production ?

  • Si vous avez recours au protocole de transport RFC3734, cela est dû au formatage XML actif uniquement sur le serveur test. Il ajoute automatiquement un saut de ligne après la balise de fin '</epp>' qui n’est pas interprété sur le serveur de production. Aussi, lorsque vous répercutez sur le serveur de production la ligne comportant cette balise de fin, veillez à supprimer le symbole '>’ qui le suit.  
  • Si vous avez programmé votre client EPP selon le langage spécifiquement développé par et pour le registre du .lu, vérifiez qu’aucun espace ne précède l'en-tête ‘<?xml’.  

De manière générale, pensez à supprimer les espaces au début et à la fin de chaque message avant de les transmettre à votre analyseur XML.

Pourquoi je n’arrive pas me connecter à l'interface Web ou au serveur EPP ?

Il existe plusieurs raisons possibles à votre problème de connexion :    

  1. Vous avez entré un mauvais mot de passe : vérifiez l’exactitude de votre mot de passe et gardez à l’esprit que si vous l’avez changé dernièrement via le serveur EPP, c’est ce nouveau mot de passe qui est à utiliser pour l'interface Web.
  2. Votre compte est verrouillé : soit votre compte n'a pas encore été déverrouillé ou a été verrouillé en raison d'un comportement inapproprié.  
  3. Votre adresse IP n’est pas autorisée : vous tentez de vous connecter depuis un ordinateur dont l’adresse IP n’est pas autorisée à communiquer avec l’interface et le serveur EPP, connectez-vous depuis un autre appareil.  

Puis-je créer des domaines en utilisant l'interface Web pour bureau d’enregistrement ?

Non. Seuls les hôtes et contacts peuvent être gérés via l'interface Web.

La création des domaines n’est possible que via le serveur EPP, seul système habilité à modifier le contenu de la base de données du registre.  

Pourquoi l'EPP fonctionne-t-il correctement sur le serveur de test et non sur le serveur de production ?

Vous avez très probablement manqué le détail important de l'affectation des ports sur le serveur de production qui est différent du serveur de test.  

  • Si vous avez recours au protocole de transport RFC3734, le port 1701 utilisé sur le système de test doit être remplacé par le port 1700 sur le serveur de production.  
  • Si vous avez programmé votre client EPP selon le langage spécifiquement développé par et pour le registre du .lu, le port 1700 utilisé sur le système de test doit être remplacé par le port 1701 sur le serveur de production.    

Il se peut également que votre logiciel EPP soit trop sensible à la mise en forme du XML. Pour cela référez-vous à la question « Pourquoi ma programmation qui fonctionne sur le serveur test échoue-t-elle sur le serveur de production ? ».  

Mon bureau d’enregistrement est accrédité pour le .lu, comment puis-je vérifier la disponibilité d'un nom de domaine ?

Pour connaître la disponibilité d’un nom de domaine, incluant les domaines en quarantaine et ceux en attente de création, utilisez la commande EPP ‘domain:check’ depuis le serveur EPP.  

  • Si le nom de domaine n'est pas disponible, la raison de son indisponibilité vous est  précisée.  
  • Si le nom de domaine est déjà enregistré, exécutez la commande ‘domain:info’ pour connaître, d’une part, le bureau d'enregistrement chez qui il est enregistré et, d’autre part, la (les) restriction(s) qui s'applique(nt) de type ‘TransferProhibited’ ou ‘TradeProhibited’ (transfert ou cession interdites).  

Vous pouvez également utiliser le DAS, qui fonctionne sur le port 4343, mais vous n’aurez alors pas accès aux noms de domaine en quarantaine ou en attente de création.

Pourquoi un domaine inconnu du WHOIS ne peut-il pas être enregistré ?

Vous essayez d'enregistrer un nom de domaine listé comme temporairement indisponible ou qui est en quarantaine. Pour déterminer le cas exact auquel vous êtes confronté, envoyez la commande EPP ‘domain:check’ au serveur EPP et référez-vous au champ ‘reason’.

J’ai réservé un domaine, comment le rendre actif ?

  1. Pour activer un nom de domaine, ses serveurs de nom doivent être opérationnels et configurés correctement. Vous pouvez contrôler la bonne configuration de vos informations grâce à notre test de serveurs de noms.
  2. Demandez la mise à jour du domaine en supprimant le statut ‘inactif’.  
  3. La mise à jour prend effet sous quelques minutes. Un messages ‘poll’ vous informe de la mise en page du résultat de la mise à jour avec, en cas d’échec, la raison de l’échec.  

Que signifie l’échec ’Billing error’ des commandes EPP ?

Sur le serveur EPP, l’échec ’Billing error’ se produit lorsque vous n'avez pas assez de crédit pour effectuer les opérations suivantes : création, restauration, transfert, transfert-cession, transfert-restauration et cession.

Vous devez alors recharger votre compte, depuis votre interface web avant de pouvoir recommencer vos opérations.    

Pour éviter ce genre de problème, depuis votre interface web du bureau d'enregistrement :  

  • surveillez régulièrement votre solde de crédit et rechargez votre compte suffisamment tôt, les transferts d'argent n’étant pas instantanément pris en compte,  
  • estimez les coûts de renouvellement auxquels vous devrez faire face dans les 7 prochains jours en vous basant sur le nombre de domaines à renouveler affiché dans 'View Summary', 'Coming renewals (7 days)'.  

À quelle fréquence les messages ‘poll’ doivent-ils être demandés ?

Toutes les opérations demandées via le serveur EPP sont traitées automatiquement une fois toutes les cinq minutes par le système dorsal du registre. Par conséquent, vous ne devez pas interroger le registre plus d'une fois toutes les cinq minutes.  

Sauf en cas d'attente de confirmation de la création ou de la mise à jour d'un domaine, il est même suffisant d'interroger moins souvent.  

Protocole de test des serveurs de noms

Tester la bonne configuration des serveurs DNS grâce à une ligne de commande.

Le protocole textuel de service de test du serveur de noms permet aux bureaux d'enregistrement accrédités de tester les serveurs DNS avant d'activer un domaine créé dans un état réservé ou avant de changer les informations de serveurs de noms pour un domaine.

Le protocole lit le texte ASCII à partir de son socket TCP de manière linéaire. Il permet de gérer les résultats et d’agir avec le registre du .lu de manière automatique.  

Découvrir les codes de résultat et leurs interprétations

Voir des exemples de sessions de test

Étape 1 : Envoyer une requête au serveur  

Descriptif d’une commande type  

Une commande unique ressemble à :

XXXX mode args ...

 

 

Définition

XXXX

Identifiant de la demande (alpha-numérique), pouvant apparaître une fois pour chaque commande  

[mode]

Type de commande, pouvant apparaître une fois pour chaque commande, parmi les suivants :  

  • [live] pour un test actif, ignorant les informations mises en cache,  

  • [cached] pour un  test basé sur les informations mises en cache,  

  • [update] pour un test actif, avec mise à jour du cache en cas de succès,

  • [cfg] pour modifier certains paramètres de configuration de la session,  

  • [quit] pour fermer la session (pas le domaine ou le serveur de noms),  

  • [help] pour afficher un petit message d'aide (pas pour le domaine ou le serveur de noms).  

Args ...

Arguments pour la commande spécifiée dans mode  

Types de commandes supportés  

 

Argument(s)

  • live

  • cached

  • update

Tests basés sur un minimum de deux arguments :  

  • Argument 1 : nom de domaine  

Le nom de domaine peut être suivi des enregistrements DS associés. Une virgule (',') est utilisée comme séparateur entre ces deux éléments. Les champs relatifs aux enregistrements DS sont, quant à eux, séparés par un deux-points (':').  

  • Argument 2 et + : définition de serveurs de nom  

La définition de serveurs de nom est composée d’un nom d'hôte suivi d'une adresse IP facultative, requise uniquement en cas de ‘glue records’.  

Le nom d'hôte et l'adresse IP sont séparés par une virgule (',').  

Les adresses IP sont ignorées pour les serveurs de noms ne nécessitant pas de ‘glue records’, sauf si le serveur de nom se résout à une adresse IP donnée.  

cfg

Commande basée sur deux arguments :  

  • Argument 1 : nom de l’option de configuration à modifier,

  •  Argument 2 : nouvelle valeur de l’option de configuration à modifier.  

Elle supporte l’option machine-output qui bascule le mode de sortie entre la description du résultat du test lisible par l'homme et la description du résultat lisible par la machine avec les codes de message et la liste des valeurs à substituer dans la chaîne de message correspondante selon les valeurs suivantes :

  • ‘on’ et ‘true’ pour passer à la sortie lisible par la machine,  

  • ‘off’ et ‘false’ pour passer à la sortie lisible par l'homme.  

quit

Aucun argument traité. La commande ferme la connexion après traitement, sans attendre la fin des tests, ni le renvoi de leurs résultats.

help

Argument facultatif contenant le nom de la commande à décrire.

Caractéristiques techniques générales

  •  Chaque commande est séparée de la commande suivante par une ligne vide. Une commande se termine donc sur la première ligne vide rencontrée.  
  • Les espaces blancs sont considérés comme des séparateurs entre les différents champs.  
  • Les sessions sont fermées par deux lignes vides consécutives ou par la commande 'quit'.  
  • Les commandes individuelles peuvent être envoyées sans attendre de réponse. Cependant, la réutilisation d'un identifiant de commande avant d'avoir obtenu une réponse correspondante n'est pas recommandée, car les réponses auront également ce même identifiant.  

Étape 2 : Intégrer la réponse du serveur  

La réponse du serveur est composée de plusieurs lignes : une ligne d'en-tête donnant l'état global du résultat et au moins une ligne de détail, lisible par l’Homme et la machine.  

Descriptif de la ligne d’en-tête  

La ligne d'en-tête ressemble à :

[code] XXXX texte...  

 

Définition

 [code]

Code de résultat de la réponse correspondant à l’une des options suivantes :

  • [help] lorsque la réponse est une notification d'aide/utilisation,  

  • [miss] quand une demande en mémoire cache a échoué en raison d'informations incomplètes dans la mémoire cache. Le client doit répéter le test en mode de mise à jour ou en mode réel.  

  • [ok] lorsque le test est réussi,  

  • [warn] lorsque le test est réussi mais présente des avertissements,  

  • [err] lorsque le test a échoué.

XXXX

Identifiant de la demande.

texte...

Message de résultat lisible par l'homme.

Descriptif des lignes de détails

La ligne de détail lisible par l’homme ressemble à :

 [code] texte...  

 

Définition

 [code]

Code de résultat de la ligne détaillée parmi les suivants :  

  • [NN] pour une notification,  

  • [II] pour une information,  

  • [WW] pour un avertissement,  

  • [EE] pour une erreur.  

texte...

Message détaillé lisible par l'homme. 

La ligne de détail lisible par la machine ressemble à :

[code] id args ...  

 

Définition

 [code]

Code de résultat de la ligne détaillée parmi les suivants :  

  • [NN] pour une notification,  

  • [II] pour une information,  

  • [WW] pour un avertissement,  

  • [EE] pour une erreur.  

id

ID identifiant le message selon une liste prédéfinie.

 

args...

Arguments requis pour la substitution dans la chaîne de message correspondant au code du message dans id. Tous les arguments sont placés entre guillemets simples, les caractères ' et \ étant échappés sous la forme \' et \\'.

Caractéristiques techniques générales  

  • Une réponse se termine sur la première ligne vide rencontrée.  
  • Aucune garantie sur la durée et l’ordre de réception des réponses, le temps de réponse de serveurs étant variable et inconnu par le registre.  
  • Au-delà d’un délai de 5 secondes, certains serveurs de noms ne répondent pas.

FAQ liées

J’ai réservé un domaine, comment le rendre actif ?

  1. Pour activer un nom de domaine, ses serveurs de nom doivent être opérationnels et configurés correctement. Vous pouvez contrôler la bonne configuration de vos informations grâce à notre test de serveurs de noms.
  2. Demandez la mise à jour du domaine en supprimant le statut ‘inactif’.  
  3. La mise à jour prend effet sous quelques minutes. Un messages ‘poll’ vous informe de la mise en page du résultat de la mise à jour avec, en cas d’échec, la raison de l’échec.