لطفا منتظر باشید ...
4.4 Setting Up DNS Data
Let''s configure the first of Movie
U.''s name servers. We''ll use the
DNS console for most of this process, so start it up if you
haven''t already done so. You don''t
have to run the DNS console on the machine running the name server,
but for now it''s easier if you do.
You''ll also need to have Administrator privileges to
use the DNS console; otherwise, you''ll only be able
to start the application, not manage any name servers with it.
4.4.1 Adding a New Server to the DNS Console
The first
step is
configuring the DNS console to
manage the primary
master name server for your zone. The primary master for a
zonealso called just the
primarystores information about the zone
on its disk. You make all changes to your zone on the primary master.
Select Action
Connect To DNS Server and specify
where the name server you want to managethe primary
masteris running. As you can see in Figure 4-9, you can choose either the local machine or
specify a name server running somewhere else. If the name server
isn''t local, enter its name or IP address. Leave the
box checked, which causes the DNS console to immediately contact the
server to obtain its status and a list of any zones it might already
be authoritative for.
Figure 4-9. Specifying the location of a name server to manage
The DNS console adds an icon in the left pane for that name server,
as in Figure 4-10.
Figure 4-10. The DNS console with a new server
It''s important to understand what we just did here.
We told the DNS console about a name server for it to manage and it
added that name server to its configuration. The DNS console did
not start the name server on the target machine.
If the name server isn''t already installed and
running, the DNS console can''t manage it and will
complain with the message, "The server is
unavailable. Would you like to add it anyway?"
Selecting Connect to DNS Server adds
that name server to the list of servers the DNS console knows about.
As you might expect, selecting the server and choosing Action
Delete (or just pressing the Delete key) removes the server from the DNSconsole''s configuration but doesn''t
change anything on the name server itself. The server will still be
runningyou can use Connect to DNS
Server to add it, and you''ll be right
back where you started.
4.4.2 Creating a New Zone
Now
it''s time
to create the movie.edu zone. Select the name
server on the left where you want to create the zone.
(There''s only one server now,
terminator, but the DNS console could know about
multiple servers.) Choose Action
New Zone.You''ll see the New Zone Wizard, as in Figure 4-11.
Figure 4-11. New Zone Wizard, first window
To continue, click Next. In the next window (see Figure 4-12), you have three choices for the type of zone:
Primary zone, Secondary zone, and Stub
zone. For now, choose Primary
zone and click Next.
Notice that the option to store this zone''s data in
Active Directory is greyed out. Microsoft calls this feature
Active Directory integration and
we''ll talk about it more in Chapter 8.
Figure 4-12. New Zone Wizard, second window
Now you need to choose whether this is a forward- or reverse-mapping
zone, as shown in Figure 4-13.
movie.edu is, of course, a forward-mapping zone,
so make that selection and click Next.
Figure 4-13. New Zone Wizard, third window
Getting tired of all these windows yet? In the next one, shown in
Figure 4-14, type the domain name of the zone, which
is movie.edu. Click Next.
Figure 4-14. New Zone Wizard, fourth window
Now you need to specify the file that will hold all the zone
information, as shown in Figure 4-15.
Figure 4-15. New Zone Wizard, fifth window
The zone file, also called a
zone datafile, is the zone''s
permanent storage location. It''s the file on the
name server''s disk where all the information about
the zone is stored: it contains all the zone''s
resource records. Other name servers require you to edit the zone
datafile to make changes to the zone, but the DNS console allows you
to avoid editing the file by hand. As a result, you probably
won''t see the zone datafiles very much.
We''ll talk about their format later in this chapter.
Even if you won''t be looking at it often, you need
to specify a zone datafile name when you create a zone. The server
expects these files to be in
%SystemRoot%\System32\DNS.
Microsoft''s suggested naming convention uses the
domain name of the zone followed by the .dns
extension. (Notice that the DNS console has filled in the filename
based on the zone name.) You can name the zone file whatever you
want, but as long as the DNS console fills in the field for you, we
recommend sticking with its suggestion. You may be familiar with
other naming conventions, such as db. followed
by the zone''s domain name (e.g.,
db.movie.edu). In fact, that''s
the recommendation in our sister book, DNS and
BIND. In the case of the DNS console, however,
it''s best to go along with
Microsoft''s default .dns
extension.
When you''ve entered a filename (or left the
automatically chosen name alone), click Next to display the window shown in Figure 4-16, which asks you to choose this
zone''s policy for dynamic updates. Dynamic updates
are a relatively recent extension to the DNS protocol that we
describe in detail in Chapter 11. Briefly, they
allow another entitysuch as a domain controller or a DHCP
serverto update the contents of a zone by sending a message to
the name server over the network. The alternative (and traditional)
way to make changes to the zone involves using the DNS console as
we''re about to describe. As you might guess,
allowing just anyone to send messages to your name server to change
your zone is a significant security risk! That''s why
the DNS console asks you up front, when creating the zone, how you
want to handle dynamic updates. Some Windows components, such as
domain controllers and DHCP servers, use dynamic updates to keep DNS
information up to date, so it''s possible
you''ll want to enable this feature eventually. But
for now, check the third option, Do not allow
dynamic updates, to leave dynamic update disabled while we
set things up.
Figure 4-16. New Zone Wizard, sixth window
Click Next and
you''ll see the confirmation window shown in Figure 4-17.
Figure 4-17. New Zone Wizard confirmation window
Click Finish to create the zone. If
we double-click on terminator in the left pane,
then double-click on Forward Lookup
Zones and select the movie.edu zone,
we see a window like the one pictured in Figure 4-18. The DNS console has created the zone and a
few resource records. Let''s talk about them one by
one.
Figure 4-18. The DNS console with a new zone
4.4.2.1 The SOA record
The first record displayed is the start of authority, or
SOA,
resource record for the movie.edu zone.
It''s a little tricky to see that the name of this
record is really movie.edu, since the DNS
console displays (same as parent
folder) in the Name
column. You need to look at the domain name selected in the left pane
to know the domain name of this resource record.
The SOA record indicates that this name server is the best source of
information for the data within this zone. Our name server is
authoritative for the movie.edu zone because of
the SOA record. An SOA record is required in each zone, and there can
be one, and only one, SOA record in a zone.
Double-click the SOA record to view its details.
You''ll see a window like the one in Figure 4-19.
Figure 4-19. The movie.edu SOA record
Let''s skip that first
field, Serial number, for
nowdon''t worry, we''ll cover
it later in the chapterand go on to the next field. The second
field is the name of the primary master name server for this zone.
(You may hear it called the MNAME field, which is its official name.)
The third field contains the email address of the person in charge of
the zone (to turn this field into an email address, you replace the
first dot with an at sign, @). The DNS console defaults to a username
of hostmaster, but in other zones you might see
root, postmaster, or
administrator as the email address. Name servers
won''t use these namesthey are meant for human
consumption. If you notice a problem in someone''s
zone, you can send an email message to the listed email address.
Most of the remaining fields are for use by secondary name servers
(also known as slave name servers) and are discussed when we
introduce secondary name servers later in this chapter. For now,
assume these are reasonable values.
4.4.2.2 The NS record
The
next record is an NS (name server) resource record. There should be
one NS record for each name server authoritative for the zone. Like
the SOA record, NS records are attached to the
zone''s domain name. In our example, the NS records
are attached to movie.edu. Right now
there''s only one name server (the primary master),
but as we configure secondary name servers, we''ll
add NS records. The DNS console created an NS record for
terminator because it''s a name
serverthe primary master name serverfor
movie.edu.
4.4.2.3 The A record
The final
automatically created record is an address record or A record.
Address records fulfill the main purpose of DNS: they provide
name-to-address mapping. Each A record maps a domain name, like
terminator.movie.edu, to an IP address, like
192.249.249.3.
Every NS record needs a corresponding A record in some zone. Think
about it: an NS record says, "To find out
information about this zone, go to this name
server." To use the NS record, you need the IP
address of the name server it specifies. In this case, the name of
the name server, terminator.movie.edu, is
contained in the movie.edu zone we just created,
so the DNS console automatically created the A record for
terminator.movie.edu to specify its IP address.
When you create a new zone, the DNS console creates an address record
for the primary name server. It uses the hostname configured in the
primary master''s DNS configuration.
Note that some abbreviating is going on in the DNS
console''s display. The DNS console displays only
terminator, but the fully qualified domain name
of this host is terminator.movie.edu. The DNS
console normally displays a relative (that is, abbreviated) domain
name on the right, so you have to look at what zone or domain is
selected on the left to construct the fully qualified domain name.
And recall that when records are attached to the name of the zone
(which is the case for the SOA and NS records here), the DNS console
displays the somewhat cryptic phrase (same as
parent folder) in the Name column.
You''re probably anxious to add resource records for
the rest of your zone, but it''s best to create
the
reverse-mapping (in-addr.arpa) zones first.
4.4.3 Creating a New Reverse-Mapping Zone
Zones
like movie.edu handle mapping names to addresses using A
records. But mapping addresses back to namesreverse
mappingis just as important. As you may recall from Chapter 2, a special portion of the namespace, the
in-addr.arpa domain, is designated for reverse
mapping. There''s one domain name in
in-addr.arpa for every possible IP address, and
PTR (pointer) records attached to a domain name provide the actual
reverse mapping. Just think of a PTR record as the opposite of an A
record.
So after we create movie.edu,
we''re not done. Movie U. has two /24 networks,
192.249.249/24 and 192.253.253/24. We need to create the
corresponding in-addr.arpa zones for reverse
mapping with the DNS console:
249.249.192.in-addr.arpa and
253.253.192.in-addr.arpa.
The process for creating an in-addr.arpa zone is
the same as that for creating any other zone. Select
terminator in the left pane and choose Action
New Zone. Follow the prompts in the New ZoneWizard as we did earlier, except this time choose Reverse lookup zone in the third window. Figure 4-20 shows the fourth window of the New Zone Wizard
when creating a reverse-mapping zone.
Figure 4-20. Specifying the network number or name of a reverse-mapping zone
We specified the network number (see the selected field), and the DNS
console automatically calculated the zone name (see the grayed-out
field). Click Next and the wizard
concludes as shown earlier.
Select the newly created zone in the left pane to see its contents in
the right pane. Note that, just as it did with the
movie.edu zone, the DNS console automatically
creates the SOA record and an NS record.
For Movie U., we''ll repeat this process to create
the 253.253.192.in-addr.arpa zone. You create
in-addr.arpa zones according to the networks you
have. Usually there''s one
in-addr.arpa zone per /24 (or smaller) network.
Larger networks are often broken into several
in-addr.arpa zones to make management easier.
The zones usually correspond to subnets. This topic is
covered in more detail in Chapter 10.
4.4.4 Adding Resource Records
Now that we''ve created Movie U.''s
zones, we can add information about all its machines. Each machine
requires two resource records: an A record in the
movie.edu zone to provide name-to-address
mapping and a PTR record in the appropriate
in-addr.arpa zone to provide address-to-name
mapping. Adding the A record is intuitive, but it''s
easy to forget about the PTR record. The DNS console makes the job
easier with the New Host command,
which creates an A record and a PTR record in one pass.
Select a forward-mapping zone (like
movie.edu) and choose Action
New Host (A). Enter the name of the host andits IP address. To create the PTR record as well, you also need to
check the Create associated pointer (PTR)
record box. The window looks like the one in Figure 4-21.
Figure 4-21. The New Host window
You''ll notice that we typed a relative domain name
(robocop) and not a fully qualified domain name
(robocop.movie.edu). The DNS console is being
helpful here and saving you some typing: it appends the domain name
of the zone selected in the left pane (i.e., the zone that
you''re adding the new host to) to create a fully
qualified domain name as shown.
4.4.4.1 Aliases
Looking
back at Movie U.''s host table in the beginning of
the chapter, you''ll see that some hosts have
aliases. (The aliases are any additional names after the first one
listed.) For example, terminator is also known
as bigt. A special resource record called the
CNAME record is used to make an alias. The name of this record is
confusing because CNAME is short for canonical name, which means the
"real" name of the host. But a
CNAME record doesn''t make a canonical name; it makes
an alias. All other types of records make a canonical name. We
recommend thinking of it this way: CNAME records
point to canonical names while other record
types make canonical names.
To create an alias, select the zone to which you want to add the
record on the left, and choose Action
New Alias (CNAME). You''ll seea window that looks like the one in Figure 4-22.
Figure 4-22. Creating a CNAME record
The input shown in Figure 4-22 will generate an
alias from bigt.movie.edu to
terminator.movie.edu. The Fully qualified domain name (FQDN) field shows
the full name of the alias, which resides in the current zone. But
the name that the alias points to (labeled Fully qualified name (FQDN) for target host)
can point anywhere, to any domain name. We could alias
bigt.movie.edu to
www.whitehouse.gov if we wanted to. An important
note, however: if you leave off the domain in the canonical name
field, the zone''s domain name is
not appended automatically. You should always
enter a fully qualified domain name in the last field.
It''s important to know
that the name server handles CNAME records in a different manner than
aliases are handled in the host table. When a name server looks up a
name and finds a CNAME record, it replaces the alias with the
canonical name and looks up the new name. For example, when the name
server looks up bigt.movie.edu, it finds a CNAME
record pointing to terminator.movie.edu. Then it
looks up terminator.movie.edu, and its address
is returned.
One thing you must remember about aliases like
bigt is that they should never appear in the
data portion (that is, on the right side) of a resource record.
Stated differently, always use the canonical name
(terminator) in the data portion of the resource
record. Notice that the NS records use the canonical name.
Sometimes you can use an A record to get the effect of an alias.
Suppose you have a router, like wormhole, and
you want to check one of the interfaces. One common troubleshooting
technique is to ping the interface to verify
that it is responding. If you ping the name
wormhole, the name server returns the addresses
of both interfaces. ping uses the first address
in the list. But which address is first?
The solution is to create two A records for
wormhole. We could use the New Host command to create them as we did
earlier in this chapter, but we''ll show you another
way. The Other New Records command
lets you choose from 22 different resource records to create. Choose
Action
Other New Records and you''llsee a window like Figure 4-23. Select a record type
to see its description. We''ve selected Host (A), and after we select Create Record we''ll see the
same New Host window that we showed earlier, which
we''ll use to add an A record for
wh249.movie.edu.
Figure 4-23. Other new records window
With the host table, we chose the address we wanted by using either
wh249 or wh253each
name referred to one of the
host''s addresses. To provide equivalent capability
with DNS, we didn''t make wh249
and wh253 into aliases (CNAME records). That
would result in both addresses for wormhole
being returned when we looked up the alias. Instead, we used address
records. Now, to check the operation of the 192.253.253.1 interface
on wormhole, we ping
wh253 since it refers to only one address. The
same applies to wh249.
4.4.4.2 One more note about PTR records
We now
have two A records, wormhole.movie.edu and
wh249.movie.edu, pointing to the same address,
192.249.249.1. We also have a PTR record pointing from
1.249.249.192.in-addr.arpa to
wormhole.movie.edu. (This record was added
automatically to the 249.249.192.in-addr.arpa
zone by the New Host option.
Remember that addresses are looked up as names: the IP address is
reversed, and in-addr.arpa is appended.) Thus,
192.249.249.1 maps to wormhole.movie.edu and not
to wh249.movie.edu. Should you create another
PTR record that maps 192.249.249.1 to
wh249.movie.edu? You can
create two PTR recordsit''s perfectly
legalbut most systems are not prepared to see more than one
name for an address. We recommend that you don''t
bother with multiple PTR records since so few systems can use them.
4.4.5 Where Is All This Information Stored?
You may be
wondering what''s
happened to all the
resource records
we''ve been entering. Where are they being stored?
The answer is: in the memory of the DNS server process. We mentioned
earlier that the DNS console communicates with the DNS server using
an RPC mechanism. As you add records to a zone with the DNS console,
they are added "on the fly" to the
name server''s memory. Of course, the name
server''s memory is transientwhen the name
server process stops, its memory is lost. Obviously it needs a
permanent storage location, too.
This is where the zone datafiles
specified when we created the zones come in. The zone datafiles are
the zones'' permanent storage location, holding all
the zones'' resource records. If you use the DNS
console to make a change to a zone, the copy of the zone in the name
server''s memory is changed, and a flag is set to
update that zone''s datafile. The name server updates
the zone datafile when it exits, unless you tell it to update the
file sooner. Choosing Action
Update Server DataFiles (available when a name server is selected in the
left pane) causes the name server to update the zone datafiles of all
the zones for which it''s a primary (if the version
of a zone in the server''s memory is more recent than
the version on disk). There''s also a per-zone
version of this command: with a primary zone selected in the left
pane, selecting Action
Update Server Data Filecauses the server to update only that
zone''s file. To avoid losing data, we recommend
using Action
Update Server Data File(s) after a
batch of changesuse it like you use the Save command in other applications. Of course,
the difference here is that the server will save
your data if it exits gracefully. You don''t have to
use Action
Update Server Data File(s) after a
batch of changes, but it doesn''t hurt anything and
you''ll sleep better.
As you''ve probably guessed, when the name server
starts up, it reads the zone datafiles into memory. When you select
Action
Refresh or press F5, the DNS console queries the name serverand updates the console''s display.
If you''ve been keeping track,
you''ll realize that DNS information exists in three
places: zone datafiles, the name server''s memory,
and the DNS console''s window. The diagram in Figure 4-24 helps explain how the information flows.
Figure 4-24. Where everything is stored
4.4.6 The Zone Datafiles
Let''s take a look at the
zone datafiles for Movie U. After
inputting the remaining host table entries, we end up with the
display shown in Figure 4-2. (Of course, this view
shows only the contents of movie.edu. The
249.249.192.in-addr.arpa and
253.253.192.in-addr.arpa zones are populated
with PTR records.)
Next we select Action
Update Server DataFiles, and the server generates three files in
%SystemRoot%\System32\DNS:
movie.edu.dns,
249.249.192.in-addr.arpa.dns, and
253.253.192.in-addr.arpa.dns. We include them
here.
4.4.6.1 Contents of movie.edu.dns
;
; Database file movie.edu.dns for movie.edu zone.
; Zone version: 17
;
@ IN SOA terminator.movie.edu. hostmaster.movie.edu. (
17 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL
;
; Zone NS records
;
@ NS terminator.movie.edu.
;
; Zone records
;
bigt CNAME terminator.movie.edu.
carrie A 192.253.253.4
dh CNAME diehard.movie.edu.
diehard A 192.249.249.4
misery A 192.253.253.2
robocop A 192.249.249.2
shining A 192.253.253.3
terminator A 192.249.249.3
wh CNAME wormhole.movie.edu.
wh249 A 192.249.249.1
wh253 A 192.253.253.1
wormhole A 192.253.253.1
A 192.249.249.1
4.4.6.2 Contents of 249.249.192.in-addr.arpa.dns
;
; Database file 249.249.192.in-addr.arpa.dns for 249.249.192.in-addr.arpa zone.
; Zone version: 7
;
@ IN SOA terminator.movie.edu. hostmaster.movie.edu. (
7 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL
;
; Zone NS records
;
@ NS terminator.movie.edu.
;
; Zone records
;
1 PTR wormhole.movie.edu.
2 PTR robocop.movie.edu.
3 PTR terminator.movie.edu.
4 PTR diehard.movie.edu.
4.4.6.3 Contents of 253.253.192.in-addr.arpa.dns
;
; Database file 253.253.192.in-addr.arpa.dns for 253.253.192.in-addr.arpa zone.
; Zone version: 7
;
@ IN SOA terminator.movie.edu. hostmaster.movie.edu. (
7 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL
;
; Zone NS records
;
@ NS terminator.movie.edu.
;
; Zone
records
;
1 PTR wormhole.movie.edu.
2 PTR misery.movie.edu.
3 PTR shining.movie.edu.
4 PTR carrie.movie.edu.
4.4.7 Zone Datafile Format
The format of zone datafiles is
specified in the DNS standards. That
means all name servers, whether Microsoft DNS Server or the BIND name
server, can read each other''s zone datafiles.
You''ve probably already guessed that the semicolon
is the comment character. It can appear anywhere on a line, and
anything to the right is considered a comment and is ignored by the
name server. Blank lines are okay, too.
Each resource record must start in the first column of the
fileno preceding whitespace. (Don''t be
confused by the examples in this book, which are indented because of
the way the book is formatted.) Resource records are
case-insensitiveyou can use uppercase or lowercase. The name
server doesn''t preserve the case, though. It matches
the case of the reply to the case of the query. For example, if a
record is written as terminator in the zone
datafile but you query for Terminator, the
server responds with
Terminator.
Resource records are broken up into fields, with any amount of
whitespace (tabs or spaces) separating the fields.
The first field, called the owner, is the domain name of the record.
Put another way, it''s the node in the namespace to
which the resource record is attached. You''ve seen
the domain name on the left side of the
right pane of the DNS console.
The next field in our examples is the class, IN, which stands for
Internet. Other classes exist, but none of them are currently in
widespread use. Our examples use only the IN class.
The field after that is the record type. We''ve
already discussed the SOA, NS, A, PTR, and CNAME record types, and
you''ve probably browsed through the list of other
record types in the DNS console''s Other New
Records window. The type simply specifies what type of
data is associated with the domain name on the right: A means IP
address, NS means the name of an authoritative name server, and so
on.
That''s a good lead-in to the final field, the RDATA
or resource record data field. This field holds the kind of data
specified by the record type. It can be divided into multiple
subfields, depending on the type. For example, A records specify only
one parameter, an IP address, but the SOA record specifies seven
parameters (remember all those fields in Figure 4-19?).
Speaking of the SOA record, you''ll notice in the
examples that it''s the only record spanning multiple
lines. If you ever have to edit zone datafiles by hand, you can use
parentheses to allow a resource record to span multiple lines. This
trick works for all record types, not just SOA.
Domain names appear a lot in resource
records. The left side of every resource record is a domain name, and
the right side (RDATA field) of many record types also contains
domain names (for example, NS and SOA records). Using a fully
qualified domain name in each case is perfectly legal, but it would
be a lot of work: imagine having to type
movie.edu at the end of every hostname if you
were entering these files by hand. Fortunately, abbreviations are
allowed. You need to understand the abbreviations because the
Microsoft DNS Server uses them in records it generates.
4.4.7.1 Appending domains
Every
zone has a domain name: it''s just the name of the
zone. (This probably strikes you as pretty obvious.) This domain name
is the key to the most useful shortcut. This domain name is the
origin of all the data in the datafile. The
origin is appended to all domain names in the file not ending in a
dot. The origin is different for each file because each file is
associated with a different zone, each of which has a different
domain name.
Since the origin is appended to names, instead of entering
robocop''s address in
movie.edu.dns as this:
robocop.movie.edu. IN A 192.249.249.2
the server generated it like this:
robocop A 192.249.249.2
The server also used another shortcut and omitted the class, IN. If
you omit the class on a record, the previous
record''s class is used. Since this file uses only
the IN class, it makes sense to specify it once on the first record
in the file and leave it off the subsequent records. In that case,
the first record''s class applies to all the other
records.
In 192.249.249.in-addr.arpa.dns, this is the
long way to write this record:
2.249.249.192.in-addr.arpa. IN PTR robocop.movie.edu.
But since 249.249.192.in-addr.arpa is the
origin, the server generated:
2 PTR robocop.movie.edu.
Notice that all the fully qualified domain names in the file end in a
dot. That tells the server that this domain name is complete and
should be left alone. Suppose you forgot the trailing dot. An entry
like this:
robocop.movie.edu A 192.249.249.2
turns into an entry for
robocop.movie.edu.movie.edu, not what you
intended at all.
4.4.7.2 @ notation
If the domain name is the
same as the origin, the name can be specified
with an at sign (@). This is most often seen in the SOA record in
datafiles generated by hand, but the Microsoft DNS Server also uses
the @ notation in NS records. In the
movie.edu.dns file in the previous example, the
@ stands for movie.edu. Of course, in the
249.249.192.in-addr.arpa.dns file, the @ stands
for 249.249.192.in-addr.arpa, and in the
253.253.192.in-addr.arpa.dns file . . . well,
you get the idea.
4.4.7.3 Repeat last name
If there is a space or a tab in column one, the name from the last
resource record is used. This shortcut gets used when a name has
multiple resource records. This example shows two address records for
one name:
wormhole A 192.253.253.1
A 192.249.249.1
In the second address record, the name wormhole
is implied. You can use this shortcut even if the resource records
are of different typesfor example, if
wormhole also had a TXT (arbitrary text)
record.
4.4.8 The Loopback Address
Those
of you familiar with the BIND
name server may be wondering
if we forgot about the
loopback address. If we were setting
up a BIND name server, it would need one additional zone datafile to
cover the loopback network: the special address
that hosts use to direct traffic to themselves. This network is
(almost) always 127.0.0.0, and the host number is (almost) always
127.0.0.1. Therefore, the name of this file would be
0.0.127.in-addr.arpa.dns, and it would look like
the other in-addr.arpa.dns files.
The following would be the contents of the
0.0.127.in-addr.arpa.dns file:
@ IN SOA terminator.movie.edu. administrator.movie.edu. (
1 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ NS terminator.movie.edu.
;
; Zone records
;
1 PTR localhost.
Why do name servers need this file? Think about it for a second. No
one was given responsibility for network 127.0.0.0, yet systems use
it for a loopback address. Since no one has direct responsibility,
everyone who uses it is responsible for it individually. If you omit
this file on a name server, it will still operate. However, a lookup
of 127.0.0.1 might fail: the name server will send the query to a
root name server that might not be configured to map 127.0.0.1 to a
name.
With the Microsoft DNS Server, you don''t have to
worry about creating this file and making your name server
authoritative for the in-addr.arpa zone
corresponding to network 127.0.0.0. The server is authoritative for
this zone by default. It''s called an
automatically created zone and is visible in the
DNS console only in advanced mode. Select View
Advanced and you can see the threeautomatically created zones shown in Figure 4-25.
Figure 4-25. The DNS console showing automatically created zones
We''ve
drilled down into the 127.in-addr.arpa zone to
show that there''s a PTR record for
1.0.0.127.in-addr.arpa pointing to the domain
name localhost. In other words, the Microsoft
DNS Server reverse-maps the IP address 127.0.0.1 to the domain name
localhost "out of the
box" without any work on your part.
The
0.in-addr.arpa and
255.in-addr.arpa zones are empty, save for NS
and A records. Some hosts attempt to reverse-map the IP addresses
0.0.0.0 and 255.255.255.255, and these zones cause the local server
to return an immediate Name Error (also known as NXDOMAIN, which is
short for nonexistent domain) for those queries rather than asking a
root name server.
4.4.9 The Root Hints Data
Besides your local
information, the name server also needs
to know where the name servers for the root zone are. (Remember that
the resolution process starts at the root zone, so knowing which name
servers are authoritative for the root zone is critical.) This
information is stored in a file called the root name server
hints file, which is named
%SystemRoot%\System32\DNS\cache.dns on your name
server. The Microsoft DNS Server ships with a version of this file
that looks like this (or at least it did when this book was
published):
;
; cache.dns -- DNS CACHE FILE
;
; Initial cache data for root domain servers.
;
; YOU SHOULD CHANGE:
; -> Nothing if connected to the Internet. Edit this file only when
; updated root name server list is released.
; OR
; -> If NOT connected to the Internet, remove these records and replace
; with NS and A records for the DNS server authoritative for the
; root domain at your site.
;
; Note, if you are a root domain server, for your own private intranet,
; no cache is required, and you may edit your boot file to remove
; it.
;
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC
; under anonymous FTP as
; file /domain/named.root
; on server FTP.INTERNIC.NET
;
; last update: Nov 5, 2002
; related version of root zone: 2002110501
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; operated by VeriSign, Inc.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
;
; housed in LINX, operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; operated by IANA
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File
The domain name "." refers to the
root zone.
This information can also be retrieved from the Internet host
ftp.rs.internic.net (198.41.0.7). Use anonymous
FTP to retrieve the file named.root from the
domain subdirectory. However, you probably
won''t ever need to update your
server''s cache.dns file.
Because the ability to reach the root name servers is so important,
the Microsoft DNS Server goes out of its way to make sure its list of
root name servers is always up to date. It views the contents of
cache.dns somewhat suspiciously and
doesn''t use that list of name servers directly.
(That''s why this file is called the root
hints.) Rather, when the server starts up, it
chooses a root name server from cache.dns at
random and asks it for the current list of root name servers. After
all, who would know the current list of root name servers better than
one of the root name servers? The list returned is the one used by
the name server to start the resolution process and is the list you
see when you drill down in the left pane of the DNS console. The DNS
server also overwrites the contents of cache.dns
with the updated list. As a result, if
you''ve started the DNS server even just once, your
cache.dns will look different than the one shown
here because the server doesn''t preserve the
comments when it overwrites the file.
You can also view this information from within the DNS console.
Select a name server in the left pane and choose Action
Properties Root Hints tab to see a window like the oneshown in Figure 4-26.
Figure 4-26. Root Hints
window
Finally, you may be wondering what the 3600000s
in the file are for. In older versions of this file, this number was
99999999. It dates back to the behavior of early
versions of BIND. The BIND name server used to put the contents of
the root hints file directly into its cache, and it had to know how
long to keep these records active. The 99999999s
meant a very long time. The root name server
data was to be kept active for as long as the server ran. Since both
BIND and the Microsoft DNS Server now store the root hints data in a
special place and don''t discard it if it times out,
the TTL is unnecessary. But it''s not harmful to have
the 3600000s, and it makes for interesting DNS
folklore when you pass responsibility to the next name server
administrator.
