Сайт відкривається не у всіх: як знайти збій DNSSEC після заміни ключа

DNSSECреагування на інцидентимережева інфраструктура

Робочий стіл чергового інженера з ключами та розірваним ланцюжком як образ DNSSEC-інциденту

Сайт працює — але не для всіх

Уявіть нічну зміну після планової заміни DNSSEC-ключа. В офісі сайт відкривається. Через мобільний інтернет — ні. Один DNS-сервер повертає адресу, інший відповідає SERVFAIL. Моніторинг застосунку зелений, сервер доступний, але частина людей усе одно не може зайти.

Це не обов’язково збій сайту. Часто проблема виникає раніше — у перевірці DNS-відповіді. Сервер повідомляє правильну адресу, але DNSSEC не дозволяє їй довіряти.

Саме такий клас помилки описано в розборі інциденту домену .AL: новий DNSKEY уже з’явився в зоні, а батьківський запис DS ще вказував не туди. Одні DNS-сервери бачили старі дані в кеші, інші — нові. Тому для одних користувачів усе працювало, а для інших домен ніби зник.

Що саме зламалося

DNSSEC можна уявити як перевірку ключа за списком довірених ключів. У самій доменній зоні лежить відкритий ключ DNSKEY. У батьківській зоні є запис DS, який підказує, якому ключу довіряти.

Після заміни ключа ці дві частини мають збігтися. Якщо зона вже показує новий DNSKEY, а DS усе ще посилається на старий, перевірка провалюється. Авторитетний DNS-сервер чесно повертає записи, але рекурсивний сервер, який перевіряє підписи, відкидає їх і відповідає SERVFAIL.

Тобто дані є, мережа працює, а безпечної відповіді для користувача немає.

Почніть не з перезапуску, а з порівняння

Не очищайте кеші й не вимикайте DNSSEC одразу. Спочатку збережіть докази: час, повну відповідь і адресу сервера для кожної перевірки. Потім порівняйте щонайменше два незалежні рекурсивні DNS-сервери з авторитетним джерелом:

dig example.ua NS
dig +dnssec example.ua DS
dig +dnssec @<authoritative-IP> example.ua DNSKEY
dig +dnssec @<resolver-IP> example.ua A
dig +dnssec +cdflag @<resolver-IP> example.ua A
delv example.ua A

Зверніть увагу на три речі:

  • Якщо звичайний запит повертає SERVFAIL, а запит із +cdflag отримує підписані дані, проблема, ймовірно, саме в перевірці підпису.
  • Якщо авторитетний сервер відповідає, а рекурсивні сервери дають різні результати, порівняйте DS, DNSKEY і кешовані значення.
  • Якщо опубліковані записи вже правильні, але помилка ще трапляється, перевірте TTL: старі дані могли залишитися в кешах.

Ці ознаки звужують пошук, але не доводять причину окремо. Звірте DS з потрібним DNSKEY, алгоритми, строки дії підписів і прапорці ключа.

Чекати, виправляти чи відкочувати

Рішення залежить не від того, який варіант швидший, а від того, який стан уже бачить інтернет.

Чекати можна, якщо DS і DNSKEY уже узгоджені, а решта помилок вкладається у відомий TTL. Одразу призначте час наступної перевірки.

Виправляти варто, якщо новий ключ правильний, але DS у батьківській зоні ще не оновлено. Тут потрібен реєстратор або реєстр домену: сам вебсервер проблему не виправить.

Відкотити зміну можна, якщо старий ключ іще доступний, DS досі довіряє йому, а повернення не створить нової помилки підпису.

NTA — аварійний міст, а не ремонт

Якщо виправлення затягується, оператор рекурсивного DNS-сервера може застосувати NTA — тимчасово не перевіряти DNSSEC для конкретної зони. Це здатне повернути доступність, але на час винятку зникає криптографічна гарантія справжності відповіді.

Тому NTA доречний лише за чітких умов: збій справді значний, дані перевірено незалежним шляхом, швидко полагодити зону неможливо, а виняток має власника й точний час автоматичного завершення. Власник сайту не може наказати зовнішнім DNS-серверам застосувати NTA.

EDE 33 допомагає не приховувати такий обхід. DNS-сервер може додати цей код до відповіді, щоб журнали й моніторинг показали: дані повернули лише завдяки тимчасовому винятку. Відсутність EDE 33 ще не доводить, що NTA немає — не всі сервери й клієнти підтримують цей код.

Як зрозуміти, що інцидент завершено

Ще раз отримайте DS і DNSKEY через незалежні сервери, перевірте підписи й дочекайтеся потрібного TTL. Потім видаліть NTA та повторіть запити без +cdflag через кілька DNS-серверів.

Не продовжуйте виняток «ще на годинку» без нового рішення. У плані мають бути відповідальний, кінцевий час, критерії відкочування, контакти реєстратора або реєстру та спосіб перевірити відновлення. Контакти краще зберігати поза проблемною DNS-зоною — інакше під час збою вони можуть стати недоступними разом із сайтом.

Чого не варто робити

Не вимикайте DNSSEC глобально через одну проблемну зону. Не вважайте відповідь авторитетного сервера доказом, що весь ланцюжок довіри справний. Не видаляйте старий DNSKEY, доки DS і кеші не перейшли на новий стан. І не плутайте дві різні цілі: повернути сайт в онлайн та знову підтвердити справжність DNS-даних.

Джерела

Короткий чеклист

  • порівняти відповіді щонайменше двох незалежних DNS-серверів
  • звірити DS у батьківській зоні з актуальним DNSKEY
  • записати час перевірок, TTL і строк дії підписів
  • призначити відповідального за виправлення або тимчасовий виняток
  • обмежити виняток однією зоною та точним часом
  • після відновлення повторити перевірки й видалити NTA

Складіть план дій для DNSSEC-інциденту

Допоможи черговій команді розібрати DNSSEC-інцидент і скласти короткий план дій. Спочатку попроси надати: домен або зону; час появи помилок у UTC; адреси авторитетних і рекурсивних DNS-серверів; відомі DS і DNSKEY; план останньої заміни ключа; вплив на сервіси; доступні контакти реєстратора або реєстру; можливість застосувати NTA; допустиму тривалість винятку. Не припускай, що SERVFAIL автоматично означає помилку DNSSEC. Пояснюй висновки просто: що ми побачили, що це може означати і чого ще не знаємо. Не радь вимикати перевірку глобально. Поверни результат у форматі: 1. Що вже відомо і яких даних бракує. 2. Команди перевірки та просте пояснення результатів. 3. Найімовірніше місце помилки. 4. Рекомендація: чекати, виправляти, відкочувати або застосувати NTA. 5. Якщо потрібен NTA — його межі, власник і час автоматичного завершення. 6. Як перевірити відновлення й безпечно прибрати виняток. 7. Коротке повідомлення для команди.