Summary

  • Un borrador individual del 5 de noviembre propone ordenar las respuestas con CNAME: primero el alias consultado, luego los demás eslabones y al final el registro solicitado. La regla se redujo al caso que causó el problema real.
  • Su relato del incidente de enero registra fallos de consultas glibc y conmutadores que se reiniciaron al resolver nombres NTP. El aviso oficial de Cisco enumera familias afectadas y un error fatal del proceso DNSC.

El paquete no necesitó un campo nuevo. Una respuesta recursiva para un alias puede llevar en la misma sección Answer el primer CNAME, otro CNAME y la dirección final. La RFC 1034 describía los CNAME como posible prefacio e indicaba copiar registros a la respuesta, pero no convirtió expresamente esa copia en una obligación de anexarlos en secuencia. Un servidor trató la sección como conjunto; un cliente la leyó en orden. El 8 de enero de 2026, una versión del resolvedor cambió la posición de los RRSet en respuestas CNAME. Según el apéndice del borrador, las pruebas no lo detectaron porque se había considerado irrelevante el orden. Fallaron búsquedas glibc y algunos conmutadores se reiniciaron al consultar el nombre del servidor NTP configurado.

El documento de Cisco identifica Catalyst 1200/1300 y CBS 250/350 con versiones concretas de firmware. Describe el error fatal DNSC, atribuye provisionalmente el fallo a ciertos formatos de respuesta y ofrece usar otro DNS, desactivar la búsqueda de nombres o fijar un mapa estático. No da una cifra para toda la flota. Los autores del IETF vinculan el episodio al orden CNAME; los registros oficiales no miden el daño total.

La revisión 02 de noviembre propone anexar primero el CNAME del nombre preguntado, después los CNAME siguientes en orden de cadena y por último el dato final. El orden dentro de un mismo RRSet sigue sin importancia. Los clientes deberían tolerar cualquier orden de CNAME, pero los servidores no deben apoyarse en esa tolerancia. La revisión 01 de agosto proponía una prescripción más amplia para las secciones DNS; la nueva se redujo tras comentarios del grupo. El seguimiento del IETF aún la presenta como borrador individual que solo actualizaría la RFC 1034 si se aprueba.

La decisión reparte el coste de los programas antiguos: emisión conservadora en el servidor y lectura flexible en el cliente. Una prueba debe conservar versión del resolvedor, ambas respuestas en bytes, cadena CNAME, resultado glibc, consulta NTP y registro del conmutador. Un código DNS de éxito no certifica que el equipo siga encendido.