Edge & DNS Ops Guide

Configuring SRV records for SIP and XMPP services

Real-time communication protocols like SIP and XMPP rely heavily on DNS SRV records to dynamically route traffic across distributed endpoints. Properly configuring these records ensures high availability, weighted load balancing, and protocol-compliant failover for VoIP and instant messaging infrastructure. This guide provides exact zone syntax, provider-agnostic deployment steps, and immediate diagnostic workflows for DevOps and cloud engineering teams.

Key Implementation Points:

  • SRV records decouple service discovery from static IP addressing, enabling dynamic failover and proportional traffic distribution.
  • SIP and XMPP require strict adherence to RFC 3263 and RFC 6120 naming conventions to prevent client fallback failures.
  • Incorrect priority/weight values or missing TLS variants cause silent connection drops in production.
  • Validation requires authoritative DNS querying and protocol-specific handshake testing before routing traffic.

SRV Record Anatomy for Real-Time Protocols

The SRV record format follows a strict structure: _service._proto.name. TTL class SRV priority weight port target. Understanding this syntax is critical for mapping traffic correctly.

Priority dictates preference, where lower values receive traffic first. Weight determines proportional load distribution among records sharing identical priority values. SIP utilizes _sip._tcp and _sip._tls prefixes. XMPP relies on _xmpp-client._tcp and _xmpp-server._tcp.

For deeper context on zone hierarchy and resolver behavior impacts, review the broader DNS Fundamentals & Advanced Record Configuration framework. Always verify record propagation before deploying to production.

dig SRV _sip._tcp.example.com

Exact Syntax: SIP SRV Configuration

Production SIP trunking requires explicit primary, failover, and secure routing entries. Misconfigured targets or missing TLS records trigger immediate client rejection.

; Primary SIP
_sip._tcp.example.com. 300 IN SRV 10 60 5060 sip-primary.example.com.
; Failover SIP
_sip._tcp.example.com. 300 IN SRV 20 0 5060 sip-backup.example.com.
; Secure SIP (SIPS)
_sip._tls.example.com. 300 IN SRV 10 60 5061 sip-primary.example.com.

Ensure all target hostnames resolve directly to A or AAAA records. CNAME targets violate RFC 1034 and break SIP stack resolution. Validate your zone entries immediately after creation.

host -t SRV _sip._tcp.example.com

Exact Syntax: XMPP SRV Configuration

XMPP routing splits client-to-server and server-to-server traffic across distinct service names. Clients strictly follow RFC 6120 lookup sequences.

; Client routing
_xmpp-client._tcp.example.com. 300 IN SRV 5 0 5222 xmpp.example.com.
; Server routing
_xmpp-server._tcp.example.com. 300 IN SRV 5 0 5269 xmpp.example.com.

Use weight values (e.g., 10 30 vs 10 70) for proportional traffic splitting across federated nodes. Missing _xmpp-client records force clients into direct A/AAAA resolution, bypassing load balancers. For algorithmic breakdowns of priority/weight interactions, consult Advanced SRV & MX Routing.

nslookup -type=SRV _xmpp-server._tcp.example.com

Implementation in DNS Providers & Edge CDNs

Translating raw zone syntax into UI or API configurations requires platform-specific adjustments. CDNs do not proxy SRV traffic; deploy records at the authoritative DNS level only.

Cloudflare: Select the SRV type in the DNS dashboard. You must disable the proxy toggle. SRV records cannot be routed through the CDN proxy layer. AWS Route 53: Create record sets with explicit priority, weight, and port fields. Avoid using Alias targets for SRV types to prevent resolution loops. Bind9/PowerDNS: Zone files require trailing dots on all FQDNs. Omitting them causes the zone origin to append automatically, corrupting the target hostname. Edge Routing: CDN WAFs ignore SRV queries entirely. Route SIP and XMPP traffic directly to origin IPs or dedicated VoIP/IM edge nodes.

curl -s https://api.cloudflare.com/client/v4/zones/{id}/dns_records \
 -H 'Authorization: Bearer {token}' \
 -d '{"type":"SRV","name":"_sip._tcp","content":"10 60 5060 sip.example.com"}'

Validation & Diagnostic Workflows

Post-deployment verification requires authoritative querying and direct port testing. Symptom: Clients report connection timeouts. Root Cause: DNS cache holds stale records or target ports are firewalled. Resolution: Flush local cache, verify authoritative response, and test TCP/UDP handshakes.

# Authoritative check
dig @ns1.provider.com SRV _sip._tcp.example.com +short

# Trace resolution path
dig +trace SRV _xmpp-client._tcp.example.com

# Verify port binding
nc -zv sip-primary.example.com 5060
openssl s_client -connect sip-primary.example.com:5061

Monitor application logs for SRV lookup failed or fallback to A record warnings. These indicate malformed entries or resolver timeouts.

dig SRV _sip._tcp.example.com +noall +answer

Configuration Examples

Standard SIP SRV with weighted failover

_sip._tcp.example.com. 300 IN SRV 10 70 5060 sip-node1.example.com.
_sip._tcp.example.com. 300 IN SRV 10 30 5060 sip-node2.example.com.
_sip._tcp.example.com. 300 IN SRV 20 0 5060 sip-dr.example.com.

Priority 10 records share a 70/30 traffic split. Priority 20 acts as a cold standby. TTL 300s balances cache freshness with query load.

XMPP Client & Server SRV pair

_xmpp-client._tcp.example.com. 300 IN SRV 5 0 5222 im.example.com.
_xmpp-server._tcp.example.com. 300 IN SRV 5 0 5269 im.example.com.

Standard ports 5222 (client) and 5269 (server-to-server). Priority 5 ensures precedence over default port 5222 fallback. Weight 0 disables proportional distribution for single-node routing.

Route 53 JSON API payload for SRV

{
 "ChangeBatch": {
 "Changes": [{
 "Action": "UPSERT",
 "ResourceRecordSet": {
 "Name": "_sip._tls.example.com.",
 "Type": "SRV",
 "TTL": 300,
 "ResourceRecords": [{"Value": "10 60 5061 sip-tls.example.com."}]
 }
 }]
 }
}

AWS Route 53 API format. Note the trailing dot in Name and Value to prevent domain suffix duplication. UPSERT ensures idempotent deployments in CI/CD pipelines.

Edge Cases & Warnings

CNAME at SRV Target Symptom: Connection timeouts or immediate fallback failures. Root Cause: RFC 1034 violation. Many SIP/XMPP clients explicitly reject CNAME targets during resolution. Resolution: Always point SRV targets directly to A/AAAA records. Use DNS flattening or ALIAS/ANAME records at the apex if necessary, but ensure they resolve to IPs before SRV evaluation.

Missing _sip._tls or STARTTLS Fallback Symptom: Clients return TLS required errors despite valid _sip._tcp records. Root Cause: Modern clients enforce encryption by default. Unencrypted records are ignored. Resolution: Deploy _sip._tls records alongside or instead of _sip._tcp. Verify target supports TLS on port 5061 or STARTTLS on 5060.

CDN Proxy Enabled on SRV Records Symptom: Complete DNS resolution failure and blocked UDP/TCP streams. Root Cause: CDNs proxy HTTP/HTTPS traffic only. Enabling proxy on SRV breaks standard DNS routing. Resolution: Disable CDN proxy (DNS-only mode) for all SRV records. Route traffic directly to origin IPs or specialized VoIP/IM edge nodes.

TTL Too High During Failover Symptom: Traffic routes to dead nodes for hours after a PBX outage. Root Cause: Clients and resolvers cache SRV records based on the configured TTL. Resolution: Set TTL to 60-300s for SRV records. Implement health-check-driven DNS updates via API or use Anycast routing for faster convergence.

FAQ

Can I use CNAME records as SRV targets for SIP or XMPP? No. RFC 1034 and RFC 3263 explicitly forbid CNAMEs at SRV targets. Use A/AAAA records or DNS flattening to ensure protocol compatibility.

Why is my XMPP client ignoring my SRV records and connecting directly to the domain IP? Clients fall back to A/AAAA resolution if _xmpp-client._tcp SRV records are missing, malformed, or have excessively high TTLs. Verify exact naming convention and port mapping.

How do I distribute traffic evenly across multiple SIP proxies using SRV? Assign identical priority values and equal weight values (e.g., 10 50 for both). DNS resolvers will randomly distribute queries based on weight ratios.

Do edge CDNs support SRV record routing? No. CDNs operate at Layer 7 (HTTP/HTTPS) and do not proxy SRV, SIP, or XMPP traffic. Deploy SRV at the authoritative DNS level and route directly to origin or specialized VoIP/IM edge nodes.