DNS записи, типа SRV

Запись SRV, заданная на сервере доменных имен (DNS), помогает соединиться с SIP пользователем, так же как MX запись помогает доставить электронную почту на сервер адресата. Когда вы отправляете почту на адрес "john@example.com", тогда MX запись для домена example.com может указать агенту, отвечающему за доставку почты, совсем другую машину, которая является почтовым сервером для этого домена, например, "zaphod.foobar.com". Подобным образом, когда вы хотите совершить вызов на SIP телефон: john в example.com, запись типа SRV, может сказать Вашему компьютеру, что для этого следует подключиться к хосту "galaxy.starsystem.tw".

Зачем может понадобиться использование DNS SRV записей для SIP протокола?
Совершение вызовов с использованием имен доменов дает возможность SIP пользователю иметь один публичный Интернет адрес "SIP адрес", поступающие туда вызовы будут перенаправлены конечному пользователю, на его фактический адрес. SRV записи позволяют в некоторой степени защитить систему, при этом так же давая возможность использовать Ваше собственное доменное имя, вне зависимости от имени домена Вашего SIP провайдера.

Записи SRV в DNS указывают, как найти сервисы для различных протоколов.

Выдержка из RFC:



Для SIP прокси серверов, обслуживающих домен, это означает что:

• Вы можете определить SRV запись для своего домена, чтобы SIP прокси других доменов знали, как Вас найти. Как и в случае с e-mail, где один почтовый сервер обрабатывает почту для многих доменов, SIP прокси сервер может обрабатывать вызовы клиентов в нескольких доменах. Значение, заданное для DNS SRV записи в Вашем файле с описанием DNS зоны (voip-info.org), может указывать на какой-нибудь другой адрес SIP прокси сервера (например, sip.iptel.org). При такой конфигурации, вызовы на адрес: user в voip-info.org, будут автоматически отправлены на SIP прокси сервер: sip.iptel.org.
• В Вашей DNS зоне, Вы можете указать несколько серверов SIP прокси. Если сервер с наивысшим приоритетом недоступен, тогда SIP клиенты (ua) или другие прокси, которые пытаются найти путь к абоненту в заданном домене, будут пытаться отправить вызов на прокси сервер, который определен в записи SRV с меньшим приоритетом.

Пример

Для использования SRV записей, Вам может понадобиться следующая информация:

a. Тип сервиса (IETF Service Type) (Вы можете найти более менее полный список этих значений тут. Оригинальное RFC #2782: тут), в формате _servicetype._layer4.
b. Приоритеты для Ваших систем.
c. Нагрузку 'weight', которую могут обработать системы. (не обязательно)
d. Номера портов, которые используются в Ваших системах.
e. Имена хостов, где располагаются Ваши системы.

Все эта информация должна располагаться в Вашем файле описания зоны в следующем порядке:

a (TTL) SRV b (c) d e.

Например, Если Вы хотите указать, что SIP сервер Вашего домена находиться по адресу host.tld, то запись может быть такой:

_sip._udp SRV 0 5060 host.tld.

Как описано выше, _sip._udp - это тип сервиса IETF для SIP протокола через транспорт UDP. SRV - это тип записи в DNS, 0 - это приоритет записи, значения нагрузки мы не указали тут, а 5060 - это номер порта, по которому SIP сервер принимает запросы. host.tld = это имя хоста.

Вы можете тоже самое сделать и для протокола iax, например, так:

_iax._udp SRV 0 4569 host.tld.


И конечно, Вам нужна соответствующая запись для хоста host.tld типа "A" или "CNAME", для того, чтобы можно было определить его IP адрес, например, такая:

host.tld A xxx.xxx.xxx.xxx

По этой ссылке Вы можете найти исчерпывающую документацию, с очень подробно описанными примерами на сайте компании Cisco:

http://www.cisco.com/univercd/cc/td/doc/product/voice/sipproxy/admingd/ver2_1/ddns.htm

Пример, с использованием фиктивного домена

Ниже приведен простой файл с описанием зоны из RFC. Обратите внимание, что тип сервиса для SRV записей указанный тут, *не* для протокола SIP, вследствие этого, у Вас он будет другой:


В данном примере используется фиктивный сервис "foobar", работающий на порту 9,
для помощи в понимании механизма использования SRV записей.

$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
; для сервиса foobar - использовать old-slow-box или new-fast-box.
; Если кто то из них доступен, указываем, что три четверти всех запросов
; должны обрабатываться сервером new-fast-box.
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
; Если не один из серверов old-slow-box или new-fast-box не работает,
; переключаемся на использование серверов: sysdmin-box и server
SRV 1 0 9 sysadmins-box.example.com.
SRV 1 0 9 server.example.com.
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
; Другие сервисы НЕ поддерживаются
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .

При совершении вызова, клиент производит следующие действия:

• проверяет, существует ли SRV запись для заданного домена.
• Если SRV запись существует, используем их по кругу, пока один из них не ответит в течение заданного периода.
• Если SRV запись не существует, используется "стандартный" поиск адреса в DNS, для соединения с сервером.

Ниже приведен пример еще одной зоны, для протокола SIP:

$ORIGIN sipdomain.com.
@ SOA ns1.sipdomain.com. root.sipdomain.com. (
1995032001 3600 3600 604800 86400 )
NS ns1.sipdomain.com.
NS ns1.elsewhere.ca.
NS ns2.elsewhere.ca.
;
; Для сервиса sip, распределяем нагрузку, по принципу:
; 3 запроса - на сервер 3x-load, на каждый 1 запрос,
; отправляемый на сервер 1x-load.
_sip._udp SRV 0 1 5060 1x-load.sipdomain.com.
SRV 0 3 5060 3x-load.sipdomain.com.
;
; Если сервера с наивысшим приоритетом не отвечают,
; то переключаемся на использование этой группы,
; равномерно распределяя запросы к этим серверам
SRV 1 0 5060 failover1.sipdomain.com.
SRV 1 0 5060 failover2.sipdomain.com.
;
; Если все вышеописанные сервера не отвечают...
; используем SIP сервера другого провайдера:
SRV 2 0 5060 offsite-failover1.elsewhere.ca.
SRV 2 0 5060 offsite-failover2.elsewhere.ca.
;
; Вам необходимо определить записи "A" типа для каждого хоста,
; указанных в записях SRV
ns1 A 10.0.0.1
1x-load A 10.0.0.3
3x-load A 10.0.0.4
failover1 A 10.0.0.5
failover2 A 10.0.0.6
;
; описание "A" записей для двух последних серверов,
; описанных здесь в SRV записях, находится в зоне
; для домена elsewhere.ca
;
; Другие сервисы НЕ поддерживаются
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .

Определение записи DNS:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

Пример:
_sip._udp.domain.tld. IN SRV 20 0 5060 mysipproxy.domain.tld.

_stun._udp.domain.tld. IN SRV 20 0 3478 mystunserver.domain.tld.

Тестирование реализаций поддержки SRV записей для SIP клиентов:

SRV,::::: implementations" class="wiki wikinew text-danger tips">SRV implementations: Результаты тестирования различных реализаций поддержки SRV записей

Сервера DNS, поддерживающие записи SRV.

• BIND 9
• djbdns (с патчем для поддержки SRV или generic SRV records)
• MyDNS: http://mydns.bboy.net/: Свободно распространяемый DNS сервер для UNIX (записи хранятся в SQL базе - на данный момент поддерживаются mySQL/PostgreSQL)

Ссылки по теме:

• RFC 2782: http://www.ietf.org/rfc/rfc2782.txt: DNS RR, для определения местонахождения определенных сервисов (DNS SRV)
• DNS
• SIP
• STUN

---