Record reference · Intermediate

SRV record reference

Understand SRV service discovery, service and protocol labels, priority, weight, port, target rules, caching, and verification limits.

Published
Jul 29, 2026
Last verified
Review by
Risk
Reversible
Provider
Provider-neutral

Written by VMCSoft Digital. Reviewed by VMCSoft Digital technical review.

An SRV RRset tells a compatible client where a named service is available. It can publish several targets with priority and weight, plus a port for each target. The application protocol must define or use SRV discovery; publishing the record does not make an arbitrary client consult it.

Purpose and type code

IANA registers SRV as type code 33 [1]. RFC 2782 defines the owner-name convention, fields, client ordering, and target rules [2].

The owner normally has this form:

_service._protocol.example.com.

The underscore-prefixed labels distinguish a service and transport protocol from ordinary hostnames. Their exact values come from the application specification or deployed service, not from a guess based on a product name.

Presentation format

_xmpp-client._tcp.example.com.  3600  IN  SRV  10 60 5222 xmpp1.example.net.
_xmpp-client._tcp.example.com.  3600  IN  SRV  10 40 5222 xmpp2.example.net.
_xmpp-client._tcp.example.com.  3600  IN  SRV  20  0 5222 backup.example.net.

After the TTL, class, and type, each record contains:

  1. priority — lower values are tried before higher values;
  2. weight — relative selection among records with the same priority;
  3. port — the TCP or UDP port for the service; and
  4. target — the domain name of the host providing the service.

Weight is not a percentage and does not promise exact traffic distribution. Clients use a weighted selection procedure within the lowest usable priority. With a single target at a priority, its weight has no balancing effect.

Owner-name and coexistence rules

All records at the same service owner form one SRV RRset. Preserve the complete set when changing one target or weight.

RFC 2782 requires the target to name a host with address records and says the target must not be an alias. Publish A or AAAA records for the target name; do not point SRV directly at an IP address or depend on a CNAME target.

A single target of . means the service is decidedly unavailable at that owner. Do not combine that signal casually with ordinary targets.

The service owner can coexist with records allowed by the protocol, but a CNAME owner cannot also hold an SRV RRset.

Caching and changes

Resolvers cache the SRV RRset separately from each target’s A and AAAA RRsets. A client can therefore observe a current SRV target while retaining an older target address, or the reverse.

Before a planned change:

  • inventory every SRV record and target address;
  • lower relevant TTLs early enough for previous values to expire;
  • prepare the new service and address data before advertising it;
  • preserve a usable target at the best priority; and
  • retain old targets through the reviewed overlap.

Changing priority, weight, or port can redirect compatible clients immediately after their cached SRV answer expires. Treat the application and firewall effects as part of the blast radius.

Security and operational limits

SRV is discovery data. It does not:

  • prove that a target accepts the advertised protocol;
  • open the published port through a firewall;
  • configure TLS identity or certificate names;
  • force clients to use SRV;
  • provide health checking or automatic recovery; or
  • make weighted traffic distribution exact.

DNSSEC can authenticate a signed SRV RRset and its address lookups when the chain validates. It does not authenticate the application session by itself.

Verify

Use the DNS diagnostic command guide or the DNS Lookup pathway and verify:

  1. the exact _service._protocol owner name;
  2. the complete SRV RRset, TTL, priority, weight, port, and targets;
  3. direct answers from every intended authority;
  4. A and AAAA answers for every target;
  5. that no target depends on a CNAME;
  6. the application actually supports this SRV discovery convention; and
  7. service reachability, TLS identity, and protocol behavior separately.

One successful connection proves only that one selected path worked. Test backup priorities and target removal behavior without disrupting production.

Next step

Use the safe DNS change checklist before editing a production SRV RRset, and record application-level verification for every advertised target.