Service (SRV) resource records enable you to specify the location of the servers for a specific service, protocol, and DNS domain. Thus, if you have two Web servers in your domain, you can create SRV resource records specifying which hosts serve as Web servers, and resolvers can then retrieve all the SRV resource records for the Web servers.

The format of an SRV record is as follows:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

• The _Service field specifies the name of the service, such as http or telnet. Some services are defined in the standards, and others can be defined locally.
• The _Proto field specifies the protocol, such as TCP or UDP.
• The Name field specifies the domain name to which the resource record refers.
• The TTL and Class fields are the same as the fields defined earlier in this chapter.
• The Priority field specifies the priority of the host. Clients attempt to contact the host with the lowest priority.
• The Weight field is a load balancing mechanism. When the priority field is the same for two or more records in the same domain, clients should try records with higher weights more often, unless the clients support some other load balancing mechanism.
• The Port field shows the port of the service on this host.
• The Target field shows the fully qualified domain name for the host supporting the service.

The following example shows SRV records for Web servers:

_http._tcp.reskit.com. IN SRV 0 0 80 webserver1.noam.reskit.com.
_http._tcp.reskit.com. IN SRV 10 0 80 webserver2.noam.reskit.com.


Note This example does not specify a TTL. Therefore, the resolver uses the minimum TTL specified in the SOA resource record.

If a computer needs to locate a Web server in the reskit.com DNS domain, the resolver sends the following query:

_http._tcp.www.reskit.com.


The DNS server replies with the SRV records listed above. The resolver then chooses between WebServer1 and WebServer2 by looking at their priority values. Because WebServer1 has the lowest priority value, the DNS server chooses WebServer1.

Note If the priority values had been the same, but the weight values had been different, the client would have chosen a Web server randomly, except that the server with the highest weight value would have had a higher probability of being chosen.

Next, the resolver requests the A record for webserver1.reskit.com, and the DNS server sends the A record. Finally, the client attempts to contact the Web server.

Purpose for the SRV records

The SRV records are to identify which servers provide the following services

• gc - Global Catalog
• ldap - Light-weight Directory Access Protocol
• kerberos - Kerberos authentication
• kpasswd - Kerberos password

When a client wants to authenticate, it consults DNS to find a kerberos server. When a client wants to search the Active Directory, it consults DNS to find a server that hosts the Global Catalog.

These DNS queries can include different criteria. Server queries can be specific as to the domain and/or site of the domain controller. For example

• An LDAP server in the WESTERN domain
• An LDAP server in the LOSANGELES site
• An LDAP server in the LOSANGELES site in the WESTERN domain
• A Global Catalog server anywhere in the forest
• A Global Catalog server in the LOSANGELES site

Each server is listed many times in DNS to represent all possible queries, as shown in the following dialog. The fully qualified domain name for a Global Catalog server in the LOSANGELES site would be _gc._tcp.losangeles._sites.company.com