Tutorial: SIP and DNS SRV Records

SRV records are a nameserver record type that returns the port as well as weight and priority information for a request. For example, SRV records are commonly used by SIP clients to discover the IP address and port of the SIP server it should use.

Lets say a SIP client wants to find out what server to use given a call to 2125551212@example.com. The server part of that address, example.com, is easily recognized but lets say the answer should include three public servers on various IPs and ports. You could just set up three standard "A" records for example.com but the client wouldn't know what answer is more preferred over another nor what port to use for each of those servers. (not to mention you probably already have "A" records that point to web servers) So instead we use an SRV record which contains this information.

In this example, our SIP client uses UDP as opposed to TCP as a transport so by convention it will append _sip._udp. to the front of the domain name. So the task is to look up the SRV records for _sip._udp.example.com. (we'll use the command-line tool "host" in this example because of its brevity though you could use anything else such as "dig".)

~> host -t srv _sip._udp.example.com
_sip._udp.example.com has SRV record 100 30 5060 sip.nyc.example.com.
_sip._udp.example.com has SRV record 100 20 5070 sip.lax.example.com.
_sip._udp.example.com has SRV record 100 10 5080 sip.dfw.example.com.
~>

We get three records back, presumably for servers in New York, Los Angeles and Dallas / Fort Worth. But which one do we actually go to? The next two numbers on each line describe priority and weight. Lower priority numbers are picked first but all three responses have the same priority of 100. So falling back to weight, it looks like sip.nyc.bandwidth.com has the highest weight so we should try that server first. Of course if for some reason that server wasn't reachable, we would move on to sip.lax.example.com and then lastly sip.dfw.example.com.

The last number we have in the SRV record is the port that we should be using for the service. In this case, sip.nyc.example.com wants to be contacted on port 5060. This happens to be the standard SIP port though as you can see, other ports are used for the other servers should we need to fail-over to them.

The last step is for us to to a standard "A" record lookup on sip.nyc.example.com to find out what IP to go to.

~> host sip.nyc.example.com
sip.nyc.example.com has address 1.2.3.4
~>

So to complete this call, we are going to send our SIP INVITE for the number 2125551212 to port 5060 on the server 1.2.3.4 using UDP.

I use djbdns fairly extensively for nameservice but SRV records aren't natively supported by the djbdns package. While there is a patch that adds an SRV record type to djbdns, you can also create SRV records with an unpatched version of djbdns by using the generic record format.

Coming up with the generic record syntax for an SRV record isn't very straightforward. To help with this, I have written a djbdns Record Builder for SRV records that lets you fill out a form to get generic SRV records. While these records aren't the easiest to administrate in their encoded form, it doesn't require patching djbdns.

It is easy to see how SRV records can be used to load balance traffic across geographic locations. You would imagine that you could get a somewhat even spread if all three answers in the example above had the same weight and priority. It would be up to the SIP client to pick one of the three at random. Of course because these records are returned dynamically and you can have a fairly low TTL (Time To Live) value on each of these records, you could drain off traffic to a particular server over time by removing its SRV record and letting the others take the load.

I usually set my TTLs to 10 minutes so I can stop new INVITES fairly quickly. Of course there is a penalty in the form of excessive DNS queries if you set the TTL too low so you should see what works best for your situation. Also, stopping initial INVITES coming in doesn't necessarily mean all traffic has stopped on a server. Calls in session would still be there. So to completely drain the average server, you would have to remove the SRV record, wait for the TTL timeout period and then wait for the average call duration. You might get lucky with all calls naturally hanging up quickly but you could be caught by one call that hangs on an extra hour or two more than expected as well!

Note: SRV records are described in RFC 2782.

Tags

Tutorial SIP DNS SRV djbdns

Trackbacks

DNS SRV Record Tutorial

Anders Brownworth has written a nice tutorial for configuring SRV records. SRV records are becoming more popular, especially for use with SIP, so it’s good to see someone writing about them.
Anders has also written an SRV record builder for u read more...

To send a trackback, use the URL of this story appending ?page=tb at the end.

Comments (3)

Bruce from Sydney/NSW/Australia

So, this is all very good. But how do I create SRV records (for SIP) to point to a different priority in different sites? As an example, If I create SRV records for NYC, LAX & DFW, I want a user in NYC to see the NYC entry as the lowest priority but a user in LAX to see the LAX entry as the lowest priority. If I have a single DNS domain e.g. MS AD, all DNS servers are going to pick up the same priority values.

Anders from RTP

Bruce: You are probably interested in the tinydns GeoIP patch which takes source address into account.

Anders from RTP

Combining DNS SRV records with a DNS server that replies differently depending on where you are requesting from is useful. In the example above, you would probably want to give East coast users the New York proxy as the highest preference while listing Los Angeles at a lower level. But West coast users should get the Los Angeles proxy as the highest preference response. This can be done through a patch to djbdns which enables a lookup of the requesting IP via an IP to location database. The result can then be used to return the most appropriate answer for your location.