Представим, что адрес сервера домена изменили: дома открывается новый сайт, а телефон всё ещё подключается к старому серверу. Даже при вводе одного имени результаты некоторое время могут различаться, если устройства обращались к разным кэшам 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-настроек.