 | Chapter 15 Miscellaneous |  |
| Chapter 15 Miscellaneous | |
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.
We'll separate dialup connections into two categories: simple dialup, by which we mean a single computer that connects to the Internet occasionally, when a user manually initiates a connection, and dial-on-demand, which means one or more computers that connect to the Internet automatically whenever they generate traffic bound for the Internet. Often, the device that makes this dial-on-demand connectivity possible is a small dialup router with an analog modem or ISDN interface, like an Ascend Pipeline 25.
The easiest way to deal with simple dialup is to configure your dialup computer'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, like Windows 95 and NT, will let you define a set of name servers for a particular dialup provider. So, for example, you can configure one set of name servers to use when you dial up Netcom, and another to use when you dial up your office. Unfortunately, defining name servers for your LAN connection under Windows 95 currently overrides all your precious dialup settings. See Chapter 6, Configuring Hosts, for details.
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. If you have special needs that aren't addressed by this configuration, take a look at the recommendations in the dial-on-demand section.
A more sophisticated dialup solution is dial-on-demand. Dial-on-demand Internet connections often use dedicated hardware, like a small dialup router, to provide connectivity whenever it's needed. If you initiate a connection to the Internet from the "remote" end of a dial-on-demand router, bingo, it dials up another router on the Internet and routes your packets across. If the connection is idle for more than a specified amount of time, the router drops the connection.
The challenge with DNS is to keep a local name server from continuously bringing the demand dial connection up and down like a yo-yo. This could be costly for you, since you sometimes pay a premium for connection setup with technologies like ISDN.
The most important strategy for minimizing this off-net traffic is to configure your resolvers to use a minimal search list. Default search lists with resolvers based on BIND 4.8.3 or earlier search the ancestors of your local domain, which can cause unnecessary remote traffic. For instance, say your local domain is tinyoffice.majorcorp.com, and you have a dial-on-demand connection to Majorcorp's enterprise network. On your older (pre-4.9) hosts, your default search list is:
tinyoffice.majorcorp.com majorcorp.com
A user typing telnet foo.tinyoffice.majorcorp.com to log in to the workstation next to him will inadvertently cause lookups of:
foo.tinyoffice.majorcorp.com.tinyoffice.majorcorp.com and foo.tinyoffice.majorcorp.com.majorcorp.com
before the correct domain name, foo.tinyoffice.majorcorp.com, is looked up. Since your local name server is probably authoritative for tinyoffice.majorcorp.com, it can tell that the first domain name, foo.tinyoffice.majorcorp.com.tinyoffice.majorcorp.com, is bogus. (It ends in com.tinyoffice.majorcorp.com, so it would require the existence of a com subdomain of your local domain, and there isn't one.) But it can't tell about the second domain name without talking to a majorcorp.com name server first. If there isn't one locally, it'll have to bring up that dial-on-demand connection.
The easiest way to prevent these unnecessary queries is to trim the parent domain out of your search list explicitly, using the search directive. Or, if you can, upgrade your resolver to BIND 4.9 or later, which will check the domain name as is first if it has at least ndots dots in it, and which doesn't put any ancestor domains into the search list by default.
If your name server continues to bring up the link, try turning on query logging (with options query-log on a 4.9 name server, or ndc query with a BIND 4.9 or 8 name server, or by turning on debugging on an older name server) and look for the domain names that bring up the link. If many of them are in your parent zone, you might consider configuring your local name server as a slave for your parent zone. At least that way you'll only bring up the link at most once per refresh interval to resolve names in your parent zone. The same logic could be applied to nearly any zone your local name server queries often.
|  | |
| 15.4 DNS and Internet Firewalls |  | 15.6 Network Names and Numbers |