Як працює DNS-кеш?

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

Що визначає строк зберігання

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

Негативні відповіді теж можуть кешуватися: наприклад, резолвер нещодавно отримав NXDOMAIN для ще не створеного імені. Після створення запису користувачі певний час можуть бачити попередній негативний результат. Для цього діють правила RFC 2308.

Як знайти джерело старої відповіді

Перевірте запис на авторитетному сервері домену, потім у вибраного публічного резолвера й на власному пристрої. Якщо авторитетна відповідь стара, виправляти треба зону або делегування; очищення локального кешу марне. Якщо авторитетна відповідь нова, а локальна стара, порівняйте TTL і повторіть запит після його завершення. Перевірка DNS-параметрів допомагає побачити записи домену.

Запитуйте саме потрібний тип: кеш A не пояснює неправильний MX, а IPv6-запис AAAA може вести на інший сервер, ніж A. Перевірте повне ім’я, включно з піддоменом. Браузер може використовувати окремий резолвер через DoH, тому його результат іноді відрізняється від системної утиліти.

Коли очищати локальний кеш

Очищення локального кешу корисне після виправлення DNS, якщо лише ваш пристрій продовжує використовувати стару відповідь. Конкретна команда залежить від ОС і ввімкненого резолвера; спершу уточніть конфігурацію пристрою. Очищення кешу не змусить провайдера, публічний резолвер або пристрій іншого користувача забути свої відповіді.

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

Практичний приклад

Сайт переїхав із 192.0.2.10 на 192.0.2.20. Авторитетний сервер відповідає новою адресою, а домашній маршрутизатор віддає стару з кешу. Повторний запит до авторитетного сервера покаже новий запис; запит через домашню мережу — попередній і залишок TTL. Після завершення TTL відповіді мають збігтися, якщо немає іншої помилки конфігурації.

Адреси в прикладі призначені для документації, а не для реального сайту. У робочій ситуації фіксуйте дату зміни, старе й нове значення, TTL і відповіді конкретних серверів. Це корисніше, ніж чекати невизначеного «повного поширення» DNS.