Versions Compared

Old Version 1

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Add_workflow_for_techpubs
AUTH2UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cd5909df, userName='null'}
AUTH1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cb8305e9, userName='null'}
JIRAIDAUTHSBX-93273
REV5UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cd5909df, userName='null'}
REV6UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cd5909df, userName='null'}
REV3UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c7cc0040, userName='null'}
REV1UserResourceIdentifier{userKey=8a00a0c8674c8a57016753eb895d0007, userName='null'}


Panel

In this section:

Table of Contents
maxLevel4



Info
iconfalse

Related articles:

 



The

Spacevars
0series4
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 is associated with the DNS Group of 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 ( 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 

Spacevars
0product
 supports the following functionality:

  • 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
    Spacevars
    0product
    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

Spacevars
0product
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 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

Spacevars
0product
supports a local DNS cache. In this scenario, the 
Spacevars
0product
performs DNS queries against either external DNS servers or the local cache. The following DNS record types can be configured in the local cache:

  • A (Address)
  • SRV (Location of Services)
  • NS (Name Server)
  • NAPTR (Naming Authority Pointer) records

TCP Enhancement

The 

Spacevars
0product
supports all DNS queries over UDP from the DNS client with no option to configure the transport protocol for DNS servers. Additionally, the 
Spacevars
0product
 supports DNS servers over TCP using 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.

Info
iconfalse
titleNote

The SBC supports configuring:

  • One Transport Protocol per DNS server
  • Up to eight DNS servers per DNS group
  • 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
0Figure
1TCP Connection

Support for TCP Fallback

The 

Spacevars
0product
sends DNS queries as UDP messages to serve DNS requests. UDP messages are preferred over TCP messages as TCP connections 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 protocol to resolve the request.

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:

Caption
0Figure
1TCP Fallback


Info
titleInfo

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.

Include Page
TCP_Fallback_Behavior
TCP_Fallback_Behavior

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

Spacevars
0product
supports the following functionalities:

AnchorFlush the DNS CacheFlush the DNS Cache

functionalities described below.

Flush the DNS Cache

The

Spacevars
0product
clears a DNS cache for:

  • Specific DNS group
  • FQDN (Full match or substring)
  • Full cache on 
    Spacevars
    0product

The 

Spacevars
0product
supports the following FQDN scenarios:

  1. To clear a particular record from the cache, the request must match the DNS group, FQDN, and record type.
  2. To clear a domain from the cache, the request must match the 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)

Spacevars
0product
  overrides the TTL value with a 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

The 

Spacevars
0product
performs a manual query when the cache receives updates of the IP address updates, TTL and port in response to the query sent to the server.. The
Spacevars
0product
updates the response if the record is already present; otherwise, it creates a new entry.

Two types of manual queries:

  • Manual queries including the server : The 
    Spacevars
    0product
    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

    Spacevars
    0product
    sends the query to the first server in the list. If the
    Spacevars
    0product
    does not receive the response from that server, it continues to the next server, and so on, until it receives the response.

    Info
    iconfalse
    titleNote

    The SBC supports up to eight DNS servers in a DNS group.  


If the 

Spacevars
0product
does not receive a response to the DNS query, it displays an error after a configurable timeout. The manual DNS query supports resending a request over TCP if the response is received with the  TC (truncation flag) set, and if TCP Fallback is enabled

Loss on DNS Service

The 

Spacevars
0product
raises an alarm when the server is blacklisted.

The 

Spacevars
0product
blacklists the server when one of the following conditions exist:

  • 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 

Spacevars
0product
generates the sonusSbxDnsServerBlacklistedNotification alarm. The alarm is cleared by the sonusSbxDnsServerRecoveredNotification alarm. 


For more information, refer to Domain Name Server (DNS) Alarms.

DNS Service Record (SRV) pathCheck

The 

Spacevars
0product
 supports the following SRV functionality:

  • Service Record (SRV) lookup while performing DNS query for FQDN based targets. The 
    Spacevars
    0product
    tracks the FQDN based IP peers that are configured using SRV and A/AAAA records. This provides more flexibility with the 
    Spacevars
    0product
    tracking the FQDN peers based on SRV records and corresponding A/AAAA record combinations. Using this method, the 
    Spacevars
    0product
    reports the availability status of the FQDN peers for each combination individually.
  • SIP OPTIONS ping. The
    Spacevars
    0product
    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. The
    Spacevars
    0product
    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 
    Spacevars
    0product
    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 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.

    Info
    iconfalse
    titleNote

     For FQDN based IP peers attached with the pathCheck profile, A/AAAA query is already supported by the pathCheck task. The

    Spacevars
    0product
    supports 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 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 
    Spacevars
    0product
    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.
Info
iconfalse
titleNote

 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 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

The 

Spacevars
0product
prefers DNS over UDP when the UDP payload limit is 512 bytes. The Extended Domain Name System (eDNS) improves the scalability of DNS. With this eDNS support, the SBC supports the maximum UDP payload size. This avoids the truncated UDP responses, which in turn try to re-enter over TCP.

Error Response (except for 0) Towards the DNS

If the 

Spacevars
0product
receives an error response (except for 0) toward the DNS query, it raises an alarm to notify the user to resolve the IP address of the far end carrier.

The 

Spacevars
0product
uses the DNS Server IP as a key in the alarm.

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 

Spacevars
0product
does not raise an alarm for each of the RCODE errors that the DNS server observes ,and subsequently limits, the rate of alarms generated for a given server.

The 

Spacevars
0product
generates INFO logs which include Server IP, FQDN, Record Type and RCODE values for every RCODE error that it encounters.

View the INFO logs by entering the following command:

Code Block
% show table alarm current status

For more information, refer to DNS - DNS Group and DNS Group - CLI

Pagebreak