14.5 Dial-up Connections | DNS on Windows 2000


Team-Fly

	DNS on Windows 2000, 2nd Edition By Matt Larson, Cricket Liu
	Table of Contents

	Chapter 14. Miscellaneous

14.5 Dial-up Connections

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

We'll separate dial-up connections into two categories: simple dial-up, 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 dial-up router with an analog modem or ISDN interface, such as an Ascend Pipeline 25.

14.5.1 Simple Dial-up

The easiest way to deal with simple dial-up is to configure your dial-up computer's resolver to use a name server provided by your 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, including all modern versions of Windows, will let you define a set of name servers for a particular dial-up 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, if you're still using Windows 95, defining name servers for your LAN connection overrides all your precious dial-up settings. ^[1]

^[1] A handy shareware utility called Netswitcher allows Windows 95 users to change resolver settings easily. For more information, see http://www.netswitcher.com.

This configuration is usually adequate for most casual dial-up users. Name resolution fails unless the dial-up 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 next section.

14.5.2 Dial-on-Demand

A more sophisticated dial-up solution is dial-on-demand. Dial-on-demand Internet connections often use dedicated hardware, such as a small dial-up 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, 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 dial-on-demand connection up and down like a yo-yo. This could be costly, because 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 (or DNS suffix list, as it's called in Windows). The default Windows search list (which you get when you don't specify an explicit list of DNS suffixes to search) searches 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 hosts without an explicit DNS suffix list, your default search list is:

 tinyoffice.majorcorp.com majorcorp.com

A user typing telnet foo.tinyoffice.majorcorp.com to log into the workstation next to him might inadvertently cause lookups of both of these addresses:

 foo.tinyoffice.majorcorp.com.tinyoffice.majorcorp.com foo.tinyoffice.majorcorp.com.majorcorp.com

before the correct domain name, foo.tinyoffice.majorcorp.com , is looked up. ^[2] 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.

^[2] The exact behavior depends on which version of Windows the user is running. Older versions of Windows exhibit this behavior, but newer versions of Windows try to resolve any domain names containing at least one dot by themselves before appending the search list. You'll find more details about resolver behavior in Chapter 6.

The easiest way to prevent these unnecessary queries is to trim the parent domain out of your search list explicitly by setting a DNS suffix list in the resolver configuration. In this example, a DNS suffix list tinyoffice.majorcorp.com (just one entry) would probably cause fewer failed off-site lookups.

If many of the names your users look up are in your parent zone, you might also consider configuring your local name server as a slave for your parent zone. At least that way you'll bring up the link at most only 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.


Team-Fly

Top