Чому запис 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 описує вибір між цілями, і читання її як механізму авторизації — це шлях, на якому корисний запис стає припущенням про безпеку. Публікуйте свідомо, називайте мітку у своїй документації й ставтеся до клієнта як до компонента, що вирішує, чи все це має значення.