You might wonder why I'm worrying about NS records. If you've ever tinkered with a Microsoft-based DNS server, you probably know that naming a given zone's secondary DNS servers isn't really necessary. I commonly see Microsoft-based DNS zones with just one NS record for the primary server. Why worry about NS records for your batch file? First, in the interest of correctness, you really should name all the zone's servers. Second, naming every NS is a good idea so that you can secure your zone.
To name a zone's secondary DNS server in Win2K, start the Microsoft Management Console (MMC) DNS snap-in, open the Forward Lookups folder, then locate and right-click the zone. Choose Properties and select the Zone Transfers tab, on which you'll see the Allow zone transfers check box and several options. The default option is To any server, which essentially permits anyone on the planet to set up a DNS server and tell that server that it's a secondary DNS server for a given zone on your DNS server—and that unwelcome secondary DNS server could then ask your DNS server to transfer everything that it knows about your DNS zone. The other options include Only to servers listed on the Name Servers tab and Only to the following servers, which lets you supply a list of servers.
In Windows 2003, Microsoft changed the DNS server's defaults. If you create a zone with a Windows 2003–based DNS server, you'll see that—by default—the server will transfer a DNS zone's information only to a server that has an NS record. So, if you're using Windows 2003, you'll be glad you've been careful about naming secondary DNS servers. And if you're using Win2K, you might consider visiting the Zone Transfers tab to implement a bit more security on your existing zones.
Now that you've taken care of bigfirm.biz, you can set up the reverse-lookup zone for 192.168.0.x. As before, you need to use the Dnscmd /zoneadd command to create the zone, the Dnscmd /config command to make it dynamic, and the Dnscmd /recordadd command to add DowntownDC as a secondary DNS server for the zone:
dnscmd localhost /zoneadd 0.168.192
.in-addr.arpa /primary /file 192.dns
dnscmd localhost /config 0.168.192
.in-addr.arpa /AllowUpdate 1
dnscmd localhost /recordadd 0.168.192
.in-addr.arpa @ NS
downtowndc.bigfirm.biz.
The only item that requires explanation is the new zone's name—0.168.192.in-addr.arpa. Reverse-lookup zones resemble the network number of a subnet (e.g., 192.168.0), but they're reversed, with the in-addr.arpa suffix appended. When you reverse 192.168.0, you get 0.168.192; when you add in-addr.arpa, you have the zone's name.
Although I haven't yet created the reverse-lookup zone for the 10.0.0 subnet (because I haven't set up DowntownDC, its future primary DNS server), I want UptownDC to be a secondary DNS server for 10.0.0's reverse-lookup zone, so I might as well create the secondary zone for 10.0.0. To do so, I can use the Dnscmd /zoneadd command but with a somewhat different syntax. I still have to specify the zone, the zone's name, and the name of its zone file. But secondary zones need one more piece of information: Who's the master? In other words, which server should the secondary DNS server look to for updating its data about that zone? That command looks like
dnscmd localhost /zoneadd 0.0.10
.in-addr.arpa /secondary 10.0.0.2
The zone name for the 10.0.0 network is the quads reversed with the in-addr.arpa suffix. The /secondary option replaces the /primary option that you've seen in previous Dnscmd /zoneadd commands, and notice that an IP address follows the /secondary option. It's the IP address of the server to which this secondary DNS server should look to find the latest information about the 0.0.10.in-addr.arpa zone.
Adding an Ipconfig /registerdns to the end of this type of batch file ensures that the DNS server registers the most up-to-date information on its zone. The result is the batch file that Listing 1 shows.
Let's finish by creating a similar batch file for DowntownDC—an easier task. You simply need to make DowntownDC a secondary server for bigfirm.biz and 0.168.192.in-addr.arpa, then create the 0.0.10.in-addr.arpa zone and make it dynamic. The result is the batch file that Listing 2 shows. The first three commands in Listing 2 create the secondary and primary zones. The fourth command sets the reverse-lookup zone for 10.0.0 to be dynamic. The fifth command adds UptownDC as a secondary DNS server for that zone. Finally, the batch file tells the DNS server to register itself.
Dnscmd has many options, but I've shown you most of what you'll need. With these examples, you should be able to begin your trek toward building your own disaster-recovery scripts.
End of Article
Prev. page
1
[2]
next page -->
