Домен и DNS: куда приходит запрос

Артефакт release-lab подготовлен, но посетитель обращается к имени сайта, а не к каталогу с файлами. Между этими объектами находятся несколько независимых настроек. В этом уроке разберём, что сообщает DNS, что выбирает веб-сервер и почему правильный IP ещё не означает правильную страницу.

Используем учебное имя example.com. Условный старый хостинг имеет адрес 198.51.100.20, новый VPS — 203.0.113.10. Это специальные документационные адреса: команды ниже показывают метод работы, а не действующую инфраструктуру. Пока готовим план, не меняя записи настоящего домена. Перенос с проверкой нового сервера до изменения DNS подробно рассмотрим в заключительном уроке.

Имя, адрес и сайт — разные сущности

Регистратор управляет регистрацией домена, а авторитетные DNS-серверы публикуют записи его зоны. Эти услуги может предоставлять одна компания, но логически они различны. Переезд файлов на другой хостинг сам по себе не требует смены регистратора. Смена DNS-серверов, напротив, может затронуть всю зону, включая почту и подтверждения сторонних сервисов. Поэтому перед изменением полезно выписать не только запись сайта, но и назначение остальных записей.

Для браузера запись A даёт IPv4-адрес, AAAA — IPv6-адрес. CNAME связывает одно имя с другим именем, после чего поиск адреса продолжается. Она не задаёт перенаправление страницы: HTTP-ответ с новым URL формирует веб-сервер. Если www.example.com указывает на тот же адрес, но сервер не знает это имя, пользователь может увидеть чужой виртуальный сайт. Для окончательного результата нужны и корректная запись, и конфигурация обслуживания имени.

Учебный план зоны после переноса
example.com.          A       203.0.113.10
staging.example.com.  A       203.0.113.10
www.example.com.      CNAME   example.com.

Это сокращённый план, не готовая полная зона. Почтовые MX и TXT здесь намеренно не показаны; в реальном проекте их сохраняют отдельно. Также не добавляем AAAA просто ради наличия IPv6. Если адрес опубликован, сервер должен отвечать по этому протоколу с нужным виртуальным сайтом и TLS. Иначе часть посетителей получит другой результат, хотя проверка только по IPv4 выглядит успешной.

Что проверить до изменения

Для будущего стенда подготовим записи с их текущими значениями, желаемыми значениями и ответственным местом изменения. Например, строка A указывает на старый хостинг; новой станет запись на VPS. Привязка example.com к конкретному сайту в панели Beget остаётся отдельной строкой плана. У этого различия есть практический эффект: иногда достаточно привязать домен к другому каталогу внутри прежнего хостинга, и DNS вообще не меняется.

На Beget «сайт» описывает место на диске, к которому прикрепляют домены. После создания сайта появляется каталог с public_html; несколько имён могут ссылаться на одно размещение. Это объясняет, почему в панели нужно смотреть и доменную запись, и выбранный сайт. Документация Beget об управлении сайтами.

Запишем также поведение www. Если основным адресом выбран https://example.com, запрос к www можно направлять на основной домен с сохранением пути и параметров. DNS не выполнит эту работу вместо сервера. Сертификат должен покрывать имя, на которое посетитель установит HTTPS-соединение до получения перенаправления. Частая ошибка — настроить сертификат только для конечного имени и считать, что первое соединение не имеет значения.

TTL и наблюдение за ответами

TTL задаёт срок, в течение которого кеширующий резолвер может использовать полученную запись. Уменьшение TTL непосредственно в момент переключения не отменяет старые ответы, уже сохранённые с прежним сроком. Если планируется переезд, меньший TTL публикуют заранее и ждут, пока прежние кеши смогут истечь. Даже после этого нельзя обещать, что все клиенты одновременно увидят новый адрес: есть локальные кеши, особенности резолверов и уже установленные соединения.

Посмотрим на способ будущей проверки. Ключ +noall +answer показывает секцию ответа, где видны имя, тип, оставшийся срок и значение. Короткий вывод +short удобен, но скрывает часть контекста. Для разбора несовпадения лучше сохранить полный ответ и указать, какой сервер его дал. Возможности dig описаны в первичной документации BIND. Руководство dig.

dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com NS +noall +answer

Предположим, что в условном наблюдении A ещё содержит 198.51.100.20. Нельзя по одной строке заключить, что запись в панели не сохранилась. Возможно, ответ пришёл из кеша. Сравнивают авторитетный ответ и ответы резолверов, отмечая время и источник. Если же авторитетный сервер продолжает публиковать старый адрес, ожидание кеша проблему не исправит: нужно вернуться к месту управления зоной и проверить изменение.

Почему сайт может остаться неправильным

После DNS браузер устанавливает соединение с выбранным адресом. В HTTP он передаёт имя сайта, а при HTTPS имя участвует также в выборе сертификата через SNI. Nginx или хостинг сопоставляет это имя со своим виртуальным сайтом. Поэтому открытие голого IP не эквивалентно открытию домена: запрос может попасть в сервер по умолчанию. Для проверки целевого узла до DNS позднее воспользуемся способом, сохраняющим и имя, и TLS-проверку.

Есть и обратная ситуация: домен уже приходит на новый узел, но его корень указывает на пустой каталог. Тогда DNS выполнил свою задачу, а публикация ещё не закончена. В журнале изменения следует отдельно отметить адрес сервера, имя виртуального сайта и выбранный выпуск. Такое описание не даёт свести любую неисправность к расплывчатому «домен не обновился» и помогает выбрать следующий шаг.

Если используется CDN, DNS может указывать на его узлы, а CDN обращаться к своему origin. Тогда проверка публичной A-записи ничего не сообщает напрямую о корне origin. Нужно учитывать ещё один слой маршрута. В нашем начальном стенде CDN отсутствует; добавим его в двадцать втором уроке. Держать первоначальную схему простой полезно: сначала должны стать понятны два основных звена, имя и обслуживающий сайт.

Результат урока — не изменённая зона, а проверяемая схема: кто публикует DNS, какие имена существуют, какие адреса ожидаются и где имя привязано к файловому корню. С этой схемой можно подготовить HTTPS и не перепутать проблему сертификата с проблемой адреса или каталога.