7.3 Updating Zone Data | DNS on Windows 2000


Team-Fly

	DNS on Windows 2000, 2nd Edition By Matt Larson, Cricket Liu
	Table of Contents

	Chapter 7. Maintaining the Microsoft DNS Server

7.3 Updating Zone Data

For nearly all changes to your zones, you'll use the DNS console. In Chapter 4 we described how to add a name server to the DNS console, create zones, and create resource records. Deleting these objects is easy: just select the object by left-clicking it, then press Delete (or select Action Delete ). Modifying objects is also straightforward. Name server names and zone names cannot be changed but must be deleted and added with the new name. For example, if the name of a name server you're managing changes, you have to delete the name server within the DNS console and replace it with the new name. The same thing goes if you change the name of a zone, say from movie.edu to movie.net .

Changing resource record data is easy, too. Just double-click the record in the right pane (or select it with a single click and choose Action Properties ). You'll see the same window as when you added the record. Note that you can change resource record data (also called RDATA ) but not the name of the record (the owner). In other words, you can change the right side of the record but not the left side (as viewed in the DNS console's right pane or in the zone data file). So you can change the IP address of terminator 's A record, but you can't change terminator to terminator2 . If you need to change the owner, you'll have to delete the record and replace it with the new owner.

7.3.1 Adding and Deleting Resource Records by Hand

Most of the time, you really should use the DNS console to make changes to your zones. The DNS console is much more versatile than its Windows NT 4.0 predecessor, the DNS Manager, but still isn't suited for some tasks sometimes you might want to edit the zone data files by hand. For example, adding, deleting, or changing a lot of records at once is tough with the DNS console but easy with a little Perl code or a good text editor. If you run a name server for long enough, you'll eventually want to make a change outside the DNS console.

Editing by hand is a little complicated because you have to manually perform some steps that the DNS console does for you automatically. The following list describes what to do:

Remember that all changes must be made on a zone's primary master name server. This is the case whether you're using the DNS console or editing by hand. If you make changes to the zone data file on a slave, the next zone transfer from the primary master will overwrite your work.
If you've made any changes using the DNS console since you started the name server (that usually means since the last reboot), stop the name server. Here's why: when you change a zone with the DNS console, the change takes effect in the primary master name server's memory right away, but the zone data file on disk is not updated immediately. The name server sets an internal "update pending" flag to remind itself that that zone's data file needs updating. If you select Action Update Server Data Files , all the zone data files of changed zones are updated and any flags are cleared. But if the server stops (whether it's halted by you or by a system rebootor for any other reason) and some zones have their update pending flags set, the server updates the corresponding zone data files before terminating. So you can see what happens if you make a change by hand but forget about a recent change made with the DNS console: when you stop and restart the server to put the manual change into effect, the zone data file gets updated, and your manual editing is lost.
Find the zone data file of the zone you want to change. Recall from Chapter 4 that the zone data files are stored in %SystemRoot%\system32\dns and the default naming convention is the name of the zone followed by the .dns extensionfor example, movie.edu.dns .
Bring up the zone data file in your favorite text editor. Notepad is a good choice; Microsoft Word isn't. Whatever you use, make sure you eventually save the file in plain text format. That's why we like Notepadyou can't save a file as anything but plain text.
Increment the serial number in the SOA record at the top of the file. (See the next section for more information on SOA serial numbers .) Since the SOA record is at the top of the file, it's a good idea to update it first so you won't forget to do it later.
Make whatever changes you need to make. If you're adding a host, you might need MX records in addition to the A record. For example, we added the following resource records to movie.edu.dns when we added the new host cujo to our network:
```
 cujo  IN  A  192.253.253.5       IN MX  10 cujo       IN MX  20 terminator 
```
When you're done, don't forget to save the file!
Don't forget to add PTR records! If you're adding a host, you should add a PTR record to the appropriate in-addr.arpa zone for each of its IP addresses. This step is easy to forget, because the DNS console adds PTR records for you automatically. And rememberif you change a zone, don't forget to increment the serial number in its SOA record. Our new host cujo has only one IP address, 192.253.253.5, so we added one PTR record to the 253.253.192.in-addr.arpa.dns file:
```
 5 IN PTR cujo.movie.edu. 
```

Your changes won't take effect until you restart the primary master name server: stop it, and then start it again. This is another task handled by the DNS console. When you make changes with the DNS console, the changes take effect immediately in the name server's memory and get written to disk later. Editing by hand reverses the process: you make the changes first on disk and have to restart the name server to get the changes into its memory.

Slave name servers will load the new data after some length of time within the time interval defined in the SOA record for refreshing their data. Sometimes your users won't want to wait for the slaves to pick up the new datathey'll want it available right away. (Are you wincing or nodding knowingly as you read this?) Can you force a slave to load the new information right away? If you've enabled zone change notification, the slaves will pick up the new data quickly because the primary master notifies the slave of changes within 15 minutes of the change. (See Chapter 10 for more information on zone change notification.) If you don't have notification set up, you should! But you can get the same effect the hard way by restarting the name server on each of the slaves. When the name server starts up, it does a serial number compare with its master for every zone for which it's a slave. If it discovers an out-of-date zone, it immediately performs a zone transfer.

To delete a host, remove all the resource records pertaining to it from the appropriate zone data files. Make sure you remove the A record, any MX records, and the PTR record. Also be sure to increment the serial number in each zone data file you modify and restart your primary master name server. (But, realistically , deleting hosts is best done with the DNS console.)

7.3.2 SOA Serial Numbers

Every zone has a serial number. Every time the data in a file is changed, the zone's serial number must be incremented. If the serial number is not incremented, slave name servers for the zone will not pick up the updated data. The change is simple. If the original data file had the following SOA record:

 movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (                                  100     ; Serial                                  10800   ; Refresh                                  3600    ; Retry                                  604800  ; Expire                                  86400 ) ; Minimum TTL

the updated data file would have the following SOA record:

 movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (                                  101     ; Serial                                  10800   ; Refresh                                  3600    ; Retry                                  604800  ; Expire                                  86400 ) ; Minimum TTL

This simple change is the key to distributing the data to all of your slaves. Failing to increment the serial number is the most common mistake made when updating by hand. The first few times you make a change manually, you'll remember to update the serial number because this process is new and you are paying close attention. After modifying zone data files becomes second nature (we bet you can't wait for that ), you'll make some "quickie" little change, forget to update the serial number... and none of the slaves will pick up the new data. Eternal vigilance is the price of modifying zone data files by hand.

There are several good ways to manage integer serial numbers. The obvious way is just to use a counter: increment the serial number by one each time the file is modified. That's what the DNS console does. Every time it updates a zone, it increments the zone's serial number. If you make changes with the DNS console, you're locked into this method. If you modify the zone data files only by hand, you have other options, such as deriving the serial number from the date. For example, you could use the eight-digit number formed by < year >< month >< day >. Suppose today is March 5, 2001. In this form, your serial number would be 20010305. This scheme allows only one update per day, though, and that may not be enough. Add another two digits to this number to indicate how many times the file has been updated that day. The first number for March 5, 2001, would then be 2001030500. The next modification that day would change the serial number to 2001030501. This scheme allows 100 updates per day. Whatever scheme you choose (or are forced to go along with), the serial number must fit in a 32-bit integer. And since you probably want to use the DNS console at least some of the time, you may just want to follow its numbering scheme.

7.3.3 Additional Records

After you've been running a name server for a while, you may want to add data to your name server to help you manage your domain. Have you ever been stumped when someone asked you where one of your hosts is? Maybe you don't even remember what kind of host it is. Administrators have to manage larger and larger populations of hosts these days, making it easy to lose track of this information. The name server can help you out. And if one of your hosts is acting up and someone notices remotely, the name server can help them get in touch with you.

So far, we've covered records critical to everyday operation: SOA, NS, A, CNAME, MX, and PTR. Name servers need these records to operate , and applications look up data of these types. Two other useful resource record types are TXT (text) and RP (Responsible Person); these can be used to tell you the machine's location and who is responsible for it. But DNS defines still more data types. For a complete list of the resource records, see Appendix A.

7.3.3.1 General text information

TXT stands for TeXT. These records contain simply a list of strings. The Microsoft DNS Server supports one string of up to 255 characters per TXT record. TXT records can be used for anything you want; a common use is to list a host's location. Creating a TXT record is easy: just highlight the zone or domain in the DNS console's left pane and select Action Other New Records... . In the Resource Record Type window, choose TXT and select Create Record... , then fill in the fields as shown in Figure 7-2.

Figure 7-2. Creating a TXT record

The TXT record shown in Figure 7-2 looks like this in a zone data file:

 cujo  IN  TXT  "Location: machine room dog house"

7.3.3.2 Responsible Person

Domain administrators will undoubtedly develop a love/hate relationship with the Responsible Person (RP) record. The RP record can be attached to any domain name, internal or leaf, and indicates who is responsible for that host or domain. This enables you to locate the miscreant responsible for the host peppering you with DNS queries, for example. But it also leads people to you when one of your hosts acts up.

The record takes two arguments as its record-specific data: an electronic mail address, in domain name format; and a domain name, which points to additional data about the contact. The electronic mail address is in the same format the SOA record uses: it substitutes a dot (.) for the at sign (@). The next argument is a domain name, which must have a TXT record associated with it. The TXT record contains free-format information about the contact, such as a full name and phone number. You can omit either field and specify the root (.) as a placeholder instead.For example, let's say that the Movie U. Network Hotline is responsible for the host robocop . It also happens that the Movie U. hotline reads all mail sent to root@movie.edu . You'd add the RP record shown in Figure 7-3 with Action Other New Records... .

Figure 7-3. Creating an RP record

You'd also add the TXT record shown in Figure 7-4 for hotline.movie.edu .

Figure 7-4. Creating an associated TXT record

Here's what these records would look like in a zone data file:

 robocop      IN  RP   root.movie.edu.  hotline.movie.edu.  hotline      IN  TXT  "Movie U. Network Hotline, (415) 555-4111"

Note that a TXT record for root.movie.edu isn't necessary since it's only the domain name encoding of an electronic mail address, not a real domain name.

7.3.4 Keeping db.cache Current

As we explained in Chapter 4, the cache.dns file tells your server where the servers for the root zone are. We also explained that, unlike a BIND name server (which never modifies the cache file), a Microsoft DNS Server updates cache.dns with its current notion of the root name servers every time it exits.

The root name servers don't change very often, but they do change. A Microsoft DNS Server that starts with a proper cache file should, in theory, always have the current list of root name servers in its cache file. A good practice and a part of maintaining your name server is to check your cache.dns file a couple times a year. In Chapter 4, we told you to get the current cache file by ftp ing to ftp.rs.internic.net. That's probably the best method to keep the file current. Remember that you must stop the name server before updating cache.dns ! If you don't, the cache file you install will be overwritten the next time the server does stop.

You can use dig , ^[2] a utility that works like nslookup , to retrieve the current list of roots just by running:

^[2] dig is a powerful DNS query tool that comes with BIND. Unfortunately, it isn't shipped with Windows 2000, but you can get a version of dig that runs on Windows 2000 from ftp://ftp.isc.org/isc/bind/ contrib /ntbind-8.2.4/BIND8.2.4Tools.zip.

 C:\>  dig @a.root-servers.net  .  ns > cache.dns


Team-Fly

Top