10. 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, ne peut avoir qu'un seul nom autoritaire, ou officiel, appelé nom canonique. Une telle exigence n'existe pas dans le DNS.
10.1. Enregistrements de ressource CNAME
L'enregistrement DNS CNAME (« canonical name ») existe pour fournir le nom canonique associé à un nom alias. Il ne peut y avoir qu'un seul nom canonique de ce type pour un alias donné. Ce nom devrait généralement être un nom qui existe ailleurs dans le DNS, bien qu'il existe quelques rares applications pour des alias dont le nom canonique correspondant n'est pas défini dans le DNS. Un nom alias (é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. Autrement dit, pour toute étiquette du DNS (tout nom de domaine), exactement l'une des propositions 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 aucun RR associé d'aucun type,
- le nom n'existe pas du tout.
10.1.1. Terminologie CNAME
Il est traditionnel de désigner l'étiquette d'un enregistrement CNAME comme « un CNAME ». C'est regrettable, car « CNAME » est l'abréviation de « canonical name », et l'étiquette d'un enregistrement CNAME n'est très certainement pas un nom canonique. Il s'agit toutefois d'un usage bien ancré. Il faut donc veiller à être très clair sur le point de savoir si c'est l'étiquette ou la valeur (le nom canonique) d'un enregistrement de ressource CNAME qui est visée. Dans ce document, l'étiquette d'un enregistrement de ressource CNAME sera toujours désignée comme un alias.
10.2. Enregistrements PTR
La confusion autour des noms canoniques a conduit à croire qu'un enregistrement PTR devrait avoir exactement un RR dans son RRSet. C'est incorrect : la section pertinente de la RFC1034 (section 3.6.2) indique que la valeur d'un enregistrement PTR devrait être un nom canonique. Autrement dit, elle ne devrait pas être un alias. Cette section n'implique nullement qu'un seul enregistrement PTR soit autorisé pour un nom. Aucune restriction de ce type ne devrait en être déduite.
Notez que, si la valeur d'un enregistrement PTR ne doit pas être un alias, rien n'exige que le processus de résolution d'un enregistrement PTR ne rencontre aucun alias. L'étiquette recherchée pour une valeur PTR peut avoir un enregistrement CNAME. C'est-à-dire qu'elle peut être un alias. La valeur de ce RR CNAME, si ce n'est pas un autre alias, ce qu'elle ne devrait pas être, donnera l'emplacement où se trouve l'enregistrement PTR. Cet enregistrement donne le résultat de la recherche de type PTR. Ce résultat final, la valeur du RR PTR, est l'étiquette qui ne doit pas être un alias.
10.3. Enregistrements MX et NS
Le nom de domaine utilisé comme valeur d'un enregistrement de ressource NS, ou comme 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 pas aussi bien qu'on pourrait l'espérer, et ne remplit pas bien l'ambition qui a pu conduire à cette approche. Ce nom de domaine doit avoir pour 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'adressage pourront être acceptables. Il peut aussi avoir d'autres RR, mais jamais un RR CNAME.
La recherche d'enregistrements NS ou MX déclenche 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, facilement anticipées dès la première requête.
Le traitement de la section supplémentaire n'inclut pas les enregistrements CNAME, et 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 renvoyée avec la valeur NS ou MX. Cela peut entraîner 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 directement le nom canonique dans l'enregistrement concerné, une seule fois, lors de sa mise à jour ou de son installation. Dans certains cas particulièrement difficiles, l'absence des enregistrements d'adresse de la section supplémentaire dans les résultats d'une recherche NS peut entraîner l'échec de la requête.