16.4 Dialup Connections

Another relatively recent development in networking that presents a challenge to DNS is the dialup Internet connection. When the Internet was young, and DNS was born, there was no such thing as a dialup connection. With the enormous explosion in the Internet's popularity and the propagation of Internet service providers who offer dialup Internet connectivity to the masses, a whole new breed of problems with name service has been introduced.

The basic goal when setting up DNS to work with dialup is to enable every host in your network to resolve the domain names of every host it needs to access. (Of course, when your connection to the Internet is down, your hosts probably don't need to resolve Internet domain names.) If you're using dial-on-demand, there's the additional goal of minimizing unnecessary dialouts: if you're looking up the domain name of a host on your local network, that shouldn't require your router to bring up a connection to the Internet.

We'll separate dialup connections into two categories: manual dialup, by which we mean a connection to the Internet that must be brought up by a user; and dial-on-demand, which implies the use of a device—often a router, but sometimes just a host running Linux or another server operating system—to connect to the Internet automatically whenever hosts generate traffic bound for the Internet. We'll also describe two scenarios for each category of dialup: one in which you have just one host dialing up a connection to the Internet, and one in which you have a small network of hosts dialing up a connection. Before we talk about these scenarios, though, let's discuss what causes dialouts and how to avoid them.

16.4.1 What Causes Dialouts

Many users, particularly in Europe, where ISDN is popular, connect to the Internet via dial-on-demand connections. Nearly all of these users want to minimize, if not completely prevent, unnecessary connections to the Internet. Connection setup is often more expensive than successive minutes, and always takes time.

BIND name servers, unfortunately, aren't terribly well suited to running behind dial-on-demand connections. They periodically send system queries to look up the current list of root name servers, even when the name server isn't resolving domain names. And the operation of the search list can cause the name server to query remote name servers. For example, say your local domain name is tinyoffice.megacorp.com and you have a local name server authoritative for that zone. Your default search list, on some resolvers, might include:

tinyoffice.megacorp.com
megacorp.com

Let's say you try to FTP to one of your local systems, deadbeef.tinyoffice.megacorp.com, but you misspell it deadbeer :

% ftp deadbeer

Because of your search list, your resolver would first look up deadbeer.tinyoffice.megacorp.com. Your local name server, authoritative for the tinyoffice.megacorp.com zone, can tell that domain name doesn't exist. But then your resolver appends the second domain name in the search list and looks up deadbeer.megacorp.com. To figure out whether that domain name exists, your name server needs to query a megacorp.com server, which will require bringing up the dial-on-demand link.

16.4.2 Avoiding Dialouts

There are several general techniques that will help you minimize unnecessary dialouts. The first, and probably simplest, is to run a version of BIND that supports negative caching (which means anything newer than BIND 4.9.5, but we certainly prefer BIND 8 and 9). That way, if you mistakenly put deadbeerinto a configuration file, your name server looks up deadbeer.megacorp.com once, and then caches the fact that the domain name doesn't exist for the duration of megacorp.com's negative caching TTL.

Another technique is to use a minimal search list. If your local domain name is tinyoffice.megacorp.com, you could make do with a search list of just tinyoffice.megacorp.com. That way, a typo won't cause a dialout.

Using a modern resolver is also important. The default search list for a post-BIND 4.9 resolver is just the local domain name, which qualifies as "minimal" in our book. And a modern resolver knows to try a domain name with dots as-is, even if it doesn't end in a dot.

Finally, you can use other naming services, such as /etc/hosts, for local name resolution and configure your resolvers to use DNS only if a name cannot be found in /etc/hosts. As long as you keep the names of all your local hosts in /etc/hosts, you won't need to worry about needless connections to the Internet.

Now let's apply these techniques to our scenarios.

16.4.3 Manual Dialup with One Host

The easiest way to deal with the simple dialup scenario is to configure your host's resolver to use a name server provided by your Internet service provider (ISP). Most ISPs run name servers for their subscribers' use. If you're not sure whether your ISP provides name servers for your use, or if you don't know what their IP addresses are, check their web site, send them email, or give them a call.

Some operating systems, such as Windows 95, 98, and NT, let you define a set of name servers for use with a particular dialup provider. So, for example, you can configure one set of name servers to use when you dial up UUNet and another to use when you dial up your office. This is useful if you dial in to multiple ISPs.

This configuration is usually adequate for most casual dialup users. Name resolution will fail unless the dialup connection is up, but that's not likely to be a problem, since there's no use for Internet name service without Internet connectivity.

Some of you, however, may want to run a name server when your dialup connection is active. It could help your performance by caching domain names you look up frequently, for example. This is easy to set up with a Unix-like operating system such as Linux: you'll typically use a script like ifup to bring up your dialup connection and ifdown to bring it down. If that's the case, there are probably also scripts called ifup-post and ifdown-post that ifup and ifdown call, respectively, after they've done most of their work. You can start named as named or with ndc start in ifup-post, and shut it down with ndc stop or rndc stop in ifdown-post. About the only other thing you'd need to do is set your local domain name in resolv.conf. The default resolver behavior, querying a name server on the local host, should do fine both when the name server's running and when it's not.

16.4.4 Manual Dialup with Multiple Hosts

The simplest solution to use with the multiple host/manual dialup scenario is similar to the resolver-only configuration. You can configure your resolvers to use your ISP's name servers, but also configure the resolvers to check /etc/hosts (or NIS, if you go for that sort of thing) before querying a name server. Then make sure your /etc/hosts file contains the names of all the hosts on your local network.

If you'd like to run a name server locally, you only need to modify this configuration slightly: configure the resolvers to use your local name server instead of your ISP's. This will give you the benefits of local caching, but local name resolution will work (via /etc/hosts) even when your connection to the Internet is down. You may as well start and stop the local name server from ifup-post and ifdown-post, as described earlier.

For those of you who really want to use DNS for all name resolution, you can forgo the /etc/hosts file and create forward-mapping and reverse-mapping zones on your local name server for your hosts. You should trim your resolvers' search lists to the bare minimum, though, to minimize the chance that you'll induce your name server to look up some wacky remote domain name.

16.4.5 Dial-on-Demand with One Host

If you have a single host with a dial-on-demand connection to the Internet, your simplest solution is still a resolver-only configuration. Configure your resolver to use your ISP's name servers, and when the resolver needs to look up a domain name, it'll query one of those name servers and bring up the link. If there are some domain names that your host looks up routinely as part of "housekeeping," like localhost or 1.0.0.127.in-addr.arpa, you can add those to /etc/hosts and configure your resolver to check /etc/hosts before querying a name server.

If you'd like to run a name server locally, make sure it is able to map localhost and 1.0.0.127.in-addr.arpa to 127.0.0.1 and localhost, respectively, and trim your search list to the minimum.

If your name server brings up the link more than you think it should, try turning on query logging (with options query-log on a BIND 4.9 name server, ndc querylog on a BIND 4.9 or 8 name server, or rndc querylog on a BIND 9.1.0 name server) and look for the domain names that bring up the link. If many of them are in a single zone, you might consider configuring your local name server as a slave for that zone. At least that way, you'll bring up the link at most only once per refresh interval to resolve domain names in the zone.

16.4.6 Dial-on-Demand with Multiple Hosts

The simplest solution in this scenario is exactly the same as the first solution we described in Section 16.4.4: a resolver-only configuration with the resolvers configured to check /etc/hosts before querying a name server. As with all dial-on-demand configurations, you'll want to trim your search list down.

Alternatively, you could try one of the two variants: running a local name server and using it as a backup to /etc/hosts, or creating forward- and reverse-mapping zones for the local hosts on the local name server.

16.4.7 Running Authoritative Name Servers over Dial-on-Demand

This may sound like a silly subject to some of you—who would run an authoritative name server behind a dial-on-demand connection?—but in some parts of the world, where bandwidth and Internet connectivity aren't easy to come by, this is a necessity. And, believe it or not, BIND provides a mechanism to accommodate such name servers.

If you run an authoritative name server behind a dial-on-demand link, you want to concentrate zone maintenance activities into as short a window as possible. If your name server is authoritative for 100 zones, you'd rather not have zone refresh timers popping every few minutes and the resulting SOA queries bringing up the dial-on-demand link over and over again.

With BIND 8.2 and newer name servers and BIND 9.1.0 and later name servers, you can configure a heartbeat interval . The heartbeat interval is how frequently you'd like your name server to bring up its dial-on-demand connection, in minutes:

options {
	heartbeat-interval 180;      // 3 hours
};

The default is 60 minutes, and you can disable zone maintenance by setting the interval to zero.

If you then mark one or more of your zones as dialup zones, the name server will try to concentrate all maintenance of that zone into a short period and to perform the maintenance no more often than the heartbeat interval. For a slave zone, that means inhibiting the normal refresh timer (even ignoring the refresh interval, if it's smaller than the heartbeat interval!) and querying the master for the zone's SOA record only at the heartbeat interval. For a master zone, that means sending out NOTIFY messages, which will presumably bring up the dial-on-demand link and trigger a refresh on the slaves.

To mark all of a name server's zones as dialup zones, use the dialup substatement in an options statement:

options {
	heartbeat-interval 60;
	dialup yes;
};

To mark a single zone as a dialup zone, use the dialup substatement to the zone statement:

zone "movie.edu" {
	type master;
	file "db.movie.edu";
	dialup yes;
};

Dialup zones are also useful in another, perhaps unintended way: on name servers that serve as slaves for thousands of zones. Some ISPs provide slave service on a large scale but get bitten by miscreants who set their zone's refresh intervals far too low. Their name servers end up swamped with sending out SOA queries for those zones. By configuring all the zones as dialup zones and setting the heartbeat interval to something reasonable, ISPs can prevent this.