DNS on the OCSBC

DNS service is best known for providing resolution of internet domain names to IP addresses. Domain names are easy to remember, but connections require IP addresses. DNS deployments can also provide more comprehensive services, if required. For example, the a DNS client may need the resolution of multiple IP addresses to a single domain name, or the types of service provided by a given server. The Oracle® Enterprise Session Border Controller (ESBC) uses DNS predominantly for resolving FQDNs to IP addresses so that it can support sessions.

When configured, the ESBC performs DNS client functions per RFC1034 and RFC1035. The user can define one primary DNS server and two backup DNS servers for the ESBC to query a domain for NAPTR (service/port), SRV (FQDN), AAAA (IPv6), and A (IP address) information. A common example of the ESBC using DNS is to locate a SIP server via server location discovery, as described in RFC 3263. An applicable context is identifying a callee so the ESBC can place a call.

There are multiple reasons for the ESBC to query a DNS server. In each case, the ESBC follows this high level procedure:

The system determines the egress realm.
The system identifies the egress network interface.
From the egress network interface, the system refers to the configured DNS server(s).
The system issues the DNS query to the primary server, then any configured backup servers, based on the function and the initial information it has.
The system performs recursive lookups or subsequent queries based on, for example, information provided in NAPTR resource responses, until it has one or more resolutions for the FQDN.
The system continues processing using the resolved FQDN(s) or indicates it cannot reach that FQDN.

Note:

DNS queries may require host routes.

The ESBC also has a DNS Application Layer Gateway (ALG) function that operates independently of its client function. See the DNS ALG Chapter in this document for information about using this ALG.

Closely related to DNS, ENUM service also provides a method of defining a target endpoint, translating E.164 phone numbers to FQDNs. The ESBC uses configured ENUM objects for routing calls. ENUM uses Naming Authority Pointers (NAPTR) records defined in RFC 2915 in order to identify available ways or services for contacting a specific node identified through the E.164 number. See the Session Routing and Load Balancing chapter for information on ENUM services and configuration.

The ESBC can cache NAPTR, SRV and A records to speed up DNS and ENUM query processes. The user configures the applicable enum-config to cache these records, providing ENUM and, when configured, DNS with applicable resolutions without having to re-query a server. These resolutions become available to all internal lookup processes that may be generated within the ESBC.

DNS Configuration

DNS configuration includes procedures to the network-interface, realm-config, and session-agent elements.

To make DNS operational, configure addressing that is version compatible to the network-interface address on the network interface itself.

Access the network-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-interface
ORACLE(network-interface)

dns-ip-primary—Set the first DNS server with which the interface conducts query procedures.
dns-ip-backup1—Set the second DNS server with which the interface conducts query procedures should the first server fail.
dns-ip-backup2—Set the third DNS server with which the interface conducts query procedures should the second server fail.

The system performs DNS query procedures with these servers every time processing encounters an FQDN for which the system needs resolution. After booting up the system, it queries dns-ip-primary for resolutions. It queries dns-ip-backup1 if dns-ip-primary fails, and queries dns-ip-backup2 if dns-ip-backup1. The system returns to using dns-ip-primary if the second backup fails or you reboot the system.

Review the ensuing sections and configure DNS components to refine DNS operation to your environment, including interface, realm, session agent, and ENUM operation refinement.

Retransmission Logic

The retransmission of DNS queries is controlled by three timers. These timers are derived from the configured DNS timeout value and from underlying logic that the minimum allowed retransmission interval should be 250 milliseconds; and that the Oracle® Enterprise Session Border Controller should retransmit 3 times before timing out to give the server a chance to respond.

Init-timer is the initial retransmission interval. If a response to a query is not received within this interval, the query is retransmitted. To safeguard from performance degradation, the minimum value allowed for this timer is 250 milliseconds.
Max-timer is the maximum retransmission interval. The interval is doubled after every retransmission. If the resulting retransmission interval is greater than the value of max-timer, it is set to the max-timer value.
Expire-timer: is the query expiration timer. If a response is not received for a query and its retransmissions within this interval, the server will be considered non-responsive and the next server in the list will be tried.

The following examples show different timeout values and the corresponding timers derived from them.

timeout >= 3 seconds
Init-timer = Timeout/11
Max-Timer = 4 * Init-timer
Expire-Timer = Timeout
timeout = 1 second
Init-Timer = 250 ms
Max-Timer = 250 ms
Expire-Timer = 1 sec
timeout = 2 seconds 
Init-Timer = 250 ms
Max-Timer = 650 ms
Expire-Timer = 2sec

DNS Support for IPv6

The Oracle® Enterprise Session Border Controller supports the DNS resolution of IPv6 addresses; in other words, it can request the AAAA record type (per RFC 1886) in DNS requests. In addition, the Oracle® Enterprise Session Border Controller can make DNS requests over IPv6 transport so that it can operate in networks that host IPv6 DNS servers.

For mixed IPv4-IPv6 networks, the Oracle® Enterprise Session Border Controller follows these rules:

If the realm associated with the name resolution is an IPv6 realm, the Oracle® Enterprise Session Border Controller will send the query out using the AAAA record type.
If the realm associated with the name resolution is an IPv4 realm, the Oracle® Enterprise Session Border Controller will send the query out using the A record type.

In addition, heterogeneous address family configuration is prevented for the dns-ip-primary, dns-ip-backup1, and dns-ip-backup2 parameters.

DNS Transaction Timeout

This section explains how to configure the DNS transaction timeout interval on a per network-interface basis. You can currently configure the Oracle® Enterprise Session Border Controller with a primary and two optional backup DNS servers. The Oracle® Enterprise Session Border Controller queries the primary DNS server and upon not receiving a response within the configured number of seconds, queries the backup1 DNS server and if that times out as well, then contacts the backup2 DNS server.

DNS Transaction Timeout Configuration

To configure DNS transaction timeout:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type system and press Enter to access the system-level configuration elements.
```
ORACLE(configure)# system
```
Type network-interface and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(system)# network-interface
ORACLE(network-interface)#
```
From this point, you can configure network interface parameters. To view all network interface parameters, enter a ? at the system prompt.
dns-timeout—Enter the total time in seconds you want to elapse before a query (and its retransmissions) sent to a DNS server would timeout. The default is 11 seconds. The valid range is:
- Minimum—1
- Maximum—999999999.
  
  If a query sent to the primary DNS server times out, the backup1 DNS server is queried. If the query times out after the same period of time elapses, the query continues on to the backup2 DNS server.
Save and activate your configuration.

DNS Entry Maximum TTL

DNS maximum time to live (TTL) is user-configurable and complies with RFCs 1035 and 2181.

One can set the DNS maximum TTL on the Oracle® Enterprise Session Border Controller permitting the DNS entry information to be held until that time is exceeded. One can specifiy the dns-max-ttl parameter per network interface and/or to support the DNS ALG feature. The default value is 86400 seconds (24 hours). When the Oracle® Enterprise Session Border Controller configured maximum value has been exceeded, the DNS TTL value is set to the configured maximum and a log entry is written. Otherwise the Oracle® Enterprise Session Border Controller honors the lower value in the DNS response. The Oracle® Enterprise Session Border Controller restricts all DNS entries minimum TTL value of 30 seconds, which the system's implementation of SIP requires.

DNS Entry Max TTL Configuration per Network Interface

Set parameter for DNS entry maximum time to live (TTL) value per network interface.

Access the network-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-interface
ORACLE(network-interface)

Select the network-interface object to edit.

ORACLE(network-interface)# select
<name>:<sub-port-id>:
1: wancom0:0 ip=10.0.0.2 gw=10.0.4.1

selection: 1
ORACLE(network-interface)#

dns-max-ttl— set to the maximum time for a DNS record to remain in cache.
- Minimum: 30— The lowest value to which the dns-max-ttl parameter can be set (in seconds)
- Maximum: 2073600— The maximum value (in seconds) for which the dns-max-ttl parameter can be set.
- Default: 86400— The value in seconds which the system uses by default.
Type done to save your configuration.

DNS-SRV Session Agent Recursion Error Handling

When a session request is sent from the Oracle® Enterprise Session Border Controller to a session agent, and an error response is received (or a transport failure occurs), the Oracle® Enterprise Session Border Controller attempts to reroute the message through the list of dynamically resolved IP addresses. The SBC can be configured to resend session requests through the list of IP addresses under more failure conditions.

This feature concerns the case when a session agent is configured with an FQDN in the hostname parameter and the dns-load-balance or ping-all-addresses option is configured. This configuration sets up the load balancing / redundancy behavior for the SBC to use all addresses returned in the SRV/A-record for that session agent. In previous versions of the SBC software, only when a 503 failure from the SA was received would the SBC resend the session request to the next dynamically resolved IP address (on the SRV/A record list).

By adding the recurse-on-all-failures option to a session agent, the Oracle® Enterprise Session Border Controller will resend a session request to the next address on the list after a 4xx or 5xx failure response has been received from a session agent.

If the SBC receives a failure response from the session agent, and the number of that failure is configured in the stop-recurse parameter, no further session requests will be forwarded to additional addresses from the SRV/A record list. The error message will be forwarded back to the UA.

Interface and Realm Support of DNS Servers

You can configure DNS functionality on a per-network-interface, or per-realm basis. Configuring DNS servers for your realms means that you can have multiple DNS servers in connected networks. In addition, this allows you to specify which DNS server to use for a given realm because the DNS might actually be in a different realm with a different network interface.

This feature is available for SIP only.

To configure realm-specific DNS in the ACLI:

dns-realm—Enter the name of the network interface that is configured for the DNS service you want to apply in this realm. If you do not configure this parameter, then the realm will use the DNS information configured in its associated network interface.

DNS Re-query over TCP

The Oracle® Enterprise Session Border Controller DNS supports the truncated (TC) header bit in DNS responses as defined in RFC 2181 and a re-query over TCP.

DNS queries start on UDP ports with the limit of 512 bytes. Longer responses require that the result not be cached and that the truncated (TC) header bit is set. After receiving a DNS response with the TC header set, the Oracle® Enterprise Session Border Controller will initiate a re-query to the DNS server over TCP. The option dns-tcp-for-truncated-response in realm-config can be set to no to disable this behavior.

DNS Re-query over TCP Config

Enable feature to support setting the truncated header bit and initiating a DNS re-query over TCP.

Access the realm-config configuration element.

ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#

Select the realm-config object to edit.

ORACLE(realm-config)# select
identifier:
1: realm01 left-left:0 0.0.0.0

selection: 1
ORACLE(realm-config)#

dns-tcp-for-truncated-response— Set the options parameter by typing options, a Space, a plus sign (+), the option name, and queal sign (=) and then yes or no and then press Enter. The default behavior is to set the truncated header bit and initiate a DNS re-query over TCP.
```
ORACLE(realm-config)# option +dns-tcp-for-truncated-response=no
```
Type done to save your configuration.

Configurable DNS Response Size

When a realm is used for DNS queries, the Oracle® Enterprise Session Border Controller can accept UDP DNS responses configurable up to 65535 bytes.

This functionality is useful when large numbers of SRV records will be returned in a DNS query thereby eliciting a large-sized DNS response. This behavior should be configured on the realm where the DNS servers are located.

To extend the valid DNS response size, add the dns-max-response-size option to the realm configuration. If this option is not configured, the Oracle® Enterprise Session Border Controller uses the default maximum response size of 512 bytes, and information past the 512th byte will be ignored.

Do not add the dns-max-response-size option to realms where DNS queries are not being performed. Ensure that the realm where this option is configured is referenced in a transport realm's dns-realm parameter. Only the local value of the dns-max-response-size option is used for the realm; there is no inheritance of this value.

DNS Response Size Configuration

Access the realm-config configuration element.

ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#

Select the realm-config object to edit.

ORACLE(realm-config)# select
identifier:
1: realm01 left-left:0 0.0.0.0

selection: 1
ORACLE(realm-config)#

Add the dns-max-response-size option to the realm with a value between 513 — 65535.
```
ORACLE(realm-config)#options dns-max-response-size=4196
```
Type done to save your configuration.

Disabling Recursive DNS Queries for ENUM

By default, the Oracle® Enterprise Session Border Controller (ESBC) requests DNS query with recursive searches. The Telecommunication Technology Committee's Standard JJ-90.31 specifies that ENUM DNS queries be performed iteratively. The ESBC complies with this requirement when remote (server) recursive searches are disabled. You can disable recursive searches on a per enum-config basis.

Remote recursive DNS queries instruct DNS servers to query other servers on behalf of the requester to resolve the query. Alternatively, the DNS server can return a list of other DNS servers for the requester to query itself. RFC 1035 specifies that setting the Recursive Data (RD) bit in the DNS query to 1 requests a remote recursive DNS. Setting RD to 0 requests lists of other servers.

By default, the ESBC sets the RD bit to 1. The user can disable this recursion by configuring the enum-config element's remote-recursion parameter to disabled.

This feature affects queries associated with the enum-config:

Health queries
CNAM subtype
ENUM query

Changing this parameter's operational value does not invalidate any current DNS cache entry. The ESBC uses the cached information until the cache is aged.

DNS Server Status via SNMP

The Oracle® Enterprise Session Border Controller monitors the status of all configured DNS servers used by a SIP daemon. If a DNS server goes down, a major alarm is sent. If all DNS servers used by a SIP daemon are down, a critical alarm is sent. The apAppsDnsServerStatusChangeTrap is sent for both events.

You can poll the status of a DNS server using the apAppsDNSServerStatusTable in the ap-apps.mib.

Once the apAppsDnsServerStatusChangeTrap has been sent, a 30 second window elapses until the server status is checked again. At the 30 second timer expiration, if the server is still down, another trap and alarm are sent. If the server has been restored to service, the apAppsDnsServerStatusChangeClearTrap is sent.