Почему запись SRV помогает только тому клиенту, который сам её запрашивает

Добавление записи SRV в вашу зону не учит ни один клиент VPN искать её. Клиент должен знать метку, решить отправить запрос и действовать по тому, что вернётся, а DNS не может обеспечить первые два из этого. Поэтому большинство неудачных планов SRV — это проблемы клиента в костюме DNS. Сначала прочитайте поведение клиента при обнаружении, а затем публикуйте только ту метку, которую он действительно запрашивает.

Запись, которую никто не запрашивает, никому не поможет

SRV публикует местоположение службы; он её не объявляет. Ничто не толкает запись к клиенту, и ни один резолвер не предлагает имя, о котором никогда не спрашивали. Поиск начинается, когда приложение решает его выполнить, поэтому метка должна приходить из документации продукта или из наблюдения за программой в сети. Там, где у клиента нет шага обнаружения, запись меняет зону и больше ничего.

Поэтому один продукт в сети может начать работать, тогда как другой не затронут тем же изменением. Переменная — это программа, и DNS-сервер делает ровно то, что ему сказали. Перечитайте зону и после правки, потому что неверно набранная метка легко прячется среди записей, которые все выглядят одинаково.

Прочитайте поля, прежде чем их записывать

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

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

Найдите метку, которую клиент действительно отправляет

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Сравните ответ с опубликованной записью символ за символом, потому что подчёркивания и точка в конце — часть имени. Пустой ответ на запрос, который действительно был отправлен, указывает на зону, тогда как полное отсутствие запроса указывает на клиента, и эти выводы ведут вас к разным командам. Настоящий ответ выглядит как строка ниже, где приоритет 20 проигрывает любой записи с более низким приоритетом, а клиент набирает порт 8443 на указанной цели.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

Цель тоже должна существовать

Цель, которая разрешается, — не то же самое, что служба, которая отвечает. Проверьте записи адреса для цели, затем проверьте, что на опубликованном порту и протоколе что-то слушает. Запись TCP, указывающая на слушателя только UDP, — это несоответствие, которое не исправит никакая правка зоны. Держите TTL коротким, пока цель нестабильна, и удлините его, когда имя перестанет двигаться.

Клиенты, которые действительно реализуют обнаружение, различаются тем, насколько они соблюдают запись. Одни используют только приоритет, другие считают вес рекомендацией, а немногие игнорируют порт и предполагают значение по умолчанию. Эти различия место в ваших заметках рядом с меткой, потому что они объясняют поведение, которое иначе выглядит как сбой резолвера.

Обнаружение — это не аутентификация

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

Для клиента без поддержки обнаружения распространяйте профиль или URL шлюза, который он принимает, и записывайте, какой продукт использует какой метод. Эта заметка мешает следующему администратору добавить запись и ожидать, что она заработает везде. Спецификация SRV описывает выбор между целями, и чтение её как механизма авторизации — это путь, на котором полезная запись становится предположением о безопасности. Публикуйте осознанно, называйте метку в своей документации и относитесь к клиенту как к компоненту, который решает, имеет ли всё это значение.