Today, we have migrated our main DNS domains to our own DNS server running bind.

This action was not done just for pride of running our own DNS but out of necessity. I would like to give some insight about the advanced DNS features that needs to be used to setup a proper sip domain.

Any SIP service provider like us needs to operate one or more SIP domains in a professional way. Each of these SIP domain is associated a DNS domain to provide the following features:

• Internet wide URI resolution
• Proxy load sharing and redundancy
• Public / private network support

Internet wide URI resolution 

An IVeS subscriber is identified his/her SIP URI e.g. 60606060@visioassistance.net. How is the domain part (here "visioassistance.net") translated into the IP address of the SIP server to use?

All the process is described in the RFC 3263: Locating SIP servers.

To give a simplified explanation, this is done in three steps:

1.  The calling User Agent (UA) sends an "SRV" DNS question to the domain specified in the domain part of the URI. The domain answers with a list of records (it is advised to use A recornds) with priority, weight, etc.
2. The A records gets translated in IP addresses. The UA selects one of the server in the list according to a well defined algorithm and can send the SIP packet to the selected address.
3. In case the initial SRV request fails, many SIP User Agents fallback to simple "A" DNS requests. 

It is to be noted that the process is very similar to mail server location using MX DNS records.

If we were running a closed garden network where our subscribers would only be capable of calling between themself, this would not be very useful but as our philosophy is to aim to interconnections with other SIP domains, this is a must.

 Redundancy and load sharing

The standard unables to define more than one SIP server per domain and per transport protocol. Furthermore, a priority and a weight can be indicated. The SIP user agent selects the actual server during the first resolution and stick to it until a failure (timeout or server failure) is encountered. This is a very elegant mecanism that enables failover and load sharing Internet wide.

The most difficult part remains to implement true redundant SIP servers, but tha'ts another story.

 Public / private network support

 We run our network both on the public Internet and a private network (an IP VPN). In order to do this, we leavageage the "view" feature of bind to serve the same names as different IP addresses depending if the user is connecter on the Internet or on our VPN. This is not part of the standard but very useful.

 Quick cookbook to setup a SIP domain

 Define your SIP proxy/regsitrar servers as A records in your zone file using names that represents the hosts themselve

server1  IN   212.1.1.10
server2  IN   212.1.1.20 

_sip._udp    SRV 0 5 5060 server1.mydomain.com.
_sip._udp    SRV 0 5 5060 server2.mydomain.com.
_sip._tcp    SRV 0 5 5060 server1.mydomain.com.
_sip._tcp    SRV 0 5 5060 server2.mydomain.com. 

Also, the standard mandate that the domain holds NAPTR record in order to notify the transport protocol preference.

@ IN NAPTR 0 0 "s" "SIP+D2U"  "" _sip._udp.mydomain.com.

@ IN NAPTR 1 0 "s" "SIP+D2T"  "" _sip._tcp.mydomain.com.

It is advised also to have a simple A records that is resolved with multiple IP for UAs that do not support SRV resolution.

sip        IN   212.1.1.10
           IN   212.1.1.20  

Conclusion : we did not find any hosted services capable of providing the level of required feature to host such DNS domain. My advise: run your own bind server.