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.
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:
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
[email protected], 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. |
