Summary

  • Индивидуальный проект от 5 ноября предлагает располагать CNAME в ответе по цепочке: сначала псевдоним запрошенного имени, затем следующие псевдонимы и в конце целевую запись. Раннюю более широкую норму сузили до случая, давшего реальные сбои.
  • Приложение к проекту описывает январское событие: запросы glibc перестали работать, некоторые коммутаторы перезагружались при поиске имени NTP-сервера. Официальная запись Cisco называет затронутые серии и фатальную ошибку процесса DNSC.

Для неприятности не понадобилось новое поле. Рекурсивный резолвер может поместить в один раздел Answer первый CNAME, следующий CNAME и итоговый адрес. RFC 1034 описывала псевдонимы как возможное вступление и предписывала копировать записи в ответ, но не превращала слово «копировать» в явную обязанность добавлять их по порядку. Один участник видел набор, другой читал последовательность. 8 января 2026 года программное обновление резолвера изменило порядок RRSet в ответах с CNAME. По приложению проекта, регрессионные проверки пропустили изменение, поскольку порядок считался несущественным. Запросы glibc стали сбоить, а часть коммутаторов перезапускалась при поиске настроенного NTP-имени.

Документ Cisco перечисляет Catalyst 1200/1300 и CBS 250/350 с конкретными версиями прошивок. Он описывает фатальную ошибку DNSC, осторожно связывает её с некоторыми форматами DNS-ответа и предлагает сменить сервер DNS, выключить поиск по имени либо задать статическое соответствие. Общего числа затронутых устройств там нет. Авторы IETF связывают событие с перестановкой CNAME; измерения ущерба по всему парку исходные документы не содержат.

Редакция 02 ноября предлагает узкое исправление. При построении ответа сервер сперва добавляет CNAME имени запроса, затем CNAME дальше по цепочке и наконец запись нужного типа. Порядок отдельных записей внутри одного RRSet остаётся свободным. Клиентам следует принимать CNAME-RRSet в любом порядке, однако серверам запрещено рассчитывать на такую терпимость. Августовская редакция 01 охватывала порядок в разделах DNS шире; после замечаний группы область сократили. Карточка IETF показывает индивидуальный проект, который обновит RFC 1034 лишь после принятия.

Стоимость старого программного обеспечения ложится на обе стороны: серверу нужен осторожный вывод, клиенту — устойчивое чтение. В испытании следует сохранить сборку резолвера, оба варианта ответа в байтах, цепочку CNAME, результат glibc, запрос NTP и журнал коммутатора. Успешный DNS-код не доказывает, что устройство осталось включённым.