DNS and VoIP: SRV Records, NAPTR, and Why Phones Fail When DNS Does

DNS is one of those infrastructure components that nobody thinks about until it breaks. And when it breaks for VoIP, the symptoms are baffling. Phones that were working fine suddenly cannot register. Calls fail intermittently with no pattern you can see. Failover to a backup server does not happen even though you configured it. Half your phones work and half do not, on the same network, with the same configuration.

The reason DNS problems produce such strange VoIP symptoms is that VoIP depends on DNS in ways that are more complex than simple web browsing. A web browser looks up a hostname, gets an IP address, and connects. A SIP phone might perform a chain of three different DNS lookups before it knows where to send its first packet, and if any link in that chain is slow, stale, or wrong, the behavior can be unpredictable.

The basics: A records and why they are not enough

At the simplest level, a VoIP phone needs to know the IP address of its SIP server. You configure the phone with a hostname like sip.example.com, the phone does a DNS A record lookup, gets back 203.0.113.10, and sends its REGISTER request to that address.

This works. Many VoIP deployments, particularly small ones, use nothing more than A records and function perfectly well. But A records have significant limitations for VoIP:

No port information. An A record returns an IP address and nothing else. SIP's default port is 5060 for UDP and TCP, and 5061 for TLS. If your server runs on a non-standard port, you cannot express that in an A record. You have to configure the port explicitly on every phone.

No transport selection. An A record does not tell the phone whether to use UDP, TCP, or TLS. The phone either has to be explicitly configured with the transport, or it has to guess (and the guess varies by manufacturer).

No failover. If you have two SIP servers for redundancy, you can put two A records on the same hostname. But A records have no concept of priority. The phone gets back two IP addresses and picks one, typically the first one in the response. If that server is down, whether the phone tries the second address depends on the phone's implementation. Some do. Some do not. Some wait for a timeout that takes 30 seconds, during which all calls fail.

No load distribution. You can use DNS round-robin with multiple A records, but you cannot control the weighting. You cannot say "send 80% of traffic to server A and 20% to server B." Round-robin is random and uncontrollable.

For a single-server deployment with phones that are all explicitly configured with the right port and transport, A records are fine. For anything more complex, SIP has better tools.

SRV records: the right way to find a SIP server

DNS SRV (service) records were designed to solve exactly the problems that A records cannot handle. An SRV record says: for this service, using this protocol, in this domain, connect to this server, on this port, with this priority and weight.

The format looks like this:

_sip._udp.example.com.  IN SRV  10 60 5060 sip1.example.com.
_sip._udp.example.com.  IN SRV  10 40 5060 sip2.example.com.
_sip._udp.example.com.  IN SRV  20 0  5060 sip-backup.example.com.

Let's break that down. The name _sip._udp.example.com means "the SIP service, over UDP, for the domain example.com." The fields after SRV are:

• Priority (10, 10, 20): Lower numbers are tried first. The two servers with priority 10 are primary. The server with priority 20 is a backup, only tried if both primaries are unreachable.
• Weight (60, 40, 0): Among servers with the same priority, weight controls load distribution. With weights of 60 and 40, roughly 60% of new connections go to sip1 and 40% go to sip2.
• Port (5060): The port to connect to. This can be different for each server.
• Target (sip1.example.com): The hostname of the server, which then requires its own A record lookup.

This is dramatically more useful than a bare A record. You get:

Explicit failover. Priority levels define a clear failover hierarchy. If all priority-10 servers are unreachable, the phone moves to priority 20. This is not implementation-dependent guessing. It is specified behavior.

Load balancing. Weights let you distribute traffic unevenly across servers. Useful when your servers have different capacities, or when you want to drain traffic from a server before maintenance.

Port flexibility. Each server can run on a different port, and the phone learns the port from DNS rather than from its local configuration.

Transport awareness. The _udp in the record name specifies the transport protocol. Separate SRV records exist for _sip._tcp and _sip._tls (or _sips._tcp for SIP over TLS). The phone can look up which transports are available and choose appropriately.

How SRV lookups actually work

When a SIP phone is configured with a domain (just example.com, not a specific server hostname), and it needs to send a request, the lookup process defined in RFC 3263 is:

1. The phone constructs an SRV query: _sip._udp.example.com (or _tcp or _tls, depending on configuration or NAPTR results).
2. The DNS server returns the SRV records, with priorities and weights.
3. The phone resolves the target hostname from the highest-priority SRV record to an IP address via a standard A (or AAAA) record lookup.
4. The phone attempts to connect to that IP on the specified port.
5. If the connection fails, the phone tries the next server according to priority and weight rules.

This is the mechanism that makes VoIP failover work at the DNS level. It is also the mechanism that breaks when DNS is misconfigured.

NAPTR records: choosing the transport

NAPTR (Naming Authority Pointer) records add another layer on top of SRV records. Where SRV records answer "which server, which port," NAPTR records answer "which transport protocol should I use, and in what order should I try them?"

A NAPTR lookup for a SIP domain might return:

example.com.  IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.example.com.
example.com.  IN NAPTR  20 0 "s" "SIP+D2T"  "" _sip._tcp.example.com.
example.com.  IN NAPTR  30 0 "s" "SIP+D2U"  "" _sip._udp.example.com.

This says: for SIP services at example.com, first try SIP over TLS (SIPS+D2T), then SIP over TCP (SIP+D2T), then SIP over UDP (SIP+D2U). Each NAPTR record points to an SRV record name, and the SRV records point to actual server hostnames.

The full resolution chain is:

1. NAPTR lookup on example.com → determines available transports and their priority
2. SRV lookup on the selected service (e.g., _sips._tcp.example.com) → determines server, port, priority, weight
3. A/AAAA lookup on the server hostname (e.g., sip1.example.com) → determines IP address

Three DNS lookups before the phone sends its first SIP packet.

In practice, many VoIP deployments skip NAPTR entirely. The phone is configured with a specific transport (usually UDP or TLS), and it goes straight to the SRV lookup. NAPTR is most commonly seen in carrier interconnect scenarios, in IMS (IP Multimedia Subsystem) networks, and in deployments that want to enforce TLS-first policies via DNS rather than phone configuration. If your VoIP provider has not published NAPTR records, your phones are almost certainly not using them, and that is fine.

ENUM: phone numbers in DNS

There is one more DNS-based system worth knowing about, though it is less commonly encountered in typical business VoIP. ENUM (E.164 Number Mapping) uses NAPTR records to map phone numbers to SIP URIs via DNS.

The idea is that if you want to call +1-212-555-0100, you can reverse the digits, separate them with dots, and append e164.arpa to get a DNS name: 0.0.1.0.5.5.5.2.1.2.1.e164.arpa. A NAPTR lookup on that name might return a SIP URI like sip:[email protected], allowing the call to be routed directly over IP without touching the PSTN.

ENUM saw some adoption among VoIP carriers as a way to keep inter-provider calls on-net (avoiding PSTN termination charges). Public ENUM never achieved widespread adoption for consumer numbers, but private ENUM is used within some carrier networks and peering arrangements for exactly this purpose: keeping calls that could be IP-to-IP from unnecessarily touching the PSTN.

For most businesses, ENUM is invisible. But if you are troubleshooting call routing anomalies where certain calls to certain numbers take unexpected paths, it is worth knowing that ENUM exists and might be in play at the carrier level.

Why DNS failures hit VoIP so hard

When your DNS server goes down or becomes slow, web browsing degrades but mostly still works because browsers cache DNS responses aggressively and many connections are long-lived. VoIP is different in ways that make it far more sensitive to DNS problems.

Registration depends on DNS

Your phone re-registers periodically, typically every 30 to 60 minutes, sometimes more often. Each re-registration may trigger a fresh DNS lookup, depending on the phone's implementation and the TTL (time to live) on the DNS records. If DNS is unreachable at the moment a phone tries to re-register, the registration fails. The phone is now unregistered, meaning incoming calls cannot reach it.

If you have 50 phones and they all have slightly different registration timers, a DNS outage will cause phones to drop off in a staggered, seemingly random pattern. Some phones re-registered recently and their registration has not expired yet, so they still receive calls. Others tried to re-register during the outage and are now offline. This is why DNS outages often produce reports like "some phones work and some don't" rather than a clean, obvious total failure.

Failover requires DNS

The entire SRV-based failover mechanism described above depends on DNS working. If your primary SIP server goes down, the phone needs to do a new DNS lookup to find the backup server. If DNS is also down, or if the phone's cached DNS response only contained the primary server's address, failover does not happen. You have two points of failure (SIP server and DNS) that are supposed to be independent but might not be if they run on the same infrastructure or share the same network path.

Low TTLs mean frequent lookups

VoIP providers often set low TTLs on their DNS records, sometimes as low as 60 seconds, because they want DNS changes to propagate quickly for failover purposes. Low TTLs mean phones are doing DNS lookups frequently. High TTLs mean phones cache the answer longer and are less affected by brief DNS disruptions, but they are also slower to notice when a server changes.

This creates a tension. Low TTLs give you fast failover but make you more dependent on DNS availability. High TTLs give you resilience to DNS blips but slow down failover. Most providers choose low TTLs and accept the DNS dependency.

DNS latency adds to call setup time

A DNS lookup that takes 500 ms instead of 5 ms adds 500 ms to the time it takes for a call to start ringing. If the lookup chain is NAPTR → SRV → A, and each step takes 500 ms, you have added 1.5 seconds to call setup. Users experience this as a long delay between dialing and hearing ringback. If the lookup times out entirely (several seconds, depending on the phone's resolver configuration), the call fails outright.

Common DNS problems in VoIP deployments

Using the wrong DNS servers

Phones should typically use the same DNS servers as the rest of your network. But some phone provisioning templates hardcode specific DNS servers, sometimes the VoIP provider's DNS servers. If those servers become unreachable from your network (firewall change, routing issue), the phones lose DNS while everything else on the network works fine. This produces the maddening symptom of "the internet works, everything else works, but the phones are down."

Check what DNS servers your phones are actually using. It is in the phone's network configuration, either set statically, delivered via DHCP option, or hardcoded in the provisioning file. Make sure those servers are reachable and responsive from the VLAN your phones are on.

DNS servers on the wrong VLAN

If your phones are on a dedicated voice VLAN (and they should be), the DNS servers they use must be reachable from that VLAN. If your DNS server is on the data VLAN and inter-VLAN routing is misconfigured or blocked, phones cannot resolve hostnames. This is especially common after network changes when someone adjusts firewall rules or ACLs and forgets that the voice VLAN needs to reach the DNS server.

Stale DNS cache

Some phones cache DNS responses beyond the stated TTL. If your VoIP provider changes their server IP addresses and your phone is still using the old cached address, the phone is sending SIP traffic to a server that no longer exists. A phone reboot forces a fresh DNS lookup. If rebooting a phone fixes a registration problem, stale DNS cache is a likely culprit.

Split-horizon DNS issues

Organizations that use split-horizon DNS (internal DNS returns private addresses, external DNS returns public addresses) need to ensure that phones resolve VoIP hostnames to the correct addresses for their network location. A phone on the internal network that resolves the VoIP provider's hostname to a public IP might work (if the firewall handles NAT hairpinning), or it might not. A remote phone that resolves to an internal IP will definitely not work.

DNS over blocked ports

DNS typically uses UDP port 53. Some networks block outbound DNS to prevent DNS-based data exfiltration or to force all DNS queries through an internal resolver. If phones are configured to use an external DNS server and port 53 is blocked outbound from the voice VLAN, DNS lookups fail silently and the phone cannot register.

Verifying DNS for VoIP

When troubleshooting, you can manually perform the same DNS lookups a phone would make. From a machine on the same network (ideally the same VLAN) as the affected phones:

# Check for NAPTR records
dig NAPTR example.com

# Check for SRV records (UDP)
dig SRV _sip._udp.example.com

# Check for SRV records (TLS)
dig SRV _sips._tcp.example.com

# Resolve the server hostname
dig A sip1.example.com

# Test with a specific DNS server
dig @10.0.0.1 SRV _sip._udp.example.com

If any of these queries return no results, return unexpected results, or take more than a few hundred milliseconds, you have found a likely contributor to your VoIP problem.

Also check that the DNS server itself is responsive:

# Measure DNS query time
dig example.com | grep "Query time"

Query times under 10 ms to a local DNS server are normal. Query times over 100 ms indicate a problem. Query times over 500 ms will cause user-visible call setup delays.

Best practices

Use local DNS resolvers. Phones should query a DNS server on your local network, not a remote public resolver. Local resolvers respond faster and are not affected by internet congestion. Your local resolver can forward to upstream servers (your ISP, Google, Cloudflare) for names it does not know, but the first hop should be local and fast.

Ensure DNS redundancy. Configure at least two DNS servers for your phones via DHCP. If one goes down, the phone falls back to the other. Make sure the two servers are not on the same physical machine or behind the same single point of failure.

Monitor DNS. If you are monitoring your VoIP infrastructure, add DNS response time and availability to your checks. A DNS server that is up but responding slowly will cause intermittent VoIP problems that are extremely difficult to diagnose without DNS-specific monitoring.

Match DNS servers to VLANs. If you run separate VLANs for voice and data, verify that the DNS servers configured for the voice VLAN are reachable from that VLAN. Test this explicitly after any network configuration change.

Know your TTLs. Look up the TTL on your VoIP provider's DNS records. If they are low (under 300 seconds), your phones are doing frequent DNS lookups and are more sensitive to DNS disruptions. This is not something you need to change, but it is something you should be aware of when diagnosing intermittent problems.

The bottom line

DNS is in the critical path of every VoIP call. It determines which server your phone talks to, which transport it uses, and whether failover works when a server goes down. When DNS is fast and reliable, it is invisible. When it is not, it produces some of the most confusing and intermittent VoIP failures you will encounter.

The good news is that DNS problems, once identified, are usually straightforward to fix. The hard part is recognizing that DNS is the problem in the first place. Now you know where to look.

For more on how SIP registration works (and what happens when it fails), see SIP Registration: How Your Phone Tells the World Where It Is. For a broader diagnostic framework, see How to Tell Where the Problem Actually Is.