SRV / NAPTR Service Discovery Check

SRV and NAPTR records tell clients where a service lives before a connection is opened. SIP and SIPS clients can use NAPTR to choose a transport and then follow SRV records to the final host and port. XMPP and LDAP discovery usually starts directly at SRV owner names.

Discovery problems often look like application outages even when the service itself is healthy. A missing SRV answer, unusable NAPTR replacement, CNAME at the terminal host, or disagreement between public recursive resolvers can send clients to the wrong place or make them fall back to a weaker path.

This check is useful for DNS publishing and troubleshooting. It does not test SIP registration, XMPP authentication, LDAP bind behavior, certificate identity, or firewall reachability beyond the DNS answers that describe the path.

Technical Details:

An SRV record contains priority, weight, port, and target. Lower priority values are preferred; weights distribute traffic among records at the same priority. NAPTR records add an earlier routing step with order, preference, flags, service, regexp, and replacement fields.

The checker normalizes domains, service URIs, URLs, and full SRV owner names into a service domain. It then probes DNS-over-HTTPS resolvers for NAPTR, SRV, A, AAAA, and CNAME data, using the selected profile to decide whether NAPTR is preferred, ignored, or treated as required.

The decision path is rule-based. Resolver failures become FAIL or WARN depending on whether enough answers remain to build the chain. Missing required NAPTR is FAIL, missing preferred NAPTR with SRV fallback is WARN, usable NAPTR is PASS, and terminal hosts with no A or AAAA answers fail endpoint readiness. CNAME at an SRV terminal host is reported as a failure because SRV targets are expected to name canonical hosts directly.

Everyday Use & Decision Guide:

Start with the service domain or URI that a client would use, then pick the Service profile. For SIP, a URI such as sip:alice@example.com is normalized to example.com. If you paste a full owner such as _sip._tcp.example.com, the owner prefix is removed before the discovery workflow runs.

Leave Resolver on Auto for a general check. Pick Cloudflare, Google Public DNS, or Quad9 when you need one recursive view. Turn on Compare resolvers when a recent DNS change may be cached differently or when users in different networks report different behavior.

• Use Profile default for normal behavior.
• Use Require usable NAPTR when a SIP or SIPS deployment must publish a NAPTR route.
• Use Ignore NAPTR and test SRV only when isolating fallback behavior.
• Increase Timeout only when local network conditions make public resolver checks flaky.

PASS does not prove the service accepts connections. It means the published discovery chain has usable DNS answers under the selected profile and resolver lens.

Step-by-Step Guide:

1. Enter Domain / URI / SRV owner. If the field reports invalid input, remove extra text or paste only the primary service name.
2. Select Service profile so the checker knows whether to look for SIP, SIPS, XMPP client, XMPP server, or LDAP records.
3. Open Advanced to choose Resolver, Compare resolvers, NAPTR policy, and Timeout.
4. Run the check and read Discovery Ledger for the overall PASS, WARN, or FAIL path.
5. Open NAPTR Routes, Service Targets, Endpoint Addresses, Fallback Posture, and Resolver Drift to locate the exact record that changed the status.

Interpreting Results:

Discovery Ledger is the summary of record health. NAPTR Routes explains whether records were followed, ignored, unusable, or absent. Service Targets shows SRV priority, weight, port, and target readiness. Endpoint Addresses confirms the terminal host has visible A or AAAA answers.

Do not treat Resolver Drift as an authoritative global DNS view. It compares the selected public resolvers only. If drift appears, check authoritative DNS, TTLs, DNSSEC, split-horizon policy, and local recursive resolver behavior before changing application configuration.

Worked Examples:

For sip:alice@example.com with the SIP endpoint profile, usable SIP+D2T or SIP+D2U NAPTR records produce a NAPTR guided path. If no usable NAPTR exists but _sip._tcp.example.com has SRV records, the summary can warn with SRV fallback rather than fail.

For conference.example.com with the XMPP client profile, the check goes to _xmpp-client._tcp.conference.example.com. NAPTR rows may appear as context, but the practical service target comes from SRV.

If Endpoint Addresses shows FAIL because the target has CNAME data, fix the SRV target to point at the canonical host name or publish direct address records for the terminal host, depending on the service design.

FAQ:

Glossary:

NAPTR

A DNS record type used by some protocols to choose a service and transport before SRV lookup.

SRV

A DNS record type that gives a service target host, port, priority, and weight.

Terminal host

The final host name from an SRV or NAPTR path that should resolve to address records.

References:

• RFC 2782: DNS SRV records
• RFC 3403: NAPTR records in DNS
• RFC 3263: locating SIP servers