A DNS RR for specifying the location of services (DNS SRV)
Extracted elements (25)
Moving port number assignment to DNS reduces the need to update /etc/services on every host when a new service is added, and makes it possible to run standard services outside the root-only port range on Unix systems.
Service and protocol labels are prepended with an underscore to reduce the probability of accidental collision with existing DNS labels used for unrelated purposes. This change from RFC 2052 is the primary functional modification.
The Weight field is intentionally limited to static server selection (e.g., 'this machine is three times as fast'). Using SRV weight for dynamic load balancing would require unreasonably short TTLs, undermining DNS caching and increasing network load.
The weighted random selection algorithm is adapted from one supplied by Dan Bernstein. It ensures proportional selection by computing a running sum of weights and choosing based on a uniform random draw, which provides the correct distribution without sorting.
DNS replies are practically limited to 512 bytes until all resolvers support larger responses. Administrators are strongly advised to keep SRV replies below 512 bytes; rough overhead is 30 bytes base + 20 bytes per SRV RR + target name lengths + NS and A record overhead.
SRV records must coexist with A record lookups because existing clients will not immediately adopt SRV. Administrators are advised to publish A records alongside SRV records to support legacy clients, and backup hosts referenced only in SRV must use the Assigned Numbers port for the service.
A client MUST attempt to contact the target host with the lowest-numbered priority it can reach. Hosts with the same priority SHOULD be tried in an order determined by the Weight field.
A client MUST parse all RRs in the SRV reply. If the Additional Data section is missing address records for any SRV target the client may need to connect to, the client MUST perform a separate DNS lookup for those address records.
A SRV-cognizant client SHOULD query QNAME=_service._protocol.target, QCLASS=IN, QTYPE=SRV, then follow the priority/weight ordering process to build a connection attempt list. If no SRV reply is found, fall back to an A record lookup for the bare target.
Any protocol specification that mandates use of SRV records MUST define the symbolic name for the Service field and MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such a protocol specification.
Port numbers SHOULD NOT be used in place of symbolic service or protocol names in SRV queries, because applications would otherwise need to perform multiple lookups and variant names would be prohibited.
The following weighted random selection algorithm SHOULD be used for SRV RRs of equal priority: place weight-0 records first, compute a running sum of weights, pick a uniform random number in [0, sum], and select the first RR whose running sum is ≥ that number. Repeat until all RRs at that priority are ordered.
The Target domain name MUST have one or more address records and MUST NOT be an alias (CNAME). Name compression is not to be used for the Target field.
The Port field (16-bit unsigned integer, 0–65535) specifies the port on the target host for the service. It need not match the well-known port from Assigned Numbers.
The Priority field (16-bit unsigned integer, 0–65535) indicates the preference order of target hosts; lower values are preferred. Clients MUST attempt to contact the lowest-priority reachable target first.
The Proto field is an underscore-prefixed symbolic name of the desired protocol (e.g., `_tcp`, `_udp`). It is case insensitive and may be any name defined in Assigned Numbers or locally.
The Service field is an underscore-prefixed symbolic name of the desired service (e.g., `_ldap`), as defined in Assigned Numbers or locally. The field is case insensitive, and the underscore prevents collisions with naturally occurring DNS labels.
The Target field is the domain name of the target host; it MUST NOT be a CNAME alias and MUST have one or more address records. A Target of "." (root domain) signals that the service is definitively not available at this domain. Name compression MUST NOT be used for this field.
The Weight field (16-bit unsigned integer, 0–65535) provides proportional server selection among targets of equal priority. A weight of 0 should be used when no selection preference exists; records with weight 0 have a very small selection probability when higher-weight records are present.
IANA has assigned RR type value 33 to the SRV resource record. No other IANA services are required by this document.
DNS spoofing attacks can supply false port numbers via SRV records in addition to false host names and addresses. This is not a new vulnerability but is a slightly extended version of the existing DNS spoofing threat, with little additional practical impact.
Fine-grained port specification in SRV records makes it impossible for routers to block clients from accessing specific external services by well-known port alone, and slightly complicates blocking of unauthorized internal services. DNS and routing operations personnel must cooperate more closely.
There is no mechanism to prevent a site's hosts from being referenced as SRV targets by other zones, which could lead to denial-of-service conditions against those hosts.
Client SRV resolution procedure: (1) query SRV RR; (2) if NOERROR with SRV records, check for Target="." and abort; otherwise sort by priority, apply weighted selection per priority level, then connect; (3) if no SRV record found, fall back to A record lookup and attempt connection.
The SRV RR has the format: `_Service._Proto.Name TTL Class SRV Priority Weight Port Target`. Priority, Weight, and Port are each 16-bit unsigned integers in network byte order with range 0–65535. DNS type code is 33.