techblog 

There are a number of technologies, such as Jabber or SIP that use what look like email addresses but actually aren’t. These addresses look just like email address of the form name@domain and they rely on SRV records to make them work.

In other words, how do I use jay@nominet.org.uk as my email address, my jabber address and my SIP address? How does the client know how to find the appropriate server if all it knows is the domain name part of nominet.org.uk?

Mail servers as we know have the special DNS record, the MX record. To specify the mail servers for a domain you just add appropriate MX records under that domain. However there aren’t special DNS records for SIP or Jabber. WE might assume that all we need do is find the address for the domain but then that would mean that all services have to run on the same server. What we need is some way to specify the address of the SIP server that is different from any other server address for that domain. So as well as SRV records we have a special way of showing protocol they refer to.

An MX record for say nominet.org.uk is specified like this in DNS:

nominet.org.uk.                      86400  IN   MX  10  mx3.nominet.org.uk

Whereas an SRV record for say SIP has a specially constructed left hand side, which looks like this:

_sip._tcp.nominet.org.uk.            86400  IN    SRV  1  0  5060  sip.nominet.org.uk

As you can see this DNS name is unique to SIP over TCP, which is how we can identify that this particular SRV record is that of the SIP server.

Similarly the SRV record for Jabber looks like either of these (xmpp is the standard name for jabber):

_jabber._tcp.nominet.org.uk.         86400  IN    SRV  1  0  5269  im.nominet.org.uk
_xmpp-server._tcp.nominet.org.uk.    86400  IN    SRV  1  0  5269  im.nominet.org.uk

All of these SRV records can happily co-exist and applications will only find those they need.

The final thing is to explain the numbers in the record. To the right of the SRV part we have Priority, Weight, Port, Server name.

• Priority. Clients should connect to the server with the lowest priority but should not try any servers with a a higher priority unless the first ones are not responding. This allow you to specify backup servers that you know will only be used if the primary servers are down.
• Weight. Clients should distribute their hits across all servers with the same priority in proportion to the weights. In other words if two servers have a weight of 50 then they both 50% of the hits.
• Port and Server. Obvious really, what server to connect to and what port to do it on.

SRV records could really make MX records redundant though nobody uses them that way. But they probably make it unlikely that any DNS record similar to MX will ever be developed in the future.