14 июля 2025 года Cloudflare внесла изменение в сервисные топологии, которое привело к отказу 1.1.1.1 на периферии сети и, как следствие, к 62-минутному простою для клиентов, использовавших публичный DNS-резолвер 1.1.1.1, а также к периодической деградации сервиса Gateway DNS.

Служба резолвера 1.1.1.1 от Cloudflare была недоступна в Интернете с 21:52 до 22:54 UTC. Было затронуто большинство пользователей 1.1.1.1 по всему миру. Для многих невозможность разрешать имена через резолвер 1.1.1.1 означала фактическую недоступность всех интернет-сервисов. Этот сбой виден на Cloudflare Radar.

Сбой произошёл из-за некорректной конфигурации легаси-систем, которые поддерживают инфраструктуру анонсирования IP-адресов Cloudflare в Интернет.

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

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

Предпосылки

Cloudflare представила публичный DNS-резолвер 1.1.1.1 в 2018 году. С момента анонса 1.1.1.1 стал одним из самых популярных IP-адресов DNS-резолвера, и им может бесплатно пользоваться любой желающий.

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

Cloudflare анонсирует эти anycast-маршруты в Интернет, чтобы трафик к этим адресам доставлялся в один из дата-центров Cloudflare; сервис обслуживается из множества локаций. Большинство сервисов Cloudflare предоставляются глобально, как и публичный DNS-резолвер 1.1.1.1, однако часть сервисов сознательно ограничена определёнными регионами.

Эти сервисы входят в состав нашего Data Localization Suite (DLS), который позволяет клиентам настраивать Cloudflare различными способами для соответствия требованиям регуляторов в разных странах и регионах. Cloudflare настраивает доступ к IP-адресам сервиса лишь там, где это нужно, чтобы трафик по всему миру обрабатывался корректно. Конкретному сервису соответствует «сервисная топология», то есть трафик этого сервиса должен направляться только в заданный набор локаций.

6 июня во время релиза по подготовке сервисной топологии для будущего сервиса DLS была внесена ошибка конфигурации: префиксы, связанные с резолвером 1.1.1.1, по ошибке попали в один набор с префиксами, предназначенными для нового сервиса DLS. Эта ошибка «дремала» в продакшен-сети, поскольку новый сервис DLS ещё не использовался, но именно она подготовила почву для сбоя 14 июля. Поскольку немедленных изменений в продакшен-сети не произошло, влияния на конечных пользователей не было, и, как следствие, никакие алерты не сработали.

Хронология инцидента

Влияние

Затронутым оказался любой трафик, приходивший в Cloudflare через сервисы резолвера 1.1.1.1 на следующих IP-префиксах. Трафик к адресам в этих префиксах также пострадал.

1.1.1.0/24
1.0.0.0/24
2606:4700:4700::/48
162.159.36.0/24
162.159.46.0/24
172.64.36.0/24
172.64.37.0/24
172.64.100.0/24
172.64.101.0/24
2606:54c1:13::/48
2a06:98c1:54::/48

Когда началось воздействие, мы наблюдали немедленное и значительное падение числа запросов по UDP, TCP и DNS через TLS (DoT). У большинства пользователей в качестве DNS-сервера был настроен 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 или 2606:4700:4700::1001. Ниже показана скорость поступления запросов для каждого из указанных протоколов и то, как они были затронуты во время инцидента.

Стоит отметить, что трафик DoH (DNS через HTTPS) оставался относительно стабильным, поскольку большинство пользователей DoH обращаются к публичному резолверу по доменному имени cloudflare-dns.com, заданному вручную или через браузер, а не по IP-адресу. DoH оставался доступным, и трафик почти не пострадал, так как для cloudflare-dns.com используется другой набор IP-адресов. Часть DNS-трафика по UDP, которая также использовала другие IP-адреса, во многом тоже не пострадала.

По мере отзыва соответствующих префиксов трафик к адресам из этих префиксов не мог достигать Cloudflare. Это видно на временной шкале BGP-анонсов для 1.1.1.0/24:

Если посмотреть на скорость запросов к отозванным IP-адресам, можно заметить, что в окно воздействия почти никакой трафик не поступал. Когда в 22:20 UTC было внедрено первичное исправление, наблюдался большой всплеск трафика, после чего он вновь снизился. Этот всплеск вызван повторными попытками клиентов. После того как мы снова начали анонсировать отозванные префиксы, запросы вновь смогли доходить до Cloudflare. Полное восстановление маршрутизации во всех локациях завершилось к 22:54 UTC, после чего трафик вернулся в основном к нормальному уровню.

Техническое описание ошибки и то, как она произошла

Сбой сервиса резолвера 1.1.1.1

Как описано выше, 6 июня изменение конфигурации внесло ошибку в сервисную топологию для непродукционного сервиса DLS. 14 июля было внесено второе изменение для этого сервиса: в сервисную топологию предпродакшен DNS-сервиса была добавлена неактивная (offline) дата-центровая локация для проведения внутренних тестов. Это изменение инициировало обновление глобальной конфигурации связанных маршрутов, и именно в этот момент проявилось воздействие ранее допущенной ошибки. Сервисная топология префиксов резолвера 1.1.1.1 была «сужена» со всех локаций до одной, причём неактивной. Эффектом стал глобальный и немедленный отзыв всех префиксов 1.1.1.1.

По мере отзыва маршрутов к префиксам резолвера 1.1.1.1 сам сервис стал недоступен. Сработали оповещения, и был объявлен инцидент.

Техническое расследование и анализ

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

У этой модели есть ещё один существенный изъян: обновления конфигурации не следуют методологии поэтапных развёртываний. Даже несмотря на то, что этот релиз прошёл экспертную проверку несколькими инженерами (peer review), изменение не прошло через серию канареечных развёртываний до попадания во все дата-центры Cloudflare.

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

Первые оповещения по DNS-резолверу сработали в 22:01 и указывали на сбои запросов, прокси и дата-центров. Исследуя оповещения, мы заметили, что трафик к префиксам резолвера резко упал и перестал доходить до наших пограничных дата-центров. Внутри компании мы используем BGP для управления анонсами маршрутов и обнаружили, что маршруты резолвера полностью отсутствовали (в нашей таблице маршрутизации).

После того как конфигурационная ошибка проявилась и системы Cloudflare отозвали маршруты из нашей таблицы маршрутизации, все маршруты к префиксам сервиса 1.1.1.1 должны были полностью исчезнуть из глобальной таблицы маршрутизации Интернета. Однако с префиксом 1.1.1.0/24 этого не произошло. Вместо этого мы получили сигналы из Cloudflare Radar о том, что Tata Communications India (AS4755) начала анонсировать 1.1.1.0/24: с точки зрения системы маршрутизации это выглядело как перехват префикса (prefix hijack). Увидеть это во время устранения проблем с маршрутизацией было неожиданно, но тут важно чётко подчеркнуть: этот BGP-хайджек не был причиной сбоя. Мы проводим дополнительное взаимодействие с Tata Communications.

Восстановление работы сервиса 1.1.1.1

Мы откатили конфигурацию к предыдущей версии в 22:20 UTC. Почти мгновенно мы возобновили анонсирование BGP-префиксов, которые ранее были отозваны с роутеров, включая 1.1.1.0/24. Это восстановило объёмы трафика 1.1.1.1 примерно до 77% от уровня до инцидента. Однако за время после  отзыва около 23% парка пограничных серверов были автоматически переконфигурированы таким образом, что необходимые привязки IP-адресов были удалены вследствие изменения топологии. Чтобы вернуть эти настройки, требовалась повторная конфигурация этих серверов через нашу систему управления изменениями, что по соображениям безопасности по умолчанию не происходит мгновенно.

Процесс восстановления привязок IP-адресов обычно занимает некоторое время, поскольку сеть в отдельных локациях спроектирована так, чтобы обновляться на протяжении нескольких часов. Мы применяем поэтапное развёртывание, а не обновляем все узлы разом, чтобы не вызвать дополнительного влияния. Тем не менее, учитывая серьёзность инцидента, после проверки изменений на тестовых локациях мы ускорили развёртывание исправления, чтобы как можно быстрее и безопаснее восстановить сервис. Нормальные уровни трафика были зафиксированы в 22:54 UTC.

Меры по устранению и дальнейшие шаги

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

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

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

Если хочется разбирать такие инциденты не «в общих чертах», а на уровне конфигов и трассировки, присмотритесь к курсу Network Engineer. Basic: соберёте и задокументируете L2/L3-сети, настроите VLAN, статическую и динамическую маршрутизацию IPv4/IPv6 и поработаете в CLI Cisco IOS. Это фундамент, без которого трудно уверенно читать BGP-картину мира, диагностировать сбои anycast-сервисов и безопасно катить изменения.

Приходите на открытые уроки, которые проведут преподаватели бесплатно в рамках набора:

• 30 октября: «IS-IS. Введение». Записаться

• 5 ноября: «Основные протоколы сети Интернет». Записаться