Setting Up the Microsoft DNS Server
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
By Paul Albitz, Matt Larson, and Cricket Liu
Chapter 4 from DNS on Windows NT, published by O'Reilly & Associates, Inc.
"It seems very pretty," she said when she had finished it, "but it's rather hard to understand!" (You see she didn't like to confess, even to herself, that she couldn't make it out at all.) "Somehow it seems to fill my head with ideas -only I don't exactly know what they are!"
If you have been diligently reading each chapter of this book, you're probably anxious to get a name server running. This chapter is for you. Let's set up a couple of name servers. Some of you may have read the table of contents and skipped directly to this chapter. (Shame on you!) If you are one of those people who cuts corners, be aware that we may use concepts from earlier chapters and expect you to understand them.
Several factors influence how you should set up your name servers. The biggest factor is what sort of access you have to the Internet: complete access (that is, you can ftp to ftp.uu.net), limited access (limited by a security firewall), or no access at all. This chapter assumes you have complete access. We'll discuss the other cases in Chapter 13, Miscellaneous.
In this chapter, we'll set up two name servers for a fictitious domain, as an example for you to follow in setting up your own domain. We'll cover the topics in this chapter in enough detail to get your first two name servers running. Subsequent chapters will fill in the holes and go into greater depth. If you already have your name servers running, skim through this chapter to familiarize yourself with the terms we use or just to verify that you didn't miss something when you set up your servers.
On This Page
Our Domain
DNS Manager
Setting Up DNS Data
Running a Primary Master Name Server
Running a Slave Name Server
Adding More Domains
DNS --> Properties
What Next?
Our Domain
Our fictitious domain is for a college. Movie University studies all aspects of the film industry and researches novel ways to distribute films. One of the most promising projects is research into using Ethernet as the distribution medium. After talking with the folks at the InterNIC, they have decided on the domain name movie.edu. A recent grant has enabled them to connect to the Internet.
Movie U. currently has two Ethernets, and they have plans for another network or two. The Ethernets have network numbers 192.249.249.0 and 192.253.253.0. A portion of Movie U.'s host table shows the following entries:
127.0.0.1 localhost # These are our killer machines 192.249.249.2 robocop.movie.edu robocop 192.249.249.3 terminator.movie.edu terminator bigt 192.249.249.4 diehard.movie.edu diehard dh # These machines are in horror(ible) shape and will be replaced # soon. 192.253.253.2 misery.movie.edu misery 192.253.253.3 shining.movie.edu shining 192.253.253.4 carrie.movie.edu carrie # A wormhole is a fictitious phenomenon that instantly transports # space travelers over long distances and is not known to be # stable. The only difference between wormholes and routers is # that routers don't transport packets as instantly--especially # ours. 192.249.249.1 wormhole.movie.edu wormhole wh wh249 192.253.253.1 wormhole.movie.edu wormhole wh wh253
And the network is pictured in Figure 4-1.
DNS Manager
To manage a Microsoft DNS Server and maintain your DNS data, you'll use a tool called DNS Manager. It has a graphical user interface (surprise) and is capable of managing multiple name servers. DNS Manager is similar in design and operation to WINS Manager and DHCP Manager, if you're already familiar with those tools.
DNS Manager is located on the Administrative Tools (Common) menu, provided you've already installed the DNS service. If you don't see DNS Manager on that menu, see Appendix B, Installing the DNS Server from CD-ROM, for instructions on installing the DNS service. You can also run DNS Manager on Windows NT Workstation by copying the executable, %SystemRoot%\system32\dnsadmin.exe, from a Windows NT Server installation.
.gif "Cc723556.settin01(en-us,TechNet.10).gif")
Figure 4-1: The Movie University network
DNS Manager communicates with the Microsoft DNS Server using a proprietary management protocol built on Microsoft's RPC (remote procedure call). That means DNS Manager only manages Microsoft's DNS Server and not other name servers, like BIND.
The main DNS Manager window looks like Figure 4-2 (or will look like it, after we've set everything up in the course of this chapter):
The left pane shows name servers, zones, and domains, while the right pane shows either name server statistics or resource records.
This particular DNS Manager knows about only one name server, with IP address 192.249.249.3. That name server is authoritative for three zones: movie.edu, 249.249.192.in-addr.arpa, and 253.253.192.in-addr.arpa. If any of these zones had subdomains, they would show up as subfolders under the appropriate zone. For example, comedies.movie.edu would be represented as a folder called comedies under movie.edu. Also notice the Cache icon. As you might expect, selecting this icon displays the contents of the name server's cache of resource records from previous queries. If you're familiar with the BIND name server, you probably know that the only way to examine that name server's cache is by dumping it to a file.
.gif "Cc723556.settin02(en-us,TechNet.10).gif")
Figure 4-2: DNS Manager main window
If a name server is selected in the left pane (instead of a zone, as in Figure 4-2), then the right panel displays usage statistics for that name server. You can see the total number of queries processed by the server and whether the transport was UDP or TCP, the total number of recursive queries, and the total number of lookups to a WINS server-more on that in Chapter 7, Maintaining the Microsoft DNS Server.
Of course, there are pull-down menus:
DNS
The really important commands are here: adding new name servers, creating zones and domains, and creating resource records. You can also delete objects and view objects' properties. We'll explain the various commands throughout this chapter.
View
Only two commands here: Split lets you move the split bar between the two panes (something you can do by just selecting and dragging the bar). Refresh causes DNS Manager to query the name server for what's currently selected in the left pane and update its display in the right pane. In other words, DNS Manager's display doesn't track the contents of the name server in real time and is not updated automatically. We can't overemphasize the importance of the Refresh command: you should use it all the time to make sure that what you see on the screen is the same information the name server has in memory. Fortunately, the function key F5 is a quick shortcut for Refresh.
Options
This menu has only Preferences, which opens a window with DNS Manager settings as in Figure 4-3.
.gif "Cc723556.settin03(en-us,TechNet.10).gif")
Figure 4-3: DNS Manager preferences
Auto Refresh Statistics causes DNS Manager to automatically update the previously mentioned name server statistics at the interval you select. Note that this automatic update only refreshes name server statistics, which you see only when you have a server selected in the left pane. You'll usually have a zone selected on the left and view the zone's contents on the right. That information isn't updated automatically no matter what this setting-you'll still need to select View --> Refresh (or hit F5) to see changes.
Show Automatically Created Zones displays three zones that every Microsoft name server is authoritative for: 0.in-addr.arpa, 127.in-addr.arpa, and 255.in-addr.arpa. We'll explain what these zones are for later on in this chapter.
Expose TTL causes DNS to show the time to live (TTL) on every resource record it displays. Turning off this option doesn't affect the TTL of any records, just whether or not DNS Manager shows you the TTL.
The default for all three options is off.
Setting Up DNS Data
Let's configure the first of Movie U.'s name servers. We'll use DNS Manager for most of this process, so start it up if you haven't already done so. You don't have to run DNS Manager 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 DNS Manager; otherwise, you'll only be able to start the application, not manage any name servers with it.
Adding a New Server to DNS Manager
The first step is configuring DNS Manager 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 DNS --> New Server, and then enter the IP address of your primary master. DNS Manager adds an icon in the left pane for that name server as in Figure 4-4.
.gif "Cc723556.settin04(en-us,TechNet.10).gif")
Figure 4-4: DNS Manager with a new server
192.249.249.3 is terminator's IP addresses in the Movie U. network. This name server is not (yet) authoritative for any zones, so only the Cache icon appears under the IP address. Since the name server itself is selected on the left, its usage statistics appear on the right. This name server hasn't been very busy.
It's important to understand what we just did here. We told DNS Manager about a name server for it to manage. DNS Manager added that name server to its configuration, queried it for a list of zones and statistics, and displayed them. DNS Manager did not start the name server on the target machine. If the name server isn't already installed and running, DNS Manager can't manage it and will complain with the rather cryptic error, "There are no more endpoints available from the endpoint mapper." That error, which appears at the bottom of the right pane, means that DNS Manager couldn't contact the name server on the target machine.
Selecting New Server just adds that name server to DNS Manager's list of servers it knows about. As you might expect, selecting the server and choosing DNS --> Delete (or just pressing the Delete key) removes the server from DNS Manager's configuration but doesn't change anything on the name server itself. The server will still be running-you can use New Server to add it, and you'll be right back where you started.
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 DNS Manager could know about multiple servers.) Choose DNS --> New Zone. You'll see a window as in Figure 4-5.
.gif "Cc723556.settin05(en-us,TechNet.10).gif")
Figure 4-5: Creating a new zone, first window
Choose Primary, and then click Next. In the next window, type the domain name of the zone in the Zone Name field. In our case, it's movie.edu. Notice that after you press Tab, the Zone File field is automatically filled in (see Figure 4-6).
.gif "Cc723556.settin06(en-us,TechNet.10).gif")
Figure 4-6: Creating a new zone, second window
The zone file, also called a zone database 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 database file to make changes to the zone, but DNS Manager allows you to avoid any hand editing. As a result, you probably won't see the zone database 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 database 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. You can name the zone file whatever you want, but as long as DNS Manager 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 a partial domain name, like db.movie. In fact, that's the recommendation in our sister book, DNS and BIND.
When you've entered a zone name and zone filename, click Next, and you'll see a window as in Figure 4-7.
.gif "Cc723556.settin07(en-us,TechNet.10).gif")
Figure 4-7: Creating a new zone, third window
We're not quite sure why this window is necessary, but there it is. Click Finish to create the zone. You'll see a window like the one pictured in Figure 4-8.
.gif "Cc723556.settin08(en-us,TechNet.10).gif")
Figure 4-8: DNS Manager with a new zone
DNS Manager has created the zone and a few resource records. Let's talk about them one by one.
The SOA record
We'll start with the second record displayed. It's the SOA (start of authority) 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 zone movie.edu because of the SOA record. (Remember, this SOA record is attached to the domain name of the zone, movie.edu.) An SOA record is required in each zone. 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-9.
.gif "Cc723556.settin09(en-us,TechNet.10).gif")
Figure 4-9: The movie.edu SOA record
The first 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 second name (administrator.movie.edu.) is the email address of the person in charge of the data (if you replace the first dot with an at sign). DNS Manager defaults to 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 NS record
The first record is an NS (name server) resource record. There should be one NS record for each name server for the zone. Like the SOA record, the 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. DNS Manager created an NS record for terminator because it's a name server for movie.edu.
The A record
The final automatically created record is an address record or A record. This record type fulfills the main purpose of DNS: it provides a name-to-address mapping. Each A record maps a domain name, like terminator.movie.edu, to an IP address, like 192.249.249.3.
When you create a new zone, DNS Manager creates an address record for the primary name server. It uses the host name configured in the primary master's DNS configuration.
Note that some abbreviating is going on in DNS Manager's display. For the SOA and NS records, the fully qualified domain name is shown, movie.edu. But for the A record, DNS Manager only displays terminator instead of terminator.movie.edu. DNS Manager 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. Only when records are attached to the name of a zone does it display a fully qualified name, as is the case with the movie.edu SOA and NS records.
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.
Creating a New Reverse Mapping Zone
Zones like movie.edu handle the mapping of names to addresses using A records. But mapping addresses back to names-reverse mapping-is just as important. As you recall from Chapter 2, How Does DNS Work?, a special portion of the name space, the in-addr.arpa domain, is designated for reverse mapping. Each domain name in in-addr.arpa corresponds to every possible IP address, and PTR 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 class C networks, 192.249.249.0 and 192.253.253.0. We need to create the corresponding in-addr.arpa zones for reverse mapping with DNS Manager: 249.249.192.in-addr.arpa and 253.253.192.in-addr.arpa.
Creating an in-addr.arpa zone is the same as creating any other zone:
Select DNS --> New Zone.
Choose Primary, and click Next.
In the next window, enter the name of the zone (249.249.192.in-addr.arpa, in this case), and press Tab.
We recommend accepting the automatically generated zone filename, but you can change it at this point if you'd like.
Click Next.
In the final window, click Finish.
Note that, just as it did with the movie.edu zone, DNS Manager 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 would create in-addr.arpa zones according to the networks you have. Usually there's one in-addr.arpa zone per Class C (or sub-Class C) network. Larger networks, like Class A or Class B, are usually 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, Parenting.
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. DNS Manager 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 DNS --> 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 PTR Record box. The window looks like the one in Figure 4-10.
.gif "Cc723556.settin10(en-us,TechNet.10).gif")
Figure 4-10: 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.) DNS Manager requires a relative domain name in this field. It appends the domain name of the zone selected in DNS Manager's left pane to create a fully qualified domain name. Don't worry-if you try to enter a fully qualified domain name, DNS Manager will give you an error message.
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. There's a special resource record called the CNAME record that's used to make an alias. The name of the 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, use the New Record command. Select the zone you want to add the record to on the left, and choose DNS --> New Record. Unlike with New Host, you can create a record in any zone. The window looks like the one in Figure 4-11.
.gif "Cc723556.settin11(en-us,TechNet.10).gif")
Figure 4-11: Creating a CNAME record
This window lets you add one of 17 different types of resource records. When you select the record type in the upper-left field, a brief description of the record type appears in the lower left, and the fields on the right change to accommodate the proper kind of data for the record type. Note that you can add A records and PTR records with this window, too.
We've selected CNAME, so fields for the alias name and canonical name (labeled as For DNS Host Name) appear on the right. The input in Figure 4-11 will generate an alias from bigt.movie.edu to terminator.movie.edu. The 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. But there is no such restriction for the canonical name field. You can point an alias anywhere. We could alias bigt.movie.edu to www.whitehouse.gov if we wanted to. If you leave off the domain in the canonical name field, the zone's domain name will be appended automatically.
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 that 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 -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 when the name is looked up. ping uses the first address in the list. But which address is first?
The solution is to create two A records for wormhole with New Record. (The first of the two records is shown in Figure 4-12.)
.gif "Cc723556.settin12(en-us,TechNet.10).gif")
Figure 4-12: Creating the first of two A records for wormhole
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 the alias was looked up. 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 (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.
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 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.
Where Is All This Information Stored?
You may be wondering what's been happening 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 DNS Manager communicates with the DNS Server using an RPC mechanism. As you add records to a zone with DNS Manager, 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 a permanent storage location is needed.
This is where the zone database files we specified when we created the zones come in. The zone database files are the zones' permanent storage location, holding all the zones' resource records. If you use DNS Manager 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 database file. The name server updates the zone database file when it exits, unless you tell it to update it sooner. The command DNS --> Update Server Data Files causes the name server to update the zone database files of all zones it's a primary for, regardless of whether or not they've been modified. To avoid losing data, we recommend using DNS --> 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 DNS --> Update Server Data Files after a batch of changes, but it doesn't hurt anything and you can sleep better.
As you've probably guessed, when the name server starts up, it reads the zone database files into memory. When you select View --> Refresh or press F5, DNS Manager queries the name server and updates its display.
If you've been keeping track, you realize that DNS information exists in three places: zone database files, the name server's memory, and DNS Manager's window. The diagram in Figure 4-13 helps explain how the information flows.
.gif "Cc723556.settin13(en-us,TechNet.10).gif")
Figure 4-13: Where everything is stored
The Zone Database Files
Let's take a look at the zone database 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 DNS --> 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:
;
; Database 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.1
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: 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:
;
; Database 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.
Zone Database File Format
The format of zone database files is specified in the DNS standards. That means all name servers, whether Microsoft's DNS Server or the BIND name server, can read each other's zone database 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 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 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 database 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 name space that the resource record is attached to. You've seen the domain name on the left side of the right pane of DNS Manager. (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 record types SOA, NS, A, PTR, and CNAME, and you've probably browsed through the list of other record types in DNS Manager's New Record 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.
And 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. This field 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-9?
Speaking of the SOA record, you'll notice in the examples that it's the only record spanning multiple lines. 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 host name if you were entering these files by hand. Fortunately, abbreviations are allowed. You need to understand them to decipher the zone database files in this chapter, because the records generated by the Microsoft DNS Server use these abbreviations.
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 database file. The origin is appended to all 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 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, and you didn't intend that at all.
@ 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 database 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.
Repeat last name
If a resource record name (that starts in column one) is a space or tab, then 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.1
In 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.
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 database 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 file 0.0.127.in-addr.arpa.dns:
@ 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 DNS Manager only if an option is set. Select Options --> Preferences, and you'll see the window shown in Figure 4-14.
.gif "Cc723556.settin14(en-us,TechNet.10).gif")
Figure 4-14: DNS Manager preferences set to show automatically created zones
Check the Show Automatically Created Zones box, and click OK. Then select the name server in the left pane, and refresh (View --> Refresh or F5). You'll see three more zones in your display as shown in Figure 4-15.
.gif "Cc723556.settin15(en-us,TechNet.10).gif")
Figure 4-15: DNS Manager 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, 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 then asking a root name server.
The Root Cache Data
Besides needing to know your local information, the name server also needs to know where the name servers for the root zone are. (Remember the resolution process starts at the root zone, so knowing which name servers are authoritative for the root zone is critical.) This information must 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 file, called the root name server cache file, should be named %SystemRoot%\System32\DNS\cache.dns on your name server. Here's the version of the file that was current 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
The domain name "." refers to the root domain. Since the root domain's name servers change over time, don't assume this list is current. Pull a new version of named.root.
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. When the name server exits, its list of root name servers is written to the cache file.
The nice thing about this behavior is that if you use an older cache file, as long as at least one of the name servers specified has the correct list of root name servers, your name server will discover the up-to-date list. And because the name server updates cache.dns on exit, it'll have the right list to begin with the next time it starts. The whole purpose of this logic is to ensure the name server has the current list of root name servers, which is very important for the resolution process to work properly.
You might be wondering if you can put information other than root name server NS records and their corresponding A records in the cache file. You can, but we don't recommend it. For one thing, the name server only rewrites root NS records (and their A records) to the cache file, so any changes you make will be overwritten eventually. In addition, BIND name servers don't have this feature. If your DNS architecture depends on any preloaded information in the cache, you're locked into using only Microsoft DNS Server as a name server platform. Yet another reason we think this is a bad idea is that you have to remember the information is there and maintain it by hand when it changes. We suggest you let the name server populate its own cache and don't interfere.
You may be wondering what the 3600000s are for. In older versions of this file, this number used to be 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 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 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.
One final note about the cache.dns file. To install a new cache.dns file, you must first stop the server. Remember, the server will overwrite the cache.dns file when it exits. Let's say you install a new file and then stop and start the server. As soon as the server stopped, your new file was overwritten with the server's list of root name servers. It then restarts, reads that list back in, and queries one of those name servers for the list of root name servers (which will almost certainly be the same list). The solution is to stop the server, replace the cache.dns file, and restart the server.
Running a Primary Master Name Server
Your primary name server is already up and running; you've been talking to it via DNS Manager. You've created a zone and populated it with information. Then you directed the server to write out zone database files with the DNS --> Update Server Data Files command. To be sure that everything is okay, you should stop and restart the server and then check the Event Log for any messages or errors.
Starting and Stopping the DNS Server
You start and stop the DNS server just like any other NT service: with the Services Control Panel document. Open the Control Panel with Start --> Settings --> Control Panel. Double-click the Services icon, and you'll see the Services window as shown in Figure 4-16.
.gif "Cc723556.settin16(en-us,TechNet.10).gif")
Figure 4-16: Windows NT services control window
Your system should look like this: the server should be running (that is, it should be started). Select the server as we've done by clicking anywhere on the Microsoft DNS Server line. Click Stop. You'll be prompted for confirmation; click Yes. After the server stops, click Start. In a few seconds, the server should be running again.
While you've got this window open, check to make sure that the DNS Server is being started automatically on bootup. You want to see Automatic in the Startup column (and not Manual or Disabled). To change the startup behavior, just click the Startup button.
You can also start and stop the DNS Server from the DOS command line: net start dns will start the server, and net stop dns stops it.
Check the Event Log for Messages and Errors
Now you need to check the Event Log. Start the Event Viewer by selecting Start --> Programs --> Administrative Tools (Common) --> Event Viewer. Be sure you're looking at system events: choose Log --> System. You should see a window like the one in Figure 4-17.
.gif "Cc723556.settin17(en-us,TechNet.10).gif")
Figure 4-17: Event Viewer
DNS Server Event ID 3 is "The DNS Server has shutdown." Event ID 1 is "Starting Microsoft DNS Server (v4.0 ServicePack3)," and Event ID 2 is "The DNS Server has started." (More events are listed in Chapter 7.) These three events are just what you want to see: a normal server shutdown and startup. We're reading from bottom to top since Event Viewer's default view is newest events first. We also cleared the Event Log before we stopped and started the server-that's why only DNS events are showing.
If there were any other messages or errors, we'd take steps to correct them now. To be honest, we didn't expect any problems because we entered all the data via DNS Manager. Since it performs some syntax and sanity checking, it's hard to enter bad data to make the name server upset enough to complain in the Event Log. Still, it doesn't hurt to check. If you ever start editing zone database files by hand, you definitely need to check the Event Log.
Testing Your Setup with nslookup
If you have correctly set up your local domain and your connection to the Internet is up, you should be able to look up a local and remote name. We'll step you through the lookups with nslookup. This book contains an entire chapter on this topic (Chapter 11, nslookup), but we will cover nslookup in enough detail here to do basic name server testing.
Look up a local name
nslookup can be used to look up any type of resource record, and it can be directed to query any name server. By default, it looks up A (address) records using the name server on the local system. To look up a host's address with nslookup, run nslookup with the host's name as the only argument. A lookup of a local name should return almost instantly.
We ran nslookup to look up carrie :
C:\> nslookup carrie
Server: terminator.movie.edu
Address: 192.249.249.3
Name: carrie.movie.edu
Address: 192.253.253.4
If looking up a local name works, your local name server has been configured properly for your domain. If the lookup fails, you'll see something like this:
*** terminator.movie.edu can't find carrie: Non-existent domain
This means that either carrie is not in your data-check DNS Manager or the zone database file-or some name server error occurred (but you should have caught the error when you checked the Event Log).
Look up a local address
When nslookup is given an address to look up, it knows to make a PTR query instead of an address query. We ran nslookup to look up carrie's address:
C:\> nslookup 192.253.253.4
Server: terminator.movie.edu
Address: 192.249.249.3
Name: carrie.movie.edu
Address: 192.253.253.4
If looking up an address works, your local name server has been configured properly for your in-addr.arpa domain. If the lookup fails, you'll see the same error messages as when you looked up a name.
Look up a remote name
The next step is to use the local name server to look up a remote name, like ftp.uu.net, or another system you know on the Internet. This command may not return as quickly as the last one. If nslookup fails to get a response from your name server, it will wait a little longer than a minute before giving up:
C:\> nslookup ftp.uu.net.
Server: terminator.movie.edu
Address: 192.249.249.3
Name: ftp.uu.net
Address: 192.48.96.9
If this works, your name server knows where the root name servers are and how to contact them to find information about domains other than your own. If it fails, either you forgot to initialize the cache file (and a message in the Event Log will show up) or the network is broken somewhere and you can't reach the name servers for the remote domain. Try a different remote domain name.
If these first three lookups succeeded, congratulations! You have a primary master name server up and running. At this point, you are ready to start configuring your slave name server.
One more test
While you are testing, though, run one more test. Try having a remote name server look up a name in your zone. This is going to work only if your parent name servers have already delegated your zone to the name server you just set up. If your parent required you to have your two name servers running before delegating your zone, skip ahead to the section "Running a Slave Name Server."
To make nslookup use a remote name server to look up a local name, give the local host's name as the first argument, and the remote server's name as the second argument. Again, if this doesn't work, it may take a little longer than a minute before nslookup gives you an error message. For instance, to have gatekeeper.dec.com look up carrie :
C:\> nslookup carrie gatekeeper.dec.com.
Server: gatekeeper.dec.com.
Address: 204.123.2.2
Name: carrie.movie.edu
Address: 192.253.253.4
If the first two lookups worked, but using a remote name server to look up a local name failed, you may not be registered with your parent name server. That is not a problem at first, because systems within your zone can look up the names of other systems within and outside your zone. You'll be able to send email and ftp to local and remote systems. Some systems won't allow FTP connections if they can't map your address back to a name. But not being registered will shortly become a problem. Hosts outside of your zone cannot look up names within your zone. You will be able to send email to friends in remote domains, but you won't get their responses. To fix this problem, contact someone responsible for your parent zone and have them check the delegation of your zone.
Running a Slave Name Server
You need to set up another name server for robustness. You can (and probably will) set up more than two name servers. Two servers are the minimum. If you have only one name server and it goes down, no one can look up names in your zone. A second name server splits the load with the first server or handles the whole load if the first server is down. You could set up another primary master name server, but we don't recommend it. Set up a slave name server.
How does a server know if it is a primary master or a slave for a zone? The DNS Server configuration information in the Registry tells the server it is a primary master or a slave on a per zone basis. The NS records don't tell us which servers are primary master for a zone and which servers are slave for a zone-they only say who the servers are. (Globally, DNS doesn't care; as far as the actual name resolution goes, slave servers are as good as primary master servers.)
What is different between a primary master name server and a slave name server? The crucial difference is where the server gets its data. A primary master name server reads its data from files. A slave name server loads its data over the network from another name server. This process is called a zone transfer.
A slave name server is not limited to loading zones from a primary master name server; a slave server can load from another slave server.
The big advantage of slave name servers is that you only maintain one set of the DNS database files, the ones on the primary master name server. You don't have to worry about synchronizing the files among name servers; the slaves do that for you.
A slave name server doesn't need to retrieve all of its db files over the network; the cache.dns is the same as on a primary master, so keep a local copy on the slave.
Note: One point about slaves may become confusing: slaves used to be called secondary master name servers. The terminology was changed since DNS Manager came out, and now everyone "in the know" uses the term slave. We'll use the term slave in this book, but you'll see that DNS Manager still uses the term secondary. As we said, the two are synonymous.
Add a New Server to DNS Manager
The first step in configuring a slave server is to add the server to DNS Manager's world view. Just as we did when configuring the primary master, select DNS --> New Server, and then enter the IP address of the slave. In this case our slave will be wormhole with IP address 192.249.249.1. Of course, the DNS Server has to be installed and running on the slave-to-be for DNS Manager to be able to manage it.
After you've added the slave to DNS Manager's configuration, double-click the IP address of the primary master name server to list the zones it's authoritative for. Having this list of zones visible makes things easier in the next step.
Create a New Zone
This new server will be a slave for every zone on the primary, so we'll have to go through the new zone process for each zone. Let's start with movie.edu. Select DNS --> New Zone. This time, select Secondary (remember, this is synonymous with slave) in the resulting window, and you'll see something like Figure 4-18.
.gif "Cc723556.settin18(en-us,TechNet.10).gif")
Figure 4-18: Creating a new secondary zone, first window, with Secondary selected
In the Zone field, enter the domain name of the zone to be a slave for (that is, movie.edu). In the Server field, enter the IP address of the primary master name server. You could type this information, or you can take advantage of a really slick shortcut offered by DNS Manager. Note the hand pointer in the window: you can specify the zone and server by dragging the hand to the zone on the primary that you want this server to be a slave for. Now you see why we wanted the primary's zones to be visible. Once the hand touches the zone, these fields are filled in. See Figure 4-19.
.gif "Cc723556.settin19(en-us,TechNet.10).gif")
Figure 4-19: Creating a new secondary zone, first window, moving the hand pointer to the primary zone
Whether you enter the zone and server manually or use the hand pointer shortcut, click Next to get the next window as shown in Figure 4-20.
.gif "Cc723556.settin20(en-us,TechNet.10).gif")
Figure 4-20: Creating a new secondary zone, second window
This is the same window you see when creating a primary zone. If you entered the zone and server manually in the previous window, only the zone is filled in here. You can still hit Tab to get the automatically generated zone filename conforming to the *.dns convention. If you used the hand pointer in the previous window, both fields are filled in.
You're probably wondering why we're specifying a zone database file here-after all, this name server will be a slave for the movie.edu zone. It will load the zone from the primary, not from a file on its disk. On a slave, the zone file is not the definitive source of information for the zone as it is on the primary. Instead it's treated as a backup copy of the zone. After the slave does a zone transfer, it saves a copy of the zone in the backup file. The slave server reads the backup file on startup and later checks with the primary master server to see if the primary has a newer copy, instead of loading a new copy of the zone immediately. If the primary master server has a newer copy, the slave pulls it over and saves it in the backup file.
The backup file saves time and network bandwidth. When the slave starts up and the zone hasn't changed, it doesn't have to go through the time and expense of performing a zone transfer. Or suppose the primary server is down when the slave starts up. The slave would be unable to transfer the zone and therefore wouldn't function as a server for that zone until the primary server is up. With a backup copy, the slave has some data, although it might be slightly out of date. Since the slave does not rely on the master server always being up, the system is more robust.
The Microsoft DNS server requires slave zones to have a backup file. Those of you familiar with BIND know that backup files are optional, although we don't know anyone who doesn't use them.
When you're finished, click Next, and you'll see the window shown in Figure 4-21.
.gif "Cc723556.settin21(en-us,TechNet.10).gif")
Figure 4-21: Creating a new secondary zone, third window
At this point, the process of creating a primary master zone and a slave zone really diverge. This is the screen where you specify where this name server will get the zone data from. In this example, we're making wormhole a slave for the movie.edu zone. We need to tell wormhole to load the zone from terminator, the primary master. "But wait," you say, "didn't we already do that two windows ago?" That's a valid question. For whatever reason, DNS Manager requires that you specify the primary's IP address in two places. In fact, on this screen you can specify multiple IP addresses. In advanced (and complicated) configurations, sometimes there are multiple primaries or multiple sources for a slave to get the zone information. DNS Manager supports those configurations. You could also just specify the IP address of another slave after that of the primary: in case the primary is down, this slave can load from another slave. Of course, Movie U. doesn't have another slave (yet).
For now, we just specify terminator's IP address, 192.249.249.3. Then click Next. The final window in the process is the same as when creating a primary zone: it just tells you that you're done now and asks you to click Finish. We'll omit showing it to you.
When you're done, the new slave immediately initiates a zone transfer to the primary to download the zone. Within a few seconds you should be able to double-click the slave's icon for the zone and see the records in the zone.
Add an NS Record for the New Slave Name Server
Your new slave won't be much good if the rest of the world doesn't know about it. As a general rule, when you add another name server for a zone, you also need to add an NS record for it. (We'll discuss the exceptions to this in Chapter 8, Growing Your Domain.)
You need to add an NS record on the zone's primary. (Remember that all changes to a zone are made on the primary and propagate automatically to the slaves. Don't get confused by the fact that DNS Manager lets you see all your name servers-you make the changes only to the zone's primary.) In our case, we need to add an NS record for wormhole to the movie.edu zone. So we highlight movie.edu under terminator, and select DNS --> New Record as shown in Figure 4-22.
.gif "Cc723556.settin22(en-us,TechNet.10).gif")
Figure 4-22: Creating an NS record
Don't Forget the in-addr.arpa Zones!
Now repeat this slave zone creation process with the 249.249.192.in-addr.arpa and 253.253.192.in-addr.arpa zones.
SOA Values
Remember this SOA record for the movie.edu zone?
@ IN SOA terminator.movie.edu.administrator.movie.edu.( 1 ; serial number 3600 ; refresh 600 ; retry 86400 ; expire 3600 ) ; minimum TTL
We never explained what the values in between the parentheses were for.
The serial number applies to all the data within the zone. We chose to start our serial number at 1, a logical place to start. DNS Manager automatically increments the serial number in a zone's SOA record whenever you make a change to the zone. If you've maintained zone database files by hand, you might have encoded the date in the serial number-like 1997102301. This format is YYYYMMDDNN, where Y is the year, M is the month, D is the day, and NN is a count of how many times the zone data were modified that day. Unforunately, you can't use that convention when also using DNS Manager. It just updates the serial number by one each time a change is made and doesn't understand the date encoding.
When a slave name server contacts a primary master server for zone data, it first asks for the serial number on the data. If the slave's serial number is lower than the primary's, the slave's zone data are out of date. In this case, the slave pulls a new copy of the zone. As you might guess, if you ever modify the zone database files on the primary master by hand, you must increment the serial number, too. Updating zone database files is covered in Chapter 7.
The next four fields specify various time intervals in seconds:
refresh
The refresh interval tells the slave how often to check that its data are up to date. To give you an idea of the system load this feature causes, a slave will make one SOA query per zone per refresh interval. The default value generated by DNS Manager when the zone was created, one hour, is reasonably aggressive. Most users will tolerate a delay of half of a working day for things like name server data to propagate, when they are waiting for their new workstation to be operational. If you provide one-day service for your site, consider raising this value to eight hours. If your data don't change very often, or if all of your slaves are spread over long distances (as the root name servers are), consider a value that is even longer: 24 hours.
retry
If a slave fails to reach the primary name server (s) after the refresh period (the hosts or hosts could be down), then it starts trying to connect every retry seconds. The retry interval is usually shorter than the refresh interval, but it doesn't have to be.
expire
If a slave fails to contact the primary server (s) for expire seconds, the slave expires its data. Expiring the data means the slave stops giving out answers about the data because the data are too old to be useful. Essentially, this field says: at some point, the data are so old that having no data is better than having stale data. We think Microsoft's default expire time of 86400 seconds (24 hours) is awfully short. Expire times on the order of a week are common-longer (up to a month) if you frequently have problems reaching your updating source. The expiration time should always be much larger than the retry and refresh intervals; if the expire time is smaller than the refresh interval, your slaves will expire their data before trying to load new data.
minimum TTL
TTL stands for time to live. This value applies to all the resource records in the zone database file. The name server supplies this TTL in query responses, allowing other servers to cache the data for the TTL interval. If your data don't change much, you might consider using a minimum TTL of several days. One week is about the longest value that makes sense. Again, the default value of 3600 seconds (one hour) is very short, which we don't recommend because of the amount of DNS traffic it causes.
What values you choose for your SOA record will depend upon the needs of your site. In general, longer times cause less loading on your systems and lengthen the propagation of changes; shorter times increase the load on your systems and speed up the propagation of changes. We find the following values work well for most sites; they're also a good starting point if you're not sure what values to use:
10800 ; Refresh 3 hours
3600 ; Retry 1 hours
2592000 ; Expire 30 days
86400 ; Minimum TTL 1 day
Adding More Domains
Now that you have your name servers running, you might want to handle more zones. What needs to be done? Nothing special, really. Just use DNS Manager to select the appropriate server in the left pane, and then choose DNS --> New Zone. Follow the instructions earlier in this chapter according to whether you are creating a primary or a slave (secondary) zone.
At this point, it's useful to repeat something we said in an earlier chapter. Calling a given name server a primary master name server or a slave name server is a little silly. Name servers can be authoritative for more than one zone. A name server can be a primary master for one zone and a slave for another. Most name servers, however, are either primary master for most of the zones they load or slave for most of the zones they load. So if we call a particular name server a primary master or a slave, we mean that it's the primary master or a slave for most of the zones it loads.
DNS --> Properties
Let's finish this chapter with an explanation of the DNS --> Properties selection. The Properties selection on the DNS menu is context sensitive. When selected, DNS Manager displays the properties of the resource record, zone, or server that is highlighted.
Resource Record Properties
Select a resource record on the right by single-clicking it. Then choose DNS --> Properties. The window should look familiar: it's the same one you used to add the record. You can get the same effect by simply double-clicking the record, too.
Zone Properties
The zone properties window is viewed by selecting a zone on the left and choosing DNS --> Properties. Unlike resource record properties, some zone information can be changed only from this window. It has four tabs:
General
This window shows the name of the zone's database file as well as indicating if it's a primary or slave (secondary) zone. The type of the zone can be changed from primary to slave or vice versa. The window for the movie.edu zone is shown in Figure 4-23.
.gif "Cc723556.settin23(en-us,TechNet.10).gif")
Figure 4-23: Zone Properties --> General
SOA Record
This window shows the zone's SOA record. The display, shown in Figure 4-24, is no different than if you double-click the SOA record in the right panel.
.gif "Cc723556.settin24(en-us,TechNet.10).gif")
Figure 4-24: Zone Properties --> SOA Record
Notify
The Notify tab is covered in Chapter 10, Advanced Features and Security.
WINS Lookup
The WINS Lookup tab is also covered in Chapter 10.
Server Properties
You can view the server properties by selecting a server on the left and choosing DNS --> Properties. It has three tabs:
Interfaces
This window allows you to specify which interfaces the server will listen on for queries. If you have multiple interfaces (like for virtual web hosting), you might not need them all listed here. The default behavior is for the server to listen on all interfaces. The window is shown in Figure 4-25.
.gif "Cc723556.settin25(en-us,TechNet.10).gif")
Figure 4-25: Server Properties --> Interfaces
Forwarders
This tab is covered in Chapter 10.
Boot Method
This window displays where the name server is obtaining its configuration information (also referred to as its boot method ). The default location of the configuration information is the Registry, but the server can also be configured to boot from a BIND Version 4 boot file. This window is "read only" and just displays the current boot method-changing the boot method means changing a Registry setting. More information about this topic is found in Appendix C, Converting from BIND to the Microsoft DNS Server.
What Next?
In this chapter, we showed you how to set up a primary master and a slave name server. There is more work to do to complete setting up your local domain: you need to modify your DNS data for email, configure the other hosts in your domain to use name servers, and you may need to start up more name servers. These topics are covered in the next few chapters.
About the Authors
Paul Albitz is a software engineer at Hewlett-Packard. He worked on BIND for the HP-UX 7.0 and 8.0 releases. During this time, Paul developed the tools used to run the hp.com domain.
Matt Larson started Acme Byte & Wire, a company specializing in DNS consulting and training, with Cricket Liu in January 1997. Previously, he worked for Hewlett-Packard, first as Cricket's successor as hp.com hostmaster, then as a consultant in HP's Professional Services Organization.
Cricket Liu went to work for Hewlett-Packard after graduation and stayed at HP for nine years. He was hp.com hostmaster for over three years, and then joined HP's Professional Services Organization to found HP's Internet consulting program. Cricket currently runs his own DNS consulting and training company, Acme Byte & Wire, with his friend Matt Larson.
Copyright © 1998 by O'Reilly & Associates, Inc.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.
International rights = English only.
.gif "Link")