DNS простыми словами: записи, dig и диагностика ошибок

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

DNS — распределённая система имён. Она хранит не только соответствия доменов IP-адресам, но и сведения о почтовых серверах, делегировании и других свойствах домена. В статье разберём путь запроса, научимся читать ответы dig и составим порядок проверки. Все запросы ниже диагностические: они не редактируют зону. Имена example.com используются для обучения; реальные ответы могут меняться.

Что происходит, когда браузер открывает сайт

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

Иерархию удобно представить как справочную службу. Корневые серверы указывают направление к зоне верхнего уровня, например com; серверы этой зоны сообщают делегирование example.com; авторитетный сервер example.com выдаёт записи, за которые отвечает. Резолвер возвращает результат клиенту и может сохранить его на ограниченное время. Это не означает, что каждый запрос обязательно проходит всю цепочку: кеширование значительно сокращает обращения.

Авторитетный сервер и рекурсивный резолвер выполняют разные задачи. Первый публикует содержимое своей зоны. Второй ищет ответы для клиентов. Панель регистратора, DNS-хостинг и веб-хостинг также могут быть тремя разными сервисами. Изменение IP в панели, которая больше не обслуживает делегированные NS, не повлияет на ответы посетителям.

Какие DNS-записи нужны на практике

• A связывает имя с IPv4-адресом; AAAA — с IPv6-адресом. Рабочая A не компенсирует ошибочную AAAA: часть клиентов сначала попробует IPv6.
• CNAME задаёт псевдоним другого имени, а не HTTP-перенаправление. В том же имени обычные пользовательские записи других типов с CNAME не совмещают. Поэтому стандартный CNAME в вершине зоны конфликтует с обязательными SOA и NS. ALIAS и flattening у провайдеров — отдельные механизмы, а не универсальное свойство DNS.
• MX указывает имя почтового сервера и приоритет: меньшее число предпочтительнее. В значении нужен домен сервера, не строка с IP. Само имя MX должно разрешаться в адрес.
• TXT хранит текстовые данные. Здесь часто размещают SPF, DKIM и подтверждение владения. Не добавляйте вторую независимую SPF-политику для одного имени вместо корректировки существующей.
• NS определяет серверы имён зоны; SOA содержит служебные параметры, включая серийный номер и данные, используемые при отрицательном кешировании.
• PTR используется для обратного поиска адреса. Обычно обратной зоной публичного IP управляет его провайдер, а не владелец произвольного домена.
• CAA ограничивает, какие удостоверяющие центры вправе выпускать сертификаты для домена. Ошибка здесь может помешать выпуску HTTPS-сертификата.

Первый запрос dig: что читать в ответе

На Debian и Ubuntu утилита обычно входит в пакет dnsutils. Установка пакета нужна только при отсутствии команды. Для первой проверки используйте полный вывод, а не сразу короткую форму:

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com NS
dig example.com SOA

Сначала смотрите status, затем секцию ANSWER и строку SERVER. Последняя показывает, кто ответил на этот конкретный запрос; это может быть локальный stub-резолвер. Значение TTL перед классом IN — оставшееся время кеширования записи в секундах. Флаг aa указывает на авторитетный ответ, но его отсутствие при обычном запросе к резолверу нормально.

NOERROR без A-записи не обязательно означает поломку: имя может существовать и иметь только другие типы данных. NXDOMAIN означает, что запрошенного имени не существует. SERVFAIL означает, что сервер не смог завершить обработку: среди причин недоступность вышестоящих серверов, ошибки делегирования и проверки DNSSEC. Тайм-аут вообще не является DNS-кодом ответа — ответ не получен.

Как сравнить кеш и первоисточник

Подставьте разрешённый вашей организацией резолвер вместо условного адреса 192.168.50.53. Во второй команде замените ns1.example.com настоящим авторитетным сервером из делегирования домена. Запрос к неверному серверу не проверит вашу зону.

dig @192.168.50.53 example.com A
dig @ns1.example.com example.com A +norecurse
dig example.com A +trace
dig example.com A +tcp
dig -x 192.0.2.10

Если авторитетный сервер уже возвращает новый адрес, а резолвер ещё старый, проверьте TTL и кеш. Если разные авторитетные серверы отвечают по-разному, ищите проблему синхронизации зоны или неверный набор NS. +trace помогает исследовать делегирование, но в сети с запретом прямых внешних DNS-запросов может не работать. Это ограничение среды, а не доказательство неисправности домена.

Обычный DNS использует UDP и TCP на порту 53. Проверка +tcp полезна, когда маленькие ответы проходят, а большие обрезаются и повтор по TCP блокируется. Не открывайте ради диагностики рекурсию всему интернету: это создаёт риск злоупотребления сервером.

Почему TTL не равен «времени обновления всего интернета»

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

Практический порядок переноса сайта: подготовить новый сервер и сертификат, проверить его с нужным именем, сохранить старые значения DNS, изменить A и при необходимости AAAA, сравнить ответы всех авторитетных серверов, затем проверить несколько резолверов и реальные HTTP-запросы. Старый сервер разумно оставить доступным на переходный период. Для динамического сайта отдельно планируют синхронизацию данных: DNS не предотвращает запись заказов в две разные базы.

DNSSEC, DoH и внутренние имена

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

При переносе DNS-хостинга учитывайте DS-запись у родительской зоны и ключи нового провайдера. Несогласованная цепочка может привести к SERVFAIL на проверяющих резолверах, хотя прямой запрос к авторитетному серверу покажет адрес. Не отключайте защиту вслепую: сначала сопоставьте делегирование, DS и DNSKEY с документацией провайдера.

Корпоративный VPN может направлять запросы внутренних зон на отдельный DNS. Браузер с собственным публичным DoH способен обойти этот маршрут и не найти внутреннее имя. Сравните браузер с resolvectl query и настройками VPN. Не публикуйте внутренние имена и адреса в сторонних диагностических сервисах без разрешения.

Мини-практика с объяснением результата

Ситуация 1: по имени сайт недоступен только на IPv6-подключении. Проверьте AAAA, доступность указанного IPv6 и прослушивание HTTPS сервером. Удалять IPv6 на всех клиентах — не исправление ошибочной записи.

Ситуация 2: новый поддомен создан, но один резолвер отвечает NXDOMAIN. Сравните авторитетный ответ и срок отрицательного кеша. Повторное создание уже правильной записи обычно не ускоряет истечение старого отрицательного ответа.

Ситуация 3: DNS возвращает ожидаемый IP, но браузер сообщает ошибку сертификата. Переходите к TLS, виртуальному хосту и имени сертификата. Полученный IP подтверждает только этап разрешения имени, а не здоровье веб-приложения.

Частые вопросы

Можно ли указать порт сайта в A-записи?

Нет. A хранит IPv4-адрес. Порт задаётся протоколом и URL; отдельные механизмы обнаружения сервисов не превращают A в запись с портом.

Почему ping не доказывает, что сайт работает?

Он проверяет другой вид обмена. ICMP может быть запрещён при работающем HTTPS, а успешный ping ничего не говорит о сертификате и ответе приложения.

Нужно ли очищать кеш всем посетителям?

Для нормального планового изменения — нет. Управляйте TTL заранее и сохраняйте совместимость в переходный период. Локальная очистка полезна для собственной проверки, но не управляет чужими резолверами.

Продолжить обучение: IP-адрес, маска и шлюз и выдача DNS и адресов через DHCP.

Документация

• RFC 1034: архитектура DNS.
• RFC 2308: отрицательное кеширование.
• BIND: справочник dig.
• RFC 4033: введение в DNSSEC.

Статья может содержать партнёрские ссылки. Это не влияет на стоимость для вас, но помогает развивать блог.