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.

Astuces d'utilisation

  • 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.

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.
ツールくん

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.

→ Voir toutes les anecdotes