verifier la validité d'un nom de domaine en php

Question

bonjour
je developpe un site d'hebergement, et j'i besoin d'un script qui verfie la disponibilté d'un nom de domaine.
comment faire ceci en php;
merci bcp

DiGhan · Answer

Hello,

il me semble qu'il faut ouvrir une connexion type socket sur le système de whois de l'Internic.

kankrelune · Answer

Tu peux utiliser les fonctions gethostby*
gethostbyname()

gethostbyaddr()

gethostbynamel()

Sinon il y a des service de whois qui permette de savoir si un nom de domaine est enregistré ou non... .. .

@ tchaOo°

l'homme est un loup pour l'homme... .. .

coucou747 · Answer

Salut,
[auteurdetail.aspx?ID=234428 DiGhan]
             , j'ai un script pour ça, mais chez moi...

les réponses aux whois sont vraiment hasardeuses... ça dépend de plein de choses, y compris du serveur auquel on s'est connecté... gethostbyname marchera mieux...

In a dream, I saw me, drop dead... U was there, U cried... It was just a dream, if I die, U won't cry, maybe, U'll be happy

juki_webmaster · Answer

Salut,

ça ne sert strictement à rien d'interoger les serveurs Whois publique.
La plupart des Whois publique dispose de protection anti flood, ce qui limite à X interogation de leurs base de données par IP / 24h, de plus leurs reponses sont mitigé.

Pour du pro :
Chaque registrar dispose d'une API fournit par l'organisme qui edite le TLD.
Sinon ya eurodns.com qui fournis une API, faute de devenir dependant d'EuroDNS.

verdy_p · Answer

Désolé de vous le dire mais un test basé sur getHostByName() n'est pas sensé indiquer que le nom de domaine existe et peut être réservé: un domaine peut être réservé sans pour autant qu'un nom d'hôte dans le domaine existe. D'ailleurs si on résoud un nom de domaine comme "example.com", il n'y a pas forcément un hôte: il peut n'y avoir que l'enregistrement d'un serveur de messagerie, ou uniquement l'indication d'un ou plusieurs serveurs de domaine "maîtres" (SOA) pour ce domaine, ce serveur se chargeant de résoudre ensuite les noms d'hôtes dans le domaine, où il n'y a aucune garantie ni obligation qu'il y existe un nom d'hôte "www".
La bonne solution pour savoir si un domaine est réservé est bien une requête Whois, mais il faut connaitre le serveur de domaine de base hébergeant ce domaine : cela dépend du TLD: chaque TLD a son serveur Whois (de même que le domaine root géré par l'IANA au sein de l'ICANN : cela permet de savoir si un TLD global existe bien et est valide, une précaution à prendre quand on sait que les TLDs vont se multiplier).

Ensuite si on veut savoir si un nom de domaine est utilisable dans une adresse de courriel, il faut faire une requête DNS pour rechercher l'existence d'une entrée de type "MX" (afin de savoir quel serveur de messagerie prend en charge le routage des courriels qui lui sont adressés), puis tenter une connexion et un envoi de courriel à l'adresse indiquée (envoi en SMTP: attention à ne pas le spammer même pour faire un simple test!)

Pour savoir si un nom de domaine héberge un site web, il faut aussi indiquer le nom d'hôte sur ce domaine (souvent "www" pas pas nécessairement). Noter aussi que certains domaines ont un hôte par défaut (anonyme) ne nécessitant pas l'indication du nom d'hôte avant le nom de domaine: ce n'est QUE dans ce cas là que la résolution par getHostByName() va réussir, à condition que cet hôte dispose d'une adresse IPv4 (il existe des hôtes accessibles uniquement en IPv6 et getHostByName() n'est souvent pas prévu pour ne retourner qu'une adresse IPv6 mais seulement une adresse IPv4. Dans les deux cas, getHostByName() va effectuer une requête DNS vers le serveur DNS maitre (SOA) gérant le domaine pour y rechercher un enregistrement de type "A" (pour obtenir une adresse IPv4) ou "AAAA" (pour obtenir une adresse IPv6) ou "ANY" (toute adresse valide). Cette résolution peut retourner aussi une adresse IPv4 ou IPv6 changeante de façon aléatoire (qui ensuite est maintenue en cache par votre client DNS ou votre serveur DNS amont auquel vous êtes connecté (sur votre LAN s'il en a un, ou nu serveur DNS cache fourni par fotre FAI via la connexion Internet établie par votre modem ou routeur)

L'existence d'un hôte résolu en IPv4 ou IPv6 ne signifie pas non plus qu'il y supporte un serveur Web, et rien ne mentionne non plus que ce serveur utilise les ports par défauts (port TCP/80 pour HTTP, port TCP/21 pour FTP, etc.).

Cela n'indique pas non plus que tous les protocoles seront routables vers cet hôte (il est courant qu'un hôte ne réponde pas au PING en IPv4 ou IPv6 car il bloque le traffic ICMP ou ICMPv6, ce qui bloque aussi les tests de routabilité par "traceroute" qui permet de tenter des tests ping sur chaque routeur ou hôte le long de la chaîne de routage.) Ni que les autres services hébergés existent.

Dernier point: un nom de domaine peut être réservé sans pour autant réussir aucun de ces tests DNS (c'est le cas pour les domaines bloqués ou en cours de renouvellement): normalement on doit les trouver dans la base WHOIS du TLD où ce nom de domaine a été réservé, cependant il peut y avoir un délai de 24 heures pour l'activation (même en interrogeant le serveur WHOIS du TLD lui-même et non un des caches souvent hébergés par les autres TLD).

Pour ce qui nous concerne, ce petit délai d'activation (ou le bloquage par suite de renouvellement pas encore réalisé mais sur un domaine qui reste tout de même réservé) peut être ignoré dans les cas courants: c'est bien la requête WHOIS qui vérifie la validité d'un domaine réservé.

Mais pour savoir si un domaine peut être réservé, ce n'est pas suffisant: il faut interroger un registrar qui va faire une requête WHOIS pour savoir si le domaien est à priori disponible, puis commander la réservation (et la payer): un tiquet de réservation sera émis par le registrar au registre gérant le TLD, ce tiquet sera accepté et pris en compte dans l'ordre "premier demandé, premier servi" et inscrit le lendemain dans la base WHOIS du TLD :

Alors le registrar encaissera définitivement votre paiement, inscrira le domaine dans la base WHOIS du TLD, et en avisera l'hébergeur DNS de votre domaine (si ce n'est pas lui-même) pour qu'il ajoute les energistrements DNS demandés (infos de gestion des caches DNS, dates de validités, serveur MX, hôtes A ou AAAA, autres infos textuelles et services propre au domaine), et enregistrera les serveurs DNS de votre hébergeur de domaine dans le serveur DNS du TLD pour votre nom de domaine.

Cela n'est pas suffisant pour pouvori héberger vos serveurs et services: il vous faut aussi une réservation d'adresse IPv4 et/ou IPv6 et cela passe par une autre réservation (faite par votre hébergeur ou votre FAI ou que vous pouvez faire vous même si vous voulez un bloc d'adresses IP dédiées à vos hôtes ou serveurs).

Cette réservation est aussi payante (mais généralement payée avec votre contrat d'hébergement de service) et ne passe pas par les mêmes DNS: c'est l'IANA via les RIRs continentaux et les LIR régionaux qui attribue les réservations de blocs d'adresses. C'est votre FAI ou hébergeur qui ensuite vous la réattribue (si vous n'avez pas d'adresse IP dédiée). Une fois un bloc d'adresses IPv4 ou IPv6 réservé (ce qui se fait complètement séparément de la réservation du domaine), il faut aussi l'annoncer au reste du réseau global pour qu'elle soit routable: c'est votre FAI qui s'en occupe avec un protocole sécurisé échangeant des informations de routage d'un domaine de routage à l'autre (les domaines de routage sont distincts des domaines web et évoluent en permanence, cependant l'association d'un bloc d'adresses IP avec un réservataire est aussi inscrite dans un DNS séparé sur le TLD ".arpa": cette hiérarchie DNS sert aux recherches "inversées" permettant de convertir récursivement une adresse IP d'un grand bloc en nom d'hôte, en permettant de rechercher quel serveur DNS inversé s'occupe de gérer les délégations de sous-blocs d'adresses IP

Sur le DNS inversé du bloc le plus petit réservé par votre hébergeur ou FAI, on trouve l'identité du domaine auquel les adresses sont attribuées, on y trouve aussi éventuellement des noms de domaien par défaut pour les hôtes, mais ces noms dits "canoniques" peuvent être très différents de ceux utilisés par vos services, et donc mentionner un nom dans un domaine propre à votre hébergeur ou FAI au lieu du nom d'un nm d'hôte dans votre domaine; ces noms ne seront identiques QUE si vous avez obtenu une délégation directe du bloc d'adresses à votre nom, donc si vous les avez achetées directement à votre nom pour router par exemple des serveurs dédiés, et dans ce cas, vous POUVEZ, sans obligation, éventuellement faire héberger les enregistrements DNS inversés sur le serveur DNS gérant votre domaine (à charge pour vous ensuite de vous assurer que votre serveur DNS contiendra les résolutions inversées dans le sous-domaine correspondant de la hiérarchie .arpa où seront inscrits les noms canoniques de vos hôtes).

Attention aussi: un nom d'hôte canonique est unique pour une adresse IP donnée, alors que vos hôtes et serveurs (ou ceux de votre hébergeur web) peuvent héberger des services pour différents domaines: ce sera le cas si vous n'avez pas d'adresses IP dédiées et si votre service est routé par votre FAI ou bien hébergé sur des serveurs mutualisés (cas des hébergeurs web gratuits). Ces noms canoniques sont donc le plsu souvent différents des noms de vos domaines pour vos services ou adresses de messagerie. Les blocs d'adresses IP réservés et enregistrés ainsi de façon inversée sont aussi l'objet d'une inscription obligatoire dans une base WHOIS (gérée par les RIR ou LIR). Ces enregistrements sont très importants et indispensables à la sécurité globale du web et sont même demandés AVANT que vos adresses IP soient routables: les différents domaines de routage vérifieront cette base WHOIS pour autoriser ou non le traffic IP d'un routeur à l'autre entre deux domaines de routage. C'est pourquoi c'est cette étape de réservation IP et d'enregistrement qui précède toutes les autres (puisqu'elle est aussi indispensable y compris pour router le traffic vers les serveurs DNS maîtres pour vos noms de domaines ou vos adresses IP inversées), et conditionne ensuite le fait que vos serveurs et services seront accessibles depuis le monde entier (sauf en cas de bloquage dans un parefeu entre deux domaines de routage, ou de rejet des annonces de routage falsifiées non inscrites dans les serveurs WHOIS inversés de la hiérarchie .arpa)

Noter enfin que l'hébergeur DNS de votre nom de domaine n'est pas nécessairement non plus l'hébergeur des serveurs Internet (web, etc...). Il est en fait très courant que ceux-ci soient différents (le serveur DNS d'un domaine, celui enregistré dans le serveur DNS de son TLD) est la ressource la plus critique et doit répondre aux requêtes (même si c'est pour mentionner qu'un nom d'hôte hôte A ou AAAA ou MX n'existe pas pour ce domaine): les hébergeurs de DNS offrent pour cela des hébergements nettement plus stables et sécurisés (et qui disposent d'outils de supervision et de contrôle du traffic contre les attaques éventuelles) qui permettent d'éviter que l'hébergement de vos hôtes et services (web, courriel) soient submergés sur leur liaison. De plus les hébergeurs DNS sont souvent physiquement situés à des endroits plus appropriés avec une connexion plus directe au "backbone mondial" pour supproter des traffics très importants, alors que votre service web ou de messagerie (ou bien les hôtes que vous avez ajoutés à votre domaine) n'est pas taillé souvent pour supporter cette charge.

Enfin les serveurs DNS maîtres des hébergeurs DNS ont souvent des parefeux beaucoup plus stricts (ils n'autorisent que le traffic des requêtes DNS entre les ports TCP ou UDP numéro 67 du serveur DNS ou UDP numéro 68 du client DNS.) mais ne laissent pas passer le reste du traffic web (HTTP, HTTPS, FTP, SMTP, RTP, ICMP, etc...) y compris pour les serveurs et services que vous avez inscrits dans votre domaine.

Tout ça semble bien compliqué pourtant c'est comme ça que le web fonctionne et assure sa stabilité: il y a de nombreuses couches indépendantes entre elles et ayant chacune leurs propres règles de fonctionnement, et de nombreux interlocuteurs avec des responsabilités différentes.

verdy_p · Answer

Tout ça pour dire que: pour répondre à la question initialement posée, si vous envisagez de créer un service d'hébergement et vérifier qu'un nom de domaine existe pour pouvoir le réserver au nom de votre client c'est une requête WHOIS qu'il faudra faire vers un des serveurs WHOIS du registre gérant le TLD. Il vous faudra contacter un registrar pour obtenir un compte d'enregistrement pour vos clients et signer un contrat avec lui (vous devrez vous engager à fournir les éléments demandés à vos clients sur leur identité et vous affranchir des frais administratifs). Si vous voulez devenir vous-mêm un registrar, il vous faudra contacter un ou plusieurs des registres de TLD que vous allez revendre (et fournir encore plus d'informations et payer TRES CHER) tout en vous engageant à respecter les conditions imposées pr l'ICANN.

La question posée « comment le faire en PHP » est très secondaire : ce n'est pas par là qu'il faut commencer et tout dépendra du type d'interface que votre site utilisera pour interroger la base WHOIS de vos domaines hébergés. Faire une requête WHOIS en PHP n'est pas difficile, c'est un protocole simple, qui n'est pas codé avec des structures binaires complexes comme pour le DNS, et nécessitant juste l'ouverture d'une socket TCP vers le serveur WHOIS à qui vous envoyez une chaine de requête, et à laquelle le serveur WHOIS va répondre avec un bloc de texte contenant les infos demandées sur un domaine: il vous faut donc juste connaitre donc le nom du serveur WHOIS à interroger pour le TLD où serait inscrit le domaine, et indiquer ce nom de serveur comme nom d'hôte à ouvrir dans la socket. Le numéro de port pour WHOIS est fixe et standardisé entre tous les serveurs WHOIS des TLD du monde (c'est le même numéro de port aussi et le même protocole pour interroger les serveurs WHOIS inversés de la hiérarchie ".arpa").

Consultez les RFC sur WHOIS, elles ne sont pas compliquées à comprendre pour créer votre client WHOIS en PHP avec une socket TCP toute bête.

Attention toutefois: les infos contenues dans les serveurs WHOIS sont protégées par le droit (elles sont affichées sommairement dans des commentaires au début du bloc de texte renvoyé avec la réponse à votre requête), vous ne pouvez pas en faire ce que vous voulez et si vous dépassez un quota d'utilisation sur un serveur WHOIS, celui-ci peut vous bloquer en limitant le nombre de requêtes autorisées par heure!

Le texte retourné par la requête WHOIS adopte un format particulier: il y a plusieurs standards selon les serveurs TLD interrogés, mais c'est une suite de lignes qui sont soient vides, soit des commentaires avec un préfixe, soit formatées avec l'(indication du type de données, un deux-points ":" et la ou les valeurs pour ce type. On y trouve les noms et adresses des réservataires (parfois aussi des numéros de téléphone, de fax, ou des infos de contact administratifs, ou pour gérer des problèmes de sécurité, ainsi que les identités des registrars), et les infos sur les DNS "maîtres" hébergeant le domaine faisant l'objet de votre demande (soit leur adresse IP ou le plus souvent leur nom de domaine).

verdy_p · Answer

Ceci dit, pour éviter de "flooder" le serveur WHOIS avec vos requêtes, il n'est pas inutile de faire avant un test DNS pour le nom de domaine avec getHostsByName() afin de savoir si le nom désiré est déjà résolu (et donc réservé et réservé par quelqu'un d'autres). Le système DNS supporte nettement mieux le traffic (grace au système des DNS cache déployés partout sur le web). Si l'adresse IP résoud, on peut alors tenter uen recherche DNS inversée pour connaitre qui a réservé le domaine: si on obtient en réponse un nom d'hôte dans le domaine demandé, on n'a plus qu'à interroger le serveur DNS de ce domaine pour obenir l'identité du propriétaire du domaine et savoir alors quel serveur WHOIS (fonction du TLD) contient les infos demandées. Si on obtient un nom d'hôte inversé dans un autre domaine, ou interrogera le serveur DNS indiqué malgré tout pour savoir s'il gère le domaine (ce n'est pas une obligation, le domaine demandé peut être hébergé sur un autre serveur DNS maitre).

Mais si vous tenez réellement à afficher les infos WHOIS, n'oubliez pas de maintenir un cache de vos requêtes passées.

Et n'autorisez pas non plus vos visiteurs à faire un nombre inconsidéré de requêtes via votre site: limitez les en maitenant un cache des adresses IP de vos visiteurs ayant fait cette requête via votre service: forcez les à patienter pour préserver votre propre quota s'il font des requêtes à des domaines pour lesquels votre cache WHOIS n'a pas d'informations sur le domaine; en revanche, un visiteur porrait refaire cette requête autant de fois que nécessaire pour un mêmr domaine: votre serveur retournera simplement les infos qu'il a déjà dans son cache temporaire (votre cache WHOIS, stocké dans une base de données ou un ensemble de fichiers, devrait avoir une durée de conservation limitée à 24 heures, et devrait purger les données trop anciennes automatiquement et qui ne sont plus forcément pertinentes).

Verifier la validité d'un nom de domaine en php

7 réponses

Votre réponse

Discussions similaires