In this section:
The
ipInterfaceGroup
( that the DNS group uses) is restricted to the same addressContext
as the DNS Group. When configuring the DNS group, the SBC associates the IP Interface Group of the same Address Context only.Within a DNS server group, each server has both a priority and a weight. The SBC sends the requests to the server with highest priority (lower value) first. It uses the servers with lower priority when all higher priority servers are marked unavailable due to previous timeouts. If multiple servers of the same priority exist, requests are load-balanced across servers in proportion to their weights.
The
- 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
- Using the following DNS queries to gather domain information:
- DNS NS—Redirects DNS query to other DNS servers
- DNS NAPTR—Gathers the transport information
- DNS SRV—Gathers the port information
- DNS A record—Gathers the address
- Maintaining a DNS Cache, where it stores the DNS records received from DNS servers.The Unable to show "metadata-from": No such page "_space_variables"supports removing cached records and changing Time To Live (TTL)
- ENUM queries to DNS servers for call routing
- DNS queries using both UDP and TCP transport and this is configurable
- Manual DNS queries
Locating a SIP Server Using DNS
The
When an SIP endpoint (such as UAC) sends a request to a resource identified by a SIP or Secure SIP (SIPS) URI, it resolves that URI into the IP address, port, and transport protocol. This URI either identifies the desired resource where the request is targeted the URI in the Request-URI), or it identifies an intermediate hop towards that resource (the URI in the Route header).
For a SIP call with an unknown transport protocol, or if the URI cannot derive the transport protocol, the SIP endpoint performs a Naming Authority Pointer (NAPTR) query for the domain name in the URI. After the transport protocol is found from the records returned by the NAPTR query, the client uses the Location of Services (SRV) query on the protocol to target host FQDN and port number. Finally, the client performs an Address (A) record query to resolve the domain names returned by the SRV query to obtain the IP address of the server.
Local Cache
For network configurations where SIP Server domain resolution is not available from external DNS servers, the
- A (Address)
- SRV (Location of Services)
- NS (Name Server)
- NAPTR (Naming Authority Pointer) records
TCP Enhancement
The
transportProtocol
configuration object with two options: udp
or tcp
. The default value is udp
. The flag tcpFallback
supports TCP fallback when the configured protocol is UDP. The default value is disabled
.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.
The figure below depicts DNS support when the transport protocol for the DNS server is configured as TCP.
TCP Connection
Support for TCP Fallback
The
Enable the tcpFallback
flag 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 enabled, the tcpFallback
and the DNS client receive the TC flag in the response over UDP, and 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:
TCP Fallback
To support backward compatibility, disable the tcpFallback
flag. The default value is disabled. 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.
The current TCP Fallback feature does the following:
- Enables the SBC to reject UDP INVITE with PDU size more than configured MTU value with “513 Message Too Large”.
- It is up to the far-end to recognize this “513 Message Too Large” and switch to TCP.
- This feature does not enable the SBC itself to fall back to TCP on receiving “513 Message Too Large” from far-end.
- Once the transport protocol is determined by the application layer in SBC, if the size of the INVITE PDU is increased later (say through SMM rules), the SBC will NOT be able to change the transport protocol to TCP, instead the INVITE is sent using the already determined transport protocol irrespective of the MTU Size configured.
TCP connection Pool
The DNS client maintains the TCP connections in the TCP Pool in order to enable the DNS client to reuse those TCP connections to deliver the DNS query 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
Flush the DNS Cache
The
- Specific DNS group
- FQDN (Full match or substring)
- Full cache on Unable to show "metadata-from": No such page "_space_variables"
The
- To clear a particular record from the cache, the request must match the DNS group, FQDN, and record type.
- To clear a domain from the cache, the request must match the DNS group name and sub-string from the domain.
Override Time To Live (TTL)
Manual DNS Query
The
Two types of manual queries:
- Manual queries including the server : The Unable to show "metadata-from": No such page "_space_variables"sends the query to the specific server. If the SBC receives the response, it updates the cache; otherwise, it generates an error message.
Manual queries which do not include the server: The
Unable to show "metadata-from": No such page "_space_variables"sends the query to the first server in the list. If theUnable to show "metadata-from": No such page "_space_variables"does not receive the response from that server, it continues to the next server, and so on, until it receives the response.
If the
Loss on DNS Service
The
The
- cannot establish the TCP connection with the DNS server after a configured number of retries
- does not recieve a response from the DNS server for TCP, despite the connection being established
- does not receive a response from the DNS server for UDP, after a configured number of retries
In the above scenarios, the
For more information, refer to Domain Name Server (DNS) Alarms.
DNS Service Record (SRV) pathCheck
The
- Service Record (SRV) lookup while performing DNS query for FQDN based targets. The Unable to show "metadata-from": No such page "_space_variables"tracks the FQDN based IP peers that are configured using SRV and A/AAAA records. This provides more flexibility with theUnable to show "metadata-from": No such page "_space_variables"tracking the FQDN peers based on SRV records and corresponding A/AAAA record combinations. Using this method, theUnable to show "metadata-from": No such page "_space_variables"reports the availability status of the FQDN peers for each combination individually.
- SIP OPTIONS ping. The Unable to show "metadata-from": No such page "_space_variables"sends the SIP OPTIONS request periodically to the configured IP peer (both IPv4 and IPv6 FQDN are supported) to check the status and discover new capabilities. TheUnable to show "metadata-from": No such page "_space_variables"sends this OPTIONS request using the Signaling Port of the zone configured for the peer. The OPTIONS ping feature verifies the peer-to-peer connectivity, and if required, enable it on an existing IP peer object.
- Configuring the frequency of OPTIONS requests. If the peer does not respond after a configurable number of consecutive OPTIONS timeout, the Unable to show "metadata-from": No such page "_space_variables"declares it as down and does not send any new calls to this peer. While the peer is down, the OPTIONS based pinging continues. After a configurable number of consecutive successful OPTIONS transactions, The peer is recovered and UP.
To support this feature, the default value ofhostPort
configuration underipPeer
option is updated topathCheck
5060
. To enable this feature, sethostPort
underipPeer
option topathCheck
0
.
When the
pathCheck
profile is attached to an FQDN based IP peer withhostPort
set to0
, thepathCheck
task performs SRV lookup to resolve the port numbers. The resolved port numbers are used to send OPTIONS ping to the IP peer.
- When the
pathCheck
profile is attached to an FQDN based IP peer configured with ahostPort
(other than the value0
), thepathCheck
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. ThepathCheck
task then continues 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:
- When an A/AAAA query for a given SRV record returns multiple A or AAAA records, those records are saved and processed. The Unable to show "metadata-from": No such page "_space_variables"sends the OPTIONS ping to all resolved IP addresses of the given SRV record, and repeats the same process for the next SRV record, performing an A/AAAA query until all SRV records complete.
For example, the pathCheck
task performs an SRV query for a given FQDN target, and two SRV records are returned: SRV1 and SRV2. The records are in the same order, after sorting, based on the weight and priority.
The SBC then sends an A or AAAA query for SRV1, followed by SRV2. Assume that the SRV query resulted in two A records.
At this point, there are total of two SRV records with two A records each. The pathCheck
task now sends an OPTIONS ping to all of 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 the pathCheck
task tries the multiple IP Address/Port combinations:
- if 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.
If a DNS query for an FQDN target fails (error, timeout, or no answer records), the pathCheck
task retries the DNS query after the configured retry duration 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.
Extended DNS (eDNS) Support
Error Response (except for 0) Towards the DNS
If the
The
If the alarm is raised for the current RCODE error, it displays the following fields:
- DNS Server IP
- DNS Zone Name
- RCODE Error value
- FQDN
- Record type that causes the RCODE
If the SBC observes the RCODE error within the configured monitor interval, then the alarms displays only the DNS server IP and DNS Zone name.
Even though the DNS server observes multiple RCODE errors, it generates a single alarm for that DNS server. In other words, the
The
View the INFO logs by entering the following command:
% show table alarm current status
For more information, refer to DNS - DNS Group and DNS Group - CLI.
Specifying a DSCP Value in DNS Queries
The SBC provides an option, on a per-DNS-server basis, to specify the Differentiated Services Code Point (DSCP) value that the SBC sends in the IP headers of DNS queries. A DSCP value is a packet header value in the range of 0 to 63 that classifies network traffic into different priority levels. For example, DSCP values are used to request high priority or best effort delivery for traffic.
The following example shows the syntax for specifying a DSCP value within DNS server configuration.
% set addressContext <address context name> dnsGroup <dns group name> server <dns server name> dscpValue <0-63>
For more information on DNS server configuration, refer to DNS Group - CLI.