10. Naming issues (Problèmes de nommage)
Il a parfois été déduit de certaines sections de la spécification DNS [RFC1034, RFC1035] qu'un hôte, ou peut-être une interface d'un hôte, est autorisé exactement un nom autoritaire ou officiel, appelé le nom canonique. Il n'y a pas une telle exigence dans le DNS.
10.1. CNAME resource records (Enregistrements de ressources CNAME)
L'enregistrement CNAME (« nom canonique », canonical name) DNS existe pour fournir le nom canonique associé à un nom d'alias. Il ne peut y avoir qu'un seul nom canonique pour un alias donné. Ce nom devrait généralement être un nom qui existe ailleurs dans le DNS, bien qu'il existe quelques applications rares pour les alias avec le nom canonique accompagnant non défini dans le DNS. Un nom d'alias (l'étiquette d'un enregistrement CNAME) peut, si DNSSEC est utilisé, avoir des RR SIG, NXT et KEY, mais ne peut avoir aucune autre donnée. C'est-à-dire, pour toute étiquette dans le DNS (tout nom de domaine), exactement l'une des affirmations suivantes est vraie :
- Un enregistrement CNAME existe, éventuellement accompagné de RR SIG, NXT et KEY
- Un ou plusieurs enregistrements existent, aucun n'étant un enregistrement CNAME
- Le nom existe, mais n'a pas de RR associés d'aucun type
- Le nom n'existe pas du tout
10.1.1. CNAME terminology (Terminologie CNAME)
Il est traditionnel de se référer à l'étiquette d'un enregistrement CNAME comme « un CNAME ». Ceci est malheureux, car « CNAME » est une abréviation de « nom canonique » (canonical name), et l'étiquette d'un enregistrement CNAME n'est certainement pas un nom canonique. C'est cependant un usage bien établi. Il faut donc prendre grand soin d'être très clair si l'on veut dire l'étiquette ou la valeur (le nom canonique) d'un enregistrement de ressource CNAME. Dans ce document, l'étiquette d'un enregistrement de ressource CNAME sera toujours appelée un alias.
10.2. PTR records (Enregistrements PTR)
La confusion concernant les noms canoniques a conduit à la croyance qu'un enregistrement PTR devrait avoir exactement un RR dans son RRSet. Ceci est incorrect, la section pertinente de RFC1034 (section 3.6.2) indique que la valeur d'un enregistrement PTR devrait être un nom canonique. C'est-à-dire qu'il ne devrait pas être un alias. Il n'y a aucune implication dans cette section qu'un seul enregistrement PTR est autorisé pour un nom. Aucune restriction de ce type ne devrait être déduite.
Notez que bien que la valeur d'un enregistrement PTR ne doive pas être un alias, il n'y a pas d'exigence que le processus de résolution d'un enregistrement PTR ne rencontre aucun alias. L'étiquette qui est recherchée pour une valeur PTR pourrait avoir un enregistrement CNAME. C'est-à-dire qu'elle pourrait être un alias. La valeur de ce CNAME RR, si ce n'est pas un autre alias, ce qu'il ne devrait pas être, donnera l'emplacement où l'enregistrement PTR est trouvé. Cet enregistrement donne le résultat de la recherche de type PTR. Ce résultat final, la valeur du PTR RR, est l'étiquette qui ne doit pas être un alias.
10.3. MX and NS records (Enregistrements MX et NS)
Le nom de domaine utilisé comme valeur d'un enregistrement de ressource NS, ou partie de la valeur d'un enregistrement de ressource MX ne doit pas être un alias. Non seulement la spécification est claire sur ce point, mais l'utilisation d'un alias dans l'une ou l'autre de ces positions ne fonctionne ni aussi bien que souhaité, ni ne remplit bien l'ambition qui a pu conduire à cette approche. Ce nom de domaine doit avoir comme valeur un ou plusieurs enregistrements d'adresse. Actuellement, ce seront des enregistrements A, mais à l'avenir, d'autres types d'enregistrements fournissant des informations d'adresse peuvent être acceptables. Il peut également avoir d'autres RR, mais jamais un CNAME RR.
La recherche d'enregistrements NS ou MX provoque un « traitement de section supplémentaire » (additional section processing) dans lequel les enregistrements d'adresse associés à la valeur de l'enregistrement recherché sont ajoutés à la réponse. Cela aide à éviter des requêtes supplémentaires inutiles qui sont facilement anticipées lorsque la première est faite.
Le traitement de section supplémentaire n'inclut pas les enregistrements CNAME, encore moins les enregistrements d'adresse qui peuvent être associés au nom canonique dérivé de l'alias. Ainsi, si un alias est utilisé comme valeur d'un enregistrement NS ou MX, aucune adresse ne sera retournée avec la valeur NS ou MX. Cela peut causer des requêtes supplémentaires et une charge réseau supplémentaire à chaque requête. Il est trivial pour l'administrateur DNS d'éviter cela en résolvant l'alias et en plaçant le nom canonique directement dans l'enregistrement affecté une seule fois lorsqu'il est mis à jour ou installé. Dans certains cas particuliers difficiles, l'absence des enregistrements d'adresse de section supplémentaire dans les résultats d'une recherche NS peut faire échouer la demande.