SRV record is an abbreviation for Server Resource Record, a record of service resources provided by a server supported in the DNS server’s database, whose main purpose is to indicate what services a server is capable of providing.
Simply put, an SRV record is a simple piece of information about which computer provides which service.
SRV records are the new face of DNS records, and were only defined in RFC 2052, so many older versions of DNS servers do not support SRV records.
RFC2782
Overview and rationale
Currently, the exact address of a server must be known in order to contact it or broadcast a problem.
SRV RR allows administrators to use multiple servers for a single domain name, easily move services from one host to another, and designate some hosts as primary servers for services and others as backups.
The client requests a specific service/protocol for a specific domain name (the term “domain” used here is strictly defined on RFC 1034) and gets the name of any available server.
Note that when this document refers to “address records”, it means A RR, AAAA RR or its most modern equivalent.
Format defined in RFC
The format defined in RFC2782 is as follows.
|
|
Detailed description of each field.
| Fields | Description |
|---|---|
| Service | The symbolic name of the desired service. Defined in Assigned Numbers or locally. Service identifiers are preceded by an underscore _ to avoid conflicts with DNS tags that occur in nature. |
| Proto | The symbolic name of the desired protocol. Preceded by an underscore _ to prevent conflicts with DNS labels that occur in nature. _TCP and _UDP are currently the most commonly used values for this field, but any name defined by Assigned Numbers or locally can be used. Proto is not case-sensitive. |
| Name | The domain name to which this RR refers. The SRV RR is unique under this domain name. |
| TTL | |
| Class | |
| Priority | |
| Weight | |
| Port | The port of the service on the target host. The symbolic name of the desired protocol, preceded by an underscore (_) to prevent conflicts with DNS labels that occur in nature. _TCP and _UDP are currently the most useful values for this field, but any name defined by Assigned Numbers or local (such as Service) may be used. Proto is not case-sensitive. The range is 0-65535. This is a 16-bit unsigned integer in the network byte order. Usually specified in Assigned Numbers, but not necessarily so. |
| Target | The domain name of the target host. The domain name must have one or more address records, and the domain name must never be an alias. Implementations are urged (but not forced) to return address records in the additional data section. Name compression must not be used in this field unless and until future standard operations allow it. A value of “.” indicates that the domain name is explicitly unavailable for this service. |
SRV records and Microsoft’s relationship
SRV records have an important place in Microsoft’s Active Directory, and as you know in the NT4 era domains and DNS didn’t have much to do with each other. But since Win2000, domains can’t do without the help of DNS, why? Because the computers in the domain rely on DNS SRV records to locate the domain controller! Microsoft’s instant messaging server, Live Communications Server, can also rely on SRV records to locate instant messaging servers.
SRV records are generally applied when setting up for Microsoft’s Active Directory. DNS can be independent of Active Directory, but Active Directory must have the help of DNS to work. In order for Active Directory to work properly, DNS servers must support Service Location (SRV) resource records, which map service names to the names of servers that provide the service. Active Directory clients and domain controllers use SRV resource records to determine the IP address of the domain controller.
Given the ability of SRV records to locate specific servers, we can expect that SRV records will play an increasing role in future Microsoft server products.