Dans DNS, un IN NS peut-il pointer vers un CNAME?

Est-il permis d'avoir un enregistrement NS comme CNAME? Par exemple:

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Cela ne semble pas fonctionner dans bind, bien que cela (bien sûr):

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Tout pointeur vers des RFC interdisant cette configuration serait apprécié.

domain-name-system cname-record ns-record

— Mark Wagner
source

Le RFC réel qui définit le NS RR ( RFC1035 ) dit simplement que c'est un nom de domaine sans spécifier le type RR de la cible (bien qu'il indique clairement qu'il ne peut pas être une IP). Il obtient cependant une mention spécifique dans la RFC1912 , section 2.4:

Avoir des enregistrements NS pointant vers un CNAME est mauvais et peut entrer en conflit avec les serveurs BIND actuels. En fait, les implémentations BIND actuelles ignoreront ces enregistrements, ce qui pourrait conduire à une délégation boiteuse. Il existe un certain nombre de vérifications de sécurité effectuées dans BIND pour éviter d'usurper les enregistrements DNS NS. En outre, les serveurs BIND plus anciens se trouveraient coincés dans une boucle de requête infinie essayant de trouver l'adresse du serveur de noms aliasé, provoquant l'envoi d'un flux continu de demandes DNS.

Pas tout à fait à ne pas faire, mais cela correspond certainement au comportement que vous voyez

— jj33
source

Et la RFC1034 dit: "Les noms de domaine dans les RR qui pointent vers un autre nom doivent toujours pointer vers le nom principal et non l'alias. Cela évite des indirections supplémentaires dans l'accès aux informations ... lorsqu'ils sont présentés avec des chaînes ou des boucles CNAME; les chaînes CNAME doivent être suivies et les boucles CNAME signalées comme une erreur. "

— larsks

J'ai trouvé que la RFC 2181 10.3 dit clairement qu'elle n'est pas valide mais votre réponse était assez bonne.

— Mark Wagner

Pour plus de clarté: le MUST NOTverbiage n'a pas d'importance ici car la RFC 1912 est informative et ne définit pas de norme. Mark a raison de dire que RFC 2181 est la référence correcte. (La RFC 1034 a été écrite avant que les normes linguistiques ne se solidifient, d'où le flou)

— Andrew B