Що таке 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-клієнт не може знайти сервер.