6. Domain administrator advice

Expecting everyone to update their client applications when the first server publishes a SRV RR is futile (even if desirable). Therefore SRV would have to coexist with address record lookups for existing protocols, and DNS administrators should try to provide address records to support old clients:

• Where the services for a single domain are spread over several hosts, it seems advisable to have a list of address records at the same DNS node as the SRV RR, listing reasonable (if perhaps suboptimal) fallback hosts for Telnet, NNTP and other protocols likely to be used with this name. Note that some programs only try the first address they get back from e.g. gethostbyname(), and we don't know how widespread this behavior is.
• Where one service is provided by several hosts, one can either provide address records for all the hosts (in which case the round-robin mechanism, where available, will share the load equally) or just for one (presumably the fastest).
• If a host is intended to provide a service only when the main server(s) is/are down, it probably shouldn't be listed in address records.
• Hosts that are referenced by backup address records must use the port number specified in Assigned Numbers for the service.
• Designers of future protocols for which "secondary servers" is not useful (or meaningful) may choose to not use SRV's support for secondary servers. Clients for such protocols may use or ignore SRV RRs with Priority higher than the RR with the lowest Priority for a domain.

Currently there's a practical limit of 512 bytes for DNS replies. Until all resolvers can handle larger responses, domain administrators are strongly advised to keep their SRV replies below 512 bytes.

All round numbers, wrote Dr. Johnson, are false, and these numbers are very round: A reply packet has a 30-byte overhead plus the name of the service ("_ldap._tcp.example.com" for instance); each SRV RR adds 20 bytes plus the name of the target host; each NS RR in the NS section is 15 bytes plus the name of the name server host; and finally each A RR in the additional data section is 20 bytes or so, and there are A's for each SRV and NS RR mentioned in the answer. This size estimate is extremely crude, but shouldn't underestimate the actual answer size by much. If an answer may be close to the limit, using a DNS query tool (e.g. "dig") to look at the actual answer is a good idea.