TTL DNS: як відрізнити кеш від помилки запису

Після зміни адреси сайту один колега бачить новий сервер, а інший — старий. Замість повторного редагування записів варто перевірити TTL DNS і з’ясувати, хто саме відповідає на запит. Навчальний сценарій цієї статті: адміністратор уже змінив A-запис для www, але результати відрізняються між мережами. Ми зберемо докази, які допоможуть відокремити кеш резолвера від неправильної зони, не перемикаючи домен повторно.

Це діагностика публічного домену, яким ви керуєте або який маєте дозвіл перевіряти. Вона не доводить працездатності застосунку: правильна IP-адреса ще не означає справний HTTPS, форму чи базу даних. Жодна команда нижче не змінює DNS, системний резолвер або файли сервера. Не застосовуйте цей маршрут до внутрішньої корпоративної зони без погодження: її імена можуть бути непублічними.

Підготуйте точне ім’я та джерело очікувань

Запишіть повне ім’я вузла, тип запису, очікуване значення та час погодженої зміни. Кореневий домен і www — різні імена; A та AAAA теж перевіряються окремо. Очікувану адресу беріть із власного плану перенесення або панелі провайдера, а не з випадкового результату пошуку. Якщо не знаєте, який запис змінювали, спочатку уточніть це в адміністратора зони.

Потрібен термінал macOS або Linux із доступним dig та дозволеними DNS-запитами. Права адміністратора й каталог проєкту не потрібні: запускати можна з будь-якої директорії. Перша команда показує версію інструмента. Якщо dig відсутній, скористайтеся документацією вашої системи для штатного встановлення; не змінюйте мережеві налаштування навмання й не запускайте сторонні інсталяційні скрипти.

dig -v
dig example.com. NS +noall +answer

example.com і ns1.example.net у матеріалі є умовними іменами, не конфігурацією вашого сайту. Замініть домен на власну публічну зону. Другий запит допомагає отримати її NS-записи; зіставте їх із делегуванням у реєстратора та даними DNS-провайдера. Заключна крапка позначає повне доменне ім’я. Для піддомену з окремою делегацією потрібні сервери саме його зони, а не довільний NS батьківського домену.

Розділіть авторитетну відповідь і кешовану копію

Виконайте наступні два запити, підставивши реальний авторитетний сервер замість ns1.example.net та потрібне ім’я замість www.example.com. Перший звертається до обраного NS без запиту рекурсії; другий використовує резолвер, обраний dig у вашому середовищі. Параметри й формат відповіді описані в офіційній документації dig.

dig @ns1.example.net. www.example.com. A +norecurse
dig www.example.com. A +noall +answer

У повній першій відповіді перевірте status, прапорець aa, секцію ANSWER та поле SERVER. Прапорець aa вказує на авторитетну відповідь, але сам собою не замінює перевірку правильності делегування. Відповідь без нього або відмова не дає підстав називати результат еталоном зони. Повторіть прямий запит для інших її авторитетних серверів: суперечність між ними потребує перевірки публікації зони, а не очікування кешу користувача.

У рядку звичайної відповіді після імені розташований TTL, далі клас IN, тип і значення. TTL вимірюється секундами та обмежує час кешування запису; базове правило визначено в RFC 1034. Наприклад, умовний залишок 120 означає дві хвилини для цього спостереження, а не гарантований строк оновлення всіх пристроїв світу. Зменшення TTL зараз не скорочує заднім числом строк уже збереженої старої копії.

Перевірте не тільки адресу, а й тип відхилення

Якщо авторитетні сервери узгоджено повертають нове значення, а резолвер — старе, збережіть обидві відповіді з часом. Через розумний інтервал повторіть той самий запит, не змінюючи мережу. Зменшення залишкового TTL узгоджується з кешуванням, але не є універсальним доказом: розподілені резолвери можуть відповідати з різних кешів. Не опитуйте сервер безперервним циклом; кількох контрольних спостережень достатньо для звернення до підтримки.

dig www.example.com. A
dig www.example.com. AAAA

Ці два запити повертають повний діагностичний вивід для IPv4 та IPv6 відповідно. Тут навмисно немає скорочення +noall: порожня ANSWER у короткому виводі не пояснює причину. NXDOMAIN означає повідомлення про відсутність імені, а NOERROR без потрібного запису може означати відсутність даних цього типу. SERVFAIL і тайм-аут не слід називати просто старою IP-адресою. Збережіть статус і сервер, а не лише порожній результат.

Відсутність імені також може кешуватися: створення нового запису не завжди одразу прибирає попередню негативну відповідь. Її строк визначається через SOA за правилами RFC 2308, а не TTL щойно доданого A-запису. Якщо бачите CNAME, врахуйте цільове ім’я окремо; не очікуйте, що зміна одного запису одночасно оновить увесь ланцюжок залежностей.

Завершіть перевірку рішенням, а не очищенням навмання

Зберіть коротку таблицю спостережень: час, мережа, запитане ім’я, тип, сервер відповіді, статус, значення й TTL. Правильний результат — пояснена різниця або конкретне питання до DNS-провайдера. Не надсилайте йому паролі, приватні зони чи повні конфігурації. Якщо DNS узгоджений, а браузер показує інший сайт, перевіряйте наступні рівні окремо: браузер може користуватися іншим резолвером, а застосунок — HTTP-кешем.

Не очищайте всі кеші та не змінюйте DNS-провайдера лише заради однакової картинки. Так можна втратити докази й створити нову проблему. Будь-яке подальше редагування зони погоджуйте окремо: збережіть попередні значення, визначте відповідального, контроль після зміни та спосіб повернення. Повернення запису теж залежить від кешування, тому не обіцяйте миттєвого відкату для всіх користувачів.

Висновок: спочатку звірте авторитетні сервери, потім резолвер, TTL і статус, і лише після цього переходьте до сайту. Для перевірки самого нового хостингу корисний окремий спосіб із curl –resolve. Якщо відповіді залишаються суперечливими, AriZone може допомогти розібрати зібрані спостереження й узгодити наступний безпечний крок без повторного перемикання домену навмання.