Skip to main content
DNS SRV (Service) records enable automatic failover and load distribution for SIP connections by resolving to multiple Telnyx signaling IPs with priority and weight parameters.

SRV record format

Telnyx SRV records follow RFC 2782 DNS SRV specification:
Example:

Parameters

Regional FQDNs

Configure SRV records to point to the Telnyx region closest to the user’s infrastructure: For the most current IP addresses and additional regions, see sip.telnyx.com.

Configuration examples

Basic configuration

Single SRV record pointing to US region:

TLS transport

For encrypted SIP signaling on port 5061:

Multi-region redundancy

Route to US as primary, EU as secondary:
Priority 10 (US) is preferred over priority 20 (EU).

Benefits over A records

Verification

Verify the user’s SRV record configuration:
Expected output shows multiple A records for the target FQDN:
Test resolution to IP addresses:

DNS provider configuration

Most DNS providers support SRV records through their control panel or API. Common DNS providers:
  • Route 53 (AWS): Record type “SRV”, value format 10 10 5060 sip.telnyx.com
  • Cloudflare: Record type “SRV”, configure service, protocol, priority, weight, port, target separately
  • Google Cloud DNS: Use gcloud dns record-sets create with --type=SRV
API example (AWS Route 53):

Failover behavior

SRV records work with Telnyx automatic failover:
  1. DNS query resolves sip.telnyx.com to both IP1 and IP2
  2. SIP INVITE sent to IP1 (primary)
  3. On timeout or error, retry to IP2 (secondary)
  4. If all IPs fail, attempt next priority SRV target (if configured)
See Failover and Retries for complete failover logic.

Troubleshooting

SRV record not resolving:
  • Verify trailing dot on target FQDN (sip.telnyx.com.)
  • Check TTL has expired if you recently updated
  • Confirm DNS propagation: dig @8.8.8.8 _sip._udp.example.com SRV
PBX not using SRV record:
  • Some PBX systems require explicit SRV lookup enablement
  • Configure PBX to use domain (example.com) not IP address
  • Check PBX logs for DNS query behavior
Unbalanced load distribution:
  • Verify equal weight values for balanced distribution
  • Some SIP stacks cache first resolved IP
  • Consider implementing client-side round-robin