Cet article fait suite à celui sur les résolutions DNS et présente le protocole utilisé par les différentes entités concernées dans une gestion de noms de domaines.
Typiquement, un registre ayant autorité sur un TLD (.fr, .com, .org) et une société qui vend des noms de domaines. EPP (Extensible Provisioning Protocol) est donc un protocole de niveau applicatif bâtit sur XML.
Niveau transport, le protocole s’appuie sur TCP (port 700) et SSL, générallement TLS 1.0.
Il y a plusieurs niveaux de sécurité présents dans ce cycle de traitement :
- Filtrage au niveau IP
- Authentification mutuelle SSL par certificat du serveur et du client & encryption
- Identification par mot de passe dans EPP
- Contrôle des opérations sur les objets concernées (code Auth) ou propriété
Le filtrage IP consiste généralement pour une société Registrar à déclarer une ou deux adresses qui seront autorisées à se connecter aux serveurs EPP.
Toujours dans la couche transport, l’étape suivante à pour objectif de réaliser une authentification mutuelle SSL. Cette méthode consiste à installer chez les 2 parties les certificats respectifs (clés publiques signées) et ainsi pouvoir mutuellement prouver leur identité, handshake Serveur & Client. Ces opérations sont réalisables en ligne de commande directement avec OpenSSL :
# openssl s_client -connect epp.xxxxxx.fr:700 -tls1 -cert server.pem
[...]
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
[...]
Passer ces étapes, le protocole consiste donc à échanger des messages XML pour obtenir des informations ou effectuer des opérations. Par exemple, déposer un nom de domaine ou effectuer une modification des serveurs DNS. Ceux enregistrés au registre et donc obtenus avec un whois:
# whois wordpress.com [...] Domain servers in listed order: NS1.WORDPRESS.COM NS2.WORDPRESS.COM NS3.WORDPRESS.COM NS4.WORDPRESS.COM NS5.WORDPRESS.COM NS6.WORDPRESS.COM
L’ensemble des messages sont détaillés dans les RFC suivants, sachant que certains registres ont implémenté quelques ajouts. Les schémas XML restent toutefois valides malgré les variantes. Cela permet (heureusement) d’optimiser les développements !
La première étape EPP consiste à envoyer une commande d’identification, sans quoi aucune opération n’est réalisable. Ceci se réalise donc avec le message suivant:
<?xml version='1.0' encoding='UTF-8'?> <epp xmlns='urn:ietf:params:xml:ns:epp-1.0'> <login><clID>XXXXXX</clID><pw>XXXXXX</pw><options> <version>1.0</version> <lang>en</lang> </options> <svcs> <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI> <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI> </svcs> </login> </command> </epp>
A cette étape, les opérations lancées pourront donc impacter tous les objets (Domaines, Contacts) propriété de la personne identifiée. Il est a noter, que dans le cas d’un domaine, il peut être demandé de fournir le CodeAuth associé. Par exemple, dans le cas d’un mot-clé réservé (nom de ville, etc…). Le code est fourni (après vérification de l’organisme demandeur) par le registre et devra être indiqué lors du dépôt.
Contrairement à ce qui est indiqué sur l’article de Wikipédia, la majorité des opérations ne sont PAS exécutées en temps réel. Lorsque tel est le cas, le retour est signalé par le code 1000. Cela concerne particulièrement les opérations de type dépôt ou de création de contact.
Dans le cas d’une modification de DNS cette démarche est totalement logique, puisque l’Afnic par exemple, effectue un ZoneCheck avant de valider ou pas le nouveau paramétrage. Le délais de traitement reste très rapide, de l’ordre de quelques minutes.
Je vous invite à lire tous les codes dans les RFCs ou dans les guides d’intégration fournis par les registres pour plus de détails.
Plus d’info:
- http://www.bortzmeyer.org/search?pattern=epp
- http://www.afnic.fr/doc/interface/epp
Filed under: Réseaux Tagged: afnic, epp, xml