Компания Cloudflare опубликовала официальное разбирательство инцидента, произошедшего 14 июля 2025 года, когда её популярный DNS-резолвер 1.1.1.1 оказался недоступен в течение 62 минут по всему миру. Как выяснилось, причиной сбоя стала внутренняя ошибка конфигурации, а не внешняя атака, хотя ситуацию усугубил параллельный BGP-хайджек, не связанный с первоначальной проблемой.
Сбой произошёл в период с 21:52 по 22:54 UTC и затронул миллионы пользователей, полагающихся на 1.1.1.1 как основной DNS-сервис. В результате большинство интернет-ресурсов стали недоступны для пострадавших, поскольку устройства не могли преобразовать доменные имена в IP-адреса. Это один из самых масштабных DNS-инцидентов за последние годы, учитывая, что 1.1.1.1 с момента запуска в 2018 году стал одним из ключевых публичных DNS-сервисов.
Причина сбоя и хронология событий
Источником проблемы оказалась ошибочная конфигурация, внесённая ещё 6 июня 2025 года в рамках подготовки к запуску нового сервиса Data Localization Suite (DLS). Ошибка связала IP-адреса DNS-резолвера 1.1.1.1 с нерабочей тестовой средой, но оставалась незамеченной более месяца, пока неактивные изменения не вступили в силу.
14 июля инженеры Cloudflare выполнили рутинное обновление конфигурации, добавив тестовую локацию в тот же сервис DLS. Это привело к глобальному обновлению сетевой топологии, в ходе которого маршруты к 1.1.1.1 были случайно отозваны из всех дата-центров Cloudflare. Затронутыми оказались не только диапазон 1.1.1.0/24, но и связанные с ним подсети, включая 1.0.0.0/24 и несколько IPv6-префиксов.
Неожиданный BGP-хайджек от Tata Communications
Пока Cloudflare пыталась восстановить маршрутизацию, индийский телеком-оператор Tata Communications (AS4755) неожиданно начал анонсировать диапазон 1.1.1.0/24, что выглядело как классический BGP-хайджек. Однако, как подчёркивает Cloudflare, это не было причиной первоначального сбоя, а лишь усложнило диагностику.
Компания обнаружила проблему в 22:01 UTC и объявила инцидентом. Уже к 22:20 UTC инженеры откатили конфигурацию, восстановив около 77% трафика. Однако ещё 23% серверов автоматически удалили необходимые IP-привязки, что потребовало дополнительных ручных вмешательств.
Чтобы ускорить восстановление, Cloudflare временно отказалась от стандартного постепенного развёртывания изменений, выполнив принудительное обновление критически важных узлов. Полная работоспособность была восстановлена к 22:54 UTC.
Последствия и выводы
Инцидент наглядно демонстрирует, насколько хрупкой может быть глобальная DNS-инфраструктура. Ошибка конфигурации, которая оставалась незамеченной несколько недель, привела к каскадному отказу, а параллельный BGP-хайджек добавил неопределённости в процесс восстановления.
Cloudflare пообещала пересмотреть внутренние процедуры тестирования изменений и усилить мониторинг маршрутизации, чтобы минимизировать риски подобных сбоев в будущем. Тем не менее, этот случай в очередной раз напоминает о важности резервных DNS-серверов для конечных пользователей и бизнеса, зависящего от бесперебойной работы интернет-сервисов.
Эксперты по кибербезопасности отмечают, что сочетание внутренних ошибок и внешних факторов, таких как BGP-инциденты, остаётся одной из ключевых угроз для стабильности интернета. В условиях роста сложности сетевой инфраструктуры даже крупные игроки, такие как Cloudflare, не застрахованы от каскадных сбоев, требующих оперативного и прозрачного реагирования.
