How to test SIP DNS SRV failover before an outage
DNS SRV records only provide usable SIP resilience when the PBX queries them, honours their priority and can reach the alternate targets. Seeing two records in a DNS lookup is not a failover test.
Read the records correctly
_sip._tcp.example.net. 300 IN SRV 10 0 5060 sip-a.example.net.
_sip._tcp.example.net. 300 IN SRV 20 0 5060 sip-b.example.net.
Lower numerical priority is preferred. Weight distributes selection among targets with the same priority; it is not a second priority field. Each target must resolve to reachable addresses, and the transport and port must match the PBX and carrier design.
Record the healthy baseline
- DNS answers and time-to-live values;
- the target selected for registration or outbound calls;
- normal keepalive or registration behaviour;
- inbound and outbound media addresses; and
- the time required to establish a test call.
Run a controlled failure
Use the carrier’s test environment or an approved maintenance window. Remove reachability to one test target at a controlled boundary; do not alter public carrier DNS. Observe when the PBX declares failure, whether it performs a fresh lookup, which alternate it selects and how many calls fail before recovery.
| Check | Pass condition |
|---|---|
| Discovery | The PBX queries the intended NAPTR/SRV/A or AAAA chain |
| Selection | The expected priority and transport are used |
| Recovery | The alternate accepts registration or calls |
| Media | Two-way audio follows the alternate path |
| Return | Behaviour after the preferred target recovers is understood |
Measure the outage experienced by callers, not merely the DNS response. UDP failure detection, TCP connection loss and registration timers can produce very different recovery times.
Related: DNS and SRV for VoIP, VoIP failover and SIP registration.
Technical references
Scheduled for 27 August 2026. Coordinate carrier-side resilience tests before intentionally blocking a production target.