The
supports domain-name resolution via external DNS servers. Each IP address context defines one or more DNS server groups, each containing up to eight DNS servers. The zone and/or SIP Trunk Group then indicates which DNS Server Group to use for requests which require DNS resolution.
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
- supports using DNS for either A record queries or full NAPTR+SRV+A record queries, and is configurable on a per SIP trunk group basis. Preferences for recursion and for name-server support are also configurable.
...
- supports the following DNS queries to gather domain information:
- DNS NS—Redirects DNS query to other DNS servers
- DNS SRV—Gathers the transport information
- DNS A record—Gathers the address
...
- maintains a DNS Cache, where it is able to store the DNS records received from DNS servers.
...
- supports removing cached records and changing Time To Live (TTL).
- also supports ENUM queries to DNS servers for call routing.
- supports DNS queries using TCP transport.
- supports manual DNS query.
Locating a SIP Server Using DNS
...
- A (Address)
- SRV (Location of Services)
- NS (Name Server)
- NAPTR (Naming Authority Pointer) records.
TCP Enhancement
In previous releases, SBC supported all DNS queries over UDP from the DNS client with no option to configure the transport protocol for DNS servers. SBC is enhanced in this release to provide support of DNS servers over TCP by the addition of transportProtocol
configuration object with two options: udp
or tcp
. Default value is udp
. Additionally, the flag tcpFallback
is added to support TCP fallback when the configured protocol is UDP. Default value is disabled
.
Info |
---|
For configuration details, see: |
Configuration of Transport Protocol
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.
Note |
---|
Transport Protocol option is configured per DNS server. You can configure up to eight DNS servers per DNS group, and up to 512 DNS Groups system-wide. |
The figure below depicts DNS support when the transport protocol for the DNS server is configured as TCP.
Caption |
---|
|
Image Added |
Support for TCP Fallback
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:
Caption |
---|
|
Image Added |
Info |
---|
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. |
TCP connection Pool
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.
DNS Cache Management and Override TTL
The SBC is enhanced in this release to provide the ability to:
Anchor |
---|
| Flush the DNS Cache |
---|
| Flush the DNS Cache |
---|
|
Flush the DNS CacheThe SBC clears a DNS cache for:
- Specific DNS group
- FQDN (Full match or substring)
- Full cache on SBC
In case of FQDN, there are two scenarios:
- To clear a particular record from the cache, request should match DNS group, FQDN and the record type.
- To clear a domain from the cache, request should match DNS group name and sub-string from the domain.
Anchor |
---|
| Override Time To Live (TTL) |
---|
| Override Time To Live (TTL) |
---|
|
Override Time To Live (TTL)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.
Manual DNS Query
SBC is enhanced to perform 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, SBC creates a new entry.
Two types of manual queries apply:
- Manual queries including the server : In this type, query is sent to the particular server. If the response is received, it updates the cache and if it ist not received, then it throw the error message.
- Manual queries which do not include the server: In this type, query is sent to the first server in the list. If response is not received from that server, then it tries the next server until it receives the response.
Note |
---|
DNS group is configured with eight DNS servers. |
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.
Loss on DNS Service
SBC is enhanced to raise an alarm when the server is blacklisted.
A server is blacklisted when:
- TCP connection with the DNS server cannot be established after a configured number of retries
- No response is received from the DNS server for TCP, despite the connection being established
- No response is received from the DNS server for UDP, after a configured number of retries
In all the above scenarios, SBC raises the following alarms:
- sonusSbxDnsServerBlacklistedNotification
- sonusSbxDnsServerRecoveredNotification