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 righthand pane or in the zone datafile). 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.
Most of the time, you really should use the DNS console to make changes to your zones. However, the DNS console isn't suited for some tasks?sometimes you might want to edit the zone datafiles 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 name server. This is the case whether you're using the DNS console or editing by hand. If you make changes to the zone datafile on a secondary, the next zone transfer from the primary 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 name server's memory right away, but the zone datafile on disk is not updated immediately. The name server sets an internal "update pending" flag to remind itself that that zone's datafile needs updating. If you select Action Update Server Data Files, all the zone datafiles 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 reboot?or for any other reason) and some zones have their update pending flags set, the server updates the corresponding zone datafiles 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 datafile gets updated, and your manual editing is lost.
Find the zone datafile of the zone you want to change. Recall from Chapter 4 that the zone datafiles are stored in %SystemRoot%\system32\dns and the default naming convention is the name of the zone followed by the .dns extension?for example, movie.edu.dns.
Bring up the zone datafile 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 Notepad?you 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 188.8.131.52 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 remember?if you change an in-addr.arpa zone, don't forget to increment the serial number in its SOA record. Our new host cujo has only one IP address, 184.108.40.206, 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 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 are 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.
Secondary name servers 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 secondaries to pick up the new data?they'll want it available right away. Can you force a secondary to load the new information right away? If you've enabled zone change notification, the secondaries will pick up the new data quickly because the primary notifies the secondary of changes within 15 minutes of the change. (See Chapter 11 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 secondaries. When the name server starts up, it does a serial number compare with its master for every zone for which it's a secondary. 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 datafiles. 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 datafile you modify and restart your primary name server. (But, realistically, deleting hosts is best done with the DNS console.)
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, secondary name servers for the zone will not pick up the updated data. The change is simple. If the original datafile had the following SOA record:
@ IN SOA terminator.movie.edu. hostmaster.movie.edu. ( 24 ; serial number 900 ; refresh 600 ; retry 86400 ; expire 3600 ) ; default TTL
the updated datafile would have the following SOA record:
@ IN SOA terminator.movie.edu. hostmaster.movie.edu. ( 25 ; serial number 900 ; refresh 600 ; retry 86400 ; expire 3600 ) ; default TTL
(Recall from Chapter 4 that "@" expands to the current origin of the zone datafile, which is usually the name of the zone. In this example, the "@" stands for movie.edu.) This simple change is the key to distributing the data to all of your secondaries. 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 datafiles becomes second nature (we bet you can't wait for that), you'll make some quick little change, forget to update the serial number . . . and none of the secondaries will pick up the new data. Eternal vigilance is the price of modifying zone datafiles by hand.
There are several good ways to manage serial numbers, which are just integers. 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 datafiles 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, 2004. In this form, your serial number would be 20040305. 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, 2004, would then be 2004030500. The next modification that day would change the serial number to 2004030501. This scheme allows 100 updates per day. Whatever scheme you choose (or are forced to go along with), the serial number must be less than or equal to 2,147,483,647. 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.
 For the curious, that value is 231 - 1. Serial numbers are unsigned 32-bit integers, but for complicated historical reasons, serial numbers in the bottom half of the space are equivalent to serial numbers in the top half. For more information on serial numbers, see RFC 1982.
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 list of the most useful resource records, see Appendix A.
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 Text (TXT), select Create Record, and fill in the fields as shown in Figure 7-2.
The TXT record shown in Figure 7-2 looks like this in a zone datafile:
cujo IN TXT "Location: machine room dog house"
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 firstname.lastname@example.org. You'd add the RP record shown in Figure 7-3 with Action Other New Records.
You'd also add the TXT record shown in Figure 7-4 for hotline.movie.edu.
Here's what these records would look like in a zone datafile:
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 (i.e., email@example.com), not a real domain name.
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 ftping 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, a utility that works like nslookup, to retrieve the current list of roots just by running:
C:\> dig @a.root-servers.net . ns > cache.dns
See Chapter 12 for more details about using dig.