Share via

Managing resource records

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Managing resource records

After you create a zone, additional resource records need to be added to it. The most common resource records (RRs) to be added are:

  • Host (A)  For mapping a DNS domain name to an IP address used by a computer.

  • Alias (CNAME)  For mapping an alias DNS domain name to another primary or canonical name.

  • Mail Exchanger (MX)  For mapping a DNS domain name to the name of a computer that exchanges or forwards mail.

  • Pointer (PTR)  For mapping a reverse DNS domain name based on the IP address of a computer that points to the forward DNS domain name of that computer.

  • Service location (SRV)  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

Host (A) resource records are used in a zone to associate DNS domain names of computers (or hosts) to their IP addresses, and can be added to a zone in several ways:

  • You can manually create an A resource record for a static TCP/IP client computer using the DNS console.

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

  • DHCP-enabled client computers running earlier versions of Microsoft operating systems can have their A resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server (only the Windows 2000 and Windows Server 2003 DHCP Server service currently supports this feature).

The host (A) resource record is not required for all computers, but is needed by computers that share resources on a network. Any computer that shares resources and needs to be identified by its DNS domain name, needs to use A resource records to provide DNS name resolution to the IP address for the computer.

Most A RRs 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 comprise the majority of resource records in a zone database.

For more information, see Resource records reference.

Alias (CNAME) resource records

Alias (CNAME) resource records are also sometimes called canonical names. These records allow you to use more than one name to point to a single host, making it easy to do such things as host both an FTP server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered using CNAME RRs that map to the DNS host name, such as "server-1", for the server computer that hosts these services.

CNAME RRs are recommended for use in the following scenarios:

  • When a host specified in an A RR in the same zone needs to be renamed.

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

When renaming a computer with an existing A RR in the zone, you can use a CNAME RR temporarily, to allow a grace period for users and programs to switch from specifying the old computer name to using the new one. To do this, you need the following:

  • For the new DNS domain name of the computer, a new A RR is added to the zone.

  • For the old DNS domain name, a CNAME RR is added that points to the new A RR.

  • The original A RR for the old DNS domain name (and its associated PTR RR if applicable) is removed from the zone.

When using a CNAME RR 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 CNAME RR and later its associated A RR is deleted, the CNAME RR can waste server resources by trying to resolve queries for a name no longer used on the network.

The most common or popular use of a CNAME RR is to provide a permanent DNS aliased domain name for generic name resolution of a service-based name, such as www.example.microsoft.com to more than one computer or one IP address used in a Web server. For example, the following shows the basic syntax of how a CNAME RR is used.

alias_nameIN CNAMEprimary_canonical_name

In this example, a computer named host-a.example.microsoft.com needs to function as both a Web server named "www.example.microsoft.com." and an FTP server named "ftp.example.microsoft.com." To achieve the intended use for naming this computer, you can add and use the following CNAME entries in the example.microsoft.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 CNAME RR in the zone for ftp.example.microsoft.com and add an additional A RR to the zone for the new computer hosting the FTP server.

Based on the earlier example, if the new computer were named "host-b.example.microsoft.com", the new and revised A and CNAME RRs would be 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

For more information, see Resource records reference.

Mail exchanger (MX) resource records

The mail exchanger (MX) RR is used by e-mail applications to locate a mail server based on a DNS domain name used in the destination address for the e-mail recipient of a message. For example, a DNS query for the name "example.microsoft.com" could be used to find an MX RR, enabling an e-mail application to forward or exchange mail to a user with the e-mail address "user@microsoft.com."

The MX RR shows the DNS domain name for the computer or computers that process mail for a domain. If multiple MX RRs 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 shows the basic syntax for use of an MX RR.

mail_domain_nameIN MXpreference mailserver_host

By using the MX RRs shown below in the example.microsoft.com zone, mail addressed to user@example.microsoft.com is delivered to user@mailserver0.example.microsoft.com first if possible. If this server is unavailable, the resolver client can then use user@mailserver1.example.microsoft.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 (example.microsoft.com) for the zone.

For more information, see Resource records reference.

Pointer (PTR) resource records

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

PTR RRs can be added to a zone in several ways:

  • You can manually create a PTR RR for a static TCP/IP client computer using the DNS , either as a separate procedure or as part of the procedure for creating an A RR.

  • Computers use the DHCP Client service to dynamically register and update their PTR RR in DNS when an IP configuration change occurs.

  • All other DHCP-enabled client computers can have their PTR RRs registered and updated by the DHCP server if they obtain their IP lease from a qualified server. The Windows 2000 and Windows Server 2003 DHCP Server service provides this capability.

The pointer (PTR) resource record is used only in reverse lookup zones to support reverse lookup. For more information, see Resource records reference.

Service location (SRV) resource records

To locate Active Directory domain controllers, service location (SRV) RRs are required. Typically, you can avoid manual administration of the SRV RR when installing Active Directory.

By default, the Active Directory installation wizard attempts to locate a DNS server based on the list of preferred or alternate DNS servers, 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 SRV RR (and other RRs related to registering Active Directory as a service in DNS) is contacted, the configuration process is complete.

If, during the installation, a DNS server that can accept updates for the DNS domain name used to name your Active 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 chose for your first domain in the forest was example.microsoft.com, a zone rooted at the DNS domain name of example.microsoft.com would be added and configured to use with the DNS server running on the new domain controller.

Whether or not you install the DNS Server service locally, a file (Netlogon.dns) is written and created during the Active Directory installation process that contains the SRV RRs and other RRs needed to support the use of Active Directory. This file is created in the systemroot\System32\Config folder.

If you are using a DNS server that fits one of the following descriptions, you should use the records in Netlogon.dns to manually configure the primary zone on that server to support Active Directory.

  1. The computer operating your DNS server is running on another platform, such as UNIX, and cannot accept or recognize dynamic updates.

  2. A DNS server at this computer that is not the DNS Server service provided with the Windows Server 2003 family is authoritative for the primary zone corresponding to the DNS domain name for your Active Directory domain.

  3. The DNS server supports the SRV RR, as defined in the Internet draft, "A DNS RR specifying the location of services (DNS SRV)", but does not support dynamic updates.

    For example, the DNS Server service provided with Windows NT Server 4.0, when updated to Service Pack 4 or later, fits this description.

In the future, the SRV RR might also be used to register and lookup other well-known TCP/IP services on your network if applications implement and support DNS name queries that specify this record type. For more information, see Resource records reference.

Other resource records

Other additional resource records are supported by Windows Server 2003 DNS and are used less frequently in most zones. These additional types of resource records can be added as needed using the DNS console. For more information about supported resource records, see Resource records reference.