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 “john@example.com”, 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 john@example.com, 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.

• 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 user@voip-info.org 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 here, original RFC #2782 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/en/US/docs/voice_ip_comm/sip/proxies/2.1/administration/guide/ddns.html

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 .