Summary

  • DNS SRV gave a domain a protocol-specific way to publish several service targets, their ports, primary and backup tiers, and a static selection bias among equal-priority hosts.
  • Priority and Weight carry different kinds of intent. The lowest reachable priority tier comes first; only within that tier does the client make a weighted random ordering. Weight is not live load telemetry.
  • The record never completes the service decision. A client still resolves each canonical target, attempts the advertised transport and port, and verifies the application endpoint; DNS publication is discovery evidence, not identity or health.

Before the service had a name of its own

The early domain-name system answered a powerful but narrower question: which address belongs to this host name? An application commonly supplied the rest from convention. It knew that a service usually occupied a particular port, consulted a local table such as /etc/services, or asked for an exact server name that an administrator had placed in documentation.

That arrangement fused several decisions. The public name, the host carrying the service, the port chosen by the operator and the fallback plan appeared to the client as one fact. Moving a service could require an address change, a new client configuration or a second discovery system. Offering several servers often meant publishing several addresses, which did not express which machines were primary, which were emergency backups or which could accept a larger static share.

RFC 2052 proposed a different record in October 1996. A client would ask DNS for the location of a service, not merely for the address of a host. The experimental SRV record joined a service label and transport protocol to a domain, then returned targets with priority, weight and port information.

The design was promoted and refined by RFC 2782 in February 2000. Its opening rationale was deliberately practical: administrators should be able to use several servers for one domain, move a service between hosts with little fuss, and identify both primaries and backups. IANA still records SRV as DNS resource-record type 33, Server Selection.

The query separated service, transport and domain

An SRV-aware LDAP client looking within example.com does not start by assuming that example.com itself runs LDAP on a locally remembered port. It asks for _ldap._tcp.example.com. The left labels state the desired service and transport; the remaining name states the administrative domain within which that service is being sought.

RFC 2782 added the leading underscores when it replaced the experimental document. Their purpose was not decoration. They lowered the risk that service metadata would collide with ordinary DNS names already used for hosts or other purposes. The revision also clarified the weight algorithm.

The later registry work made the namespace boundary more explicit. RFC 6335 unified service-name and port-number procedures and allowed a registered service name to be used by discovery mechanisms such as SRV even when no port number was assigned. Registration coordinates a name; IANA expressly warns that it does not endorse an application, product or traffic.

In 2019, RFC 8552 created a registry for globally scoped underscored DNS node names so different specifications could not silently assign the same global attribute leaf to incompatible uses. RFC 8553 then updated SRV-using specifications to fit that registry model while preserving deployed practice. A convention that began as collision avoidance acquired an auditable allocation surface.

Four fields, four different claims

An SRV record carries Priority, Weight, Port and Target. Treating them as one generic load-balancer policy erases the design.

Priority defines tiers. A client must attempt a reachable target with the lowest numeric priority. Records at a higher number are backups, not equal candidates that merely receive less traffic. Only when the lower tier cannot be reached does the next tier become relevant.

Weight operates among records that share one priority. Larger weights should receive proportionately greater probability of being selected. RFC 2782 describes a randomized procedure: add the weights, draw a uniform random number, choose against a running sum, remove that target and repeat until an order is built. The output belongs to the client. DNS supplies relative intent, not a permanent route for every request.

The distinction is visible in the RFC's fictional example. Two preferred hosts share priority zero, with weights one and three. Over enough independent selections, the second should tend to receive about three quarters of first attempts. Two other hosts sit at priority one and are considered only when the preferred pair cannot serve. One query or one user is not promised an exact three-to-one outcome.

Nor is Weight a live measure of CPU, queue depth or current latency. RFC 2782 says dynamic load changes too quickly for cached DNS data. Chasing it with very short TTLs would weaken caching, add DNS load and reduce reliability. Weight was intended to express slower-moving facts such as relative server capacity or network connection quality.

Port removes another hidden dependency. The service can run on the port published for that target rather than on the number every client happens to remember. The value may match the assigned port but need not. This let an operator move a service outside a privileged Unix port range or introduce a new service without updating a file on every client machine.

Target names the host to contact, but with a strict termination rule. It must have address records and must not be an alias. The client may use addresses returned in the DNS Additional section or issue separate A and AAAA queries. SRV can point toward address resolution; it cannot hide an indefinite CNAME or DNAME chain inside the target field.

Absence and deliberate unavailability are different

The root label . has a narrow meaning as an SRV target. If it is the sole record, the service is decidedly unavailable at that domain. That is a positive administrative statement, not a failure to find the domain and not a claim that every other service is absent.

The difference matters to automation. No usable SRV answer can mean that the protocol's older discovery convention should still be tried. An explicit root target says that this service should not be inferred from the domain's ordinary address.

RFC 2782 preserved that compatibility path because universal client upgrades were unrealistic. When no usable SRV record existed, its procedure fell back to an address lookup for the queried domain. Administrators were advised to maintain sensible address records for old clients. But a backup-only host should not be exposed in that ordinary address set if legacy clients would mistake it for a primary.

The result was not a clean flag day. New clients could understand service, port, priority and weight. Old clients continued to see addresses and conventional ports. Operators had to decide whether the compatibility surface preserved access or bypassed the very policy that SRV expressed.

Publishing candidates did not prove a service

A conforming client parses the full RRset, groups it by priority, performs the weighted ordering within each tier, resolves target addresses and tries the resulting protocol/address/port combinations. Each step can fail independently.

An authoritative DNS answer proves, at most, what the relevant DNS authority published and what its authenticity mechanism protects. It does not prove that the target accepts a connection, that the process on the advertised port is healthy, that the application identity is correct, that the target operator consented to being listed or that two target names belong to the same organisation.

RFC 2782's security section makes the extra control surface visible. A DNS spoofer can supply a false port as well as a false host or address. A domain can point clients at an unrelated site's host, creating unwanted traffic. Fine-grained service ports complicate filtering and require DNS and network operators to coordinate. SRV did not invent every underlying weakness, but it expanded what a false discovery statement could direct.

That is why the applicability rule is important. An application specification must say that clients use SRV, define the symbolic service name and address security considerations. A domain administrator cannot unilaterally make every client protocol obey an invented label. The protocol author controls the discovery contract; the domain authority controls records inside it; the client controls the actual selection and attempt.

The sources and what they cannot show

The historical record here is closed to six official sources: experimental RFC 2052, standards-track RFC 2782, service-name procedures in RFC 6335, underscore registry design in RFC 8552, its SRV update in RFC 8553, and the current IANA DNS Parameters registry.

They establish syntax, ordering, administrative boundaries and normative evolution. They do not measure current adoption, latency saved, accuracy of weight distributions, software compliance or the health of any live service. They do not turn a discovery record into proof of ownership, authority or successful delivery.

SRV's historical contribution was more modest and more durable. A service could outlive one host and one default port because the DNS name carried a bounded set of choices. Yet every choice remained incomplete until a client resolved, selected, connected and verified what answered.