Мы создали туннель для партнерской фирмы. Часть их политики безопасности настаивает на том, что наши DNS-запросы являются только TCP (UDP не будет маршрутизироваться).
Мы можем использовать dig +tcp
и убедитесь, что запросы разрешаются правильно, но наши собственные DNS-серверы, интегрированные в AD (Server 2008), используют UDP для переадресованного запроса, который по тайм-ауту и повторно отправляется в SERVFAIL обратно исходному клиенту.
Настройки для серверов условной пересылки не предусматривают выбор протокола:
RFC 1123 говорит
преобразователь DNS или сервер, который отправляет запрос без передачи зоны, ДОЛЖЕН сначала отправить запрос UDP.
... но это было заменено в 5966 году на
Резолвер ДОЛЖЕН сначала отправить запрос UDP, но МОЖЕТ выбрать отправку запроса TCP вместо этого, если у него есть веские основания ожидать, что ответ будет усечен, если он был отправлен через UDP.
Это не сулит ничего хорошего, если я использую Server 2008 (последний RFC был с 2010 года). Кто-нибудь знает, как я могу заставить мой сервер пересылки использовать только TCP (или, по крайней мере, сначала)? Возможно ли это в каких-либо других реализациях DNS, если мне придется настроить его в качестве посредника?
Невозможно отключить UDP в Microsoft DNS Server (отметьте dnscmd документация).
Это ограничение на UDP-пакеты кажется необоснованным и уверенным, что их брандмауэр достаточно гибкий, чтобы принимать исключение, что вашим серверам разрешено отправлять запросы через UDP-порт 53.
Всякий раз, когда RFC говорит «ДОЛЖЕН», вам лучше следовать тому, что он говорит, чтобы избежать неопределенного / непредсказуемого поведения. Правильный способ - использовать только TCP после получен UDP с усеченным ответом.
RFC 1035 (относительно предпочтительного метода):
UDP неприемлем для передачи зон, но рекомендуется для стандартных запросов в Интернете.
RFC 2181 (относительно усеченных ответов UDP):
Если установлен TC, в ответе можно оставить частичный RRSet, который не подходит полностью. Когда DNS-клиент получает ответ с установленным TC, он должен проигнорировать этот ответ и запросить еще раз, используя механизм, такой как TCP-соединение, которое разрешит более крупные ответы.
У них должна быть очень веская причина не разрешать UDP 53 (что крайне маловероятно).