SRV / NAPTR Service Discovery Check

Introduction:

Many internet services are reached by name long before a client knows which host and port to contact. A domain such as example.com might publish web addresses, mail routes, voice signaling, chat federation, and directory service records at the same time. DNS service discovery gives protocol-aware clients a way to ask for the right service route instead of guessing a host name or relying on one fixed port.

Address records answer a narrow question: which IPv4 or IPv6 addresses belong to this host name. SRV records answer a service question: which hosts serve a named protocol, which port should be used, and which target has higher priority. NAPTR records can sit before SRV when a protocol needs a routing rule, such as choosing SIP over TCP, SIP over UDP, or secure SIP over TLS before the SRV lookup begins.

Service owner

The DNS name built from service, transport, and domain labels, such as _sip._tcp.example.com or _xmpp-server._tcp.example.net.

Route rule

A NAPTR answer that can point a client toward an SRV owner or a terminal host for a matching protocol and transport.

Terminal host

The final host named by the discovery chain. It should expose direct A or AAAA records rather than requiring another alias hop.

Service discovery is most visible when a connection fails for a reason that is not really an application problem. SIP and SIPS clients may depend on NAPTR to choose a transport before looking up SRV. XMPP clients and servers normally start at service-specific SRV owners. LDAP deployments can publish directory locations through SRV when a domain should advertise more than one directory host.

A valid DNS discovery path is only the beginning of a connection. DNS can show that a client has a route to a host and port, but it cannot prove that the server accepts TCP, TLS, SIP registration, XMPP stream negotiation, LDAP binds, authentication, or the certificate identity a real client will require.

How to Use This Tool:

Run one service identity at a time, then keep the profile and resolver settings consistent when comparing results.

1. Enter a single value in Domain. Plain domains, SIP-style addresses, URLs, and full SRV owners are accepted, then reduced to the service domain used by the selected profile.
2. Choose Service profile. SIP endpoint and SIPS endpoint prefer matching NAPTR routes first. XMPP client, XMPP server, and LDAP service focus on their profile-specific SRV owner.
3. Open Advanced when you need repeatable resolver evidence. Resolver can use Auto, Cloudflare, or Google Public DNS. Compare resolvers adds side-by-side evidence when public recursive views disagree.
4. Use NAPTR policy to match the troubleshooting question. Profile default follows the normal route for the selected service, Require usable NAPTR treats missing NAPTR as blocking, and Ignore NAPTR checks the SRV path directly.
5. Set Timeout only if lookups are consistently slow or too short for your network path. The accepted range is 1000 to 10000 ms.
6. Select Check Discovery. If the page warns that extra lines were ignored, reduce the input to the one name you want to test because the check handles one service identity per run.
7. Open SRV/NAPTR Chain Health and start with Discovery Ledger, then inspect NAPTR Routes, Service Targets, Endpoint Addresses, Fallback Posture, and Resolver Drift when that table appears. Re-run the check if the stale-results notice appears after input changes.

Interpreting Results:

The summary label is the first triage signal. Ready means the selected resolver view can follow the DNS discovery chain to terminal hosts. Needs review means the chain still has a usable path but includes fallback, resolver drift, partial endpoint failure, or terminal-host hygiene problems. Broken chain means the DNS evidence does not reach a usable terminal host set for the selected profile.

• Discovery Ledger explains which stage set the result: resolver lens, NAPTR routes, service targets, terminal hosts, or client path.
• NAPTR Routes is important for SIP and SIPS because missing or unsupported NAPTR can change transport selection before SRV is queried.
• Service Targets shows SRV priority, displayed weight share, port, target, and whether each target can continue to terminal-host checks.
• Endpoint Addresses should show direct A or AAAA data. CNAME evidence on a terminal host is treated as a repair item.
• Resolver Drift indicates that compared public resolver views did not return the same NAPTR, target, or endpoint snapshot during the run.

Do not treat a Ready result as proof that the service is up. Verify port reachability, protocol negotiation, TLS names, credentials, and application logs separately when a client still fails after the DNS chain looks clean.

Technical Details:

SRV records use the owner form _service._proto.name. The answer publishes priority, weight, port, and target. Lower priority values are tried first. Records with the same priority use weight as a relative selection hint. The port comes from the SRV answer, and the target is expected to be a canonical host name with address records.

NAPTR records provide ordered rules before the SRV step when the protocol uses Dynamic Delegation Discovery System routing. For SIP, service fields such as SIP+D2T, SIP+D2U, and SIPS+D2T describe protocol and transport choices. A flag of S points to an SRV owner, while a flag of A can point directly to a host. Regex-based terminal rewrites are not followed here, so those entries are reported rather than expanded.

Rule Core:

Formula Core:

When several SRV records share one priority value, the displayed share is the record weight divided by the total weight for that priority group. If every same-priority weight is zero, the display is split evenly across those records.

For two same-priority rows with weights 20 and 80, the displayed shares are 20% and 80%. This share is a DNS routing hint, not a measurement of live server load.

Status Rules:

SRV target hygiene is strict because the SRV target is meant to be the terminal host name. A target of . means the service is not available at that owner, and a target that resolves through CNAME weakens interoperability even when some client libraries tolerate it.

Privacy and Accuracy Notes:

This performs public DNS lookups, not service connection tests. The names you check are sent to the selected public DNS-over-HTTPS resolver. Resolver comparison sends the same discovery names to more than one public resolver view.

• Avoid testing confidential internal names against public resolvers unless that disclosure is acceptable for your environment.
• Recursive caches, TTLs, split-horizon DNS, DNSSEC validation, provider policy, and recent zone changes can make one resolver view differ from another.
• Some public JSON resolver views may not return every DNS record type in the same way. When NAPTR is resolver-limited, the result should be read as an SRV and terminal-host check for that run.
• The check does not open SIP, SIPS, XMPP, LDAP, TCP, TLS, authentication, or bind sessions to terminal hosts.

Advanced Tips:

• Keep Resolver fixed when comparing before-and-after DNS changes. Auto is useful for a first pass, but a fixed public resolver makes repeated evidence easier to compare.
• Use Compare resolvers when propagation, split recursive caches, or DNS provider changes are part of the investigation. Treat Resolver Drift as a clue to compare TTLs and authoritative data before blaming the application service.
• For SIP and SIPS, set NAPTR policy to Require usable NAPTR only when the NAPTR route itself is the troubleshooting target. Profile default reports fallback without blocking a direct SRV path.
• If a resolver cannot expose NAPTR through its JSON DNS view, repeat the run with a NAPTR-capable resolver before concluding that the zone has no route rules.
• Use the JSON tab after a clean re-run when you need a ticket attachment. A stale-results warning means the copied evidence no longer matches the current inputs.

Worked Examples:

SIP reaches SRV fallback. Enter sip:alice@example.com, choose SIP endpoint, and leave NAPTR policy on profile default. If no usable SIP+D2T or SIP+D2U route appears, the summary can show Needs review. Discovery Ledger marks NAPTR routes as WARN, while Service Targets may still list _sip._tcp.example.com or _sip._udp.example.com targets that continue to Endpoint Addresses.

SIPS requires NAPTR during troubleshooting. Enter example.net, choose SIPS endpoint, and set NAPTR policy to Require usable NAPTR. If no SIPS+D2T route is visible, the summary becomes Broken chain. The useful repair clue is in NAPTR Routes and Fallback Posture, not in TLS logs, because the required DNS route is missing before any TLS connection can begin.

XMPP terminal host uses an alias. Enter chat.example.org and choose XMPP server. If Service Targets points to xmpp-edge.example.org but Endpoint Addresses shows CNAME evidence instead of direct A or AAAA answers, the terminal-host stage fails. Replace the alias with a canonical host that publishes address records, then run the same resolver view again.

FAQ:

Glossary:

SRV record

A DNS record that publishes priority, weight, port, and target host for a named service.

NAPTR record

A DNS record that publishes ordered routing rules, often before SRV in SIP service discovery.

Service owner

The DNS owner name built from service, protocol, and domain labels, such as _ldap._tcp.example.com.

Terminal host

The final host named by the discovery chain, expected to expose direct A or AAAA records.

Resolver drift

A difference between public recursive resolver views for the same discovery path during the same run.

SRV fallback

A direct SRV route used when a preferred NAPTR-guided route is missing, skipped, resolver-limited, or unusable.

References:

• RFC 2782: A DNS RR for specifying the location of services, IETF, February 2000.
• RFC 3403: Dynamic Delegation Discovery System Part Three, IETF, October 2002.
• RFC 3263: Session Initiation Protocol: Locating SIP Servers, IETF, June 2002.
• RFC 6120: Extensible Messaging and Presence Protocol: Core, IETF, March 2011.
• Using JSON with Cloudflare DNS over HTTPS, Cloudflare Docs.
• JSON API for DNS over HTTPS, Google Public DNS.