A SRV-cognizant client SHOULD use this procedure to locate a list of
servers and connect to the preferred one:
Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
QTYPE=SRV.
If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
RR which specifies the requested Service and Protocol in the
reply:
If there is precisely one SRV RR, and its Target is "."
(the root domain), abort.
Else, for all such RR's, build a list of (Priority, Weight,
Target) tuples
Sort the list by priority (lowest number first)
Create a new empty list
For each distinct priority level
While there are still elements left at this priority
level
Select an element randomly, with probability
Weight, and move it to the tail of the new list
For each element in the new list
query the DNS for A RR's for the Target or use any
RR's found in the Additional Data secion of the
earlier SRV query.
for each A RR found, try to connect to the (protocol,
address, service).
else if the service desired is SMTP
skip to RFC 974(-> 2821prop) (MX).
else
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
for each A RR found, try to connect to the (protocol,
address, service)
Notes:
- Port numbers SHOULD NOT be used in place of the symbolic service
or protocol names (for the same reason why variant names cannot
be allowed: Applications would have to do two or more lookups).
- If a truncated response comes back from an SRV query, and the
Additional Data section has at least one complete RR in it, the
answer MUST be considered complete and the client resolver
SHOULD NOT retry the query using TCP, but use normal UDP queries
for A RR's missing from the Additional Data section.
- A client MAY use means other than Weight to choose among target
hosts with equal Priority.
- A client MUST parse all of the RR's in the reply.
- If the Additional Data section doesn't contain A RR's for all
the SRV RR's and the client may want to connect to the target
host(s) involved, the client MUST look up the A RR(s). (This
happens quite often when the A RR has shorter TTL than the SRV
or NS RR's.)
- A future standard could specify that a SRV RR whose Protocol was
TCP and whose Service was SMTP would override RFC 974(-> 2821prop)'s rules
with regard to the use of an MX RR. This would allow firewalled
organizations with several SMTP relays to control the load
distribution using the Weight field.
- Future protocols could be designed to use SRV RR lookups as the
means by which clients locate their servers.
