In this section:
The SBC Core supports domain name resolution through external DNS servers. Each IP address context defines one or more DNS server groups. Each DNS server group contains up to eight DNS servers. The zone and/or SIP Trunk Group indicates the DNS Server Group to use for the requests, which require a DNS resolution. The Zone of a particular Address Context that can be associated with the DNS Group of an another Address Context. For example, the DNS Group (D1) is configured in the Address Context (AC1). The SBC supports associating Zone of Address Context (AC2) with DNS Group (D1) of the Address Context (AC1). The ipInterfaceGroup
used by a DNS Group is restricted to be of the same addressContext
as the DNS Group. When configuring the DNS group, the SBC is allowed to associate only the IP Interface Group of the same Address Context.
Within a DNS server group, each server has both a priority and a weight. Requests are sent to the server with highest priority (lower value) first. Servers of a lower priority are only used when all servers of a higher priority are marked unavailable based on previous timeouts. If multiple servers of the same priority exist, requests are load-balanced across servers in proportion to their weights.
The SBC supports the following functionality:
The SBC uses the DNS procedures RFC3263 to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact.
When a SIP endpoint (like a UAC, for example) needs to send a request to a resource identified by a SIP or Secure SIP (SIPS) URI, it needs to resolve that URI into the IP address, port, and transport protocol. This URI can identify the desired resource to which the request is targeted (in which case, the URI is found in the Request-URI), or it can identify an intermediate hop towards that resource (in which case, the URI is found in the Route header).
For a SIP call where the transport is not known, or cannot be derived from the URI, the SIP endpoint should perform a Naming Authority Pointer (NAPTR) query for the domain name in the URI. Once the transport protocol is found from the records returned by the NAPTR query, the client can then use Location of Services (SRV) query on the protocol to target host FQDN and port number. Finally, the client can then perform an Address (A) record query to resolve the domain names returned by the SRV query to obtain the IP address of the server.
For network configurations where SIP Server domain resolution is not available from external DNS servers, the SBC supports a local DNS cache. DNS queries can then be made against either external DNS servers or the local cache. The following DNS record types can be configured in the local cache:
The SBC supports all DNS queries over UDP from the DNS client with no option to configure the transport protocol for DNS servers. Additionally, the SBC supports DNS servers over TCP using the transportProtocol
configuration object with two options: udp
or tcp
. Default value is udp
. The flag tcpFallback
supports TCP fallback when the configured protocol is UDP. The default value is disabled
.
The DNS Group Transport Protocol option allows the user to choose either UDP or TCP transport protocol for a DNS query for the associated DNS Group.
The figure below depicts DNS support when the transport protocol for the DNS server is configured as TCP.
DNS queries are sent over UDP to serve DNS Requests. UDP messages are preferred over TCP messages as TCP connections can consume computing resources for each connection. DNS servers get numerous connections per second and using TCP can add too much overhead. However, when the response data is received with TC flag, then DNS Client uses TCP as transport to resolve the request.
The tcpFallback
flag can be enabled per DNS server to notify the DNS client to support TCP fallback when the DNS response on the UDP is received with TC flag. When the tcpFallback
is enabled and the DNS client receives TC flag in response over UDP, then the DNS Client sends the same query again over TCP to the same server.
The figure below depicts TCP Fallback when the initial transport protocol is UDP and tcpFallback
flag is enabled for that particular DNS server:
This tcpFallback
flag is disabled by default to support backward compatibility. The DNS over TCP works for both IPv4 and IPv6 transport protocol based on the configured address of the DNS server.
The SBC supports, by default, 1,300 Maximum Transmission Unit (MTU) bytes, and the MTU size used by the SBC is configurable. If the initial INVITE message size exceeds the default MTU value, the SBC sends the data over the TCP transport protocol. The TCP transport protocol is used if it is allowed by the transport profile irrespective of its preference order.
DNS client maintains the TCP connections in the TCP Pool, enabling DNS client to reuse those TCP connection, if DNS query is to be sent to the same server. Thus, the DNS client avoids opening TCP connection each time the DNS query comes for the same server. However, the DNS client removes the TCP connections periodically from the TCP Pool which are least recently used and their ideal timer expires.
SBC supports the following functionalities:
The SBC clears a DNS cache for:
In case of FQDN, there are two scenarios:
SBC is able to override the TTL value with the new value if the matching FQDN and record type is found in the given DNS Group. If that FQDN value is not matching, it returns an error.
The SBC supports performing a manual query where the cache receives updates of the IP address, TTL and port received in response to the query sent to the server. The response is updated if record is already present; otherwise, the SBC creates a new entry.
Two types of manual queries apply:
If the SBC does not receive a response to the DNS query, it display an error after a configurable timeout. The manual DNS query supports re-sending the request over TCP, if the response is received with the TC (truncation flag) set and TCP Fallback is enabled.
The SBC supports raising an alarm when the server is blacklisted.
A server is blacklisted when:
In the above scenarios, the SBC generates the following alarms:
For alarm details, refer to Domain Name Server (DNS) Alarms.
The SBC supports the following functionality:
hostPort
configuration under ipPeer pathCheck
option is updated to 5060
. To enable this feature, set hostPort
under ipPeer pathCheck
option to 0
.When the pathCheck
profile is attached to an FQDN based IP peer with hostPort
set to 0
, the pathCheck
task performs SRV lookup to resolve the port numbers. The resolved port numbers are used to send OPTIONS ping to the IP peer.
pathCheck
profile is attached to an FQDN based IP peer configured with a hostPort
(other than the value 0
), the pathCheck
task does not perform SRV lookup. It uses the configured port to send OPTIONS ping to the IP peer.The pathCheck
task processes DNS SRV response as follows:
pathCheck
task sorts SRV records based on weight and priority and saves all the records. The pathCheck
task then iterates through all the SRV records in the same order after the sorting to perform A/AAAA query on each SRV record.The pathCheck
task processes DNS A/AAAA response for each SRV record as follows:
For example, the pathCheck
task performed SRV query for a given FQDN target and two SRV records are returned: SRV1 and SRV2. They are in the same order after sorting based on weight and priority. SBC then sends A or AAAA query for SRV1 followed by SRV2. Assume that SRV query resulted in two A records. There are total of two SRV records with two A records each. The pathCheck
task now sends OPTIONS ping to all the IP Address/Port combinations - A1:SRV1, A2:SRV1, A3:SRV2, and A4:SRV2.
The pathCheck
task maintains overall status of an FQDN based Peer just like it does for the IP based Peer: It tracks and updates status of the FQDN peer using the OPTIONS ping messages sent to all learned SRV record combinations. When multiple IP Address/Port combinations are tried by the pathCheck
task:
If DNS query for an FQDN target fails (error, timeout, or no answer records), the pathCheck
task retries the DNS query again after the configured retry time in the pathCheck
profile.
If an FQDN peer to which the pathCheck
profile is attached to is deleted, the pathCheck
task clears all associated saved DNS records.
If an FQDN peer to which the pathCheck
profile is attached to is modified with a new FQDN, the pathCheck
task clears the associated DNS records for the earlier FQDN and performs a fresh DNS query using the newly updated FQDN.