Windows Server 2003 : Installing and Configuring DNS Servers (part 2) - Creating Resource Records

4. Creating Resource Records

New zones contain only two resource records: the Start Of Authority (SOA) record corresponding to the zone, and a Name Server (NS) record corresponding to the local DNS server created for the zone. After you create a zone, you must add resource records to it. Although some records might be added automatically, others might need to be added manually.

To add common resource records for a zone, right-click the zone icon in the DNS console and from the shortcut menu, select the appropriate resource record you want to create, as shown in Figure 1.

Figure 1. Creating resource records

To select from a long list of resource record types to add to a zone, complete the following steps:

1.	Open the DNS console.
2.	In the console tree, right-click the applicable zone and select Other New Records. The Resource Record Type dialog box appears.
3.	In the Select A Resource Record Type list box, select the type of resource record you want to add.
4.	Click Create Record.
5.	In the New Resource Record dialog box, enter the information needed to complete the resource record.
6.	After you specify all the necessary information for the resource record, click OK to add the new record to the zone.
7.	Click Done to return to the DNS console.

Resource Record Format

Resource records appear in varying formats, depending on the context in which they are used. For example, when lookups and responses are made using DNS, resource records are represented in binary form in packets. In the DNS console, resource records are represented graphically so that they can be viewed and modified easily. However, at the source—in the zone database files—resource records are represented as text entries. In fact, by creating resource records in the DNS console, you are automatically adding text entries to the corresponding zone’s database file.

In these zone files, resource records have the following syntax:

Owner TTL Class Type RDATA

Table 1 describes each of these fields.

Table 1. Typical Resource Record Fields

Name	Description
Owner	The name of the host or the DNS domain to which this resource record belongs.
Time To Live (TTL)	A 32-bit integer that represents, in seconds, the length of time that a DNS server or client should cache this entry before it is discarded. This field is optional, and if it is not specified, the client uses the minimum TTL in the SOA record.
Class	The field that defines the protocol family in use. For Windows DNS servers, the resource record is always of the class Internet, abbreviated IN. This field is optional and is not automatically generated.
Type	The field that identifies the type of resource record, such as A or SRV.
RDATA	The resource record data. It is a variable-length field that represents the information being described by the resource record type. For example, in an A resource record, this is the 32-bit IP address that represents the host identified by the owner.

Most resource records are represented as single-line text entries. If an entry is going to span more than one line, parentheses can encapsulate the information. In many implementations of DNS, only the SOA resource record can contain multiple lines. For readability, blank lines and comments ignored by the DNS server are often inserted in the zone files. Comments always start with a semicolon (;) and end with a carriage return.

Record Types

The most common resource records you need to create manually include the following:

• Host (A)

• Alias (CNAME)

• Mail exchanger (MX)

• Pointer (PTR)

• Service location (SRV)

Host (A) Resource Records

Host (A) resource records make up the majority of resource records in a zone database. These records are used in a zone to associate DNS domain names of computers (or hosts) to their IP addresses. They can be added to a zone in different ways:

• You can manually create an A resource record for a static Transmission Control Protocol/Internet Protocol (TCP/IP) client computer using the DNS console or the Dnscmd.exe support tool at the command line.

• Computers running Windows Server 2003 use the DHCP Client service to dynamically register and update their own 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 A resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server. (The DHCP service provided with Windows 2000 and Windows Server 2003 support this feature.)

Once created in the DNS console, an A resource record that maps the host name server1.lucernepublishing.com to the IP address 172.16.48.1 is represented textually within the lucernepublishing.com.dns zone file as follows:

server1         A       172.16.48.1

Tip

If you can ping a computer by IP address but not by name, the computer is missing an A resource record in DNS. You can attempt to remedy this situation by executing the Ipconfig /registerdns command at the computer that is missing its A record—but only if the client computer is running a version of Windows 2000, Windows XP, or Windows Server 2003. For non-Windows clients, such as Linux, UNIX, and Macintosh computers, you must create the A resource record manually in DNS.

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. For example, the well-known server names (ftp, www) are registered using CNAME resource records. These records map the host name specific to a given service (such as ftp.lucernepublishing.com) to the actual A resource record of the computer hosting the service (such as server-boston.lucernepublishing.com).

CNAME resource records are also recommended for use in the following scenarios:

• When a host specified in an A resource record 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 resource records) that provide the same service (for example, a group of redundant Web servers)

Once created in the DNS console, a CNAME resource record that maps the alias ftp.lucernepublishing.com to the host name ftp1.lucernepublishing.com would be represented textually within the lucernepublishing.com.dns zone file as follows:

ftp               CNAME        ftp1.lucernepublishing.com.

Mail Exchanger (MX) Resource Records

The mail exchanger (MX) resource record is used by e-mail applications to locate a mail server within a zone. It allows a domain name such as lucernepublishing.com, specified in an e-mail address such as joe@lucernepublishing.com, to be mapped to the A resource record of a computer hosting the mail server for the domain. This type of record thus allows a DNS server to handle e-mail addresses in which no particular mail server is specified.

Often, multiple MX records are created to provide fault tolerance and failover to another mail server when the preferred server listed is not available. Multiple servers are given a server preference value, with the lower values representing higher preference. Once created in the DNS console, such MX resource records would be represented textually within the lucernepublishing.com.dns zone file as follows:

@     MX     1    mailserver1.lucernepublishing.com.
@     MX    10    mailserver2.lucernepublishing.com.
@     MX    20    mailserver3.lucernepublishing.com.

Pointer (PTR) Resource Records

The pointer (PTR) resource record is used only in reverse lookup zones to support reverse lookups, which perform queries for host names based on IP addresses. Reverse lookups are performed in zones rooted in the in-addr.arpa domain. PTR resource records are added to zones by the same manual and automatic methods used to add A resource records.

Once created in the DNS console, a PTR resource record that maps the IP address 172.16.48.1 to the host name server1.lucernepublishing.com would be represented textually within a zone file as follows:

1 PTR server1.lucernepublishing.com.

Service Location (SRV) Resource Records

Service location (SRV) resource records enable you to specify the location of specific services in a domain. Client applications that are SRV-aware can use DNS to retrieve the SRV resource records for the application servers.

Windows Server 2003 Active Directory is an example of an SRV-aware application. The Netlogon service uses SRV records to locate domain controllers in a domain by searching the domain for the Lightweight Directory Access Protocol (LDAP) service.

Tip

All the SRV records required for an Active Directory domain controller can be found in a file named Netlogon.dns, located in the WINDOWS\System32\Config folder. If SRV records are missing in your DNS zone, you can reload them automatically by running the Netdiag /fix command at a command prompt. (The Netdiag.exe command is available after you install Windows Server 2003 Support Tools from the Windows Server 2003 CD-ROM.)

If a computer needs to locate an LDAP server in the lucernepublishing.com domain, the DNS client sends an SRV query for the name:

_ldap._tcp.lucernepublishing.com.

The DNS server then responds to the client with all records matching the query.

Although most SRV resource records are created automatically, you might need to create them through the DNS console to add fault tolerance or troubleshoot network services. The following example shows the textual representation of two SRV records that have been configured manually in the DNS console:

_ldap._tcp     SRV    0   0  389    dc1.lucernepublishing.com.
               SRV    10  0  389    dc2.lucernepublishing.com.

In the example, an LDAP server (domain controller) with a priority of 0 (highest) is mapped to port 389 at the host dc1.lucernepublishing.com. A second domain controller with a lower priority of 10 is mapped to port 389 at the host dc2.lucernepublishing.com. Both entries have a 0 value in the weight field, which means no load balancing has been configured among servers with equal priority.

Tip

You can deploy Active Directory with the “least amount of administrative effort” by installing your network’s first DNS domains, along with its first Active Directory domains, on computers running Windows Server 2003. This news is hardly surprising because only in Windows environments are the many SRV records required for Active Directory created automatically. If you want to deploy DNS on a UNIX server and integrate the UNIX server into an Active Directory infrastructure, configure the UNIX server as a secondary DNS server.