A Domain Name Server (DNS) SRV record helps connecting to a SIP user in a similar way that an MX record helps email delivery. When you send email to “[email protected]”, the MX record for ”example.com” might tell the mail transfer agent to deliver email to a completely different machine, such as “zaphod.foobar.com”. Similarly, when you want to make a SIP phone call to [email protected], the SRV record might tell your computer that it should connect to “galaxy.starsystem.tw” to do so.
__Why use DNS SRV records for SIP?__
Dialling by domain names lets a SIP user have a single public “SIP address” which can be redirected at will to their current location. SRV records maintain stability and also opens up the possibility to use your own domain, regardless of the domain of the SIP service you are using.
DNS SRV resource records indicates how to find services for various protocols.
From the RFC:
^
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.
Currently, one must either know the exact address of a server to contact it, or broadcast a question.
The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.
Clients ask for a specific service/protocol for a specific domain (the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers.
^
For a SIP proxy in a domain, this means that
* You can set SRV records of a domain to point to a SIP proxy in another domain. Like e-mail, where a mail server handles mail to many domains, a SIP proxy can handle users in many domains. The key is to set the DNS SRV records in the user domain (like voip-info.org) zone file to point to a SIP Proxy somewhere else (like sip.iptel.org). With a configuration like this, calls to [email protected] will be automatically routed to the SIP proxy sip.iptel.org.
* In a DNS zone, you can specify multiple SIP proxies. If the proxy with the highest priority is not reachable, the SIP ua or proxy that tries to reach a user within the domain tries the next proxy defined in the zone with a SRV record.
!Example
In order to use SRV records, you will need the following information:
a. The IETF Service Type (You can view a more or less complete listing of those [http://www.dns-sd.org/ServiceTypes.html|here], original RFC #2782 [http://www.ietf.org/rfc/rfc2782.txt|here]) in the format _servicetype._layer4.
b. The priority of your systems.
c. The load, or ‘weight’ those systems can handle. (optional)
d. The port number your service will be running on.
e. The hostname of the system your service will run on.
All of this information gets entered into your zone file in the above order, like so:
a (TTL) SRV b (c) d e.
For example, you would do a SIP server, running on host.tld like so:
_sip._udp SRV 0 5060 host.tld.
As I described above, _sip._udp is the IETF Service Type for SIP protocol running on UDP. SRV is the DNS record type, 0 is the priority of this entry, we don’t have a load entry here, and
5060 is the port number that SIP runs on. host.tld is our hostname.
You could do a similar setup for iax, like so:
_iax._udp SRV 0 4569 host.tld.
You will of course need to make sure that host.tld has a related A record or CNAME record to go with it, like so:
host.tld A xxx.xxx.xxx.xxx
There is an extensive document with a very detailed example at Cisco’s webite:
[http://www.cisco.com/univercd/cc/td/doc/product/voice/sipproxy/admingd/ver2_1/ddns.htm]
Here’s the sample zone file from the RFC. Note the SRV they are defining is *not* for SIP, so it’ll be different for you:
Fictional example
This example uses fictional service “foobar”, running on port 9 as an aid in
understanding SRV records. If ever service “foobar” is implemented,
it is not intended that it will necessarily use SRV records. This is
(part of) the zone file for example.com, a still-unused domain:
$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 – use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin’s box and the 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
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
When placing a call, the client
* checks to see if there are SRV records for the defined domain
* if there are SRV records, round-robins through them till one of them replies within the timeout period
* if there are no SRV records, uses a “regular” DNS lookup to connect to the server
Here’s another zone, setup for 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.
;
; For service SIP give 3 requests to 3x-load for each 1 given
; to 1x-load
_sip._udp SRV 0 1 5060 1x-load.sipdomain.com.
SRV 0 3 5060 3x-load.sipdomain.com.
;
; If 1st priority servers don’t answer, failover to this group
; giving requests to the servers equally
SRV 1 0 5060 failover1.sipdomain.com.
SRV 1 0 5060 failover2.sipdomain.com.
;
; If none of our servers are up…try another
; SIP provider elsewhere:
SRV 2 0 5060 offsite-failover1.elsewhere.ca.
SRV 2 0 5060 offsite-failover2.elsewhere.ca.
;
; You need an A record for each host you set an SRV for
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
;
; The A recs backing up the final two SRVs are in the zone
; for elsewhere.ca
;
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
!!Definition of DNS record:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
example
_sip._udp.domain.tld. IN SRV 20 0 5060 mysipproxy.domain.tld.
_stun._udp.domain.tld. IN SRV 20 0 3478 mystunserver.domain.tld.
!!Testing of SRV implementations in SIP clients:
((SRV implementations)): Test results of the SRV implementations
!DNS Servers Supporting SRV Records
* BIND 9
* djbdns (through [http://mywebpage.netscape.com/guibv/#djb|patching for SRV] or [http://www.anders.com/projects/sysadmin/djbdnsRecordBuilder/|generic SRV records])
* MyDNS: [http://mydns.bboy.net/]: A free DNS server for UNIX (serving records from SQL – currently ySQL/PostgreSQL)
* Microsoft DNS (ie: can any one share how to publish these records to Microsoft DNS server, since many use it for intrAnet resolution? If so, please add detailed steps.)
!See Also
* RFC 2782: [http://www.ietf.org/rfc/rfc2782.txt]: A DNS RR for specifying the location of services (DNS SRV)
* ((DNS)): The domain name system
* ((SIP))
* ((STUN))