Summary

  • Un projet individuel du 5 novembre propose de placer, dans une réponse DNS avec CNAME, d’abord l’alias demandé, puis les alias suivants et enfin l’enregistrement final. La règle a été resserrée sur le cas ayant posé problème.
  • Le récit de l’incident de janvier dans ce projet mentionne des échecs de recherche glibc et des commutateurs redémarrant lors de la résolution de noms NTP. La notice officielle de Cisco indique les familles de matériels et une erreur fatale du processus DNSC.

La réponse n’avait pas besoin d’un nouveau champ pour faire tomber un équipement. Un résolveur récursif peut mettre dans une même section Answer le premier CNAME, un second CNAME et l’adresse finale. La RFC 1034 parlait de CNAME pouvant précéder la réponse et demandait de copier les enregistrements dans cette section, sans transformer explicitement « copier » en obligation d’ajouter dans l’ordre. Un serveur y voyait un ensemble ; un client lisait une séquence. Le 8 janvier 2026, une mise à jour du résolveur a changé l’ordre des RRSet liés aux CNAME. Selon l’annexe du projet, les tests n’ont rien signalé, car l’ordre était jugé sans importance. Les recherches glibc ont échoué et certains commutateurs ont redémarré en demandant l’adresse de leur serveur NTP.

La notice Cisco cite Catalyst 1200/1300 et CBS 250/350, avec les versions de micrologiciel concernées. Elle décrit une erreur DNSC fatale, soupçonne certains formats de réponse DNS et propose comme palliatifs un autre serveur DNS, l’arrêt de la recherche de noms ou une correspondance statique. Le document ne chiffre pas l’ensemble des appareils touchés. Les auteurs de l’IETF relient l’épisode à l’ordre des CNAME ; les dossiers officiels ne mesurent pas l’impact sur tout le parc.

La révision 02 impose, dans sa proposition, l’ordre de la chaîne : CNAME du nom demandé, CNAME suivants, enregistrement correspondant au type demandé. L’ordre des enregistrements au sein d’un même RRSet reste libre. Les clients devraient accepter les CNAME dans n’importe quel ordre ; les serveurs ne doivent pas compter sur cette tolérance. La révision 01 d’août prescrivait plus largement l’ordre dans les sections DNS. Après les remarques du groupe, la nouvelle version s’en tient au traitement des CNAME. Le suivi de l’IETF indique toujours un projet individuel, qui ne modifiera la RFC 1034 qu’en cas d’approbation.

Le choix partage le coût des anciens logiciels : réponse conservatrice côté serveur, lecture plus souple côté client. Un essai doit garder la version du résolveur, les deux ordres en octets, une chaîne de CNAME, les résultats glibc, la résolution NTP et le journal du commutateur. Un code de réponse DNS positif ne dit pas si l’appareil a tenu.