_ (Trait de soulignement) est-il illégal dans un enregistrement CNAME?

9

Nous avons du mal à créer le long enregistrement TXT pour la clé DKIM sur l'interface Web de notre hébergeur.

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 le suggèrent. Ni l'un ni l'autre ne fonctionne.

Ensuite, nous avons essayé de créer un cname pour un enregistrement sur un autre hébergeur, où nous pouvons créer les enregistrements DKIM TXT.

Mais maintenant, l'interface Web se plaint du nom illégal dans l' CNAMEenregistrement.

mail._domainkey.example.com TXTest ok
mail._domainkey.example.com CNAMEn'est pas ok
mail.domainkey.example.com CNAMEest ok, mais pas ce que nous voulons.

L'interface Web est-elle juste déterminée à nous rendre fous, ou est-ce vraiment «illégal» d'avoir des soulignés CNAME?

domain-name-system opendkim Lenne
la source
1
Le fournisseur corrige l'interface Web pendant que j'écris ceci!
Lenne

Réponses:

18

Oui, les noms DNS (cela inclut également A / AAAA) peuvent uniquement contenir [0-9], [a-z], -, le trait de soulignement n'est donc pas valide. Notez qu'un enregistrement TXT n'est pas un nom d'hôte et que cette restriction ne s'applique pas. Et une dernière modification: -ne peut pas non plus être utilisé comme premier caractère, donc mail.-domainkey.our.domne serait pas valide.

https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames

Édition finale: je me suis trompé en partie. Lorsqu'un CNAME est utilisé comme nom d'hôte, les restrictions ci-dessus s'appliquent. Il semble qu'un CNAME ne soit 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 /programming/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491

Sven
la source
Mais un CNAME est-il un nom d'hôte? Certaines documentations montrent qu'il faut utiliser le soulignement dans un cname, donc apparemment cela fonctionne. kb.mailchimp.com/accounts/email-authentication/…
Lenne
En outre, les traits de soulignement apparaissent dans les entrées DNS sur les zones intégrées à MS Windows Active Directory qui sous-tendent les domaines Windows, au moins dans l'outil de gestion DNS de Microsoft, mais je ne sais pas si ces traits de soulignement font réellement partie du nom et Windows prend en charge les traits de soulignement dans DNS ou si les traits de soulignement n'apparaissent que dans le composant logiciel enfichable de gestion DNS et ne font en fait pas partie des noms.
Todd Wilcox le
Notez que l'entrée Wikipédia citée concerne les noms Internet et non DNS.
Jim B
@ Lenne: Un CNAME est un nom d'hôte valide car c'est un alias pour un hôte. @ToddWilcox: oui, cela est connu, et il s'agit d'une violation (délibérée?) Des spécifications par MS qui n'a causé aucun problème à d'autres systèmes car ils apparaissent dans les paquets DNS, DHCP,… bien qu'ils ne soient pas légaux.
mirabilos
2
@mirabilos "Un CNAME est un nom d'hôte valide" non, la cible (RDATA) d'un CNAME est un nom de domaine, pas un nom d'hôte (un nom de domaine est un sur-ensemble de tous les noms d'hôte possibles). _foo CNAME _barest complètement légitime, vous pouvez tester avec named-checkzone.
Patrick Mevzek
2

Tous les caractères valides sont autorisés dans DNS. Voir https://tools.ietf.org/html/rfc2181#section-11

"DNS lui-même ne place qu'une seule restriction sur les étiquettes particulières qui peuvent être utilisées pour identifier les enregistrements de ressources. Cette restriction concerne la longueur de l'étiquette et le nom complet. La longueur d'une étiquette est limitée entre 1 et 63 octets. "

Le client doit valider les valeurs de nom EG, un enregistrement MX peut contenir la valeur "Alice" mais après la recherche, cette valeur doit être rejetée car "Alice" n'est pas une adresse e-mail valide.

Dans ce cas, il semble que votre hébergeur "valide" votre entrée, et il devrait pouvoir l'entrer manuellement pour vous.

Jim B
la source
"Tout caractère valide est autorisé dans DNS" c'est un peu plus compliqué que ça. Il existe des noms de domaine et des noms d'hôte. Sauf indication contraire, partout où vous avez des étiquettes qui sont des noms de domaine, ce qui signifie en effet n'importe quel caractère, ainsi _ou quoi que vous vouliez aussi. Mais, pour certains enregistrements, vous ne pouvez utiliser que des noms d'hôtes et non des noms de domaine. Les noms d'hôtes ne sont que des lettres, des chiffres et des tirets, rien d'autre. Par exemple, le propriétaire d'un Aou d' un AAAAenregistrement est un nom d'hôte, pas un nom de domaine. Le RDATA (cible) d'un NSenregistrement est également un nom d'hôte, pas un nom de domaine.
Patrick Mevzek
1
"un enregistrement MX peut contenir la valeur" Alice "mais après la recherche, cette valeur doit être rejetée car" Alice "n'est pas une adresse e-mail valide." Depuis quand les RR MX font-ils référence aux adresses e-mail?
un CVn
0

RFC 1034: Les étiquettes doivent suivre les règles des noms d'hôte ARPANET. Ils doivent commencer par une lettre, se terminer par une lettre ou un chiffre et avoir comme caractères intérieurs uniquement des lettres, des chiffres et un trait d'union. Il existe également des restrictions sur la longueur. Les étiquettes doivent contenir 63 caractères ou moins.

micmav
la source
J'ai également des problèmes avec Arduino, où certaines bibliothèques donnent un nom d'hôte comme ESP_245537, ce nom est rejeté lorsque le serveur DHCP tente de mettre à jour le DNS.
Lenne
C'est faux. L'étiquette d'un CNAME n'est pas nécessairement un nom d'hôte, donc tous les caractères sont valides ici, y compris le _.
Patrick Mevzek
1
Et même sans cela, ce sont les anciennes règles. Ils interdisaient les noms d'hôte commençant par un chiffre, mais pour accommoder 3com.compar exemple cette règle a été assouplie, voir tools.ietf.org/html/rfc1123#page-13 "Un aspect de la syntaxe du nom d'hôte est par la présente changé: la restriction sur le premier caractère est détendu pour autoriser une lettre ou un chiffre. "
Patrick Mevzek
@Lenne si esp_245537est utilisé comme nom d'hôte, la mise à jour DNS doit être refusée car ce n'est pas un nom d'hôte valide. Si celui-ci est utilisé comme nom de domaine, la mise à jour DNS doit réussir (sinon c'est un bogue), car il s'agit d'une étiquette DNS valide.
Patrick Mevzek
J'ai vu des indices qu'il est possible de traduire des caractères invalides de DHCP en DNS, mais je ne l'ai jamais fait fonctionner.
Lenne
0

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)

Patrick Mevzek
la source