Share via

Adding Resource Records

  • Article

Applies To: Windows Server 2008

After you create a zone, you must add additional resource records to it. The most common resource records that you add include the following:

  • Host (A) resource records: for mapping a Domain Name System (DNS) domain name to an IP address that is used by a computer.

  • Alias (CNAME) resource records: for mapping an alias DNS domain name to another primary or canonical name.

  • Mail exchanger (MX) resource records: for mapping a DNS domain name to the name of a computer that exchanges or forwards mail.

  • Pointer (PTR) resource records: for mapping a reverse DNS domain name that is based on the IP address of a computer that points to the forward DNS domain name of that computer.

  • Service location (SRV) resource records: for mapping a DNS domain name to a specified list of DNS host computers that offer a specific type of service, such as Active Directory domain controllers.

  • Other resource records as needed.

Host (A) resource records

You use host (A) resource records in a zone to associate DNS domain names of computers (or hosts) to their IP addresses. You can add them to a zone in several ways:

  • You can manually create a host (A) resource record for a static TCP/IP client computer by using DNS Manager.

  • Windows clients and servers use the DHCP Client service to dynamically register and update their own host (A) resource records in DNS when an IP configuration change occurs.

  • Dynamic Host Configuration Protocol (DHCP)–enabled client computers running earlier versions of Microsoft operating systems can have their host (A) resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server. (Only the Windows 2000, Windows Server 2003, and Windows Server 2008 DHCP Server service support this feature.)

Not all computers require the host (A) resource records, but computers that share resources on a network need them. Any computer that shares resources and must be identified by its DNS domain name must use host (A) resource records to provide DNS name resolution to the IP address for the computer.

Most host (A) resource records that are required in a zone can include other workstations or servers that share resources, other DNS servers, mail servers, and Web servers. These resource records make up the majority of resource records in a zone database.

Alias (CNAME) resource records

Alias (CNAME) resource records are also sometimes called canonical name resource records. With these records, you can use more than one name to point to a single host, which makes it easy to do such things as host both a File Transfer Protocol (FTP) server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered with alias (CNAME) resource records that map to the DNS host name (such as server-1) for the server computer that hosts these services.

We recommend alias (CNAME) resource records for the following scenarios:

  • When a host that is specified in an host (A) resource record in the same zone must be renamed

  • When a generic name for a well-known server, such as www, must resolve to a group of individual computers (each with individual host (A) resource records) that provide the same service, for example, in a group of redundant Web servers.

When you rename a computer with an existing host (A) resource record in the zone, you can use an alias (CNAME) resource record temporarily to allow a grace period for users and programs to switch from the old computer name to the new one, as follows:

  • For the new DNS domain name of the computer, add a new host (A) resource record to the zone.

  • For the old DNS domain name, add an alias (CNAME) resource record that points to the new host (A) resource record.

  • Remove the original host (A) resource record for the old DNS domain name (and its associated pointer (PTR) resource record, if applicable) from the zone.

When you use an alias (CNAME) resource record for aliasing or renaming a computer, set a temporary limit on how long the record is used in the zone before removing it from DNS. If you forget to delete the alias (CNAME) resource record and later its associated host (A) resource record is deleted, the alias (CNAME) resource record can waste server resources trying to resolve queries for a name that is no longer used on the network.

The most common or popular use of an alias (CNAME) resource record is to provide a permanent DNS aliased domain name for generic name resolution of a service-based name, such as www.tailspintoys.com, to more than one computer or one IP address on a Web server. The following example shows the basic syntax of an alias (CNAME) resource record:

alias_nameIN CNAMEprimary_canonical_name

In this example, a computer named host-a.tailspintoys.com functions as both a Web server named www.tailspintoys.com. and as an FTP server named ftp.tailspintoys.com. To achieve the intended objective of naming this computer, you can add the following CNAME entries in the tailspintoys.com zone:

host-a    IN  A      10.0.0.20
ftp       IN  CNAME  host-a
www       IN  CNAME  host-a

If you later decide to move the FTP server to another computer—, separate from the Web server on host-a—simply change the alias (CNAME) resource record in the zone for ftp.tailspintoys.com and add an additional host (A) resource record to the zone for the new computer hosting the FTP server.

Based on the earlier example, if the new computer is named host-b.tailspintoys.com, the new and revised host (A) and alias (CNAME) resource records appear as follows:

host-a    IN  A      10.0.0.20
host-b    IN  A      10.0.0.21
ftp       IN  CNAME  host-b
www       IN  CNAME  host-a

Mail exchanger (MX) resource records

E-mail applications use the mail exchanger (MX) resource record to locate a mail server based on a DNS domain name in the destination address for the e-mail recipient of a message. For example, a DNS query for the name example.tailspintoys.com can be used to find a mail exchanger (MX) resource record, which makes it possible for an e-mail application to forward or exchange mail to a user with the e-mail address user@tailspintoys.com.

The mail exchanger (MX) resource record shows the DNS domain name for the computer or computers that process mail for a domain. If multiple mail exchanger (MX) resource records exist, the DNS Client service attempts to contact mail servers in the order of preference from lowest value (highest priority) to highest value (lowest priority). The following example shows the basic syntax of a mail exchanger (MX) resource record:

mail_domain_nameIN MXpreferencemailserver_host

Using the mail exchanger (MX) resource records in the following example for tailspintoys.com zone, mail that is addressed to user@tailspintoys.com is delivered to user@mailserver0.tailspintoys.com first, if possible. If this server is unavailable, the resolver client can then use user@mailserver1.tailspintoys.com instead.

@         IN  MX   1    mailserver0
@         IN  MX   2    mailserver1

Note that the use of the "at" sign (@) in the records indicates that the mailer DNS domain name is the same as the name of origin (tailspintoys.com) for the zone.

Pointer (PTR) resource records

Pointer (PTR) resource records support the reverse lookup process, based on zones that are created and rooted in the in-addr.arpa domain. These records locate a computer by its IP address and resolve this information to the DNS domain name for that computer.

Pointer (PTR) resource records can be added to a zone in several ways:

  • You can manually create a pointer (PTR) resource record for a static TCP/IP client computer using DNS, either as a separate procedure or as part of the procedure for creating a host (A) resource record.

  • Computers use the DHCP Client service to dynamically register and update their pointer (PTR) resource record in DNS when an IP configuration change occurs.

  • All other Dynamic Host Configuration Protocol (DHCP)-enabled client computers can have their pointer (PTR) resource records registered and updated by the DHCP server if they obtain their IP lease from a qualified server. The Windows 2000, Windows Server 2003, and Windows Server 2008 DHCP Server service provides this capability.

The pointer (PTR) resource record is used only in reverse lookup zones to support reverse lookup.

Service location (SRV) resource records

Service location (SRV) resource records are required for location of Active Directory domain controllers. Typically, you can avoid manual administration of service location (SRV) resource records when you install Active Directory Domain Services (AD DS).

By default, the Active Directory Domain Services Installation Wizard attempts to locate a DNS server based on the list of preferred or alternate DNS servers, which are configured in any of its TCP/IP client properties, for any of its active network connections. If a DNS server that can accept dynamic update of the service location (SRV) resource record is contacted, the configuration process is complete. (This is also true for other resource records that are related to registering AD DS as a service in DNS.)

If, during the installation, a DNS server that can accept updates for the DNS domain name that is used to name your directory is not found, the wizard can install a DNS server locally and automatically configure it with a zone to support the Active Directory domain.

For example, if the Active Directory domain that you choose for your first domain in the forest is example.tailspintoys.com, you can add and configure a zone that is rooted at the DNS domain name of example.tailspintoys.com to use with the DNS server that is running on the new domain controller.

In the future, the service location (SRV) resource record may also be used to register and look up other well-known TCP/IP services on your network if applications implement and support DNS name queries that specify this record type.

Other resource records

Other additional resource records are supported by Windows Server 2008 DNS and are used less frequently in most zones. You can add these additional types of resource records as necessary with DNS Manager.