DNS & Domains

Validateur de noms de domaine

Un nom seul par ligne. Choisissez le mode correspondant au champ que vous configurez.

Validateur de noms de domaine

Un nom par ligne

Rapport de validation

Les noms sont vérifiés dans ce navigateur, sans requête DNS ni visite du domaine saisi.

Options de validation

Au moins deux étiquettes ; le point final est facultatif. Aucune liste de TLD n’est consultée.

UTS #46 non transitionnel · STD3 · NFC · Contrôles Bidi et caractères de jonction.

100 lignes non vides au maximum ; 65 536 unités UTF-16 au total, 4 096 par ligne. Le JSON inclut les entrées invalides.

Ouvrir le convertisseur Punycode

La saisie ou le mode a changé. Relancez la validation avant l’export.

Un Validateur de noms de domaine sert à distinguer une faute de saisie d’un problème de configuration. Un accent, un point compatible ou une étiquette trop longue après encodage peut expliquer un refus. Comparez la forme d’origine avec la forme ASCII avant de modifier les paramètres du service.

Pourquoi utiliser ce Validateur de noms de domaine

Mesurer après conversion

Le Validateur de noms de domaine compte les octets des étiquettes encodées. Une partie courte avec des accents peut produire une forme xn-- plus longue. Les longueurs du nom ASCII et du format DNS sont distinctes ; le point racine final reste visible sans entrer dans les 253 octets du corps.

Trois parties d’un nom deviennent des blocs ASCII de longueurs différentes, chacun accompagné d’une barre de mesure.

Conserver les lignes refusées

L’ordre, les doublons et les numéros de ligne d’origine restent dans le rapport. Une erreur ne masque pas les autres résultats. Le JSON inclut les noms invalides et des codes de diagnostic stables, ce qui permet de garder une trace des corrections nécessaires.

Des lignes de saisie rejoignent un rapport où une étiquette erronée est marquée en rouge parmi les lignes valides.

Choisir les règles du champ cible

01

Distinguer domaine et nom local

Le mode domaine demande deux étiquettes au minimum. Le mode hôte accepte printer. Ici, FQDN demande un point racine explicite et accepte également com. Aucun suffixe de recherche du système n’est ajouté.

02

Comparer les deux écritures

Ouvrez les détails des étiquettes pour lire leurs longueurs. La normalisation peut changer la casse ou les points compatibles ; le traitement non transitionnel conserve ß. Le texte d’entrée reste intact.

03

Figer le résultat à exporter

Désactivez l’automatisme pour utiliser Valider ou Ctrl/Cmd + Entrée. Toute modification désactive immédiatement l’ancien export. Les exemples et l’effacement affichent d’abord le nombre de lignes remplacées ; l’annulation restaure ensemble la saisie et le rapport.

Ce que mesure le rapport

Contrôler les noms de domaine internationalisés

Unicode et les étiquettes xn-- suivent le même profil strict UTS #46 non transitionnel. Il vérifie les caractères STD3, les traits d’union, le texte bidirectionnel et le contexte des caractères de jonction. Un encodage ACE mal formé n’est pas accepté simplement parce qu’il utilise de l’ASCII.

Vérifier chaque niveau du nom

Chaque étiquette encodée contient de 1 à 63 octets. Le nom ASCII avec ses points séparateurs ne dépasse pas 253 octets hors point racine. Le format DNS non compressé atteint au maximum 255 octets, avec les octets de longueur et celui de la racine.

Lire une erreur à sa place

La syntaxe des noms de domaine est contrôlée séparément pour chaque ligne non vide, jusqu’à 100 noms. Les lignes vides ne changent pas les numéros d’origine. Les 50 premiers résultats sont affichés, puis les suivants sur demande. L’export conserve toujours toutes les entrées.

Portée et limites des contrôles

Aucune conclusion sur la disponibilité
Il n’y a ni requête DNS, WHOIS, RDAP, HTTP ou certificat, ni comparaison avec une liste de TLD. Un suffixe inconnu peut respecter la syntaxe. Le rapport ne prouve donc ni réservation, ni résolution, ni disponibilité à l’achat, ni identité du titulaire.
Un profil de nom d'hôte précis
Les noms de service avec soulignement, les jokers et les noms DNS échappés par barre oblique inverse sont exclus. Le profil IDN strict refuse aussi deux traits d’union aux positions trois et quatre dans une étiquette non ACE. Les caractères autorisés sont donc plus limités que dans un simple contrôle LDH.
Uniquement le nom, sans extraction
Les espaces extérieurs sont supprimés par ligne. URL, port, chemin, adresse électronique, échappement pour cent et espaces internes sont rejetés. Dans un nom à plusieurs étiquettes, la dernière ne peut pas être entièrement numérique. Une étiquette numérique locale reste admise en mode hôte. 123 est admis comme nom local ; 123. est refusé car il désigne explicitement une étiquette numérique sous la racine.
Le point final est un choix de contrôle
Ce mode FQDN impose un point racine pour contrôler une écriture explicitement absolue. Cela ne signifie pas que toutes les représentations de FQDN doivent l’afficher. Le point seul, les points répétés et les étiquettes intermédiaires vides sont invalides.
Des limites qui ne tronquent pas le rapport
La saisie est limitée à 65 536 unités UTF-16, 4 096 par ligne et 100 lignes non vides. Un lot trop grand bloque l’export. Il n’y a ni import de fichier, ni tri, ni dédoublonnage, ni export des seuls noms valides ; le JSON garde les codes d’erreur.

Validateur de noms de domaine : questions

Combien de caractères peuvent contenir les différentes parties d'un domaine ?

Chaque étiquette peut occuper au maximum 63 octets après conversion ASCII. Le nom avec séparateurs est limité à 253 octets sans point racine ; avec ce point final, la représentation peut atteindre 254 caractères. Les 255 octets du format DNS comptent aussi les longueurs et la racine, pas seulement le texte affiché.

Le caractère de soulignement est-il accepté dans un nom d'hôte ?

Pas dans ce profil de nom d’hôte. Certains noms de service DNS, comme _dmarc ou _sip._tcp, utilisent pourtant un soulignement. Un refus ici indique que la chaîne ne respecte pas le profil sélectionné, et ne signifie pas que ces enregistrements DNS sont interdits.

Pourquoi faut-il éviter un trait d'union aux extrémités d'une étiquette ?

Les règles de nom d’hôte et d’IDN choisies refusent un trait d’union au début ou à la fin d’une étiquette. À l’intérieur, il est généralement permis, sauf notamment aux positions trois et quatre simultanément pour un nom non ACE dans ce profil strict.

Comment contrôler un domaine écrit avec des caractères non latins ?

Le nom est normalisé avec UTS #46 puis converti en Punycode. Les longueurs sont mesurées sur cette forme ASCII, et une entrée xn-- déjà encodée est également vérifiée. Le lien vers le convertisseur spécialisé ouvre un autre outil sans y envoyer automatiquement la saisie.

Quels contrôles faut-il effectuer avant de réserver un domaine ?

La syntaxe est une première vérification. Il faut ensuite contrôler séparément la disponibilité actuelle auprès d’un service de réservation ainsi que les exigences du registre et les droits attachés au nom envisagé. Cette page ne réalise pas ces contrôles : un résultat valide ne garantit pas que vous pourrez réserver le nom.

Un autre cas de domaine à vérifier ?

Vérifier avant de configurer

Utilisez le Validateur de noms de domaine pour relire les étiquettes encodées et conserver le résultat de chaque ligne avant la mise en configuration.