1770465634
2026-02-07 11:33:00
8 января плановое обновление службы DNS изменило порядок появления записей CNAME в ответах, что привело к сбою некоторых DNS-клиентов при разрешении имен, поскольку они ожидали, что записи псевдонимов будут первыми. Хотя большинство современных программ считают порядок записей в ответах DNS неважным, команда Cloudflare обнаружила, что некоторые реализации ожидают, что записи CNAME будут появляться раньше всех других типов записей.
Когда этот порядок изменился, разрешение DNS начало давать сбой, что вызвало значительный сбой в работе популярной общедоступной службы DNS 1.1.1.1. Себастьян Нойтбумсистемный инженер Cloudflare, объясняет, почему и когда было внесено это изменение:
Внеся некоторые улучшения для снижения использования памяти нашей реализацией кэша, мы внесли небольшое изменение в порядок записей CNAME. Изменение было введено 2 декабря 2025 г., выпущено в нашу среду тестирования 10 декабря, а развертывание началось 7 января 2026 г.
Когда распознаватель DNS ищет имя с помощью записи CNAME, он может увидеть серию записей псевдонимов, связывающих исходное имя с конечным адресом, и кэширует каждый шаг со своим собственным сроком действия. Cloudflare отмечает, что если срок действия части этой цепочки в кеше истек, преобразователь повторно извлекает только просроченную часть и объединяет ее с действительными частями для формирования полного ответа.
Cloudflare подчеркивает, что когда преобразователь DNS ищет имя с помощью CNAME, он может увидеть серию записей псевдонимов, связывающих исходное имя с конечным адресом, и преобразователь кэширует каждый шаг со своим собственным сроком действия. Если срок действия части этой цепочки в кеше истек, преобразователь повторно извлекает только просроченную часть, а затем объединяет ее с еще действительными частями, чтобы сформировать полный ответ. Нойтбум добавляет:
Раньше код создавал новый список, вставлял существующую цепочку CNAME, а затем добавлял новые записи (…). Однако, чтобы сохранить некоторые выделения памяти и копии, код был изменен и вместо этого добавлял CNAME к существующему списку ответов. В результате в ответах, возвращаемых 1.1.1.1, записи CNAME теперь иногда появлялись внизу после окончательного разрешенного ответа.
;; РАЗДЕЛ ВОПРОСОВ: ;; www.example.com. В А ;; РАЗДЕЛ ОТВЕТОВ: cdn.example.com. 300 IN A 198.51.100.1 www.example.com. 3600 В CNAME cdn.example.com.
Хотя многие реализации DNS-клиентов не зависят от порядка, например, с разрешением systemdдругие, в том числе getaddrinfo функция в glibc обрабатывает цепочку разрешения, отслеживая ожидаемые имена записей и выполняя последовательные итерации, ожидая найти записи CNAME до каких-либо ответов. На Reddit пользователь комментарии:
С одной стороны, я очень уважаю детали их вскрытий и действительно высокие стандарты разработки, но с другой стороны, я не могу отделаться от мысли, что у них нет надлежащего тестирования (и его культуры), чтобы понять, какое влияние они оказывают во всем мире.
На популярная тема Hacker NewsМногие пользователи обсуждают, действительно ли RFC неясен из-за тонкого различия RRsets и RR в разделах сообщений, или же разработчики Cloudflare его неправильно поняли. Вместо этого Патрик Мэй комментирует:
Отличный пример закона Хайрама: «При достаточном количестве пользователей API не имеет значения, что вы обещаете в контракте: все наблюдаемое поведение вашей системы будет от кого-то зависеть». в сочетании с несоблюдением закона Постеля: «Будьте консервативны в том, что отправляете, будьте либеральны в том, что принимаете».
В Интернет-Черновик Для обсуждения в IETF Cloudflare предлагает RFC, который явно определяет, как правильно обрабатывать записи CNAME в ответах DNS.
Согласно опубликованному графику, Cloudflare начал глобальное развертывание 7 января и достиг 90% серверов к 8 января в 17:40 UTC. Вскоре после этого компания заявила об инциденте, начала отмену изменения в 18:27 UTC 8 января и завершила откат к 19:55 UTC.
#Как #порядок #CNAME #спецификациях #RFC #привел #сбою #Cloudflare #1.1.1.1
Продолжение темы
