DNS отвечает на короткие запросы, но ломается на больших: проверьте TCP 53

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

Сохраните первоначальный ответ

dig @192.0.2.53 example.org DNSKEY +dnssec +ignore +bufsize=512
dig @192.0.2.53 example.org DNSKEY +dnssec +tcp

Замените адрес своим резолвером. Для воспроизведения выберите согласованную зону с достаточно большим ответом. Параметр bufsize ограничивает объявленный размер UDP-ответа, а ignore позволяет увидеть усечённый ответ без автоматического повторения по TCP. Это диагностическое ограничение, не рекомендация постоянной настройки.

Ищите флаг TC. Он сообщает, что ответ усечён. Маленький ответ без TC при выбранном имени не опровергает проблему: в нём могло оказаться мало данных. Нужен пример, который действительно включает механизм перехода. Не сравнивайте результаты по разным зонам, если хотите связать их с одной поломкой.

Проверьте TCP отдельно

Второй вызов напрямую использует TCP. Если UDP возвращает TC, а TCP-подключение не проходит, появляется конкретный кандидат: фильтрация TCP 53, отсутствие слушателя либо проблема маршрута. На своём сервере сопоставьте TCP- и UDP-слушатели. На внешнем передайте оператору адрес клиента, имя и время проверки.

Представим, что первый ответ пришёл за несколько миллисекунд и содержит TC, а второй ждёт до таймаута. Сам DNS-сервер достижим по UDP, поэтому проверка только его IP мало что добавит. Следующий вопрос — принимает ли он TCP от этой сети. Если TCP отвечает SERVFAIL, транспорт уже работает и исследование переходит к выполнению самого запроса.

Успешный TCP-запрос через другой резолвер не доказывает исправность нужного пути. Проверяйте тот же адрес сервера. Также различайте два участка: клиент до рекурсивного сервера и рекурсивный сервер до авторитетного. Первый может работать, пока второй блокируется политикой сети.

Восстановите полный сценарий

Отключение DNSSEC иногда уменьшает ответ и скрывает симптом, но меняет смысл разрешения имён. Повышение UDP-размера без учёта MTU может перенести проблему в фрагментацию. Сначала убедитесь, что оба транспорта работают и сеть корректно обрабатывает согласованные размеры.

После исправления повторите три проверки: обычный короткий запрос, диагностический ответ с TC и получение полного ответа по TCP. Затем запустите исходное приложение. Так вы подтверждаете сценарий, который ломался, а не только доступность порта в отрыве от запроса.

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

Завершённый runbook объясняет назначение каждого вызова: первый показывает причину повторного запроса, второй — возможность получить полный результат. Следующий инженер сможет воспроизвести проверку и правильно прочитать различие.

Проверяйте сеть на уровне полезного результата. Откройте программу Linux и Bash для DevOps-инженеров. В ней есть диагностика DNS, портов и HTTP: подходящая база, чтобы отличать работающий транспорт от полностью работающей операции приложения.

Ещё по теме

• Проверяем новый сервер до переключения DNS: curl --resolve с настоящим именем
• DNS после изменения записи: сравниваем авторитетный сервер и резолвер