Если небольшой DNS-ответ приходит, а крупный зависает или заканчивается тайм-аутом, проверяйте не только записи зоны. Чаще всего нужно сравнить доставку по UDP и TCP 53, работу EDNS и прохождение фрагментов: один и тот же DNS-сервер может успешно отдавать короткий ответ и терять более объёмный.
Сначала повторите один и тот же запрос к одному серверу по UDP и TCP. Если TCP 53 недоступен или крупный UDP-пакет не проходит путь, обычная A-запись может отвечать, а DNSKEY, длинный TXT либо ответ с DNSSEC — нет.
Почему размер ответа меняет результат
Классический DNS использует UDP и TCP на порту 53. Без EDNS размер UDP-сообщения ограничен 512 байтами. Если ответ не помещается, сервер может вернуть усечённый ответ с флагом TC, после чего клиент должен повторить запрос по TCP.
EDNS позволяет клиенту объявить больший допустимый UDP-ответ, но не отменяет TCP. Крупный UDP-пакет может потребовать IP-фрагментации, а отдельные фрагменты иногда теряются или отбрасываются firewall, NAT и другим сетевым оборудованием. Поэтому правило «UDP 53 открыт — DNS работает» неполно.
Размер зависит не только от имени домена. Его увеличивают число записей, CNAME-цепочка, DNSSEC-подписи, DNSKEY и некоторые TXT-ответы. Из-за этого проверка одной короткой A-записи не подтверждает, что весь DNS-путь исправен.
Зафиксируйте условия проверки
Перед командами запишите четыре параметра:
- домен и тип запроса, на котором заметна проблема;
- адрес проверяемого DNS-сервера;
- сеть, из которой выполняется запрос;
- время проверки с часовым поясом.
Не смешивайте авторитетный сервер домена и рекурсивный резолвер провайдера: между ними разные участки сети. Сначала проверяйте каждый участок отдельно, иначе успешный ответ из кэша может скрыть неисправность.
Шаг 1. Сравните одинаковый запрос по UDP и TCP
В примерах замените ns1.example.net и example.ru своими значениями. dig по умолчанию начинает с UDP, а ключ +tcp явно выбирает TCP.
dig @ns1.example.net example.ru A +norecurse +comments +stats
dig @ns1.example.net example.ru DNSKEY +dnssec +norecurse +bufsize=1232 +ignore +comments +stats
dig @ns1.example.net example.ru DNSKEY +dnssec +norecurse +tcp +comments +statsКлюч +ignore нужен только для диагностики: он не даёт dig автоматически перейти с усечённого UDP-ответа на TCP. В выводе смотрите на флаг tc, размер сообщения, время ответа и тайм-аут, а не только на наличие строк в секции ANSWER.
Полезно повторить тест с тем типом записи, который реально не разрешается. Запрос ANY для этого не подходит: серверы вправе отвечать на него сокращённо, поэтому результат не воспроизводит проблему конкретной A, TXT, DNSKEY или другой записи.
Как читать сочетание результатов
| Малый UDP-ответ | Крупный UDP-ответ | Тот же запрос по TCP | Что проверять первым | |---|---|---|---| | проходит | не проходит | не проходит | доступность TCP 53 и фильтрацию крупного UDP | | проходит | не проходит | проходит | EDNS, MTU, фрагментацию и сетевые устройства на пути | | проходит | проходит | не проходит | TCP 53 всё равно неисправен; следующий крупный ответ может вызвать сбой | | не проходит | не проходит | не проходит | адрес сервера, маршрутизацию, ACL и сам DNS-сервис |
Это ориентир, а не автоматический диагноз. Например, разные ответы могут приходить от разных узлов anycast или от нескольких NS, поэтому проверяйте каждый авторитетный сервер отдельно.
Шаг 2. Проверьте TCP 53 по всей цепочке
Убедитесь, что DNS-служба действительно слушает TCP 53, а не только UDP. Затем последовательно проверьте правила на сервере, в облачной security group, сетевом ACL, NAT, балансировщике и внешнем firewall.
Для публичного авторитетного DNS запросы должны доходить до каждого NS по обоим транспортам. Для рекурсивного сервера доступ клиентам обычно ограничивают доверенными сетями, но его исходящие соединения к авторитетным серверам тоже не должны терять TCP 53.
Если TCP-соединение устанавливается, но DNS-ответа нет, одной проверки порта недостаточно. Смотрите журналы DNS-сервера, ограничения числа соединений, тайм-ауты балансировщика и совпадение конфигурации на всех узлах.
Шаг 3. Отделите EDNS от фильтрации фрагментов
Сравните один запрос с разным объявленным размером UDP-буфера:
dig @ns1.example.net example.ru DNSKEY +dnssec +norecurse +bufsize=512 +ignore
dig @ns1.example.net example.ru DNSKEY +dnssec +norecurse +bufsize=1232 +ignoreЕсли при 512 байтах виден tc, а больший UDP-ответ исчезает, исследуйте путь пакета и захват трафика с обеих сторон. Важно понять, отправил ли сервер ответ, дошли ли все фрагменты и возвращаются ли служебные ICMP-сообщения, необходимые для определения допустимого размера пакета.
Не превращайте bufsize=1232 в универсальную настройку только потому, что тест прошёл. Это диагностическое значение, а рабочий размер зависит от пути и конфигурации. Постоянное занижение EDNS-буфера без исправного TCP лишь чаще включает переход на транспорт, который уже заблокирован.
Шаг 4. Найдите неисправный участок
Проверьте отдельно направления «клиент → рекурсивный резолвер» и «рекурсивный резолвер → авторитетные NS». Если прямой запрос к NS проходит, а через нужный резолвер нет, ищите проблему в резолвере, форвардере или его исходящей сети.
Повторите проверку из другой сети и для каждого NS домена. Сбой одного узла часто выглядит плавающим: часть пользователей получает ответ, а часть попадает на сервер с другой firewall-политикой.
Браузер для такой диагностики недостаточен. Он может использовать кэш, системный резолвер, DNS over HTTPS или корпоративный прокси, поэтому не показывает, какой именно классический DNS-запрос прошёл по UDP или TCP 53.
Что исправлять, а что не маскировать
Исправление должно соответствовать найденной границе:
- включите обработку TCP-запросов в DNS-сервисе и откройте TCP 53 там, где он необходим;
- синхронизируйте UDP/TCP-правила на firewall и балансировщике;
- устраните потерю крупных UDP-пакетов и ошибочную фильтрацию фрагментов;
- проверьте одинаковую конфигурацию всех авторитетных серверов;
- оставьте рабочий переход на TCP для усечённых ответов.
Не начинайте с отключения DNSSEC, удаления нужных записей или увеличения клиентского тайм-аута. Эти действия могут скрыть симптом, но не восстанавливают корректную доставку DNS.
После исправления повторите тесты по UDP и TCP, затем проверьте разрешение через рабочий рекурсивный сервер и открытие сайта. Один успешный запрос подтверждает только текущую точку наблюдения; для регулярного контроля доступности можно добавить сайт в Web-Puls и отслеживать последствия DNS-сбоев для пользователей.
Если резолвер возвращает SERVFAIL, используйте отдельный порядок диагностики SERVFAIL. Для подписанной зоны также проверьте цепочку DNSSEC.
Когда передать диагностику специалисту
Если вы не можете определить, где пропадает TCP 53 или крупный UDP-ответ, отправьте заявку через форму профессиональной поддержки. Укажите публичный домен, время и часовой пояс, проверенные NS или резолверы и обезличенный вывод команд — без паролей, Cookie и приватных адресов.