il semble que la réponse soit essentiellement que les architectes d'origine n'ont jamais pensé que ce serait utile ou quelque chose d'aussi irréfléchi.
Il est important de comprendre que le système de noms de domaine (DNS) remplaçait un arrangement qui utilisait une version clonée globalement de /etc/hosts sur tous les ordinateurs de l'internet de l'époque, de sorte que la fiabilité et la rapidité des réponses moyennes étaient essentielles à son adoption. La fiabilité et la rapidité des réponses moyennes étaient donc essentielles à son adoption. L'inclusion de résolveurs de mise en cache dans la conception originale a donc été un élément essentiel de son succès.
Depuis lors, l'accent a été mis sur la rétrocompatibilité. también extrêmement important : les résolveurs DNS en cache sont un service de base sur les appareils grand public qui fonctionnent généralement pendant 10~15 ans sans mises à jour logicielles.
Imaginons maintenant qu'un enregistrement CNAME soit autorisé en combinaison avec un autre type d'enregistrement, puis envisageons un résolveur de mise en cache.
Le premier problème est l'efficacité.
Selon l'ordre des requêtes et les TTL des enregistrements, il finira par n'avoir qu'un CNAME dans son cache pour un nom donné.
Que se passe-t-il alors lorsqu'un client (qui pourrait être un autre résolveur de cache) demande un AAAA : doit-il répondre en utilisant le CNAME, ou demander un AAAA au serveur faisant autorité ?
Le problème suivant est l'ambiguïté.
Si les noms du propriétaire et de la cible sont tous deux des sommets de zone, et que le client demande NS ou SOA, il y a deux réponses possibles complètement différentes, toutes deux valables en fonction des critères suivants pourquoi la demande a été faite.
La conception "keep it simple" voudrait que l'on traite toutes les requêtes de la même manière, car on ne sait pas si les requêtes sont identiques ou non. pourquoi le client demande : suivez toujours la redirection.
On pourrait arguer que des règles différentes devraient s'appliquer à des types d'enregistrement différents, et qu'il devrait y avoir une liste énumérée de types de RR qui pourraient coexister avec les enregistrements CNAME, mais une telle liste aurait dû faire partie de la conception originale (au début des années 1980). Et si cela aurait résolu le problème pour SOA & NS, cela n'aurait pas résolu le problème pour DNAME qui n'a été ajouté que plus tard.
L'ajout d'un champ "do not follow CNAME" dans l'enregistrement de la requête aurait probablement résolu la plupart des problèmes, sans ajouter beaucoup complexité, mais cela aurait été une conception prémonitoire à une époque où les liens symboliques étaient une nouveauté, et O_NOFOLLOW était encore dans une dizaine d'années.
