Я установил DNS-сервер на SLES10 (в настоящее время привязка 9.6) на многосетевом сервере. Этот сервер может быть запрошен из всех внутренних сетей и доставляет ответы для всех внутренних сетей. У нас есть две отдельные «главные» зоны DNS. Каждая из этих зон обслуживается несколькими авторитетными DNS-серверами Windows.
Теперь мой linux-сервер является вторичным DNS-сервером для одной из этих зон (частная внутренняя зона) и действует как сервер пересылки для другой зоны (общедоступная внутренняя зона).
До недавнего времени эта установка работала без проблем. Теперь я получаю - при запросе общедоступной внутренней зоны (например, host команда на клиенте linux) сообщение об ошибке
;; Усечено, повторная попытка в режиме TCP
дамп wirehark выявил причину этого: первый запрос выходит в режиме UDP, ответ не помещается в UDP (из-за длинного списка авторитетных NS), затем он повторяется в режиме TCP, доставляя правильный ответ.
Теперь вопрос: Могу ли я настроить привязку для запроса серверов пересылки в режиме TCP без предварительной попытки UDP?
Обновление: Пробую свои силы в ASCII-арте ...
+--------------+ +--------------+ +-----------------+
| W2K8R2 DNS | | SLES 10 DNS | | W2K8R2 DNS |
| Zone private +---+ All internal +---+ Zone public |
| internal 2x | | Zones | | internal 30+ x |
+--------------+ +-+----------+-+ +-----------------+
| |
+--+---+ +--+---+
|Client| |Client|
+------+ +------+
Во-первых, я бы не назвал это ошибкой, это просто информационное сообщение.
Во-вторых, DNS-серверы всегда будут отвечать на запросы UDP (по крайней мере, BIND, я не могу найти параметры для отключения UDP), а клиенты всегда (?) Будут пытаться сначала отправить запрос UDP (например, в resolv.conf нет параметров, чтобы изменить это ни в JVM) - если они помещаются в пакет UDP (обычно это делают запросы)
Если у вас есть конкретный вариант использования, вы можете указать использование TCP, например в сценарии оболочки используйте 'dig + tcp' или 'host -T' для разрешения, и вы можете использовать системные вызовы 'sethostent / gethostbyname / endhostent' (см. справочную страницу) для принудительного использования TCP в других случаях.
Если вы действительно хотите попытаться заблокировать UDP, единственный вариант, который я вижу, - это правило iptable, но я не уверен, что эта настройка сработает. Я ожидаю, что разрешение DNS просто не удастся.
Ваш сервер BIND должен использовать EDNS (см. RFC 2671), чтобы разрешить UDP-пакеты длиннее 512 байт.
options {
edns-udp-size 4096;
max-udp-size 4096;
};
Это должно позволить получить ваш большой набор NS через UDP, не требуя накладных расходов TCP-соединения для других небольших запросов.
Однако обратите внимание, что это фактически значения по умолчанию. Если EDNS не используется, либо что-то блокирует его, либо серверы, получающие параметры EDNS, не поддерживают его.
Также обратите внимание, что host не поддерживает EDNS. Вполне возможно, что ваш сервер пересылки -> запросы к серверу уже используют EDNS, и вы просто не можете его увидеть, когда пытаетесь использовать локальный клиент.
Пытаться dig +bufsize=4096 @server hostname A Вместо того, чтобы использовать host.