Validateur de noms de domaine (vérification de conformité RFC)

Vérifie si un nom de domaine respecte les règles de syntaxe des RFC 1035/1123. Valide individuellement la longueur de chaque étiquette, la longueur totale, les caractères autorisés et la position des tirets, en indiquant le motif précis de toute infraction.

Qu'est-ce que le validateur de noms de domaine ?

Le validateur de noms de domaine vérifie point par point si une chaîne saisie respecte les règles de syntaxe des noms de domaine définies par les RFC 1035 (publiée en 1987) et RFC 1123 (publiée en 1989), en évaluant chaque règle individuellement plutôt qu'en renvoyant un simple verdict « valide ou non valide ». Comme il indique précisément quelle règle a été enfreinte et, le cas échéant, quelle étiquette (chacune des parties d'un domaine séparées par des points) en est la cause, il est particulièrement utile lorsque vous savez déjà qu'une chaîne de domaine est rejetée quelque part sans en connaître la raison.

Il est important de comprendre ce que cet outil ne fait pas : il ne vérifie que la syntaxe, c'est-à-dire la forme de la chaîne en tant que texte. Il n'interroge pas le DNS pour confirmer que le domaine est réellement enregistré, ne vérifie pas qu'un site web fonctionne à cette adresse et n'indique pas si le nom est actuellement disponible à l'enregistrement. Il convient donc parfaitement pour confirmer qu'un nom candidat pour un nouveau domaine, ou un nom d'hôte que vous intégrez dans un fichier de configuration, est syntaxiquement correct avant de franchir l'étape supplémentaire de l'enregistrement ou du déploiement.

Comment utiliser le validateur de noms de domaine

  1. Saisir un nom de domaine Saisissez dans le champ le nom de domaine à vérifier (par exemple example.com). Retirez au préalable tout protocole en début de chaîne comme `https://` ou tout chemin en fin de chaîne comme `/path`, afin de ne conserver que la partie domaine.
  2. Consulter le résultat de la validation Dès la saisie, six règles sont évaluées en temps réel et chacune est marquée Conforme, Non conforme ou Remarque.
  3. Lire le motif d'une non-conformité Chaque ligne marquée Non conforme comporte un motif précis, comme l'étiquette en cause ou son nombre de caractères, afin que vous sachiez exactement quelle partie de la chaîne modifier.
  4. Tester les boutons d'exemple pour voir les cas limites Les boutons Exemple valide et Exemple invalide remplissent le champ avec des chaînes d'exemple situées juste aux limites des règles, ce qui permet de voir rapidement le comportement de chacune.

Astuces pour en tirer le meilleur parti

  • Cet outil valide selon les règles de syntaxe définies par les RFC 1035/1123 ; il ne vérifie pas si le domaine est réellement enregistré ou résoluble via le DNS.
  • Avant d'écrire votre propre expression régulière de validation pour un formulaire, testez cet outil sur les cas limites (exactement 63 caractères, position des tirets, etc.) afin de vous assurer que votre implémentation les couvre.
  • Une saisie contenant des caractères non ASCII, comme un nom de domaine en japonais, ne fait qu'ignorer la vérification du jeu de caractères. Convertissez-la d'abord en notation `xn--` avec le convertisseur Punycode pour une vérification totalement précise.
  • Un TLD entièrement numérique ne se produit quasiment jamais en pratique, mais il est volontairement inclus pour détecter les saisies pouvant être confondues avec une adresse IP lors de la validation d'un formulaire.
  • Le même ensemble de règles peut s'appliquer à la partie d'une adresse e-mail située après le symbole `@`, ce qui en fait aussi une vérification légère du domaine de messagerie.

Dans quels cas utiliser cet outil

Vérifier une expression régulière de validation avant sa mise en production

Avant d'écrire votre propre expression régulière pour valider un champ de domaine, testez ici les cas limites — une étiquette d'exactement 63 caractères, un tiret tout au début ou à la fin — afin de repérer tôt les lacunes de votre implémentation.

Vérifier à l'avance un nom candidat pour un nouveau domaine

Lorsque vous choisissez le nom d'un nouveau service ou d'un sous-domaine, vous pouvez confirmer sa correction syntaxique avant même de le rechercher chez un bureau d'enregistrement.

Contrôler ponctuellement la partie domaine d'une adresse e-mail

Comme la partie d'une adresse e-mail située après le symbole @ suit généralement les mêmes règles de nom d'hôte, cet outil sert aussi de contrôle secondaire léger pour votre logique de validation des e-mails.

Rechercher la cause d'un rejet

Si un système signale qu'une chaîne n'est « pas un nom de domaine valide » sans que la raison soit évidente, collez-la ici pour identifier précisément la règle non respectée.

Glossaire

Étiquette
Chacun des segments d'un nom de domaine séparés par des points. Dans www.example.com, il y a trois étiquettes : « www », « example » et « com ». La RFC 1035 fixe les limites de longueur et de caractères au niveau de l'étiquette, et non du domaine dans son ensemble.
TLD (domaine de premier niveau)
L'étiquette la plus à droite d'un nom de domaine, comme .com ou .fr. Elle se situe au sommet de la hiérarchie DNS, juste en dessous de la racine invisible.
FQDN (nom de domaine pleinement qualifié)
Un nom de domaine écrit intégralement, du nom d'hôte jusqu'au TLD, sans omettre aucune partie. Strictement parlant, un FQDN se termine par un point final représentant la racine du DNS (par exemple example.com.), même si ce point final est généralement omis dans l'usage courant.
IDN (nom de domaine internationalisé)
Un nom de domaine contenant des caractères non ASCII, comme le japonais, le chinois ou l'écriture arabe. Le DNS lui-même ne pouvant traiter que des caractères ASCII, un IDN est converti en Punycode avant d'être réellement enregistré ou résolu.
Punycode
Un procédé d'encodage qui convertit la partie non ASCII d'un IDN en une chaîne ASCII que le DNS peut traiter, préfixée par xn--. Les navigateurs reconvertissent généralement cette chaîne dans les caractères d'origine pour l'affichage dans la barre d'adresse.
Format de transmission
Le format binaire dans lequel les requêtes et réponses DNS sont réellement échangées sur le réseau. Chaque étiquette est précédée d'un octet unique indiquant sa longueur, et cet octet ne peut représenter que des valeurs de 0 à 63, ce qui est à l'origine technique de la limite de 63 caractères par étiquette.
Nom d'hôte
Un nom utilisé pour identifier un appareil sur un réseau. Il s'agit d'un type particulier de nom de domaine, et la RFC 1123 restreint les caractères qu'un nom d'hôte peut utiliser aux lettres, chiffres et tirets — exactement l'ensemble de règles que cet outil vérifie.

Questions fréquentes

Selon la RFC 1035, chaque étiquette (la partie entre les points) peut comporter de 1 à 63 caractères, et le domaine entier jusqu'à 253 caractères (dérivé de la limite de 255 octets du format de transmission). Notez que les registres peuvent imposer des restrictions supplémentaires au-delà de ces limites.

Selon les RFC 1035/1123, seuls les lettres, les chiffres et les tirets sont autorisés dans un nom d'hôte ; les tirets bas ne sont pas permis. Ils apparaissent cependant dans des étiquettes DNS qui ne sont pas des noms d'hôte, comme les enregistrements TXT ou SRV (par exemple `_dmarc.example.com`).

La RFC 1123 exige que chaque étiquette commence et se termine par un caractère alphanumérique. Autoriser un tiret en début ou en fin rendrait l'analyse ambiguë et risquerait de poser des problèmes de compatibilité avec d'anciennes implémentations DNS.

Les noms de domaine internationalisés (IDN) contenant des caractères comme le japonais doivent être convertis en Punycode (notation ASCII commençant par `xn--`) avant d'être enregistrés dans le DNS. Cet outil étant conçu pour valider la chaîne déjà convertie en Punycode, il est recommandé de convertir d'abord le domaine non ASCII avec le convertisseur Punycode, puis d'effectuer ici la vérification de syntaxe.
Tool-kun

Anecdote — Pourquoi la validation des noms de domaine est-elle sans cesse réinventée

La vérification de la syntaxe d'un nom de domaine paraît, au premier abord, pouvoir se résoudre avec une simple expression régulière ; c'est pourtant un domaine où de nombreux développeurs ont trébuché avec leurs propres implémentations. De la validation d'e-mails dans les formulaires à l'analyse de noms d'hôte dans les fichiers de configuration, en passant par la validation d'URL dans les API, les « chaînes ressemblant à des domaines » apparaissent partout, mais les implémentations reflétant fidèlement les règles officielles des RFC 1035 (1987) et RFC 1123 (1989) restent étonnamment rares.

La limite de longueur à deux niveaux — 63 caractères par étiquette, 253 au total — provient directement de la conception du format de transmission du DNS (le format binaire réellement échangé sur le réseau). Chaque étiquette est précédée d'un octet indiquant sa longueur, et cet octet est limité à la plage 0-63 (la valeur maximale représentable sur 6 bits), ce qui explique directement la limite de longueur des étiquettes.

La convention selon laquelle un TLD ne devrait pas être entièrement numérique a elle aussi une histoire intéressante. Il ne s'agit pas d'une règle imposée par une RFC, mais plutôt d'une pratique d'implémentation largement adoptée pour distinguer les noms de domaine des adresses IPv4 (suites de chiffres et de points). De nombreux résolveurs DNS et navigateurs utilisent cette convention pour décider qu'une chaîne telle que 192.168.1.1 doit être traitée comme une adresse IP plutôt que comme un nom de domaine.