Previous Page
Next Page

8.6. Coping with Disaster

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. Living out in California, as we do, we have some first-hand experience with disaster, and some suggestions.

8.6.1. Long Outages (Days)

If you lose network connectivity for a long time, your nameservers may begin to have problems. If they lose connectivity to the root nameservers for an extended period, they'll stop resolving queries outside their authoritative zone data. If the slaves 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 site-wide or workgroup /etc/hosts around. In times of dire need, you can move resolv.conf to resolv.bak, kill the local nameserver (if there is one), and just use /etc/hosts. It's not flashy, but it'll get you by.

As for slaves, you can reconfigure a slave that can't reach its master to temporarily run as a primary. Just edit named.conf and change the type substatement in the zone statement from slave to master, then delete the masters substatement. If more than one slave for the same zone is cut off, you can configure one as a primary temporarily and reconfigure the others to load from the temporary primary.

8.6.2. Really Long Outages (Weeks)

If an extended outage cuts you off from the Internetsay for a week or moreyou may need to restore connectivity to root nameservers artificially to get things working again. Every nameserver needs to talk to a root nameserver occasionally. It's a bit like therapy: the nameserver needs to contact a root periodically to regain its perspective on the world.

To provide root name service during a long outage, you can set up your own root nameservers, 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 nameservers that believe they're root nameservers but don't know anything about most top-level domains. A close second is the Internet nameserver configured to queryand reporta false set of root nameservers.

That said, and with our alibis in place, here's what you have to do to configure your own root nameserver. First, you need to create db.root, the root zone datafile. 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 db.root file for toystory that looks like this:

$TTL 1d
. IN SOA toystory.movie.edu. al.movie.edu. (
                 1        ; Serial
                 3h       ; Refresh
                 1h       ; Retry
                 1w       ; Expire
                 1h )     ; Negative TTL

  IN NS toystory.movie.edu. ; toystory is the temp. root

; Our root only knows about movie.edu and our two
; in-addr.arpa domains

movie.edu. IN NS toystory.movie.edu.
           IN NS wormhole.movie.edu.

249.249.192.in-addr.arpa. IN NS toystory.movie.edu.
                          IN NS wormhole.movie.edu.

253.253.192.in-addr.arpa. IN NS toystory.movie.edu.
                          IN NS wormhole.movie.edu.

toystory.movie.edu.   IN A 192.249.249.3
wormhole.movie.edu.   IN A 192.249.249.1
                      IN A 192.253.253.1

Then, we need to add the appropriate line to toystory's named.conf file:

// Comment out hints zone
// zone . {
//              type hint;
//                      file "db.cache";
//              };

zone "." {
                type master;
                file "db.root";
};

We then update all of our nameservers (except the new, temporary root) with a db.cache file that includes just the temporary root nameserver (it's best to move the old root hints file aside; we'll need it later, once connectivity is restored).

Here are the contents of the file db.cache:

.  99999999  IN  NS  toystory.movie.edu.

toystory.movie.edu.  99999999   IN  A  192.249.249.3

This process keeps movie.edu name resolution going during the outage. Once Internet connectivity is restored, we can delete the root zone statement from named.conf, uncomment the hint zone statement on toystory, then restore the original root hints files on all other nameservers.


Previous Page
Next Page