...
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.
...
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.
...
DNS Cache Management and Override TTL
The SBC The is enhanced in this release to provide the ability to:
...
| Anchor |
|---|
| Flush the DNS Cache |
|---|
| Flush the DNS Cache |
|---|
|
Flush the DNS Cache
The SBC
clears a DNS cache for:
- Specific DNS group
- FQDN (Full match or substring)
- Full cache on SBCon
In case of FQDN, there are two scenarios:
...
| 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 the
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
is SBC is enhanced to raise an alarm when the server is blacklisted.
...
- 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
generates the following alarms:
- sonusSbxDnsServerBlacklistedNotification
- sonusSbxDnsServerRecoveredNotification
DNS Service Record (SRV) pathCheck
Currently, when the pathCheck target is configured as FQDN,
performs only A or AAAA lookup. This feature enhances to support Service Record (SRV) lookup while performing DNS query for FQDN based targets. It enables to support tracking of FQDN based IP peers that are configured using SRV and A/AAAA records. This provides more flexibility as tracks the FQDN peers based on SRV records and corresponding A/AAAA record combinations. Using this, reports the availability status of the FQDN peers for each combination individually. already supports the SIP OPTIONS ping feature. SIP OPTIONS request is periodically sent to a configured IP peer (both IPv4 and IPv6 FQDN are supported) to check the status and discover new capabilities. The OPTIONS request is sent using the Signaling Port of the zone configured for the peer. The OPTIONS ping feature is used to verify peer-to-peer connectivity, and if required, is enabled on an existing IP peer object.The frequency of OPTIONS request is configurable. If the peer does not respond after a configurable number of consecutive OPTIONS timeout, it is declared as down and no new calls are sent to this peer. While the peer is down, OPTIONS based pinging continues. The peer is considered UP (recovered) after a configurable number of consecutive successful OPTIONS transactions.
To support this feature, the default value of 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.
| Note |
|---|
For FQDN based IP peers attached with the pathCheck profile, A/AAAA query is already supported by the pathCheck task. is enhanced to support SRV, if hostPort is set to 0. |
- When the
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:
- When SRV query returns multiple SRV records, the
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:
- If multiple A or AAAA records are returned during A/AAAA query for a given SRV record then all those records are saved and tried. OPTIONS ping is sent to all the resolved IP addresses of a given SRV record. It then continues in the same way with the next SRV and performs A/AAAA query until all the SRV records are completed.
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. then sends A or AAAA query for SRV1 followed by SRV2. Assume that SRV query resulted in two A records. There are total of 2 SRV records with 2 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 even one IP/Port combination is reachable, then the FQDN target is considered as UP.
- if all the IP/Port combinations are un-reachable, then the FQDN target is considered as DOWN.
| Note |
|---|
The pathCheck task internally sends notifications to registered tasks (such as ARS task) regarding FQDN target status change. Tasks registered with pathCheck receive the notification when a given FQDN target is UP or DOWN. This ensures that the task does not even attempt to send a call to the FQDN peer, which is DOWN.
|
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.