Уявімо, що адресу сервера домену змінили: удома відкривається новий сайт, а телефон досі підключається до старого сервера. Навіть за однакового введеного імені результати можуть тимчасово відрізнятися, якщо пристрої зверталися до різних кешів DNS. HTTP-кеш, з якого повторно отримують сторінку, і DNS-кеш, що допомагає знайти адресу підключення, потребують перевірки різних речей.
У цій статті простежимо зв’язок розв’язання імен і кешування на прикладі вигаданого вузла бібліотеки www.library.example. Ім’я й розклад створені для пояснення; відповіді справжньої служби не вимірювалися. Мета — розділити отримання адреси через DNS, причини затримки видимих змін і збої після розв’язання імені.
1. DNS має різні типи відповідей для одного імені
DNS надає пов’язані з доменним ім’ям відомості у записах різних типів. A означає адресу IPv4, AAAA — адресу IPv6; одному імені можуть відповідати кілька адрес. CNAME — псевдонім, що вказує на інше ім’я, MX позначає сервер приймання пошти, а NS — авторитетний сервер імен відповідної зони. Отже, відповідь для того самого імені залежить від запитаного типу запису.
Як пояснює опис записів DNS від Cloudflare, значення CNAME — інше ім’я, а не IP-адреса. Якщо потрібна адреса, розв’язання цього імені може тривати далі. Крім того, в https://www.library.example/books DNS працює з іменем вузла www.library.example. Шлях /books і вміст сторінки в DNS не реєструють. Налаштування CNAME саме собою не створює HTTP-перенаправлення, що змінює адресний рядок браузера.
2. Як рекурсивний резолвер знаходить авторитетний сервер
Засіб розв’язання імен на пристрої зазвичай звертається до налаштованого рекурсивного резолвера. Той використовує потрібні відомості з кешу, а якщо їх бракує — опитує інші сервери DNS і повертає остаточну відповідь або помилку. Стандарт термінології DNS RFC 9499 відрізняє таку роль посередника під час розв’язання від авторитетного сервера, який зберігає відомості про свою зону. Походження відповіді слід тлумачити залежно від ролі, у якій відповідає сервер.
У спрощеній схемі без кешів і проміжних пересилань кореневий сервер скеровує резолвер до серверів домену верхнього рівня, а вони — до авторитетних серверів потрібної зони. Останній авторитетний сервер повертає потрібний запис чи псевдонім. Один кореневий сервер не зберігає IP-адрес усіх сайтів. Насправді пошук може початися зі збережених відомостей про делегування або передаватися іншому резолверу, тому весь порядок не обов’язково повторюється щоразу.
3. TTL — залишок часу в кеші, а не світовий годинник
TTL запису — передані в секундах відомості про строк його зберігання в кеші. У звичайній відповіді з кешу залишок часу зменшується під час зберігання. Наприклад, якщо о 10:00 резолвер зберіг адресу з TTL 300 секунд, у відповіді з тієї самої копії о 10:02 залишиться приблизно 180 секунд. Нижче наведено вигаданий розклад одного резолвера без повторних запитів, завчасного оновлення й надання прострочених відповідей.
| Вигаданий час | Адреса на авторитетному сервері | Дія цього резолвера |
|---|---|---|
| 10:00 | Стара адреса | Зберігає стару адресу з TTL 300 секунд |
| 10:01 | Змінено на нову адресу | Збереженій копії ще залишилося 240 секунд |
| 10:03 | Нова адреса | Може повторно використовувати стару адресу ще 120 секунд |
| Перший запит після 10:05 | Нова адреса | Припускаємо, що замість простроченої копії повторний запит отримує нову адресу |
Інший резолвер міг зберегти запис пізніше або ще жодного разу його не бачити. Час оновлення різниться, тому один TTL не визначає момент одночасного перемикання всіх користувачів світу. Кеш може видалити відомості й до завершення строку, а оновлення вебсторінки не очищує копію спільного резолвера. TTL допомагає зрозуміти повторне використання відповідей DNS, але не обмежує час усього вебз’єднання чи оновлення екрана.
4. Коли зменшувати TTL і як кешується відповідь «немає»
Кеш, який раніше отримав стару адресу з TTL 3600 секунд, не дізнається негайно, що оператор зараз зменшив TTL до 60 секунд. За запланованої зміни адреси TTL слід коригувати завчасно, враховуючи час, протягом якого ще можуть існувати відповіді з попереднім довгим строком. Низький TTL може спричиняти частішу перевірку змін, але також збільшує навантаження запитів і залежність від авторитетного сервера. Замість одного короткого значення для всіх служб розглядають і план зміни, і реагування на збої.
Кешуватися можуть NXDOMAIN, що означає відсутнє ім’я, і NODATA, коли ім’я є, але запису запитаного типу немає. Стандарт негативного кешування RFC 2308 визначає строк негативної відповіді як менше зі значень TTL запису SOA авторитетного сервера й поля MINIMUM цієї SOA. Отже, навіть після додавання раніше відсутнього вузла може залишатися попередня відповідь «немає». Якщо дивитися лише на TTL нового запису A й вважати строк тієї відповіді таким самим, можна пропустити причину.
5. Перевіряємо однакові ім’я, тип і сервер
У записі перевірки фіксуйте точне запитане ім’я, тип, наприклад A чи AAAA, опитаний сервер DNS і час. Якщо встановлено dig, ім’я й тип можна вказати командою dig example.com A. Під час дослідження справжньої проблеми замініть example.com на свій перевірюваний вузол. Це приклад процедури: у статті команду насправді не виконували й часу відповіді не вимірювали.
Розглядайте разом статус відповіді та ім’я, тип, значення і TTL у розділі ANSWER. За повторного однакового запиту до того самого резолвера перевіряйте, чи зменшується TTL, але не вважайте збільшення одразу помилкою. Можливе завчасне оновлення або відповідь іншого вузла серед кількох кешів. Окремі записи A й AAAA, без змішування результатів, допомагають побачити, у якій родині адрес є відмінність.
Оператор може порівняти відповіді свого рекурсивного резолвера й авторитетного сервера керованої зони для однакових імені та типу. За відмінностей послідовно перевіряють залишок часу кешу, узгодженість даних авторитетних серверів і делегування. Відповідь одного публічного резолвера не можна поширювати на стан усіх користувачів. Внутрішній DNS корпоративної мережі чи окремі DNS-налаштування браузера можуть змінити шлях запиту, тому під час порівняння записують і середовище підключення.
6. Розрізняємо помилки DNS, з’єднання та винятки
NXDOMAIN — відповідь про відсутність імені, NODATA — випадок відсутності запитаного типу запису. SERVFAIL натомість означає нездатність сервера обробити запит, а тайм-аут — спостереження, що відповіді не надійшло у відведений час. Не можна тлумачити все це як видалення домену. Спершу збережіть, чи був код відповіді й до якого сервера зверталися: це допоможе визначити наступну перевірку.
Стара відповідь після завершення TTL не завжди порушує правила. Механізм serve-stale у RFC 8767 описує використання прострочених відомостей для підвищення доступності за виняткових обставин, коли неможливо оновитися з авторитетного сервера. Це не означає, що всі резолвери застосовують його з однаковими налаштуваннями. Замість висновку про час оновлення з одного TTL перевіряйте поведінку справді використаного резолвера.
Нарешті, успішний пошук адреси не гарантує відкриття сайту. Мережа на шляху до адреси, сертифікат TLS, вебсервер і застосунок — окремі етапи. Якщо DNS повернув очікувану адресу, але сторінка не відкривається, переходьте до перевірки наступного етапу з’єднання. Окремі записи результату розв’язання імені та вебвідповіді допомагають точніше локалізувати збій до безсистемного очищення кешу сторінки чи зміни DNS-налаштувань.