When disaster strikes, it really helps to know what to do. Knowing to duck under a sturdy table or desk during an earthquake can save you from being pinned under a toppling monitor. Knowing how to turn off your gas can save your house from conflagration.
Likewise, knowing what to do in a network disaster (or even just a minor mishap) can help you keep your network running.
If you lose network connectivity for a long time, your name servers may have problems. If they lose connectivity to the root name servers for an extended period, they'll stop resolving queries outside their authoritative zone data. If the secondaries can't reach their master, sooner or later they'll expire the zone.
In case your name service really goes haywire because of the connectivity loss, it's a good idea to keep a sitewide or workgroup HOSTS file around, as we recommended earlier in this chapter. If your name servers all go down, your hosts will still be able to resolve the names of hosts in the HOSTS file.
As for secondaries, you can reconfigure a secondary that can't reach its master to run temporarily as a primary master. Just right-click on the zone's domain name in the DNS console, select Properties, make sure the General tab is selected, and click on Change to change the zone type from secondary to primary. If more than one secondary for the same zone is cut off, you can configure one as a primary master temporarily and reconfigure the other to load from the temporary primary.
If an extended outage cuts you off from the Internet?say for a week or more?you may need to restore connectivity to root name servers artificially to get things working again. Every name server needs to talk to a root name server occasionally. It's a bit like therapy: the name server needs to contact the root to regain its perspective on the world.
To provide root name service during a long outage, you can set up your own root name servers, but only temporarily. Once you're reconnected to the Internet, you must shut off your temporary root servers. The most obnoxious vermin on the Internet are name servers that believe they're root name servers but don't know anything about most top-level domains. A close second is the Internet name server configured to query?and report?a false set of root name servers.
That said, and our alibis in place, here's what you have to do to configure your own root name server. First, you need to create the root zone. The root zone will delegate to the highest level zones in your isolated network. For example, if movie.edu were to be isolated from the Internet, we might create a root zone datafile, root.dns, for terminator:
. IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day ; Refresh, retry, and expire really don't matter since all ; roots are primaries. Minimum TTL could be longer, since ; the data is likely to be stable. IN NS terminator.movie.edu. ; terminator is the temp. root ; Our root only knows about movie.edu and our two ; in-addr.arpa domains movie.edu. IN NS terminator.movie.edu. IN NS wormhole.movie.edu. 249.249.192.in-addr.arpa. IN NS terminator.movie.edu. IN NS wormhole.movie.edu. 253.253.192.in-addr.arpa. IN NS terminator.movie.edu. IN NS wormhole.movie.edu. terminator.movie.edu. IN A 188.8.131.52 wormhole.movie.edu. IN A 184.108.40.206 IN A 220.127.116.11
Then we need to add the zone with the DNS console and update all of our name servers (except the new, temporary root) with a cache.dns file that includes just the temporary root name server (it's best to move the old cache file aside?we'll need it later, once connectivity is restored).
Here are the contents of the cache.dns file:
. 99999999 IN NS terminator.movie.edu. terminator.movie.edu. IN A 18.104.22.168
This process will keep movie.edu name resolution going during the outage. Once Internet connectivity is restored, we can delete the root zone on terminator and restore the original cache files on all our other name servers.