1. Configuration Guide
  2. STIR/SHAKEN Client
  3. Server Names as FQDNs

Server Names as FQDNs

You can configure the SBC to use FQDNs for STI-AS and STI-VS server to establish STIR/SHAKEN server pools using DNS.

The primary objective for establishing server pools for STI servers using FQDNs is to load balance the servers, assuming they resolve to more than one STI server address. When the SBC cycles through an FQDN-resolved pool, it attempts to reach each of the servers in the list using round robin. The system tracks these servers' availability using its circuit breaker configuration and the DNS TTL, the latter of which confirms each IP address' availability upon expiry.

Your configured FQDN may reside within a sti-group, or be present as one of the four sti-servers configured on your source object (session-agent, sip-interface or realm). The system performs its resolution process on configuration load or TTL expiry. Each time the system picks an FQDN, the system refers to its resolution list and uses round-robin to select the next available IP address.

You setup the SBC to use DNS services for STIR/SHAKEN deployments by configuring the "root" configurations in the sti-server using an FQDN as prefix instead of an IP address:

  • as-server-root—Applies to both modes
  • vs-server-root—Applies to both modes
  • div-as-server-root—Applies to 3GPP mode
  • div-vs-server-root—Applies to 3GPP mode

When configured as an FQDN, a root setting syntax specifying all detail looks like the following:

ORACLE (sti-server)#as-server-root MyAsServer1/StirShakenWeb/resources/v1/signing

Note:

If you do not specify a port for root configurations, the SBC uses port 80 for HTTP and port 443 for HTTPS

When the SBC uses FQDNs, it queries DNS for an A record (or AAAA record if you are using IPv6) to resolve/update the FQDNs on system bootup, configuration load, configuration activation, and TTL expiration. Upon resolution, the SBC:

  • Enforces the applicable constraints, including realm max-burst-rate and max-sustain-rate, for each sti-server regardless of the number of IP addresses resolved
  • Uses the round-robin strategy to load balance requests to each sti-server
  • Establishes and maintains a circuit-breaker for each resolved address
  • Uses TTL to trigger new queries to DNS to resolve/update the FQDNs

Note:

An FQDN entry operates the same whether it resolves to a single or multiple IP addresses.

Monitoring FQDN-Resolved Server Status

The SBC maintains a circuit breaker for each of the IP address returned by the DNS Resolver as separate entities, creating their circuit breakers when the address gets used. If the system chooses an address that already has a circuit breaker associated, it re-uses that circuit breaker. Each circuit breaker monitors the status of the corresponding server instance and triggers the system to raise major and minor traps and alarms. The correlation of server object status and separate IP address availability depends on the number of addresses resolved to each server object:

  • If there is a single address associated with a server—The system generates a major alarm and trap when this circuit-breaker goes open (address unavailable).
  • If there are multiple addresses associated with a server—The system generates a minor alarm and trap when one circuit-breaker goes open (address unavailable), and there is at least one other circuit-breaker closed (address available).

    Whenever every circuit-breaker associated with a resolved FQDN is open, the system generates a major alarm and trap.

Server status also depends on the role configuration within your sti-server. You can configure a server to be an AS server, a VS server or both (default). Oracle recommends you configure your DIV root with the same IP or FQDN prefix used for the AS or VS root on the same device. If not:

  • If the configured role is STI-AS, and the as-server-root and div-as-server-root are configured with different IPs, then the system marks the sti-server as down if any one of the IP’s configured against as-server-root or div-as-server-root is down.
  • If the configured role is STI-VS, and the vs-server-root and div-vs-server-root are configured with different IPs, then the system marks the sti-server as down if any one of the IP’s configured against vs-server-root or div-vs-server-root is down.
  • If the configured role is both, and all root configurations have different IPs, the behavior includes:
    • If any of the IPs configured against as-server-root and div-as-server-root are down, the system marks the authentication service as down.
    • sti-server vs-server-root and div-vs-server-root are down, the system marks the verification service as down.