{{ summaryHeading }} {{ overallLabel }} {{ summarySecondaryLine }}

DomainNAPTRSRVA / AAAA
Enter one public name, such as example.com or sip:user@example.com.
Choose the client discovery path that will consume these DNS records.
Use Auto for a first pass or pin a resolver for repeatable evidence.
Use an override only when the NAPTR hop itself is the troubleshooting question.
Keep this off unless cache or resolver-policy drift is part of the investigation.
{{ compare_resolversBool ? 'On' : 'Off' }}
Accepted range: 1000 to 10000 milliseconds.
ms
EvidenceSubjectStateFindingDetailCopy
{{ row.kind }}{{ row.subject }}{{ row.status }}{{ row.finding }}{{ row.detail }}
PathStateFindingRecommendationCopy
{{ row.path }}{{ row.status }}{{ row.finding }}{{ row.recommendation }}
DNS Glue & Delegation Check Check DNS glue and delegation for a public zone, compare resolver views, and identify missing NS addresses, aliases, or DS evidence.
DNS Delegation Trace Analyzer Trace a public hostname through DNS delegation and aliases, compare resolver views, and inspect DNSSEC or negative-cache clues.
DNS Propagation Checker Check DNS propagation across public resolvers, compare the intended record set, and identify cache holdouts with TTL and failure evidence.
MX Record Lookup Inspect a domain's MX route and compare public DNS answers while catching Null MX conflicts, unresolved exchanges, and alias targets.

A service can have working host records and still be undiscoverable. SIP, XMPP, and LDAP clients may begin with a service-specific DNS name that identifies a transport and use, then follow the records to a port and one or more terminal hosts. A plain lookup of the bare domain misses that route.

Service owner
The underscored DNS name for a service and transport, such as _xmpp-server._tcp.example.net.
Service target
The hostname and port published in an SRV answer.
Terminal host
The target after it resolves to direct IPv4 or IPv6 addresses.

Service (SRV) records carry four values after the owner name: priority, weight, port, and target. Priority selects the preferred group, with lower numbers tried first. Weight distributes selections among targets that share the same priority. The target is another hostname, which must ultimately lead to address records before a client can connect.

Naming Authority Pointer (NAPTR) records can add an earlier routing decision. For SIP and SIPS, a client can use NAPTR order and preference to choose an acceptable service and transport, then follow an S rule to an SRV owner. When no usable NAPTR route exists, normal client behavior may continue at well-known SRV owners. XMPP and LDAP profiles usually begin at SRV in this check, so any NAPTR data is contextual rather than required.

The difference between priority and weight is easy to misread. A target with priority 20 and weight 100 does not outrank a target with priority 10 and weight 1. Weight matters only inside the active priority group, and it is a relative selection value rather than a measured capacity or health score.

DNS publication also stops short of proving application availability. Direct A or AAAA records complete the discovery chain, but they do not show that the port accepts connections, that SIP or XMPP negotiation succeeds, or that TLS presents the right certificate. Resolver caches can also show different record sets during a change.

A useful service-discovery review therefore checks the route in order: the client profile, any applicable NAPTR decision, the SRV targets, and the terminal addresses. Each hop answers a different question, and a clean earlier hop cannot compensate for a broken later one.

How to Use This Tool:

Choose the client behavior you are troubleshooting before judging the DNS records.

  1. Enter one public Service domain. A SIP-style URI, URL, or full matching SRV owner is reduced to its domain; extra lines are ignored.
  2. Select the Service profile for SIP, SIPS, XMPP client, XMPP server, or LDAP. The profile determines the expected NAPTR services, SRV owner names, transports, and normal ports.
  3. Keep Resolver on Auto for a first pass, or pin Cloudflare, Google Public DNS, or Quad9 when you need a repeatable recursive view.
  4. Run Check discovery and read the overall Ready, Needs review, or Broken chain result before opening the detailed evidence.
  5. Use NAPTR policy only when that hop is the question. Require makes a missing usable NAPTR route fail; Ignore starts directly at the profile’s SRV owners.
  6. Enable Compare resolvers when cache or resolver-policy differences matter. Increase the per-query timeout only when slow responses are obscuring otherwise valid answers.

Interpreting Results:

Ready means the selected recursive view reached at least one service target with direct address data and found no warning or failure in the active path. Needs review covers usable paths with fallback, partial terminal failure, alias evidence, or resolver differences. Broken chain means the published route did not reach a usable terminal host.

  • Read NAPTR and SRV status against the selected profile. A record can be syntactically valid yet name the wrong service or transport.
  • A fallback warning may still describe a route that standards-aware clients can use. Decide whether direct SRV fallback is intentional before changing DNS.
  • A CNAME at an SRV target is treated as a failure. Replace the target with a canonical hostname that has direct A or AAAA records.
  • Resolver comparison shows three public recursive views, not worldwide propagation. Confirm authoritative DNS and relevant client-side caches before declaring a rollout complete.
  • Passing address checks do not test the service port or application protocol. Follow with a connection, handshake, or application-level check.

Technical Details:

Discovery begins by normalizing the supplied URI, URL, domain, or matching SRV owner to a public DNS name. The selected profile then determines whether NAPTR is preferred and which direct SRV owners form the fallback route.

Lookup Core:

Profile NAPTR service Direct SRV owner Normal port
SIP endpoint SIP+D2T or SIP+D2U _sip._tcp or _sip._udp 5060
SIPS endpoint SIPS+D2T _sips._tcp 5061
XMPP client Informational only _xmpp-client._tcp 5222
XMPP server Informational only _xmpp-server._tcp 5269
LDAP Informational only _ldap._tcp 389

NAPTR answers are sorted by ascending order, then ascending preference. For SIP and SIPS, only a service value allowed by the profile and an S or A flag can become a route. An S rule leads to SRV; an A rule with a replacement hostname leads directly to address lookup. Regular-expression rewrites and unsupported flags are reported but not followed.

SRV answers are sorted by ascending priority. Weight is evaluated only among records with the same priority, and a target of . means that the service is unavailable at that owner. Each usable target is then queried for A, AAAA, and CNAME data.

Formula Core:

The displayed weight share is the record’s weight divided by the sum of weights in its priority group. When the group’s total weight is zero, records receive equal displayed shares.

Si = wi ∑j=1nwj × 100 %

Shares are rounded to whole percentages for display. They describe relative selection inside one priority group and do not predict the exact distribution of a small number of client connections.

Rule Core:

Condition Result Meaning
No service target, or no terminal host with address data Fail The client path cannot reach a usable endpoint.
Terminal target resolves through CNAME Fail The SRV target is not a canonical host with direct addresses.
Some targets or terminal hosts fail while another path remains usable Warn The route is partial and needs repair or confirmation.
No usable preferred NAPTR route, with profile-default fallback allowed Warn Direct SRV fallback was required.
No usable NAPTR route while Require is selected Fail The chosen policy makes the missing hop blocking.
All active stages succeed Pass The selected resolver exposes a complete DNS route.

Auto starts with the first suitable built-in public resolver and moves on when it cannot obtain a usable response. Resolver comparison checks Cloudflare, Google Public DNS, and Quad9, then compares normalized NAPTR routes, SRV targets, and terminal-address snapshots. The accepted per-query timeout is 1,000 to 10,000 milliseconds.

Privacy and Accuracy Notes:

DNS questions are sent from the browser to the selected public DNS-over-HTTPS resolver. The resolver can observe the service domain and each NAPTR, SRV, A, AAAA, or CNAME name queried. Comparing resolvers sends those questions to all three built-in providers.

  • The result reflects recursive resolver caches and policies at check time; it is not an authoritative-zone audit or global propagation measurement.
  • Some public JSON DNS interfaces do not expose NAPTR consistently. When that limitation is detected, the report identifies the missing lens and continues at SRV.
  • No TCP connection, TLS handshake, SIP exchange, XMPP stream, or LDAP bind is attempted.
  • A timeout can mean network delay, resolver trouble, or browser policy rather than a missing DNS record. Recheck with a pinned resolver before changing production DNS.

References: