La réponse de @ Sven, avec la modification, est déjà juste, mais juste pour exprimer les choses directement.
TL; DR oui le soulignement est valide dans un CNAMEenregistrement des deux côtés, lisez ci-dessous pour savoir pourquoi.
La RFC 1034 et d'autres définissent des enregistrements basés sur des "noms de domaine" qui sont des étiquettes avec n'importe quel caractère, donc y compris _.
Mais certains enregistrements ont des règles plus strictes pour le nom du propriétaire et / ou les données de ressource (RDATA). Là, seul un nom d'hôte sera accepté et en effet, les règles sont maintenant (elles étaient assouplies dans le passé où un nom d'hôte ne pouvait pas commencer par un chiffre) que vous pouvez utiliser n'importe quelle lettre ASCII (pas de respect de la casse), tous les chiffres ASCII et les tirets , plus quelques règles de position supplémentaires: pas de trait d'union au début ou à la fin et pas de double trait d'union aux positions 3 et 4 (en raison de la "réservation" pour les IDN qui sont de la forme xn--qui est uniquement autorisée par la casse).
Par exemple, le nom du propriétaire d'un Aou d' un AAAAenregistrement est un nom d'hôte, pas un nom de domaine. Il test.example.com A 192.0.2.1est donc
valable pourquoi tous ces éléments ne sont pas:
_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1
Il est facile de tester des choses avec le named-checkzoneprogramme (une partie du bindlogiciel du serveur de noms mais peut être utilisée et installée séparément et d'autres serveurs de noms peuvent avoir des outils de vérification similaires et il y a probablement des interfaces en ligne pour cela aussi de toute façon), il suffit de mettre des enregistrements dans un fichier et de l'exécuter sur:
$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)
(le nombre avant le INest le TTL, ceci n'est pas lié à notre problème ici, mais il suffit de passer la validation de la syntaxe d'un enregistrement).
Pour les autres enregistrements, c'est l'inverse: car NSil n'y a pas de restrictions sur le propriétaire, mais des restrictions sur la "cible" que sont les données. Les données ne peuvent être qu'un nom d'hôte, pas un nom de domaine, car vous devez pointer vers des serveurs de noms faisant autorité qui sont des hôtes physiques qui répondent aux requêtes DNS.
Maintenant CNAME, voici les citations pertinentes de la RFC 1034, dans la section 3.6:
"propriétaire: qui est le nom de domaine où se trouve le RR." ce qui signifie par défaut n'importe quel nom, pas seulement un nom d'hôte (comme source de l'enregistrement CNAME)
"RDATA: qui est le type et parfois les données dépendant de la classe qui décrivent la ressource:"
"CNAME un nom de domaine."
Ainsi, à la fois le propriétaire d'un CNAME(ce qui est à gauche) et les données de ressource qui lui sont attachées, sa destination / cible (ce qui est à droite) sont des noms de domaine, et pas seulement des noms d'hôte. Fondamentalement, n'importe quel caractère, donc l'inclusion _est autorisée des deux côtés.
Encore une fois, facile à tester avec named-checkzone:
$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.
Aucune erreur sur le CNAME(les autres erreurs sont attendues car dans ma fausse zone je n'en ai pas mis SOAou des NSenregistrements comme une vraie zone l'aurait fait)