SRV-запись (Service Record) — это тип DNS Lookup из RFC 2782, который указывает клиентам, на каком хосте и проверку портов работает конкретный сетевой сервис. Формат _service._proto.name TTL IN SRV priority weight port target позволяет автоматически находить серверы SIP-телефонии, XMPP, LDAP и других протоколов без жёсткого прописывания адреса в настройках.
Материал разбирает синтаксис SRV по полям, объясняет логику priority и weight, показывает реальные примеры для SIP, XMPP, Autodiscover и Minecraft, а также перечисляет типовые ошибки — от отсутствия завершающей точки в target до неверного формата имени сервиса. В конце — как проверить SRV-запись через dig и онлайн.
Что такое SRV-запись и зачем она нужна
Обычная A- или AAAA-запись связывает имя домена с IP геолокацию, но ничего не сообщает о порте и приоритете сервиса. SRV-запись решает эту задачу: клиент запрашивает специальное имя вида _service._proto.domain и получает список серверов с указанием порта, приоритета и веса. Это позволяет строить отказоустойчивые и балансируемые схемы без внешнего балансировщика.
Стандарт описан в RFC 2782. Именно SRV-записи лежат в основе автоматической настройки почтовых клиентов (Autodiscover), федерации XMPP, обнаружения контроллеров домена в Active Directory (LDAP/Kerberos) и подключения к SIP-провайдерам.
Главное преимущество SRV — гибкость: администратор может перенести сервис на другой хост или порт, поменяв одну DNS-запись, и все клиенты подхватят изменение автоматически. Не нужно рассылать новые настройки пользователям или трогать конфигурацию приложений. Это особенно ценно в корпоративной среде с сотнями рабочих станций, где ручная перенастройка каждого клиента непрактична.
Синтаксис SRV: разбор по полям
Полная строка SRV-записи в зоне выглядит так:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.Здесь _sip — символьное имя сервиса, _tcp — транспортный протокол, example.com — домен, 3600 — TTL, IN — класс, SRV — тип. Далее идут четыре ключевых поля данных, которые и определяют поведение клиента.
Поля значения SRV-записи
| Поле | Назначение | Пример |
|---|---|---|
| priority | Приоритет сервера: меньшее число обрабатывается первым | 10 |
| weight | Вес для балансировки нагрузки среди серверов с одинаковым priority | 60 |
| port | TCP/UDP-порт, на котором слушает сервис | 5060 |
| target | Полное доменное имя (FQDN) хоста с завершающей точкой | sipserver.example.com. |
Как формируется имя сервиса
Имя строится по шаблону _service._proto.name. Символ подчёркивания перед именем сервиса и протокола обязателен — он отделяет служебные метки от обычных поддоменов и предотвращает коллизии. Протокол почти всегда _tcp или _udp. Например, для XMPP-сервера клиент-к-серверу используется _xmpp-client._tcp.example.com.
Как работают priority и weight
Поля priority и weight управляют выбором сервера и распределением нагрузки. Логика двухуровневая: сначала клиент смотрит на priority, затем на weight.
Приоритет (priority)
Клиент всегда сначала обращается к записям с наименьшим значением priority. Записи с большим priority используются только если все серверы предыдущего уровня недоступны. Это готовый механизм failover: основной сервер получает priority 10, резервный — priority 20. Значение priority — целое число от 0 до 65535, и меньшее всегда важнее. Многие ошибочно считают наоборот, поэтому запомните аналогию с MX-записями: чем меньше число, тем выше приоритет.
Вес (weight)
Среди записей с одинаковым priority клиент распределяет запросы пропорционально weight. Если два сервера имеют weight 70 и 30, они получат примерно 70% и 30% трафика. Значение weight 0 означает, что сервер выбирается в последнюю очередь, когда есть другие ненулевые веса. Диапазон weight — от 0 до 65535. Если у всех серверов одного приоритета weight равен, нагрузка делится поровну — это простой способ равномерной балансировки без тонкой настройки долей.
Правило запоминания: priority определяет очерёдность (кто первый), weight определяет долю (сколько трафика) внутри одного приоритета.
Где применяются SRV-записи
SRV используют протоколы, которым нужно автоматическое обнаружение сервера. Ниже — самые распространённые сценарии.
- SIP-телефония:
_sip._tcp,_sips._tcp— подключение софтфонов и IP-АТС к провайдеру. - XMPP (Jabber):
_xmpp-client._tcpи_xmpp-server._tcp— федерация мессенджеров. - Autodiscover:
_autodiscover._tcp— автонастройка Outlook и других почтовых клиентов. - Active Directory:
_ldap._tcp,_kerberos._tcp— поиск контроллеров домена. - Minecraft:
_minecraft._tcp— подключение к серверу на нестандартном порту без указания порта в клиенте.
Важно: запись _dmarc к SRV не относится — это обычная TXT-запись политики DMARC, несмотря на схожий вид имени с подчёркиванием. Не путайте служебные TXT-метки (SPF, DKIM, DMARC) с SRV.
Примеры SRV-записей
Autodiscover для почты Exchange:
_autodiscover._tcp.example.com. 3600 IN SRV 0 0 443 mail.example.com.Два SIP-сервера с failover и балансировкой:
_sip._tcp.example.com. 3600 IN SRV 10 70 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 30 5060 sip2.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 0 5060 sip-backup.example.com.Здесь sip1 и sip2 делят трафик 70/30 на приоритете 10, а sip-backup включается только при отказе обоих основных.
Как проверить SRV-запись
Самый быстрый способ в терминале — утилита dig:
dig SRV _sip._tcp.example.com +shortВ ответе вы увидите четыре поля через пробел: priority, weight, port и target. Для Windows аналог — nslookup -type=SRV _sip._tcp.example.com. Проверить запись в браузере без установки утилит можно через DNS-проверку enterno.io — выберите тип SRV и введите полное имя сервиса.
Если dig возвращает пустой результат, проверьте три вещи: правильность имени с подчёркиваниями, факт публикации записи у DNS-провайдера и то, что вы не попали в кэш старого значения. Для обхода кэша можно явно указать резолвер: dig SRV _sip._tcp.example.com @8.8.8.8 +short. Так вы получите свежий ответ напрямую от публичного DNS Google, минуя локальный кэширующий сервер.
Частые ошибки в SRV-записях
Отсутствие точки в target
Поле target должно быть полным FQDN с завершающей точкой: sipserver.example.com. Без точки многие DNS-серверы дописывают имя зоны и получают sipserver.example.com.example.com, из-за чего сервис не находится.
Неверный формат имени сервиса
Подчёркивание перед service и proto обязательно. Запись sip.tcp.example.com вместо _sip._tcp.example.com просто не будет распознана как SRV. Также следите за правильным протоколом — SIP по TCP и по UDP это разные записи.
Использование IP вместо имени в target
По RFC target обязан быть доменным именем, а не IP-адресом. Указание IP нарушает стандарт и часто игнорируется клиентами. Создайте A/AAAA-запись для хоста и ссылайтесь на неё.
Weight у единственной записи
Если сервер один, weight не важен, но многие ошибочно ставят разные приоритеты для одного и того же хоста, ломая логику failover. Для единственного сервера обычно ставят priority 0 и weight 0.
SRV в контексте других DNS-записей
SRV работает не в изоляции. Разберитесь, как устроены остальные типы записей: обзор в статье типы DNS-записей, роли серверов в типах DNS-серверов, а настройка почты — в материале про MX-записи и настройку почты. Полезная документация по формату — MDN DNS Glossary.
Частые вопросы
Чем SRV отличается от MX-записи?
MX-запись обслуживает только почту и не содержит порт — он всегда 25. SRV универсальна: она описывает любой сервис, содержит порт, приоритет и вес. По сути SRV — это обобщение идеи MX на произвольные протоколы, поэтому в ней явно указывается и порт, и хост назначения.
Обязательна ли завершающая точка в target?
Да, для корректной работы target должен быть полным FQDN с точкой на конце. Без неё DNS-сервер трактует значение как относительное имя и дописывает имя текущей зоны, что почти всегда приводит к неправильному хосту и недоступности сервиса.
Может ли быть несколько SRV-записей для одного сервиса?
Да, и это нормальная практика. Несколько записей с разными priority дают failover, а записи с одинаковым priority и разным weight обеспечивают балансировку нагрузки. Клиент сам выбирает сервер по описанным в RFC 2782 правилам приоритета и веса.
Как быстро обновляется SRV-запись?
Скорость обновления зависит от значения TTL записи. Если TTL равен 3600, кэширующие резолверы будут хранить старое значение до часа. Перед плановой миграцией снизьте TTL заранее, чтобы изменения распространились быстрее, а после — верните обратно.
Поддерживают ли SRV-записи все сервисы?
Нет, сервис должен уметь искать SRV. Протоколы SIP, XMPP, LDAP, Autodiscover и Minecraft делают это по умолчанию. HTTP/SSL/TLS проверку исторически SRV не использует — для веба обычно применяют A/AAAA и CNAME запись, хотя существуют новые записи SVCB и HTTPS с похожей идеей.