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.
The first step is configuring the DNS console to manage the primary master name server for your zone. The primary master for a zone—also called just the primary—stores information about the zone on its disk. You make all changes to your zone on the primary master.
Select Action → Connect To Computer... and specify where the name server you want manage—the primary master—is running, either on the local machine or somewhere else. If the name server isn’t local, enter its name or IP address. The DNS console adds an icon in the left pane for that name server, as in Figure 4-5.
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 Computer 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 DNS console’s configuration but doesn’t change anything on the name server itself. The server will still be running—you can use Connect To Computer... to add it, and you’ll be right back where you started.
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-6.
To continue, click Next. In the next window (Figure 4-7), you have three choices for the type of zone: Active Directory integrated, Standard primary and Standard secondary. For now, choose Standard primary and click Next. We’ll talk more about Active Directory integration of zones in Chapter 11.
Now you need to choose the whether this is a forward- or reverse-mapping zone, as shown in Figure 4-8. movie.edu is, of course, a forward-mapping zone, so make that selection and click Next.
Getting tired of all these windows yet? In the next one, shown in Figure 4-9, type the domain name of the zone, which is movie.edu. Click Next.
Now you need to specify the file that will hold all the zone information, as shown in Figure 4-10.
The zone file, also called a zone data file, 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 data file to make changes to the zone, but the DNS console allows you to avoid any hand-editing. As a result, you probably won’t see the zone data files 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 data filename 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.
When you’ve entered a filename (or left the automatically chosen name alone), click Next, and you’ll see the confirmation window shown in Figure 4-11.
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-12. The DNS console has created the zone and a few resource records. Let’s talk about them one by one.
The first record displayed is the start of authority, or SOA,[16] 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-13.
Let’s skip that first field, Serial number, for now—don’t worry, we’ll cover it later in the chapter—and 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 (if you replace the first dot with an at sign, @). The DNS console defaults to a username of administrator, but in other zones you’ll often see root, postmaster, or hostmaster as the email address. Name servers won’t use these names—they 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 slave name servers and are discussed when we introduce slave name servers later in this chapter. For now, assume these are reasonable values.
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 slave name servers, we’ll add NS records. The DNS console created an NS record for terminator because it’s a name server—the primary master name server—for movie.edu.
Unfortunately, we’re missing a required record: the address (A) record for terminator.movie.edu, the host running the name server. 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 we need an A record for terminator.movie.edu in our zone that will specify its IP address. We’re bringing this up now because those of you familiar with Windows NT 4.0 might remember that DNS Manager (the former incarnation of the DNS console) would have automatically created an A record for terminator.movie.edu when the movie.edu zone was created.We will have to manually add this A record, but not just yet: it’s best to create the reverse-mapping (in-addr.arpa) zones first.
Zones like movie.edu handle mapping names to addresses using A records. But mapping addresses back to names—reverse mapping—is 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 Zone Wizard as we did earlier, except this time choose Reverse lookup zone in the third window. Figure 4-14 shows the fourth window of the New Zone Wizard when creating 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 will 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 9.
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.... Enter the name of the host and its 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-15.
You’ll notice that we typed a relative domain name (terminator) and not a fully qualified domain name (terminator.movie.edu.) The DNS console requires a relative domain name in this field. (It won’t even let you type a period!) It appends the domain name of the zone selected in the DNS console’s left pane (and shown in the Location field in the window) to create a fully qualified domain name.
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.... You’ll see a window that looks like the one in Figure 4-16.
The input in Figure 4-16 will generate an alias from bigt.movie.edu to terminator.movie.edu. The Parent domain field is just a reminder of the current domain. As was the case with the New Host command, you must enter a single-label (that is, no periods) name in the Alias name field: the Alias name field is always relative to the current domain. There is no such restriction for the canonical name field (labeled Fully qualified name for target host)—you can point this alias anywhere. 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 (as was the case with DNS Manager in Windows NT 4.0). 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 name 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 above, but we’ll show you another way. The Other New Records command lets you choose from 19 different resource records to create. Choose Action → Other New Records... and you’ll see a window like Figure 4-17. Select a record type to see its description. We’ve selected Host (which is the nonadvanced-mode way of specifying an A record), 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.
With the host table, we chose the address we wanted by using either wh249 or wh253—each 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.
To state this as a general rule: if a host is multihomed (i.e., has more than one network interface), create an address (A) record for each alias unique to one address. Create a CNAME record for each alias common to all the addresses.
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 command. 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 records—it’s perfectly legal—but 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.
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 transient—when the name server process stops, its memory is lost. Obviously it needs a permanent storage location, too.
This is where the zone data files we specified when we created the zones come in. The zone data files 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 data file. The name server updates the zone data file when it exits, unless you tell it to update the file sooner. The command Action → Update Server Data Files causes the name server to update the zone data files 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). To avoid losing data, we recommend using Action → Update Server Data Files after any changes—use 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 Files after a batch of changes, but it doesn’t hurt anything and you’ll be able to sleep better.
As you’ve probably guessed, when the name server starts up, it reads the zone data files into memory. When you select Action → Refresh or press F5, the DNS console queries the name server and updates the console’s display.
If you’ve been keeping track, you’ll realize that DNS information exists in three places: zone data files, the name server’s memory, and the DNS console’s window. The diagram in Figure 4-18 helps explain how the information flows.
Let’s take a look at the zone data files for Movie U. After inputting the remaining host table entries, we end up with the display shown previously 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 Data Files, 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. They look like the
following.
Contents of movie.edu.dns:
;
; Data file movie.edu.dns for movie.edu zone.
; Zone version: 4l
;
@ IN SOA terminator.movie.edu. administrator.movie.edu. (
1 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ IN NS terminator
;
; Zone records
;
bigt IN CNAME terminator
carrie IN A 192.253.253.4
dh IN CNAME diehard
diehard IN A 192.249.249.4
misery IN A 192.253.253.2
robocop IN A 192.249.249.2
shining IN A 192.253.253.3
terminator IN A 192.249.249.3
wh IN CNAME wormhole
wh249 IN A 192.249.249.1
wh253 IN A 192.253.253.1
wormhole IN A 192.249.249.1
IN A 192.253.253.1Contents of 249.249.192.in-addr.arpa.dns:
;
; Data file 249.249.192.in-addr.arpa.dns for 249.249.192.in-addr.arpa zone.
; Zone version: 5l
;
@ IN SOA terminator.movie.edu. administrator.movie.edu. (
5 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ IN NS terminator.movie.edu.
;
; Zone records
;
1 IN PTR wormhole.movie.edu.
2 IN PTR robocop.movie.edu.
3 IN PTR terminator.movie.edu.
4 IN PTR diehard.movie.edu.Contents of 253.253.192.in-addr.arpa.dns:
;
; Data file 253.253.192.in-addr.arpa.dns for 253.253.192.in-addr.arpa zone.
; Zone version: 4l
;
@ IN SOA terminator.movie.edu. administrator.movie.edu. (
4 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ IN NS terminator.movie.edu.
;
; Zone records
;
1 IN PTR wormhole.movie.edu.
2 IN PTR misery.movie.edu.
3 IN PTR shining.movie.edu.
4 IN PTR carrie.movie.edu.The format of zone data files 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 data files.
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 file—no 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-insensitive—you 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 data file 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. (Got that?)
The next field in our examples is the class, IN, which stands for Internet. There are other classes, 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. 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 may specify only one parameter, an IP address, but the SOA record specifies seven parameters (remember all those fields in Figure 4-13?).
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 data files 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.
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 data file. 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 IN A 192.249.249.2
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 IN 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 IN A 192.249.249.2
turns into an entry for robocop.movie.edu.movie.edu, which you didn’t intend at all.
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 data files generated by hand, but the Microsoft DNS Server
also uses the @ notation in the 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.
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 there are multiple resource records for a name. Here is an example where there are two address records for one name:
wormhole IN A 192.249.249.1
IN A 192.253.253.1In the second address record, the name wormhole is implied. You can use this shortcut even if the resource records are of different types—for example, if wormhole also had a TXT (arbitrary text) record.
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 data file 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.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
;
@ IN NS terminator.movie.edu.
;
; Zone records
;
1 IN 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 BIND 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 three automatically created zones shown in Figure 4-19.
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, a Microsoft DNS Server will reverse-map 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 NXDOMAIN (name not found) error for those queries rather than asking a root name server.
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):
; 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 registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: Aug 22, 1997 ; related version of root zone: 1997082200 ; ; ; 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 ; ; temporarily housed at NSI (InterNIC) ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; temporarily housed at ISI (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
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. The domain name
“.” refers to the root zone. Since the root zone’s
name servers change over time, don’t assume this list is
current. Pull a new version of
named.root.
You can also view this information from within the DNS console: select a name server in the left pane and choose Action → Properties. Then select the Root Hints tab to see a window like the one shown in Figure 4-20.
It’s worth noting that the root NS records are not put into the cache and used directly. Rather, upon startup the server queries one of the root servers in the cache file for the list of root 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 double-click the Cache icon.
You may be wondering what the 3600000s are for. In older versions of this file, this number was 99999999. It dates back to the behavior of early versions of BIND, the reference implementation of the name server. The BIND name server used to put the contents of the cache file directly into its cache, and it had to know how long to keep these records active. The 99999999smeant 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 cache file 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.
[16] Here’s where a difference between normal (i.e., nonadvanced) and advanced mode comes in. Figure 4-12 shows the record type as Start of Authority because the DNS console is in basic mode. In advanced mode, the record type would show up as simply SOA.
Get DNS on Windows 2000, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
