SRV Record Lookup — Service Location Records

SRV_rdata encodes four fields: priority, weight, port, and target. Clients sort by lowest priority first, then distribute load among equal-priority rows using weight. Port tells applications which TCP or UDP port to open without guessing from defaults.

The owner name combines underscore-prefixed service and protocol labels plus the domain. _ldap._tcp.example.com locates LDAP over TCP. Getting the label wrong returns NXDOMAIN or empty answers even when the service runs fine on a known host.

SIP telephony publishes _sip._tcp and _sip._udp. Microsoft autodiscover uses SRV under _sipfederationtls and related names. XMPP instant messaging expects _xmpp-client._tcp and _xmpp-server._tcp. Kubernetes and some databases expose cluster discovery through SRV when operators choose DNS-based service location.

When migrating providers, compare old and new SRV rows with our DNS compare tool limited to other types — for SRV-specific moves, run this lookup on both environments and archive screenshots for rollback.

Priority is a simple integer ranking. Lower numbers win. Weight applies only among records sharing the same priority; higher weight receives proportionally more traffic in clients that implement the algorithm correctly.

A single SRV row with priority zero and weight zero is valid and common for small deployments. Multiple rows enable failover: secondary targets stay at higher priority until the primary returns.

Email delivery still depends on MX for Internet mail transfer. Some clients use SRV for submission or legacy autoconfiguration, but MX remains authoritative for inbound SMTP routing. Do not replace MX planning with SRV alone.

If mail autodiscovery fails, verify MX with a dedicated MX lookup and SRV only where your client documentation explicitly requires it.

Confirm the service label including underscores and protocol suffix. _service._tcp is only a default probe — production records use specific names. Verify you query the correct zone apex versus subdomain delegation.

DNS propagation delays affect SRV like any type. After edits, wait for TTL and query again. Also ensure firewalls allow the port listed in SRV, since DNS correctness does not imply reachable services.

SRV targets are hostnames, not IP addresses. Resolvers must fetch A or AAAA for the target separately. If the target lacks address records, clients fail after successful SRV retrieval.

After reading target hostnames here, resolve them with A/AAAA lookups or our hostname tools to complete the path from service discovery to IP.

Geo-redundant setups publish distinct SRV rows per region with equal priority and tuned weights, or staggered priorities for active-passive failover. Document intended traffic split so future edits do not accidentally send all users to one coast.

Health checks should remove or deprioritize targets before DNS TTL expires in automated systems; manual SRV edits remain common in smaller teams.

SRV reveals internal hostnames and ports useful for reconnaissance. That visibility is inherent to public DNS. Restrict sensitive admin services to private DNS or VPN when possible instead of publishing public SRV to obscure ports.

TLS still required: SRV does not encrypt traffic. Applications must upgrade connections per their protocol standards.

Returned records include parsed priority, weight, port, and target fields when the resolver supplies standard SRV rdata. The query field echoes the full owner name queried so you can paste it into change requests.

This is live public DNS only. Internal views behind split horizon may differ from what external clients experience.