Что такое SRV-запись и зачем она нужна
Обычная A-запись отдаёт только IP-адрес. Она ничего не знает о портах и не умеет распределять нагрузку между несколькими серверами одной службы. SRV-запись (Service record, RFC 2782) закрывает эту задачу: она хранит вместе адрес сервера, порт и параметры приоритета для конкретного сервиса — SIP-телефонии, XMPP-чата, LDAP-каталога или федерации Matrix.
Благодаря SRV клиентское приложение не требует от пользователя вручную вводить порт и хост сервера: достаточно домена, а само приложение запрашивает SRV-запись и получает всё нужное для подключения.
Синтаксис SRV-записи: приоритет, вес, порт, цель
Имя записи всегда строится по шаблону _служба._протокол.домен, а значение состоит из четырёх полей:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 0 5060 sip2.example.com.
_matrix._tcp.example.com. 3600 IN SRV 10 0 8448 matrix.example.com.Приоритет (первое число) — чем ниже, тем важнее сервер: клиент сначала пробует записи с меньшим значением. Вес (второе число) распределяет нагрузку между записями одного приоритета пропорционально своему значению. Третье поле — порт службы, четвёртое — полное имя целевого сервера, которое обязано резолвиться в A или AAAA запись, а не в CNAME.
SRV для SIP-телефонии: пример настройки
Для подключения IP-АТС или софтфона по SIP достаточно указать домен без адреса и порта сервера — клиент найдёт их сам через записи _sip._tcp и _sip._udp. Такая схема удобна, если провайдер SIP-транка меняет серверы: обновляется только зона, а настройки на телефонах остаются прежними.
Основы работы других типов записей, которые обычно соседствуют с SRV в одной зоне, разобраны в статье про A, CNAME, MX, TXT и NS-записи.
SRV для Matrix-сервера: федерация без нестандартного порта
Федерация Matrix по умолчанию ожидает порт 8448. Запись _matrix._tcp.example.com позволяет держать сервер на любом другом порте, спрятанном за обратным прокси. Начиная с версии протокола Matrix 1.x рекомендуемый способ делегирования — файл .well-known/matrix/server на основном домене, а SRV-запись остаётся резервным механизмом для серверов, которые ещё не проверяют well-known.
Для защиты порта федерации TLS-сертификатом стоит также настроить привязку сертификата к DNS-зоне — подробности в статье про TLSA и DANE.
Как проверить SRV-запись через dig
Запрос конкретной SRV-записи выполняется так:
dig SRV _matrix._tcp.example.com +short
dig SRV _sip._tcp.example.com +shortВывод должен показать приоритет, вес, порт и целевое имя. Если ответа нет — либо запись не опубликована, либо она находится в другой зоне после делегирования поддомена, что стоит перепроверить способами из статьи про проверку DNS-зоны через dig.
Типичные ошибки при настройке SRV
- Цель SRV указывает на CNAME вместо A или AAAA — по RFC 2782 это некорректно, часть клиентов такую запись просто отклонит.
- Забыли точку в конце имени домена в поле target внутри зонного файла — это меняет смысл записи.
- Порт в SRV не совпадает с портом, реально открытым в файрволе.
- TTL записи слишком высокий, из-за чего смена сервера SIP-транка растягивается на часы — низкий TTL стоит выставить заранее, подробнее в статье про настройку TTL.
Итог: чек-лист для SRV-записей
Перед публикацией SRV-записи проверьте: имя строится как _служба._протокол.домен, целевой хост резолвится в A/AAAA, порт совпадает с открытым портом службы, приоритет и вес расставлены осознанно, а сама запись видна через dig с внешнего резолвера. Такой набор проверок избавляет от долгих разборов, почему софтфон или Matrix-клиент не может найти сервер.