SIP SRV records are created to generate information for different set of services that are commonly available on systems and are commonly associated with the SIP Configuration. SRV Records follow a unique system for generation of names. In simple words, it starts with an underscore that is further followed by service name, a period, again one underscore, and then protocol of the system, one more dot and finally name of the domain.

Let’s take a look at the break down of an SRV record, how to implement them with SIP and then touch briefly on NAPTR records.

 

What are the components that make up an SRV record?

 

  • Name: As already discussed, the naming system for SIP SRV records follow a specific pattern where underscore is followed by name of service, then comes a period, after this underscore, then protocol, one more dot and finally name of the domain.
  • Host: It includes details about the system that is going to receive service.
  • Priority: It works in similar manner as that of MX level. Here, lowest number is used to indicate highest priority and that is the most desirable target.
  • Weight: Weight is used by the zone administrator for distribution of loads to several targets so that a perfect balance can be maintained. This field help to determine load and relative capacity of two different SRV fields that are on priority. All the hits are on proportionate basis by this weight field so that administrators can easily share all the loads between weak as well as powerful servers. Here, the smallest number that is 0 indicates lowest load.
  • Port: It shows actual port for the offered service.

Let’s look at a sample SRV record:
# host -t SRV _sip._tls.example.com
_sip._tls.example.com SRV 5 100 5060 sip-tls.example.com.
_sip._tls.example.com SRV 10 100 5060 sip-tls-backup.example.com.

SRV Lookup

 

How do DNS SRV Records work?

When your SIP device does a lookup by domain name, the DNS server provides a public SIP address to the device depending on your protocol preference, prioritized by the DNS entry.

For example;

If the SIP client supports both TLS and UDP and the SRV record prioritizes TLS followed by TCP and then UDP, you would receive the SIP servers TLS server IP or DNS name. If an IP is served, the client device will connect directly via the IP. If a DNS name is specified, the client equipment will then do a lookup on the DNS name given which could contain multiple IP’s for load balancing, or simply a single IP setup. As a SIP Server admin you may want to specify a DNS name instead of an IP even if not load balancing so that you can change the IP anytime without needing to give out new IP’s to non SRV supported clients. You should however always provide your new list of IP’s to clients in order for them to Whitelist on their Firewall’s and ID’s, etc.

There are two major operations that are performed during this operation for SIP users and SIP providers:

  1. The first task is to provide greater stability to the system. This task is accomplished by simply allowing administrators to access multiple servers over a single domain where few of these work like primary servers and rest are backups. It ensures faster processing with safe service.
  2. It allows the SIP users to access their personal domains for independent SIP address and this service works regardless of SIP provider’s domain.

 

NAPTR DNS Records

As a final note, you may be asking yourself “what about NAPTR records? NAPTR is an older method to lookup DNS records in order to find out what the DNS address is for a certain record. Although it was commonly used in VoIP to find the actual SRV record it’s more commonly used now to find setup details for email using “auto-discover”.

Sample NAPTR record:
example.com NAPTR 10 100 “S” “SIP+D2U” “” _sip._udp.example.com.

Although NAPTR lookup still exists in some VoIP devices it isn’t used by many providers anymore for 3 simple reasons.

  • SRV lookup is more widely used in VoIP devices
  • NAPTR does a lookup on a domain name such as “provider.com” which in turn will return the SRV record. This is an un-needed additional step and also gives us less control over the DNS naming conventions. If I want to provide a user with multiple DNS names for redundancy, it’s much easier to just provide the sub-domains, “sip.provider.com” for example.
  • NAPTR records are not common with most DNS/Domain providers.

 

In an upcoming post we will show you how to setup SRV records in Cloudflare and other DNS providers, so stay tuned.