CloudfloorDNS Blog

MX Records are one of those critical DNS records that are required for any domain that’s using email.  They are a different type of record than all the others in that they have built in redundancy into the record set itself. This built in redundancy comes in from having two or more MX records required (primary and backup server at the least) and priorities set on these records

MX records for email servers would look like:

Host                                          Priority
primarymail.example.com             10
backupmail.example.com              20

MX records are designed this way to ensure mail will be reliable and that there is always a backup server.  If an email is sent and the first server isn’t responding, the second server at priority 20 get’s called into duty and the email is delivered.  SRV records are another type of DNS resource record that also offers built in redundancy in the form of multiple records with both weight and priority and port.   Here’s the excerpt from the RFC written by Paul Vixie back in Feb 2000:

“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.”

SRV records have been around for a while, but since the recent surge of VOIP, UC & UCaaS providers (Unified Communications) and many collaboration clients utilize SRV records for their services. When an organization set’s up a Unified Communications platform such as the Cisco Spark, they setup Cisco Expressways, Cisco Call Managers that offer these services. Clients then request these DNS SRV Resource records when attempting to connect.

For example, when using Cisco UC and firing up the Jabber collaboration client, the client first requests the _collab_edge DNS SRV record set to see available servers.

DNS SRV records for Cisco UC Collaboration (Jabber) records would look like this:

DNS SRV Name   Priority  Weight  Port  Target or (Host)
_collab-edge._tls      1 3 8443 na-jabber.example.com.
_collab-edge._tls      2 2 8443 eu-jabber.example.com.
_collab-edge._tls      3 1 8443 ap-jabber.example.com.

When a user in the North American office of Example corp and fires up their Jabber client the DNS will respond with the above records.  This tells the Jabber client to connect to the lowest priority server, in this case we can see that na-jabber.example.com is the lowest priority. If that server isn’t available, the client will step up to the next priority server, in this case the eu-jabber.example.com server.

Just like MX records, you can see that SRV has built in redundancy into the resource record and it goes a few steps further by allowing weight and priority and the service port. Pretty cool huh?   Just one of the neat ways you can use DNS SRV….but wait it gets better.

DNS SRV records are great but as companies grow and scale they add more servers and more SRV records. When an employee goes on the road and depending on where they are, the setup of the SRV and VPN or No VPN there are issues with the way the SRV records are handed back. Take the example above, as an employee in the North American Chicago office, It’s no problem since they are always connecting to the na-jabber server. As soon as the employee travels to Japan for a visit, their Jabber client is going to connect all the way back to North America. This can be a problem and not only take longer to connect, but it can also introduce high latency (slowdowns) that can wreak havoc on video quality, connection times and not to mention patience.

Here’s where some DNS SRV and Geographic DNS comes into play. Since we have three global locations to connect to, we can enable GEO DNS on our DNS SRV records and get even more usability out of these handy resource records.

Adding GEO DNS into these _collab-edge records now provide us the advantage to hand back the closest server to them in the region they are in. For example, now when the Chicago employee lands in Japan and connects to Jabber, the local DNS will direct him though the magic of DNS to our CloudfloorDNS Anycast DNS servers which will geo-locate John and determine that he’s using an IP address located in Japan. Our GEO Anycast DNS servers then respond back with the custom order of DNS SRV records for that region which would look like below:

DNS SRV Name   Priority  Weight  Port  Target or (Host)
_collab-edge._tls      1 3 8443 ap-jabber.example.com.
_collab-edge._tls      2 2 8443 eu-jabber.example.com.
_collab-edge._tls      3 1 8443 na-jabber.example.com.

You can see here that Geographic DNS located the user and determined they were in the APAC region and then hands back the DNS SRV records that sets the ap-jabber.example.com server with the lowest priority making it the first choice.  We still provide the other SRV records as backup in the order that makes the most sense for lower latency and higher performance.  Best of all it works for all DNS SRV record types such as _xmpp-server, _xmpp-client, sip, _sips, _sipfederation, and others.  We hope this howto helps you utilize your DNS SRV records to better streamline your services and provide a higher quality of service.