Отзыв маршрутов Cloudflare 1.1.1. Сбой Cloudflare 1.1.1.

Резюме

Cloudflare сообщает, что её публичный рекурсивный DNS-сервис 1.1.1.1 был недоступен по всему миру с 21:52 до 22:54 UTC 14 июля 2025 года. Затронуто большинство пользователей, а Gateway DNS испытывал периодическую деградацию. Непосредственным механизмом стал отзыв производственных префиксов сервиса после внутреннего изменения топологии, а не атака или дефект протокола DNS. [1]
Причинная запись началась 6 июня. Конфигурация ещё не запущенного в эксплуатацию сервиса Data Localization Suite случайно ссылалась на сервис Resolver 1.1.1.1 и его префиксы. Ошибка оставалась скрытой, поскольку не вызывала изменений трафика. 14 июля добавление тестовой площадки к этому непроизводственному сервису запустило глобальное обновление, сократив топологию резолвера со всех производственных точек мира до одной офлайн-площадки и вызвав отзыв маршрутов. [1][8]
Cloudflare перечислила затронутые префиксы IPv4 и IPv6, включая 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 и связанное адресное пространство резолвера. Трафик UDP, TCP и DNS over TLS резко упал. DNS over HTTPS оставался сравнительно стабильным для многих пользователей, поскольку cloudflare-dns.com использовал другой набор адресов. Границу сбоя определяли выбор конечной точки и маршрута, а не только название продукта. [1][16][17]
Сработали оповещения, и инцидент был объявлен в 22:01. Cloudflare откатила конфигурацию в 22:20. Повторное анонсирование маршрутов восстановило трафик примерно до 77 % прежнего уровня, но около 23 % пограничных серверов уже удалили необходимые IP-привязки. Полное восстановление трафика потребовало восстановления этих привязок и было зафиксировано в 22:54. [1]
После отзыва маршрутов Cloudflare стало видно объявление источника Tata Communications India для 1.1.1.0/24. Cloudflare охарактеризовала это как похожее на перехват с точки зрения системы маршрутизации, но прямо заявила, что оно не стало причиной сбоя. Проверка источника и мониторинг маршрутов имеют доказательную ценность, но не могут подтвердить, что авторизованный оператор анонсирует сервисный префикс из нужных точек или отвечает на DNS-запросы. [1][3][18][19]
Anycast распределяет один сервисный адрес из нескольких точек. RFC 4786 объясняет и его устойчивость, и сложность мониторинга. Июльское событие не показало, что anycast сам по себе небезопасен. Оно показало, что одна неточная глобальная запись «сервис — префикс» может стереть весь производственный охват, если в системе генерации маршрутов нет жёсткого инварианта против нуля работающих площадок. [9][12][13]
Подотчётность следует за практическим контролем над реестром «префикс — сервис», формируемой топологией, глобальным обновлением, анонсами маршрутов, пограничными привязками, устройством оповещений, полномочиями на откат и доказательством восстановления сервиса. Тикет или предполагаемая конфигурация — это свидетельство намерения. Работающий маршрут и завершённый DNS-ответ — свидетельство реальности.
Согласно доктрине Heng.lu, записи IP-префиксов и топологии должны сохранять уникальность, точность, метаданные безопасности и операционную непрерывность. Они остаются реестрами, а не суверенной заменой работающей сети. Тезис о сетевой инфраструктуре рушится, если убрать факты о DNS, IP-префиксах, anycast, BGP и пограничных привязках, поэтому поверхность доктрины является центральной, а не декоративной.

Резолвер может выйти из строя ещё до обработки DNS-вопроса

Когда пользователи описывают сбой DNS, естественный образ — это резолвер, который получает имя и не возвращает адрес. Это один из возможных сбоев. В июльском инциденте Cloudflare 2025 года он не был первым.

Клиент может задать резолверу вопрос только после того, как пакеты достигнут сервисных адресов резолвера. Для 1.1.1.1 эти знакомые адреса доставляются через anycast-сеть. Несколько точек Cloudflare анонсируют достижимость одних и тех же префиксов, и интернет-маршрутизация выбирает путь к одной из них. Затем программное обеспечение резолвера выполняет рекурсивную работу, используя записи кэша или обращаясь к авторитетным серверам имён при необходимости. [5][6][12]

Июльский сбой прервал более ранний шаг. Производственные точки Cloudflare прекратили анонсировать соответствующие префиксы. Трафик, направленный на эти адреса, не мог достичь пограничных точек, которые должны были отвечать. Резолвер не стал сначала ошибаться в доменном имени. Сеть стала ошибаться в отношении того, где существует сервис резолвера. [1]

Это различие важно для подотчётности, потому что оно определяет управляющие системы.

Команда реализации DNS может проверять рекурсию, кэширование, DNSSEC, поведение при повторных попытках и корректность ответов. Эти тесты не доказывают, что сервисные адреса останутся маршрутизируемыми. Сетевая команда может наблюдать за BGP-анонсами и пограничными интерфейсами. Эти наблюдения не доказывают, что процесс резолвера ответит. Система топологии сервиса может фиксировать, какой продукт использует какие префиксы и площадки. Эта запись не доказывает, что скомпилированное состояние маршрутов или пограничные привязки соответствуют задуманному проекту.

Сервис успешен только тогда, когда эти уровни согласуются:

Идентичность сервиса связана с правильными префиксами.
Предполагаемые производственные площадки связаны с сервисом.
Система генерации маршрутов анонсирует эти префиксы из предполагаемых площадок.
Пограничные системы сохраняют IP-привязки, необходимые для приёма трафика.
Процесс резолвера принимает соответствующие транспорты и завершает запросы.
Мониторинг обнаруживает расхождение достаточно быстро для контролируемого восстановления.

Постмортем Cloudflare показывает расхождение, начавшееся на первых двух уровнях и распространившееся на следующие два. Предпроизводственный объект приобрёл ссылку на производственные префиксы резолвера. Позднее обновление скомпилировало эту связь в отзыв маршрутов. Некоторые пограничные серверы затем удалили необходимые привязки. [1]

Назвать результат «DNS не работает» понятно, но слишком грубо для анализа управления. Класс сбоя — это проблема идентичности и достижимости в сетевой инфраструктуре: какой сервис владеет адресом, где этот сервис должен быть доступен, какое состояние маршрутов следует из записи и какая физическая или программная конечная точка готова принять трафик.

Именно поэтому статусная панель не может быть единственным доказательством. Панель может сообщать, что компонент DNS работает, в то время как его префиксы отсутствуют в важных представлениях маршрутизации. Коллектор маршрутов может сообщать о префиксе, хотя за ним не привязан ни один исправный резолвер. Монитор процессов может сообщать о исправном демоне, который не получает пакетов. Подотчётный контроль — это сверка этих состояний, а не зелёный индикатор любого из них.

«Спящая» ошибка уже была производственным риском

Cloudflare датирует появление ошибки конфигурации 6 июня 2025 года. Компания готовила топологию сервиса для будущего сервиса Data Localization Suite. Новый сервис не был в производстве. Его конфигурация случайно содержала ссылку на сервис Resolver 1.1.1.1 и, соответственно, на префиксы резолвера. [1]

Тогда ничего видимого не произошло. Не было ни изменения маршрутов, ни сдвига трафика, ни оповещения. Запись находилась в производственной среде конфигурации без немедленных последствий.

Этот тихий период не является доказательством того, что запись была безвредной. Это доказательство того, что система ещё не задействовала её.

Системы конфигурации часто содержат неактивные, поэтапные, будущие, отключённые или связанные с офлайн-площадкой объекты. Операторам нужны такие состояния. Они позволяют представить планируемые сервисы до активации. Риск появляется, когда «спящий» объект может претендовать на критичные для производства ресурсы или ссылаться на них без проверки конфликтов, а поздняя операция может обновить глобальную сеть на основе этого объекта.

Поэтому полезный вопрос не только «Изменило ли июньское изменение трафик?», но и «Какую власть приобрела июньская запись?»

Если запись могла повлиять на владение производственным префиксом при будущем обновлении, то она пересекла границу производственного риска, даже пока сервис оставался офлайн. Рецензент или автоматический валидатор должен был понять скрытый эффект. Отсутствие немедленного воздействия на трафик сделало обычные оповещения о здоровье неэффективными, потому что событие было дефектом целостности состояния, а не ещё дефектом здоровья сервиса.

Точная плоскость управления должна уметь отвечать:

Какой сервис является авторитетным владельцем каждого производственного префикса?
Могут ли два объекта сервиса ссылаться на один префикс?
Если общая ссылка разрешена, какое правило определяет результирующий набор площадок?
Может ли непроизводственный сервис сузить глобальную топологию производственного сервиса?
Какая операция следующей скомпилирует или обновит эту запись?
Какие изменения маршрутов и пограничных привязок она произведёт?
Какой инвариант блокирует достижение глобальным сервисом нуля онлайн-площадок?
Кто должен утвердить межсредовую ссылку на критичный публичный адрес?

Это не процессные украшения. Каждый вопрос может стать детерминированной проверкой.

Таблица владения префиксами может требовать один авторитетный идентификатор сервиса. Компилятор топологии может вычислять эффективный набор площадок до развёртывания. Политика может отклонять вывод с нулём работающих площадок. Предпросмотр изменений может показывать все производственные префиксы, затронутые непроизводственным объектом. Независимый наблюдатель может сравнивать предполагаемый вывод с текущими анонсируемыми маршрутами.

Цель контроля не запретить «спящую» конфигурацию, а помешать «спящей» власти ускользнуть от проверки.

Текущая документация Cloudflare по Data Localization объясняет законную необходимость контролировать, где сервисы обрабатывают трафик. Она описывает географические и комплаенс-продукты, но не может доказать точную частную модель данных или средства контроля, использованные в июне и июле 2025 года. [8] Постмортем остаётся источником механизма инцидента. Текущая документация даёт контекст, почему расположение сервиса является важным входом конфигурации.

Эта граница фактов важна. Было бы легко вывести конкретную схему, базу данных или инструмент развёртывания из текущей документации. Публичная запись не раскрывает этих деталей. Подотчётность не требует их выдумывать. Она требует назвать наблюдаемое требование контроля: будущий или офлайн-сервис не должен молча приобретать власть над производственными префиксами резолвера.

Глобальное обновление превратило запись в действующее состояние маршрутов

14 июля Cloudflare добавила тестовую площадку к непроизводственному сервису. Сама площадка не была активна, но изменение запустило обновление сетевой конфигурации по всему миру. Поскольку июньская запись связала префиксы 1.1.1.1 с этим сервисом, обновление включило их. Эффективная топология резолвера была сокращена со всех производственных площадок до одной офлайн-площадки. Его префиксы начали отзываться. [1]

Последовательность демонстрирует, почему радиус поражения изменения следует измерять по сформированному выводу, а не по видимому размеру ввода.

Ввод можно описать как добавление одной тестовой площадки к одному непроизводственному сервису. Вывод затронул глобальный публичный резолвер и несколько префиксов IPv4 и IPv6. Оба описания совместимы. Только второе раскрывает операционный риск.

Автоматизация инфраструктуры часто усиливает компактные декларации. Короткая конфигурация может генерировать правила для множества маршрутизаторов, серверов или площадок. В этом смысл автоматизации. Это также означает, что проверка должна показывать расширение.

Безопасный предпросмотр для этого класса изменений должен показывать как минимум:

Каждый сервис, чья эффективная топология меняется.
Каждый префикс, добавленный, удалённый или переназначенный.
Каждую площадку, которая начнёт или прекратит анонсировать каждый префикс.
Каждую пограничную привязку, которая будет добавлена или удалена.
Каждую затронутую конечную точку протокола.
Минимальное оставшееся количество работающих площадок.
Ожидаемую дельту BGP-анонсов.
Ожидаемую дельту распределения DNS-запросов.

Предпросмотр должен вычисляться тем же кодом и путём данных, что и развёртывание. Отдельная сводка, созданная другой логикой, может расходиться с реальным компилятором. Это примат работающего кода в практической форме: объект проверки должен быть сформированным кандидатом, а не только человеческим описанием.

Тот же принцип применим к канареечным проверкам. Маленький первый шаг полезен только если он проверяет режим сбоя. Добавление тестовой площадки к офлайн-сервису может выглядеть безопасным, потому что там не ожидается клиентский трафик. Если операция вызывает глобальное обновление маршрутов и логику привязки префиксов, канареечная проверка должна наблюдать этот глобальный вывод. Локальный тест конечной точки на офлайн-площадке пропустит решающий эффект.

Поэтому июльский инцидент ставит под сомнение распространённое сокращение «непроизводственное изменение».

Объект может быть непроизводственным с точки зрения клиентского использования, но его метаданные участвуют в производственном компиляторе. Площадка может быть офлайн, но её добавление запускает глобальный пересчёт. Сервис может не иметь пользователей, но его привязки префиксов изменяют широко используемый резолвер. Метки среды не определяют реальную границу. Её определяют поток данных и полномочия развёртывания.

Это не значит, что каждую запись промежуточной среды нужно считать живым сбоем. Это значит, что организация должна классифицировать изменения по системам и ресурсам, которые они могут изменять. Непроизводственный объект со ссылками на производственные префиксы относится к более высокому классу риска, чем изолированный тестовый объект без полномочий генерации маршрутов.

Доказательства для такой классификации могут оставаться ограниченными. Тикет изменения может называть затронутый компилятор. Машинный предпросмотр может перечислять затронутые производственные ресурсы. Результат политики может фиксировать проверки инвариантов. Отчёт канареечной проверки может показывать наблюдения маршрутов и сервиса. Сохранённый файл полезнее широкого заверения, что среды промежуточная и производственная разделены.

Anycast распределил сервис и сконцентрировал ошибку управления

Anycast часто описывают как метод устойчивости. Один и тот же сервисный адрес доступен из нескольких сетевых точек, и маршрутизация направляет пользователей к одной из них. RFC 4786 документирует модель и предупреждает, что мониторинг усложняется, поскольку доступность зависит от расположения клиента и охвата маршрутизации. [12]

Cloudflare широко использует anycast, в том числе для 1.1.1.1. Её текущая документация и публичные сетевые материалы описывают глобально распределённый сервис и адресное пространство, анонсируемое по всей сети. [4][5][9][10][11]

Июльский сбой не следует читать как доказательство того, что anycast провалился по своей конструкции. Конструкция создаёт множество потенциальных сервисных точек. Система конфигурации одновременно удалила из них достижимость.

Это различие отделяет избыточность плоскости данных от независимости плоскости управления.

Многие площадки могут обслуживать один адрес. Если все они потребляют одну ошибочную глобальную запись топологии, количество площадок не создаёт независимой защиты от этой записи. Парк географически распределён, но логически имеет общий режим отказа.

Соответствующие вопросы устойчивости:

Может ли одна привязка «сервис — префикс» удалить все anycast-узлы?
Существует ли неизменяемое или отдельно контролируемое правило минимального присутствия для критичных префиксов?
Требует ли глобальное изменение успешной проверки несколькими независимыми наблюдателями?
Может ли подмножество площадок сохранить последнее известное корректное анонсирование при неопределённости плоскости управления?
Возможно ли аварийное восстановление без зависимости от того же компилятора топологии?
Защищены ли пограничные привязки от автоматического удаления до согласования проверок маршрутов и сервиса?

Ни на один нет единственно правильного ответа. Сохранение устаревшего маршрута может направить пользователей к сломанному сервису. Блокировка любого автоматического отзыва может помешать безопасности или обслуживанию. Правило минимального присутствия может быть опасным, если оставшиеся площадки неисправны. Контроль должен согласовывать достижимость со здоровьем сервиса, а не считать что-либо абсолютным.

Именно поэтому доказательства должны включать и состояние маршрутов, и состояние сервиса.

Анонс маршрута доказывает, что интернет может направлять пакеты к оператору. Он не доказывает, что нужное приложение исправно. Проверка здоровья резолвера доказывает, что один процесс может ответить с одной точки наблюдения. Она не доказывает, что пользователи в других зонах охвата могут маршрутизироваться к нему. Запись топологии доказывает, что система намеревается. Она не доказывает, что реализовали маршрутизаторы и пограничные хосты.

Глобальному резолверу нужно комбинированное условие приёмки. Например:

Предполагаемый сервис сохраняет как минимум заданный набор исправных производственных площадок.
Требуемые префиксы остаются видимыми из независимых коллекторов маршрутов и выбранных клиентских сетей.
Пограничные привязки существуют там, где завершаются маршруты.
Проверки UDP, TCP, DoT и DoH завершаются из репрезентативных регионов.
Объём запросов и распределение кодов ответов остаются в ограниченных ожиданиях.

Cloudflare Radar предоставляет публичные наблюдения DNS и маршрутизации, но это всё ещё измерительная поверхность, управляемая Cloudflare, и она не может представлять каждый пользовательский путь. [2][3] Независимые коллекторы, проверки интернет-провайдеров и клиентские измерения усилили бы запись. Суть не в том, что один внешний график может сертифицировать сервис. Суть в том, что глобальная конфигурация должна наблюдаться вне системы конфигурации, которая её произвела.

Протокольные пути выявили фактический радиус поражения

Cloudflare сообщила о немедленном и значительном падении запросов резолвера по UDP, TCP и DNS over TLS при отзыве префиксов. Многие пользователи настраивают 1.1.1.1, 1.0.0.1 или их IPv6-эквиваленты напрямую. Пакеты на эти адреса потеряли маршрут к производственному сервису Cloudflare. [1]

Трафик DNS over HTTPS оставался сравнительно стабильным для многих пользователей, поскольку они обращались к cloudflare-dns.com, который использовал другой набор IP-адресов. Некоторый UDP-трафик с другими адресами также оставался сравнительно стабильным. [1]

Это различие содержит несколько уроков подотчётности.

Во-первых, у продукта может быть несколько путей доставки с разными зависимостями. Все они могут называться 1.1.1.1 в документации или разговорах пользователей, но операционная граница — это конечная точка и набор адресов, используемые клиентом.

Во-вторых, разнообразие полезно только если оно реально и применимо. DoH оставался доступным не потому, что метка «HTTPS» изначально более устойчива, чем UDP. В этом событии он оставался сравнительно стабильным, потому что многие клиенты обращались к имени хоста, связанному с другими адресами. Будущий сбой может затронуть эти адреса или путь разрешения имени хоста иначе.

В-третьих, отчёт о воздействии должен называть путь. Говорить «1.1.1.1 не работал» отражает общий клиентский опыт, но скрывает, почему некоторые запросы продолжались. Говорить «весь DNS не работал» было бы неточно. Различие транспорта и конечной точки в постмортеме делает отчёт более полезным. [1][16][17]

В-четвёртых, клиенты не всегда могут переключить протоколы во время сбоя. Устройство, настроенное с литеральным адресом резолвера, может не иметь безопасного автоматического пути к имени хоста DoH. Сетевой оператор, пересылающий запросы абонентов, может иметь договорные, приватные, производительностные или политические причины для конкретной конечной точки. Резервный путь, существующий в документации продукта, не обязательно развёрнут, авторизован или протестирован в среде пользователя.

Поэтому вопрос подотчётности на стороне клиента не «Почему все не переключились?», а понимали ли критичные пользователи свою зависимость от резолвера, имели ли совместимый альтернативный путь и проверяли ли его без создания регрессий безопасности или политики.

Вопрос на стороне провайдера — составила ли она карту этих различий путей до инцидента и использовала ли их в мониторинге и коммуникации. Полезное уведомление об инциденте может указать, какие адреса и транспорты нарушены, какие остаются доступными, что клиенты могут безопасно делать и какие риски сопровождают обходной путь.

Доказательства должны сохранять:

Частоту запросов по конечной точке и транспорту.
Достижимость из репрезентативных сетей.
Успешность резолвера, тайм-ауты и частоту ошибок.
Поведение клиента при повторных попытках.
Активацию аварийного переключения или альтернативного резолвера.
Свойства безопасности и приватности резервного пути.
Время восстановления по каждому пути.

Эти записи делают границу воздействия проверяемой. Они также не позволяют использовать выживший путь для преуменьшения сбоя другого.

Постороннее объявление источника было доказательством, а не причиной

В 21:54, после того как собственные маршруты Cloudflare начали исчезать, Tata Communications India AS4755 анонсировала 1.1.1.0/24. Cloudflare заявила, что система маршрутизации сделала событие похожим на перехват префикса. Она также прямо сказала, что объявление не было причиной сбоя. [1]

Это различие должно оставаться нерушимым.

Отзыв маршрута создал условие, в котором стал виден другой источник. Наблюдение важно, потому что трафик может пойти по маршруту, который ранее был менее предпочтительным или скрытым. Оно поднимает отдельные вопросы: почему существовало объявление, как оно распространялось, какие средства контроля источника маршрута применялись и какой трафик достиг его. Эти вопросы не меняют причинный порядок, опубликованный Cloudflare.

Смешение двух событий дало бы драматичную, но более слабую статью. Оно также направило бы исправление не на тот контроль.

Валидация источника RPKI, как описано в RFC 6811, позволяет маршрутизатору классифицировать, авторизован ли AS источника для префикса согласно данным авторизации источника маршрута. [18] Операционные рекомендации BGP касаются фильтрации и гигиены маршрутизации. [19] Эти средства контроля могут снизить часть риска неавторизованного источника.

Они не доказывают доступность.

Авторизованный источник Cloudflare может отозвать свой маршрут. Действительный маршрут может завершаться на пограничном устройстве без работающего резолвера. Корректный источник может анонсировать со слишком малого числа площадок. Пограничное устройство может сохранять IP-привязку, пока сервис неисправен. И наоборот, маршрут, который выглядит аномальным, может не иметь отношения к инициирующему сбою.

Поэтому июльское событие иллюстрирует ограниченную роль метаданных безопасности.

Записи источника маршрута отвечают на конкретный вопрос: авторизован ли этот источник для этого префикса? Они не отвечают:

Должен ли префикс анонсироваться прямо сейчас?
Из скольких производственных площадок?
Ведёт ли маршрут к предполагаемому сервису?
Присутствует ли пограничная привязка?
Отвечает ли резолвер корректно?
Удалило ли изменение топологии собственный маршрут авторизованного оператора?

Это согласуется с трактовкой реестров и записей в доктрине Heng.lu. Реестр может сделать идентичность, авторизацию и историю изменений проверяемыми. Он не может командовать плоскостью данных декларацией. Маршрут и сервис всё равно должны работать.

Явное заявление постмортема об отсутствии причинной связи само по себе ценная практика доказательств. Отчёты об инцидентах должны отделять параллельные наблюдения от причинной цепи. Хронология может отметить аномалию, объяснить, почему она стала видимой, и указать, что известно, а что нет. Это помогает операторам исправить инициирующий сбой, не игнорируя вновь выявленную проблему маршрутизации.

Обнаружение началось после того, как пользователи потеряли маршрут

Cloudflare сообщает, что DNS-трафик начал падать в 21:52. Внутренние оповещения резолвера начались в 22:01, когда был объявлен инцидент. [1]

Девятиминутный интервал может быть коротким в одних операционных контекстах и длинным для глобального резолвера. Более важный момент — что породило сигнал.

Июньская ошибка не вызвала оповещений, потому что не изменила трафик. 14 июля оповещения сработали после того, как отзыв маршрутов сократил входящие запросы и вызвал сбои резолвера, прокси и дата-центров. Система обнаружила последствия после того, как глобальное обновление вступило в силу.

Мониторинг исходов необходим, но плоскости управления также нужны сигналы до развёртывания и корреляции изменений.

Можно выделить три уровня обнаружения:

Обнаружение целостности состояния

Этот уровень проверяет, внутренне корректна ли конфигурационная граф до развёртывания. Он может обнаружить дублирующее владение префиксами, производственные ссылки из непроизводственных сервисов, вывод с нулём работающих площадок или несоответствие критичности сервиса и масштаба изменения.

Обнаружение эффекта изменения

Этот уровень наблюдает сформированную и развёрнутую дельту. Он может сравнивать ожидаемые и фактические BGP-анонсы, пограничные привязки и наборы площадок во время окна канареечной проверки.

Обнаружение сервисного исхода

Этот уровень измеряет то, что испытывают пользователи: достижимость, завершение DNS-запросов, задержку, тайм-ауты, коды ответов и здоровье конкретных протоколов.

Три уровня отвечают на разные вопросы. Валидация состояния может остановить известный недопустимый вывод, не дожидаясь воздействия. Обнаружение эффекта изменения может поймать ошибку компилятора или развёртывания. Мониторинг сервиса может поймать сбои, не представленные в конфигурационной модели.

Ни одному уровню не следует доверять в одиночку.

Корректная конфигурационная модель может быть реализована неверно. Правильная дельта маршрута всё равно может указывать на неисправный сервис. Успешные синтетические запросы могут пропустить региональный охват или клиентскую сеть. Публичные коллекторы маршрутов могут пропустить частные пути. Цель контроля — своевременное обнаружение расхождений.

Для глобального резолвера полезный шлюз изменений может требовать:

Отсутствие неавторизованного изменения владения критичным префиксом.
Отсутствие сокращения производственного префикса ниже минимального набора исправных площадок.
Отсутствие незапланированного отзыва в независимых представлениях BGP.
Отсутствие потери пограничных привязок вне утверждённого объёма.
Отсутствие существенного падения объёма запросов, не объяснённого ожидаемым трафиком.
Отсутствие роста тайм-аутов по конкретному транспорту.
Отсутствие потери управленческой достижимости или достижимости отката.

Каждому требованию нужен назначенный владелец и действие остановки. Монитор, который оповещает без полномочий остановить или откатить, — лишь система наблюдения. Конвейер изменений, который может остановиться без достаточных независимых данных, может заблокировать безопасную работу или сохранить сломанное состояние. Операционная конструкция должна связывать доказательства с правами принятия решений.

Повторное анонсирование маршрута было лишь частичным восстановлением

Cloudflare откатила инициирующую конфигурацию в 22:20. Компания сообщает, что это почти сразу восстановило анонсы отозванных префиксов и вернуло трафик резолвера примерно к 77 % прежнего уровня. Это не восстановило всё. Примерно 23 % пограничного парка были автоматически перенастроены на удаление необходимых IP-привязок. [1]

Оставшаяся работа имела другой операционный профиль.

Обычный процесс восстановления привязок использовал постепенное развёртывание в течение нескольких часов. Такой темп был разработан для снижения риска внесения ещё одной проблемы изменений. Во время инцидента Cloudflare протестировала вручную ускоренное действие на ограниченных площадках, а затем применила его шире. Трафик вернулся к в основном нормальному уровню к 22:54. [1]

Эта последовательность — полезная модель восстановления, поскольку она выявляет три отдельных состояния:

Запись топологии сервиса была откачена.
BGP-префиксы были повторно анонсированы.
Пограничные серверы восстановили IP-привязки, необходимые для приёма и обслуживания трафика.

Организация, закрывающая инцидент на первом состоянии, примет предполагаемую конфигурацию за восстановление. Закрытие на втором примет достижимость за завершённый сервис. Третье состояние всё ещё требует проверки резолвера и клиентских путей.

Поэтому доказательства восстановления должны быть многоуровневыми:

Точная откаченная запись и утверждение.
Сформированный набор маршрутов после отката.
Независимые наблюдения повторного анонсирования.
Инвентаризация пограничных привязок по площадкам.
Здоровье процесса резолвера.
Завершение запросов по транспорту и региону.
Объём трафика по сравнению с ограниченным базовым уровнем.
Остаточные ошибки и отчёты клиентов.
Решение и тестовые доказательства для ускоренного развёртывания.

Показатель 77 % не следует считать универсальным процентом восстановления пользователей. Он описывает трафик относительно прежнего уровня в отчёте Cloudflare. Эффекты для пользователей различаются в зависимости от конфигурации резолвера, географии, поведения повторных попыток и альтернативных путей. Показатель ценен тем, что демонстрирует неполное восстановление после повторного анонсирования маршрутов, а не тем, что считает уникальных людей.

Напряжение между безопасным постепенным развёртыванием и срочным восстановлением заслуживает явного управления.

Постепенное развёртывание снижает радиус поражения при обычных изменениях. При сбое, вызванном отсутствующими привязками, медленное развёртывание продлевает недоступность. Ускорение восстановления может быстрее вернуть сервис, но повышает риск ещё одного непроверенного глобального изменения. Cloudflare сообщает, что проверила ручное действие на тестовых площадках до ускорения. [1]

Подотчётный аварийный процесс должен определять:

Кто может отменить обычный темп развёртывания.
Какие тесты всё ещё должны пройти.
Какие площадки образуют первую канареечную проверку восстановления.
Какие метрики останавливают ускорение.
Как независимые наблюдатели подтверждают улучшение.
Как блокируются параллельные изменения.
Как система возвращается к обычным средствам контроля развёртывания.

Аварийный путь следует отрабатывать до аварии. Иначе организация обнаруживает свои разрешения, инструменты и зависимости, когда пользователи уже офлайн.

Владение должно следовать всей цепи управления

Заманчиво приписать событие одному автору конфигурации. Публичная запись не даёт достаточно доказательств для индивидуальной вины, а распределённая цепь управления делает такую рамку неполной, даже если бы давала.

Практический контроль существовал на нескольких уровнях:

Владение сервисом

Кто-то определил сервис 1.1.1.1, его критичность, префиксы, конечные точки и требования к площадкам. Этот владелец должен определять инварианты и приемлемые условия восстановления.

Владение номерными ресурсами и сетью

Кто-то контролировал производственные префиксы, BGP-анонсы, пиринговые отношения и системы маршрутизации. Этот владелец должен поддерживать точные записи идентичности и состояния маршрутов и независимое наблюдение.

Владение системой топологии

Кто-то проектировал и эксплуатировал сервисную топологию и механизмы глобального обновления. Этот владелец должен обеспечивать границы сред, целостность ссылок, проверку сформированной дельты и безопасный откат.

Владение пограничной платформой

Кто-то контролировал, как сервисные адреса привязывались или удалялись на пограничных серверах. Этот владелец должен определять, когда состояние маршрута и состояние привязки могут меняться и как доказывается их сверка.

Владение резолвером

Кто-то эксплуатировал рекурсивное программное обеспечение DNS, транспорты, проверки здоровья и целевые показатели уровня сервиса. Этот владелец должен измерять завершённый сервис запросов, а не выводить его из присутствия маршрута.

Командование инцидентом

Кто-то координировал обнаружение, откат, ручное ускорение, публичное уведомление и последующие действия. Этот владелец должен предотвращать конфликтующие изменения и сохранять общую доказательную хронологию.

Владение зависимостью клиентов и сетевых операторов

Организации, настроившие клиентов или абонентские сети на зависимость от 1.1.1.1, контролировали собственное проектирование альтернативных резолверов, тестирование, компромиссы приватности и безопасности. Их ответственность не стирает контроль провайдера над сломанным сервисом.

Ответственность можно разделить, не делая её расплывчатой. У каждого владельца должна быть проверяемая обязанность и сохранённые доказательства.

Владелец префикса может доказать, что авторитетная привязка сервиса уникальна. Владелец топологии может доказать инвариант отсутствия нуля работающих площадок. Владелец сети может доказать ожидаемые анонсы. Владелец пограничной платформы может доказать привязки. Владелец резолвера может доказать ответы. Командование инцидентом может доказать скоординированную хронологию. Клиенты могут доказать проверенную непрерывность там, где этого требует их риск.

Этот подход избегает двух слабых крайностей.

Одна крайность говорит, что провайдер отвечает за всё, потому что он эксплуатировал сервис. Это может игнорировать архитектуру клиента и ограничения бесплатного публичного резолвера. Другая говорит, что клиенты должны были использовать альтернативный резолвер, и поэтому провайдер не несёт подотчётности. Это игнорирует контроль над ошибочной привязкой, обновлением, отзывом маршрутов, привязками и ремонтом.

Подотчётность следует за практическим контролем над предотвращением, обнаружением, ограничением, раскрытием и восстановлением. Тот факт, что другая сторона могла снизить свою подверженность, не снимает обязанность стороны, контролировавшей сломанный механизм.

Слой реальности Heng.lu — это идентичность сервиса в работе

Доктрина Heng.lu рассматривает реестры как книги учёта и хранителей записей, а не суверенных создателей операционной реальности. Она отдаёт приоритет работающему коду и рассматривает номерные ресурсы как объекты, требующие уникальности, точности, метаданных безопасности и непрерывности.

Июльский инцидент даёт прямой сетевой пример.

Префиксы 1.1.1.1 имели идентичности. У сервиса было имя. Записи топологии связывали сервисы, префиксы и площадки. BGP и RPKI предоставляли дополнительные доказательства маршрутов и авторизации. Эти записи имели значение. Неточная привязка стала началом сбоя.

Однако сама запись не сделала резолвер доступным или недоступным.

Доступность изменилась, когда автоматизация превратила запись в отзыв маршрутов и изменения пограничных привязок. Восстановление продвигалось, когда маршруты были повторно анонсированы, привязки вернулись и запросы завершились. Работающая сеть разрешила спор между предполагаемым и фактическим состоянием.

Это не аргумент против записей. Это аргумент за более сильные записи, связанные с операционным доказательством.

Для производственного сервисного префикса книга учёта должна сохранять:

Префикс и семейство адресов.
Авторитетного владельца сервиса.
Предполагаемые производственные площадки.
Метаданные источника маршрута и авторизации.
Требования к пограничным привязкам.
Конечные точки протоколов.
Историю изменений.
Критичность и политику минимального присутствия.
Зависимости и владельца восстановления.
Последнюю наблюдённую проверку маршрута и сервиса.

Книга учёта должна делать конфликтующие претензии видимыми. Она не должна иметь возможности объявлять успех лишь потому, что поля заполнены.

Операционное доказательство должно включать:

Сформированный вывод маршрутов.
Состояние анонсов маршрутизатора.
Видимость независимых коллекторов.
Состояние пограничного интерфейса или привязки.
Здоровье резолвера.
Завершённые DNS-вопросы с репрезентативных путей.
Результаты учений по восстановлению.

Реестр как книга учёта не означает пассивную документацию. Качественная книга учёта может управлять валидацией, авторизацией и аудитом. Она может отклонять дублирующее владение или отсутствующие метаданные. Чего она не может, так это заменить декларацией доставку пакетов.

Принцип также ограничивает риторику статьи.

Это не требование, чтобы один центральный орган утверждал каждый маршрут или конфигурацию. Это не аргумент, что RPKI, RIR, регулятор или вендор должны стать суверенами над сетью Cloudflare. Это не утверждение, что общественные или географические метки определяют легитимность.

Это утверждение слоя реальности: если запись может отозвать публичный сервисный префикс, её власть, точность и эффект должны быть проверяемы против маршрута и сервиса, которые действительно работают.

Инвариант должен предотвращать достижение глобальным сервисом нуля работающих площадок

Постмортем Cloudflare сообщает, что топология префиксов резолвера была сокращена со всех площадок до одной офлайн-площадки. [1] Этот вывод предполагает прямую цель контроля: критичный глобальный сервис не должен развёртываться с нулём онлайн-производственных площадок, если не используется явно авторизованный путь аварийного отключения.

Точный инвариант требует тщательного проектирования.

Простой счётчик «больше нуля» может быть слишком слабым. Одна работающая площадка может не иметь достаточной ёмкости или географического охвата. Фиксированный минимум может не учитывать обслуживание, региональные ограничения или проект сервиса. Правило, предотвращающее все отзывы, может сохранить маршруты к скомпрометированным или опасно сломанным системам.

Более сильный инвариант может включать несколько измерений:

Как минимум заданное минимальное число исправных производственных площадок.
Охват независимых доменов отказа.
Достаточную измеренную ёмкость для ожидаемого трафика.
Отсутствие неутверждённого перехода от глобального к локальному охвату.
Отсутствие непроизводственного объекта как единственного владельца производственных префиксов.
Отсутствие удаления пограничных привязок до проверки альтернативных исправных площадок.
Явную аварийную авторизацию глобального отзыва.

Инвариант должен работать как на сформированном кандидате, так и на наблюдаемом текущем состоянии.

Предположим, конфигурация говорит, что останутся десять площадок, но пять уже офлайн для обслуживания. Статическая проверка кандидата может пройти, в то время как операционный результат оставит недостаточный охват. И наоборот, коллектор маршрутов может видеть много анонсов, пока соответствующие процессы резолвера неисправны. Шлюзу нужны свежие данные о здоровье и ёмкости с известными ограничениями.

Результат должен быть закрытым при сбое для критичного глобального изменения, но закрытый режим должен быть операционно спроектирован. Если валидатор недоступен, изменение не должно молча обходить его. Если сеть уже отказывает, командованию инцидентом может понадобиться ограниченное переопределение. Переопределение должно быть названным, ограниченным по времени, зарегистрированным и сверенным после восстановления.

Полезный отчёт об инварианте может содержать:

Поле	Доказательство
Кандидатное сопоставление «сервис — префикс»	Точный SHA сформированной конфигурации
Текущее производственное сопоставление	Снимок только для чтения и отметка времени
Предполагаемые площадки	Упорядоченный список со средой и состоянием здоровья
Оставшиеся работающие площадки	Количество, регионы, ёмкость и домены отказа
Дельта маршрутов	Анонсы и отзывы по префиксам и площадкам
Дельта пограничных привязок	Адреса, добавленные или удалённые по площадкам
Внешнее наблюдение	Выбранные BGP-коллекторы и проверки клиентских путей
Наблюдение сервиса	DNS-ответы по транспорту, региону и конечной точке
Состояние переопределения	Владелец, причина, срок действия и утверждение

Это не просьба публиковать чувствительную топологию. Полный отчёт может оставаться защищённым. Публичные постмортемы могут раскрывать класс контроля, результат и ограничения, не раскрывая точные управленческие адреса или внутреннюю архитектуру.

Заявления об исправлениях требуют долговечных операционных доказательств

Постмортем Cloudflare перечисляет меры, призванные предотвратить повторение. Компания сообщает, что удаляла унаследованный глобальный охват системы конфигурации, добавляла защиту от глобального отзыва маршрутов 1.1.1.1, улучшала валидацию и оповещения и пересматривала унаследованные системы. [1]

Эти действия охватывают правильные поверхности отказа.

Удаление глобального охвата может снизить радиус поражения. Защита защищённых префиксов может остановить катастрофический вывод. Улучшенная валидация может выявить ошибки ссылок и топологии. Улучшенные оповещения могут сократить время обнаружения. Пересмотр унаследованных систем может выявить скрытую власть.

Публичная запись не доказывает завершение или постоянную эффективность каждого пункта.

Это не критика, уникальная для Cloudflare. Постмортемы обычно описывают немедленную работу и планы до появления всех долгосрочных доказательств. Подотчётность требует более позднего закрытия, которое различает:

Предложенное исправление.
Внедрённое средство контроля.
Протестированное средство контроля.
Отработанное средство контроля.
Средство контроля, работающее с задокументированными исключениями.

Для класса сбоев июля долговечные доказательства могут включать:

Тесты конфликтов привязки префиксов

Тест пытается привязать производственный префикс резолвера к несвязанному непроизводственному сервису. Система отклоняет его и фиксирует конфликт владельцев.

Тесты нуля работающих площадок

Кандидатная топология оставила бы резолвер без онлайн-производственных площадок. Компилятор отклоняет её до генерации маршрутов.

Проверка сформированной дельты

Изменение тестовой площадки создаёт машинно-читаемый список всех затронутых производственных префиксов и площадок. Рецензенты видят глобальный охват, даже если ввод выглядит локальным.

Канарейка отзыва маршрута

Контролируемое учение проверяет, что неожиданный отзыв в выбранных публичных представлениях BGP останавливает развёртывание и сохраняет доступ восстановления.

Сверка пограничных привязок

Система сравнивает предполагаемые привязки, состояние хоста и состояние маршрута до и после изменения. Она обнаруживает условие «маршрут восстановлен на 77 %, но привязки неполные».

Проверки протокольных путей

Проверки UDP, TCP, DoT и DoH используют те же варианты конечных точек, что и реальные клиенты. Учение фиксирует, какие резервные пути действительно независимы.

Учение по аварийному ускорению

Операторы восстанавливают привязки через аварийный путь, доказывают успех канарейки, блокируют конфликтующие изменения и возвращаются к обычному постепенному процессу.

Ценность этого пакета не в обещании отсутствия будущих сбоев. Он показывает, что известный класс сбоев ограничен, наблюдаем и восстанавливаем.

Практический пакет доказательств

Советам директоров, клиентам, регуляторам и техническим рецензентам не нужна каждая частная команда для оценки модели контроля. Им нужны доказательства, привязанные к механизму.

Контроль	Сохранённые доказательства	Операционный тест	Ограничение
Владение префиксами	Реестр «сервис — префикс», владелец, история и авторизация	Дублирующее или межсредовое притязание отклоняется	Уникальная запись всё равно может быть ошибочной
Целостность топологии	Сформированный граф «сервис — площадка»	Критичный сервис сохраняет утверждённый исправный производственный охват	Данные о здоровье могут устаревать
Предпросмотр глобального радиуса поражения	Точная дельта маршрутов и привязок	Малый ввод выявляет каждый производственный вывод	Дефект компилятора может затронуть и предпросмотр, и развёртывание
Инвариант защищённых префиксов	Версионированная политика критичных префиксов	Вывод с нулём работающих площадок блокируется	Аварийный отзыв всё равно требует пути
Канарейка изменения	Репрезентативный результат компилятора, маршрута и пограничной привязки	Независимое наблюдение согласуется до продвижения	Одна канарейка не может представлять каждый охват
Наблюдение BGP	Журналы маршрутизаторов и независимые коллекторы	Ожидаемые анонсы остаются видимыми	Коллекторы не видят каждый путь
Инвентаризация пограничных привязок	Состояние привязок на уровне хостов по площадкам	Состояния маршрутов и привязок сверяются	Привязка не доказывает здоровье резолвера
Доказательство сервиса резолвера	Завершение запросов по конечной точке, транспорту и региону	Реалистичные вопросы получают ограниченные ответы	Синтетический охват остаётся частичным
Полномочия отката	Блокировка инцидента, владелец и журнал команд	Одна последовательность восстановления не может быть перезаписана	Ручная работа может ускользнуть от автоматизации
Аварийное развёртывание	Переопределение, канарейка, критерии остановки и срок действия	Ускоренное восстановление проверяется безопасно	Срочность повышает операционный риск
Непрерывность клиента	Карта зависимостей и протестированный альтернативный путь	Критичный сервис переживает ограниченную потерю резолвера	Альтернативные пути могут иметь общие зависимости
Долговечность исправлений	Регулярное учение и запись исключений	Известный класс сбоев остаётся ограниченным с течением времени	Тест не может доказать всё будущее поведение

Каждый пункт отличает запись от результата.

Реестр префиксов необходим, но недостаточен. Граф топологии необходим, но недостаточен. Видимость BGP необходима, но недостаточна. DNS-ответ необходим, но недостаточен для каждого пользовательского пути.

Цепочка доказательств становится достоверной, когда состояния сверяются:

Утверждённая запись имеет одного подотчётного владельца.
Сформированный вывод сохраняет критичный инвариант.
Развёрнутые маршруты соответствуют сформированному выводу.
Пограничные привязки соответствуют завершению маршрутов.
Процессы резолвера отвечают через ожидаемые транспорты.
Репрезентативные пользователи могут достичь сервиса.
Доказательства восстановления закрывают каждый затронутый уровень.

Чувствительные детали можно защитить. Точная конфигурация маршрутизаторов, управленческие адреса, внутренние имена сервисов и средства безопасности могут создавать риск при публикации. Независимые рецензенты могут проверять их под конфиденциальностью. Публичные доказательства могут указывать классы контроля, сроки, охват, результаты тестов и нерешённые ограничения.

Вопросы для операторов, клиентов и рецензентов

Сетевые и платформенные операторы должны спрашивать:

Какая система авторитетна для владения «сервис — префикс»?
Может ли непроизводственный объект ссылаться на производственный префикс или сужать его?
Показывает ли проверка сформированную глобальную дельту маршрутов и привязок?
Какой инвариант предотвращает ноль исправных производственных площадок?
Какой независимый наблюдатель может остановить развёртывание?
Сверяются ли маршрут, пограничные привязки и здоровье резолвера?
Может ли восстановление продолжаться без отказавшей системы топологии?
Кто владеет блокировкой изменений инцидента?
Как аварийное развёртывание ускоряется, а затем нормализуется?
Когда этот класс сбоев отрабатывался в последний раз?

Клиенты и пересылающие сетевые операторы должны спрашивать:

Какие критичные сервисы используют адреса 1.1.1.1 напрямую?
Какие используют cloudflare-dns.com или другой путь?
Настроен ли альтернативный резолвер, совместим ли он и протестирован?
Сохраняет ли аварийное переключение приватность, фильтрацию и политику безопасности?
Могут ли локальные кэши или проект сервиса снизить зависимость без создания устаревших или небезопасных ответов?
Какие журналы показывают фактическое воздействие, а не общепровайдерское допущение?
Может ли операционная коммуникация продолжаться, если выбранный резолвер недоступен?

Рецензенты должны спрашивать:

Имела ли июньская запись скрытую производственную власть?
Выявил ли июльский предпросмотр отзывы префиксов резолвера?
Отработала ли канарейка глобальное обновление?
Использовала ли политика защищённых префиксов свежее здоровье площадок?
Когда вернулись маршруты, привязки и запросы?
Какие доказательства отделяют не причинное объявление Tata от корневой причины?
Какие обязательства по исправлениям имеют текущие результаты тестов?
Какие ограничения остаются частными или неизвестными?

Вопросы не требуют идеальной доступности. Они требуют ограниченной и проверяемой связи между контролем и последствием.

Границы сравнения имеют значение

Cloudflare опубликовала несколько отчётов об инцидентах, связанных с маршрутизацией или 1.1.1.1. Рассматривать их как один общий сбой означало бы стереть средства контроля, нуждающиеся в ремонте.

Сбой июня 2022 года был связан с порядком терминов политики экспорта BGP, архитектурой Multi-Colo PoP и репрезентативным поэтапным изменением. Он уже освещён отдельной статьёй Daniel Kade. Событие июля 2025 года было связано с унаследованной ошибочной привязкой топологии сервиса, которая глобально отозвала префиксы резолвера.

Инцидент 1.1.1.1 июня 2024 года был связан с перехватом и утечкой маршрута. [20] Этот механизм отличается от внутреннего отзыва 2025 года.

Объявление Tata Communications India, наблюдённое в июле 2025 года, было параллельным и, по данным Cloudflare, не причинным. [1] Его не следует объединять с компаратором 2024 года или представлять как причину исчезновения резолвера.

Сбой конфигурации feature-file Cloudflare затронул другой сервис и путь управления. Общая фраза «глобальная конфигурация» не делает события дубликатами.

Уникальная граница статьи 2025 года узка: неточное владение «сервис — префикс», глобальное обновление топологии, отзыв маршрутов, удаление пограничных привязок и многоуровневое восстановление публичного рекурсивного DNS-сервиса.

Ограничения источников

Постмортем Cloudflare — самый подробный публичный источник механизма инцидента, хронологии, затронутых префиксов, различий путей трафика, восстановления и исправлений. Это отчёт первой стороны. Публичная запись не раскрывает полный конфигурационный граф, компилятор, частное состояние маршрутизаторов, все пограничные хосты, утверждения изменений, каждое оповещение, инвентаризацию воздействия на клиентов или внутренние записи решений. [1]

Cloudflare Radar предоставляет публичные представления DNS и маршрутизации. Он управляется Cloudflare и опирается на выбранные источники данных и сеть компании. Он не представляет каждый маршрут, резолвер, интернет-провайдера или пользовательский путь. [2][3]

Текущая документация Cloudflare объясняет публичный резолвер, вышестоящее разрешение, использование сетевыми операторами, Data Localization Suite, контекст IP-адресов и пиринга. Она обновлялась с течением времени и не может доказать точную частную архитектуру июля 2025 года или состояние исправлений. [4]-[11]

RFC определяют DNS, anycast, BGP, шифрованный DNS, валидацию источника и операционные практики. Они не устанавливают частную реализацию Cloudflare, договорную обязанность или юридический стандарт заботы. [12]-[19]

Постмортем июня 2024 года — компаратор границ событий, а не доказательство того, что те же действующие лица или средства контроля вызвали инцидент июля 2025 года. [20]

Статья не устанавливает злой умысел, сокрытие, небрежность, уголовное поведение, гражданскую ответственность, нарушение регулирования, общие потери клиентов или индивидуальную вину. Она не утверждает, что RPKI предотвратил бы сбой. Она не утверждает, что каждое объявленное исправление развёрнуто или эффективно.

Показатель трафика 77 % — это сообщённый оператором уровень трафика после повторного анонсирования маршрутов, а не процент восстановленных уникальных пользователей. Показатель парка 23 % описывает пограничные серверы, удалившие необходимые привязки, а не число затронутых пользователей.

Эти ограничения не препятствуют анализу подотчётности. Они определяют доказательства, необходимые для перехода от подробного операторского постмортема к долговечному доказательству контроля.

Заключение

Сбой Cloudflare 1.1.1.1 в июле 2025 года начался с неточной записи и стал сбоем, когда работающие системы начали действовать на её основе. Непроизводственная топология сервиса ссылалась на производственные префиксы резолвера. Позднее изменение тестовой площадки запустило глобальное обновление. Топология резолвера схлопнулась до одной офлайн-площадки, производственные маршруты были отозваны, а на части парка удалены необходимые пограничные привязки. [1]

Для клиентского опыта это был сбой DNS, а по механизму — сбой состояния маршрутов. Оба описания важны. Резолвер не мог ответить пользователям, которые не могли его достичь. Разные транспорты и наборы адресов конечных точек дали разные результаты. Повторное анонсирование маршрутов восстановило лишь часть трафика, пока не наверстали пограничные привязки и состояние сервиса.

Подотчётный контроль — это не общее обещание проверять конфигурацию внимательнее. Это конкретная цепочка доказательств:

Один авторитетный владелец для каждого производственного сервисного префикса.
Сформированный предпросмотр глобальных эффектов маршрутов и привязок.
Жёсткий инвариант против нуля исправных производственных площадок.
Репрезентативные канарейки, отрабатывающие реальный компилятор и путь обновления.
Независимое наблюдение BGP и клиентских путей.
Сверка маршрутов, пограничных привязок и состояния резолвера.
Один владелец изменений инцидента и протестированный путь аварийного восстановления.
Текущие доказательства того, что исправления остаются активными.

RPKI, BGP-коллекторы, записи топологии, тикеты изменений и страницы статуса вносят вклад. Ни один не может заменить работающий сервис. Авторизация источника не доказывает доступность. Маршрут не доказывает ответ резолвера. Здоровый процесс не доказывает достижимость. Предполагаемая топология не доказывает развёрнутое состояние.

Это слой реальности Heng.lu. Записи номерных ресурсов и сервисов должны быть уникальными, точными, безопасными и непрерывными, потому что они делают эксплуатацию проверяемой. Они — книги учёта, а не суверенные декларации, заставляющие пакеты прибывать. Финальное доказательство — префикс, всё ещё анонсируемый из исправных площадок, пограничное устройство, всё ещё привязанное, резолвер, всё ещё отвечающий, и путь восстановления, всё ещё пригодный, когда обычная плоскость управления ошибается.

Постмортем Cloudflare даёт необычно ясную причинную запись и указывает соответствующие исправления. Следующий шаг подотчётности — долговечные доказательства: тесты, которые отклоняют ту же межсредовую привязку, блокируют вывод с нулём работающих площадок, сверяют маршруты и привязки, отрабатывают восстановление и фиксируют исключения с течением времени.

Глобальная инфраструктура будет продолжать зависеть от компактной конфигурации, управляющей огромными парками. Правильный ответ — не отказываться от автоматизации или anycast. Нужно сделать их власть видимой. Малый ввод должен показывать свой глобальный вывод до развёртывания. Запись должна указывать ресурс, которым управляет. Канарейка должна представлять систему, которая может отказать. А восстановление должно закрываться только тогда, когда пользователи могут завершить сервис, а не когда предполагаемая конфигурация снова выглядит правильной.

Сбой Cloudflare 1.1.1.1 в 2025 году: отзыв маршрутов как проверка подотчётности DNS

Почему это важно