Est-ce que _ (Underscore) illégal dans un enregistrement CName?
Nous avons du mal à créer le long TXT pour la touche DKIM de l'interface Web de notre Hoster.
Chaque ligne ne peut accepter que 256 caractères.
Nous avons essayé plusieurs lignes, puis essayé d'ajouter (" au premier et ") après le dernier comme certains suggèrent. Ni fonctionne.
Ensuite, nous avons essayé de faire un nom d'information sur un enregistrement sur un autre hébergement, où nous CAN Faire le dkim TXT enregistrements.
Mais maintenant, le webinterface se plaint du nom illégal dans l'enregistrement CNAME.
mail._domainkey.example.com TXT ça va
[.____] mail._domainkey.example.com CNAME ça ne va pas
[.____] mail.domainkey.example.com CNAME ça va, mais pas ce que nous voulons.
L'interface Web est-elle juste déterminée à nous rendre fou, ou est-ce vraiment "illégale" d'avoir des traits de soulignement dans CNAME?
Oui, les noms DNS (ceci incluent également A/AAAA) ne peuvent contenir que [0-9], [a-z], -, le soussecore n'est donc pas valide. Notez que A TXT n'est pas un nom d'hôte, et cette restriction ne s'applique pas pour cela. Et une dernière modification: - Peut ne pas être utilisé comme premier caractère non plus, alors mail.-domainkey.our.dom ne serait pas valide.
https://fr.wikipedia.org/wiki/hostname#restrictions_on_valid_hostnames
Final Modifier: J'étais partiellement tort. Lorsqu'un nom CNAME est utilisé comme nom d'hôte, les restrictions ci-dessus s'appliquent. Il apparaît qu'un CNAME n'est pas considéré comme un nom d'hôte dans le contexte DKIM et dans ce cas, _ devrait être une partie valide d'une entrée CNAME. Voir https://stackoverflow.com/questions/13650233/underscore-in-cname-required-by-ses-not-byved-by-registrar/26692491#26692491
Tous les caractères valides sont autorisés dans DNS. Voir https://tools.ietf.org/html/rfc2181#ssectionn-11
"DNS lui-même ne place qu'une seule restriction sur les étiquettes particulières pouvant être utilisées pour identifier les enregistrements de ressources. Cette restriction se rapporte à la longueur de l'étiquette et au nom complet. La longueur de toute étiquette est limitée à 1er et 63 octets. "
Le client doit valider les valeurs de nom, par exemple un enregistrement MX peut contenir la valeur "Alice", mais après la recherche que la valeur doit être rejetée car "Alice" n'est pas une adresse électronique valide.
Dans ce cas, il semble que votre hébergement soit "validant" votre entrée, et ils devraient pouvoir le saisir manuellement pour vous.
RFC 1034: Les étiquettes doivent suivre les règles des noms d'hôtes Arpanet. Ils doivent commencer par une lettre, se terminer par une lettre ou un chiffre et avoir uniquement des caractères d'intérieur que des lettres, des chiffres et un trait d'union. Il y a aussi quelques restrictions sur la longueur. Les étiquettes doivent être de 63 caractères ou moins.
@ La réponse de Sven, avec la modification, a déjà raison, mais juste pour former des phrases directement.
TL; DR Oui Underscore est valide dans un enregistrement CNAME des deux côtés, lisez ci-dessous pourquoi.
RFC 1034 et d'autres personnes définissent des enregistrements sur la base de "noms de domaine" qui sont des étiquettes avec n'importe quel caractère, y compris _.
mais Certains enregistrements ont des règles plus strictes pour le nom du propriétaire et/ou les données de ressources (RDATA). Seul un nom d'hôte sera accepté et, en effet, les règles sont maintenant (elles ont été détendues dans le passé où un nom d'hôte n'a pas pu démarrer avec un chiffre) que vous pouvez utiliser n'importe quel ASCII (sans cas de sensibilité au cas. ), tout ASCII chiffres et les traits d'union, ainsi que des règles de position supplémentaires: aucun trait d'union au démarrage ou à la fin et à double trait d'un trait en position 3 et 4 (en raison de "réservation" pour les IDN qui sont de la forme xn-- qui n'est que l'affaire autorisée).
Par exemple, le nom du propriétaire d'un enregistrement A ou AAAA est un nom d'hôte, pas un nom de domaine. Donc test.example.com A 192.0.2.1 est valable pourquoi tout cela 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 les choses avec le named-checkzone Programme (une partie du logiciel de noms de noms de noms bind peut être utilisé et installé séparément et d'autres noms de noms peuvent avoir des outils de vérification similaires et il y a probablement des interfaces en ligne pour cela aussi), il suffit de mettre des enregistrements dans un fichier et d'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 IN est le TTL, cela n'est pas liée à notre problème ici, mais il est nécessaire de passer simplement la validation de la syntaxe d'un enregistrement).
Pour d'autres enregistrements, c'est le contraire: pour NS Il n'y a aucune restriction sur le propriétaire, mais des restrictions sur la "cible" qui correspond aux données. Les données ne peuvent être qu'un nom d'hôte, et non un nom de domaine, car vous devez indiquer des serveurs de noms autoritatifs qui sont des hôtes physiques qui répondent aux requêtes DNS.
Maintenant, environ CNAME, voici les citations pertinentes de la RFC 1034, à la section 3.6:
"Propriétaire: Quel 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 (en tant que source de l'enregistrement CName))
"RDATA: Quel est le type et les données dépendantes parfois de la classe décrivant la ressource:"
"CNAME Un nom de domaine."
Alors le propriétaire d'un CNAME (ce qui est à gauche de celui-ci) et que les données de ressources sont jointes à celle-ci, sa destination/cible (ce qui se trouve à droite) sont des noms de domaine et non des noms d'hôte seul. Fondamentalement n'importe quel caractère, y compris _ est autorisé 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 quant à ce que ce soit sur le CNAME (les autres erreurs sont attendues depuis que dans ma fausse zone, je n'ai pas mis de SOA ou NS enregistrements comme une zone vraie aurait)