`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Cloudflare пояснила часовий глобальний збій DNS-сервісу 1.1.1.1

0 
 
Компанія Cloudflare повідомила про глобальний збій у роботі свого публічного DNS-сервісу 1.1.1.1, що стався 14 липня 2025 року. Перебої в роботі тривали 62 хвилини, починаючи з 21:52 UTC і закінчуючись о 22:54 UTC, і призвели до недоступності інтернету для багатьох користувачів по всьому світу. Це також викликало періодичну деградацію сервісу для Gateway DNS.
 
Як пояснили у Cloudflare, основною причиною інциденту стала помилка конфігурації застарілих систем, які використовуються для підтримки інфраструктури, що анонсує IP-адреси компанії в інтернеті. У компанії підкреслили, що це була внутрішня помилка конфігурації, а не результат зовнішньої атаки чи BGP-перехоплення.
 
Cloudflare представила свій публічний DNS-сервіс 1.1.1.1 у 2018 році, і з того часу він став однією з найпопулярніших IP-адрес DNS-роздільника, доступною безкоштовно для всіх. Більшість сервісів Cloudflare доступні в інтернеті за допомогою методу маршрутизації anycast, що дозволяє обслуговувати трафік у багатьох місцях по всьому світу, збільшуючи пропускну здатність та продуктивність.
 
Проблема виникла 6 червня 2025 року о 17:38 UTC, коли була внесена зміна в конфігурацію сервісу DLS (Data Localization Suite), який ще не був увімкнений. Ця зміна випадково включила посилання на сервіс 1.1.1.1 Resolver та пов'язані з ним префікси. Оскільки на той момент нова служба DLS не використовувалася, помилка залишилася "сплячою" у виробничій мережі, не викликаючи негайного впливу на користувачів чи спрацьовування систем оповіщення.
 
14 липня 2025 року о 21:48 UTC була внесена ще одна конфігураційна зміна для того ж сервісу DLS. Ця зміна, що додавала тестову локацію до невиробничого сервісу, спричинила глобальне оновлення конфігурації мережі. Через попередню помилку, яка пов'язувала IP-адреси 1.1.1.1 Resolver з невиробничим сервісом, ці IP-адреси 1.1.1.1 були ненавмисно виключені з виробничих центрів обробки даних Cloudflare по всьому світу.
 
Вже о 21:52 UTC трафік DNS до сервісу 1.1.1.1 Resolver почав падати по всьому світу. О 22:01 UTC внутрішні оповіщення про стан сервісу 1.1.1.1 Resolver почали спрацьовувати, і о 22:01 UTC був оголошений інцидент. Цікаво, що о 21:54 UTC спостерігалося непов'язане BGP-перехоплення префікса 1.1.1.0/24 компанією Tata Communications India (AS4755), яке стало видимим саме через відкликання маршрутів Cloudflare. Цей збій не був причиною інциденту Cloudflare, але збігся з ним у часі.
 
Під час збою спостерігалося негайне та значне падіння запитів через протоколи UDP, TCP та DNS over TLS (DoT). Варто зазначити, що трафік DNS-over-HTTPS (DoH) залишався відносно стабільним, оскільки більшість користувачів DoH використовують домен cloudflare-dns.com для доступу доresolver, а не IP-адресу, і цей домен використовує інший набір IP-адрес.
 
Відкат до попередньої конфігурації було розпочато о 22:20 UTC. Майже миттєво Cloudflare відновила анонсування BGP-префіксів. Це дозволило відновити рівень трафіку 1.1.1.1 приблизно до 77% від рівня до інциденту. Однак, близько 23% серверів на периферії були автоматично переконфігуровані для видалення необхідних прив'язок IP-адрес. Для відновлення конфігурацій ці сервери потребували переналаштування за допомогою системи управління змінами, що не є миттєвим процесом. Для прискорення повного відновлення сервісу, після перевірки змін у тестових локаціях, було прискорено розгортання виправлення. Нормальні рівні трафіку були зафіксовані о 22:54 UTC, і о 22:55 UTC інцидент було оголошено вирішеним.
 
Cloudflare вже визначила кілька кроків для зменшення ризику виникнення подібних проблем у майбутньому. Компанія планує поетапне розгортання адресації, відмову від застарілих систем, що не використовують поступовий підхід до розгортання, а також прискорення міграції систем адресації від ризикованих методологій розгортання до сучасних, які забезпечують поетапну перевірку та моніторинг стану.

Стратегія охолодження ЦОД для епохи AI

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT