Skip to main content

3. Domain Administrator Advice

3.1 Backward Compatibility Considerations​

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:

3.2 Configuration Strategies​

3.2.1 Multi-Host Distributed Services​

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.

Client Behavior Warning

Some programs only try the first address they get back from e.g. gethostbyname(), and we don't know how widespread this behavior is.

3.2.2 Single Service, Multiple Hosts​

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)
  • Provide address records just for one (presumably the fastest)

3.2.3 Backup Servers​

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.

3.2.4 Port Requirements for Backup Records​

Mandatory Requirement

Hosts that are referenced by backup address records MUST use the port number specified in Assigned Numbers for the service.

3.2.5 Future Protocol Design​

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.

3.3 DNS Reply Size Limitations​

3.3.1 Practical Limit​

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.

3.3.2 Size Estimation​

All round numbers, wrote Dr. Johnson, are false, and these numbers are very round:

Reply Packet Components:

  • 30 bytes: general overhead
  • Variable: the name of the service (e.g., "_ldap._tcp.example.com")
  • 20 bytes + target name: each SRV RR
  • 15 bytes + NS name: each NS RR in the NS section
  • ~20 bytes: each A RR in the additional data section

This size estimate is extremely crude, but shouldn't underestimate the actual answer size by much.

Verification

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.

Tags:
Last updated on