DNS записи SRV

Имя SRV-записи состоит из четырех логических частей: имени службы, протокола, домена и зоны DNS. Первые две части начинаются с символа подчеркивания. Например, запись для службы SIP по TCP в домене company.ru может иметь имя _sip._tcp.company.ru.

Значение записи содержит четыре обязательных параметра: приоритет, вес, порт и целевое имя хоста. Типичная конструкция выглядит так: 10 20 5060 sip01.company.ru. Число 10 задает приоритет, 20 определяет вес при равном приоритете, 5060 указывает порт, а последнее значение задает сервер, к которому должен подключиться клиент.

Целевой хост не должен быть IP-адресом. Для него необходимо создать отдельную A-запись или AAAA-запись. После получения SRV-записи клиент разрешает имя целевого сервера в адрес и только затем устанавливает соединение. Точка в конце полного доменного имени важна в интерфейсах, где запись может быть автоматически дополнена именем текущей зоны.

Приоритет определяет порядок выбора серверов. Чем меньше число, тем выше приоритет. Если для одной службы опубликовано несколько SRV-записей, клиент в первую очередь пытается подключиться к серверам с минимальным значением приоритета. Более высокие значения обычно используют для резервных узлов.

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

Например, два основных сервера могут иметь приоритет 10 и веса 70 и 30. В таком случае большая часть новых подключений будет направляться на первый узел. Резервный сервер можно задать с приоритетом 20 и любым подходящим весом: к нему перейдут только при недоступности серверов с приоритетом 10. Не все приложения одинаково корректно учитывают вес, поэтому для критичных систем следует проверять поведение конкретного клиента.

Один из распространенных сценариев использования связан с корпоративной телефонией и SIP. Клиентские приложения могут найти сервер сигнализации через записи вида _sip._tcp, _sip._tls или _sips._tcp. Это позволяет перенести сервис на другой хост или изменить порт без массового обновления настроек пользователей.

SRV-записи применяются в инфраструктуре Microsoft Active Directory для поиска контроллеров домена, служб Kerberos, LDAP и глобального каталога. В таких средах DNS является частью механизма обнаружения сервисов, поэтому удаление или неверное изменение записей может нарушить вход пользователей в домен и работу рабочих станций.

Еще один пример — XMPP, игровые платформы, средства совместной работы и внутренние микросервисы. SRV удобна, когда клиент должен самостоятельно обнаруживать точку подключения. Обычные сайты и браузерные приложения редко используют такие записи напрямую: для веб-сайтов основными остаются A, AAAA, CNAME и MX в зависимости от задачи.

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

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

Убедитесь, что для хоста назначения существуют корректные A- или AAAA-записи. Если сервер расположен в другом домене, можно указать его полное имя при условии, что оно разрешается через DNS. После сохранения изменения становятся доступны не мгновенно: срок зависит от TTL, кеширования у рекурсивных резолверов и особенностей приложения.

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

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

Наиболее частая ошибка — неверное имя записи. Подчеркивания, название протокола и доменная зона должны соответствовать формату, который запрашивает клиент. Также часто путают порт SRV-записи с портом панели управления или веб-интерфейса сервиса. В результате DNS отвечает корректно с формальной точки зрения, но приложение подключается не к той службе.

Проблемы возникают и при неправильной расстановке приоритетов: если резервный узел получил меньшее значение, он станет основным. Еще одна причина сбоев — целевой сервер без A- или AAAA-записи, внутреннее имя, недоступное внешним клиентам, либо устаревший кеш после изменения зоны. При миграции сервиса полезно временно уменьшить TTL заранее, изменить записи, проверить работу и только затем вернуть обычное значение TTL.