Locating SIP Servers Using DNS Overview
The BSG supports DNS to resolve SIP Uniform Resource Identifiers (URIs) into the IP address, port, and transport protocol of the next-hop SIP server for new transaction requests that it receives. This feature complies with RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers.
The BSG uses the following queries of DNS records on the domain resolution server to locate the preferred transport protocol, port, and IP address of the next-hop SIP server:
- Name authority pointer (NAPTR) record query—Queries the DNS NAPTR records for the preferred transport protocol of the domain in the SIP URI.
- Service resource (SRV) record query—Queries the DNS SRV records to acquire A records.
- Address (A) record query—If there are multiple DNS A records, queries the A records to acquire the IP address for servers associated with the domain name that the BSG received as a result of the SRV query.
After the BSG obtains this information about the SIP server, it adds an entry for the server to a name resolution cache.
How the DNS Resolution Process Works
When the BSG receives a new transaction, it queries the name resolution cache for the requested SIP server. If the SIP server is not in the cache, the BSG queries the name resolution server. The following example shows how the BSG uses SIP queries to locate the preferred transport protocol, port, and IP address for the example.com domain in the SIP URI:
- To determine the transport protocol, the BSG issues
a name authority pointer (NAPTR) query for the example.com domain.
The BSG receives the following response:
; order pref flags service regexp replacement example.com NAPTR 100 50 "s" "SIP+D2U "" _sip._udp.example.com
The preferred transport protocol in this example is UDP.
- To acquire A records, the BSG issues a service
record (SRV) query of _sip._udp.example.com.
The BSG receives the following response:
; Priority Weight Port Target _sip._udp.example.com SRV 0 20 5060 server1.example.com. SRV 0 10 5060 server2.example.com. SRV 10 10 5060 server3.example.com. - To determine the IP address, the BSG issues an
A query for server1.example.com.
The BSG receives the following response:
; Address server1.example.com A 192.168.1.10
- If the attempt to get the IP address for server1.example.com fails, the BSG sends an A query to server2.example.com. If the second query fails, the BSG sends an A query to the next target in the list, and so on.
- If the BSG receives a CNAME alias instead of an IP address, it adds the alias to the name resolution cache and issues a new A query for the alias.
- The BSG uses the information from the queries to add a SIP server entry to its name resolution cache. This server is now a possible destination for request URIs with the domain example.com.
- The BSG routes INVITE requests that it receives for example.com to 192.168.1.10.
This procedure is the default process. You can set up the BSG to accelerate the process.
Methods for Accelerating the Name Resolution Process
To accelerate the DNS resolution process, use the following options in the CLI:
- initiate-alternative-queries—The BSG sends the NAPTR, SRV (both UDP and TCP), and the A queries in parallel instead of waiting for a response to the previous query. This option saves time in cases where the NAPTR or SRV queries fail.
- initiate-next-queries—The BSG sends A record queries to all SIP servers returned in the SRV response instead of querying the first A record in the SRV response.
- no-refresh-before-ttl-expiry—The BSG does not send queries to refresh entries in the cache, and the entries are removed from the cache when the TTL expires.
Name Resolution Cache
Each SIP server in the name resolution cache has a time-to-live (TTL) value that indicates how long the server can be saved in the cache. You can specify the maximum number of servers saved in the cache. You can also lower the TTL value by setting the maximum number of seconds that servers can be held in cache. This setting overrides the TTL only if it is lower than the TTL value.
If the BSG routes a request to an entry in the name resolution cache and discovers that the server is down, it marks the server as unavailable for a defined period of time. During this time, the server is considered blacklisted and is not included in query responses. However, if a server has only one A record, and this record is marked as down, the BSG does not add it to the blacklist, and still sends requests to the server.
Server Clusters
The name resolution cache can contain multiple addresses for a domain. For example:
; Address Priority Weight
server1.example.com A 192.168.1.10 0 10
server2.example.com A 192.168.2.20 0 20
A 192.168.2.21
server3.example.com A 192.168.3.30 0 30
In this case, each IP address is a possible destination for every request URI in the domain example.com. These four host addresses represent a server cluster. The BSG chooses among the servers in a cluster according to the following logic:
The BSG groups servers that have the same priority. The group with the lowest priority is preferable. If all servers in a priority group are unavailable, the BSG uses the next-lowest priority group. Within each group, the BSG selects a server according to its relative weight within the sum of weights in the group.
Priorities, then, make one server an inactive backup of another server, and weights enable load balancing between several servers.
In the preceding server cluster, whenever server2.example.com is chosen, address 192.168.2.20 is used. IP address 192.168.2.21 is used only if 192.168.2.20 is in the blacklist.
