Every host on the Internet has a unique IP address. Then why do we use names such as www.totalsem.com to access hosts, such as a Web server, instead of an IP address?

Although computers use IP addresses to communicate with each other over a TCP/IP network, people need easy-to-remember names. To resolve this conflict, long ago, even before TCP/IP and the Internet took over, network developers created a process called name resolution that automatically converts computer names to logical addresses or physical addresses (MAC addresses) to make it easier for people to communicate with computers (Figure 9-1).

Figure 9-1 Turning names into numbers

Like any process that’s been around for a long time, name resolution has evolved over the years. Ancient networking protocols would resolve a computer name such as Mike’s Laptop to a MAC address. As TCP/IP gained dominance, name resolution concentrated on resolving names to IP addresses. Even within TCP/IP, there have been many changes in name resolution. Entire TCP/IP applications have been written, only to be supplanted (but never totally abandoned) by newer name resolution protocols.

All TCP/IP networks, including the Internet, use a name resolution protocol called Domain Name System (DNS). DNS is a powerful, extensible, flexible system that supports name resolution on tiny in-house networks, as well as the entire Internet. Most of this chapter covers DNS, but be warned: your brand-new system, running the latest version of whatever operating system, still fully supports a few older name resolution protocols that predate DNS. This makes name resolution in contemporary networks akin to a well-run house that’s also full of ghosts; ghosts that can do very strange things if you don’t understand how those ghosts think.

In this chapter, you’ll take an in-depth tour of name resolution, starting with a discussion of two ghostly precursors to DNS: Microsoft’s ancient NetBIOS protocol and the hosts file. The chapter then turns to DNS, explaining how it works, and how DNS servers and clients are used today.

Odds are good you have a system connected—or that at least can connect—to the Internet. If I were you, I’d fire up that system and use it while you read this chapter. The vast majority of the programs you’re going to learn about here come free with every operating system.

Test Specific

Before DNS

Early name resolution solutions offered simple but effective network naming. While most of these are long dead, there are two name resolution solutions that continue to work in modern systems: Microsoft’s NetBIOS names and hosts files.

NetBIOS

Even though TCP/IP was available back in the 1980s, Microsoft developed and popularized a light and efficient networking protocol called NetBIOS/NetBEUI. It had a very simple naming convention (the NetBIOS part) that used broadcasts for name resolution. When a computer booted up, it broadcast its name (Figure 9-2) along with its MAC address. Every other NetBIOS/NetBEUI system heard the message and stored the information in a cache. Any time a system was missing a NetBIOS name, the broadcasting started all over again.

Figure 9-2 NetBIOS broadcast

NOTE  Microsoft didn’t lump NetBIOS and NetBEUI into a single protocol, but they were used often enough together that I’m lumping them for convenience of discussion. You won’t see NetBEUI on the CompTIA Network+ exam.

NetBIOS was suitable only for small networks for two reasons. First, it provided no logical addressing like IP addresses; each system had to remember the NetBIOS name and the MAC address. Without a logical address, there was no way to support routing. Second, all of the broadcasting made it unacceptable for large networks.

Microsoft’s networking was designed for small, unrouted networks of no more than around 40 hosts. There was no such thing as Telnet, e-mail, Minecraft, or the Web with NetBIOS, but it worked well for what it did at the time.

By the mid-1990s, Microsoft realized the world was going with TCP/IP and DNS, and it needed to switch too. The problem was that there was a massive installed base of Windows networks that needed NetBIOS/NetBEUI.

Microsoft designed a new TCP/IP protocol that enabled it to keep using the NetBIOS names but dump the NetBEUI protocol. The new protocol, NetBIOS over TCP/IP (NetBT), runs NetBIOS on top of TCP/IP. In essence, Microsoft created its own name resolution protocol that had nothing to do with DNS.

EXAM TIP  Getting NetBIOS to play nicely with TCP/IP requires proper protocols. NetBIOS over TCP/IP uses TCP ports 137 and 139, and UDP ports 137 and 138.

NetBT made things weird on Windows systems. Windows systems used NetBT names for local network jobs such as accessing shared printers or folders, but they also used DNS for everything else. It basically meant that every Windows computer had one name used on the local network—like MIKES-PC—and a DNS name for use on the Internet.

To be more accurate, NetBIOS only handled host names, it didn’t actually do any of the resource sharing. Microsoft used another protocol called Server Message Block (SMB) that ran on top of NetBT to support sharing folders and files. SMB used NetBIOS names to support the sharing and access process. SMB isn’t dependent on NetBIOS and today runs by itself using TCP port 445.

hosts

When the Internet was very young and populated with only a few hundred computers, name resolution was pretty simple. The original TCP/IP specification implemented name resolution using a special text file called hosts. A copy of this file was stored on every computer system on the Internet. The hosts file contained a list of IP addresses for every computer on the Internet, matched to the corresponding system names. Part of an old hosts file might look something like this:

If your system wanted to access the system called fred, it looked up the name fred in its hosts file and then used the corresponding IP address to contact fred. Every hosts file on every system on the Internet was updated every morning at 2 A.M.

Not only was the Internet a lot smaller then, but also there weren’t yet rules about how to compose Internet names, such as that they must end in .com or .org, or start with www or ftp. People could name computers pretty much anything they wanted (there were a few restrictions on length and allowable characters) as long as nobody else had snagged the name first.

This hosts file naming system worked fine when the Internet was still the province of a few university geeks and some military guys, but when the Internet grew to about 5000 systems, it became impractical to make every system use and update a hosts file. This created the motivation for a more scalable name resolution process, but the hosts file did not go away.

Believe it or not, the hosts file is still alive and well in every computer. You can find the hosts file in WindowsSystem32DriversEtc in Windows 10. On macOS and Linux systems, you usually find hosts in the /etc folder.

The hosts file is just a text file that you can open with any text editor. Here are a few lines from the default hosts file that comes with Windows:

See the # signs? Those are remark symbols that designate lines as comments (for humans to read) rather than code. Windows ignores any line that begins with #. Remove the # and Windows will read the line and try to act on it. Although all operating systems continue to support the hosts file, few users will actively modify and employ it in the day-to-day workings of most TCP/IP systems.

The Internet stopped using hosts files and replaced them with the vastly more powerful DNS. The hosts file still has a place today. Some folks place shortcut names in a hosts file to avoid typing long names in certain TCP/IP applications. It’s also used by some of the nerdier types as a tool to block adware/malware. There are a number of people who make hosts files you can copy and place into your own hosts file. Do a Google search for “hosts file replacement” and try a few.

NOTE  A lot of anti-malware software solutions use a custom hosts file to block known malicious or pesky sites. Check out this site for perhaps the best custom hosts file available: http://someonewhocares.org/hosts/.

DNS

When the Internet folks decided to dump the hosts file for name resolution and replace it with something better, they needed a flexible naming system that worked across cultures, time zones, and different sizes of networks. They needed something that was responsive to thousands, millions, even billions of requests. They implemented the Domain Name System (DNS) to solve these problems. This section looks at how DNS works, then examines the servers that make the magic happen. DNS wraps up with troubleshooting scenarios.

EXAM TIP  The CompTIA Network+ objectives list DNS service as a network service type. This is technically true, but DNS is most commonly referred to as simply DNS. Be prepared for any of these terms on the exam.

How DNS Works

DNS relies on that time-tested bureaucratic solution: delegation! The top-dog DNS system would delegate parts of the job to subsidiary DNS systems that, in turn, would delegate part of their work to other systems, and so on, potentially without end. These systems run a special DNS server program and are called, amazingly enough, DNS servers.

EXAM TIP  DNS servers primarily use UDP port 53 (and sometimes TCP port 53, although not for queries or responses).

NOTE  The DNS root for the entire Internet consists of 13 powerful DNS server clusters scattered all over the world. Go to www.root-servers.org to see exactly where all the root servers are located.

This is all peachy, but it raises another issue: the DNS servers needed some way to decide how to divvy up the work. Toward this end, the Internet folks created a naming system designed to facilitate delegation. The top-dog DNS server is actually a bunch of powerful computers dispersed around the world. They work as a team and are known collectively as the DNS root servers (or simply as the DNS root). The Internet name of this computer team is “.”—that’s right, just “dot.” Sure, it’s weird, but it’s quick to type, and they had to start somewhere.

EXAM TIP  The original top-level domain names were .com, .org, .net, .edu, .gov, .mil, and .int.

The DNS root servers have only one job: to delegate name resolution to other DNS servers. Just below the DNS root in the hierarchy is a set of DNS servers—called the top-level domain servers—that handle what are known as the top-level domain (TLD) names. These are the .com, .org, .net, .edu, .gov, .mil, and .int names, as well as international country codes such as .us, .eu, etc. The top-level DNS servers delegate to hundreds of thousands (maybe millions by now?) of second-level DNS servers; these servers handle the millions of names like totalsem.com and whitehouse.gov that have been created within each of the top-level domains. Second-level DNS servers support individual computers. For example, stored on the DNS server controlling the totalsem.com domain is a listing that looks like this:

www 209.29.33.25

NOTE  The Internet Corporation for Assigned Names and Numbers (ICANN) has the authority to create new TLDs. Since 2001, they’ve added many TLDs, such as .biz for businesses, .info for informational sites, and .pro for accountants, engineers, lawyers, and physicians in several Western countries.

This means the totalsem.com domain has a computer called www with the IP address of 209.29.33.25. Only the DNS server controlling the totalsem.com domain stores the actual IP address for www.totalsem.com. The DNS servers above this one have a hierarchical system that enables any other computer to find the DNS server that controls the totalsem.com domain.

NOTE  The Internet DNS names are usually consistent with this three-tier system, but if you want to add your own DNS server(s), you can add more levels, allowing you to name a computer www.houston.totalsem.com if you wish. The only limit is that a DNS name can have a maximum of 255 characters.

Name Spaces

The DNS hierarchical name space is an imaginary tree structure of all possible names that could be used within a single system. By contrast, a hosts file uses a flat name space—basically just one big undivided list containing all names, with no grouping whatsoever. In a flat name space, all names must be absolutely unique—no two machines can ever share the same name under any circumstances. A flat name space works fine on a small, isolated network, but not so well for a large organization with many interconnected networks. To avoid naming conflicts, all its administrators would need to keep track of all the names used throughout the entire corporate network.

A hierarchical name space offers a better solution, permitting a great deal more flexibility by enabling administrators to give networked systems longer, more fully descriptive names. The personal names people use every day are an example of a hierarchical name space. Most people address our town postman, Ron Samuels, simply as Ron. When his name comes up in conversation, people usually refer to him as Ron. The town troublemaker, Ron Falwell, and Mayor Jones’s son, Ron, who went off to Toledo, obviously share first names with the postman.

In some conversations, people need to distinguish between the good Ron, the bad Ron, and the Ron in Toledo (who may or may not be the ugly Ron). They could use a medieval style of address and refer to the Rons as Ron the Postman, Ron the Blackguard, and Ron of Toledo, or they could use the modern Western style of address and add their surnames: “That Ron Samuels—he is such a card!” “That Ron Falwell is one bad apple.” “That Ron Jones was the homeliest child I ever saw.” You might visualize this as the People name space, illustrated in Figure 9-3. Adding the surname creates what you might fancifully call a Fully Qualified Person Name—enough information to prevent confusion among the various people named Ron.

Figure 9-3 Our People name space

A name space most of you are already familiar with is the hierarchical file name space used by hard drive volumes. Hard drives formatted using one of the popular file formats, like Windows’ NTFS or Linux’s ext4, use a hierarchical name space; you can create as many files named data.txt as you want, as long as you store them in different parts of the file tree.

In the example shown in Figure 9-4, two different files named data.txt can exist simultaneously on the same system, but only if they are placed in different directories, such as C:Program1Currentdata.txt and C:Program1Backupdata.txt. Although both files have the same basic filename—data.txt—their fully qualified names are different: C: Program1Currentdata.txt and C:Program1Backupdata.txt. Additionally, multiple subfolders can use the same name. Having two subfolders that use the name data is no problem, as long as they reside in different folders. Any Windows file system will happily let you create both C:Program1Data and C:Program2Data folders. Folks like this because they often want to give the same name to multiple folders doing the same job for different applications.

Figure 9-4 Two data.txt files in different directories on the same system

In contrast, imagine what would happen if your computer’s file system didn’t support folders/directories. Windows would have to store all the files on your hard drive in the root directory! This is a classic example of a flat name space. Because all your files would be living together in one directory, each one would have to have a unique name. Naming files would be a nightmare! Software vendors would have to avoid sensible descriptive names like readme.txt because they would almost certainly have been used already. You’d probably have to do what the Internet does for IP addresses: An organization of some sort would assign names out of the limited pool of possible filenames. With a hierarchical name space, on the other hand, which is what all file systems use (thank goodness!), naming is much simpler. Lots of programs can have files called readme.txt because each program can have its own folder and subfolders.

NOTE  As hard as this may be to believe, some early file systems used a flat name space. Back in the late 1970s and early 1980s, operating systems such as CP/M and the early versions of DOS did not have the capability to use directories, creating a flat name space where all files resided on a single drive.

The DNS name space works in a manner extremely similar to how your computer’s file system works. The DNS name space is a hierarchy of DNS domains and individual computer names organized into a tree-like structure that is called, rather appropriately, a DNS tree. Each domain is like a folder—a domain is not a single computer, but rather a holding space into which you can add computer names.

At the top of a DNS tree is the root. The root is the holding area to which all domains connect, just as the root directory in your file system is the holding area for all your folders. Individual computer names—more commonly called host names in the DNS naming convention—fit into domains. In the PC, you can place files directly into the root directory. DNS also enables us to add computer names to the root, but with the exception of a few special computers (described in a moment), this is rarely done.

Each domain can have subdomains, just as the folders on your PC’s file system can have subfolders. You separate each domain from its subdomains with a period. Characters for DNS domain names and host names are limited to letters (A–Z, a–z), numbers (0–9), and the hyphen (-). No other characters may be used.

NOTE  Even though you may use uppercase or lowercase letters, DNS does not differentiate between them.

Don’t think DNS is only for computers on the Internet. If you want to make your own little TCP/IP network using DNS, that’s fine, although you will have to set up at least one DNS server as the root for your little private intranet. Every DNS server program can be configured as a root; just don’t connect that DNS server to the Internet because it won’t work outside your little network. Figure 9-5 shows a sample DNS tree for a small TCP/IP network that is not attached to the Internet. In this case, there is only one domain: ABCDEF. Each computer on the network has a host name, as shown in the figure.

Figure 9-5 Private DNS network

When you write out the complete path to a file stored on your PC, the naming convention starts with the root directory on the left, followed by the first folder, then any subfolders (in order), and finally the name of the file—for example, C:SoundsThundermynewcobra.wav.

The DNS naming convention is exactly the opposite. A complete DNS name, including the host name and all of its domains (in order), is called a fully qualified domain name (FQDN), and it’s written with the root on the far right, followed by the names of the domains (in order) added to the left of the root, and the host name on the far left. Figure 9-5 shows the FQDNs for two systems in the ABCDEF domain. Note the period for the root is on the far right of each FQDN!

Mikes-PC.ABCDEF.

Janelle.ABCDEF.

Given that every FQDN will always have a period on the end to signify the root, it is commonplace to drop the final period when writing out FQDNs. To make the two example FQDNs fit into common parlance, therefore, you’d skip the last period:

Mikes-PC.ABCDEF Janelle.ABCDEF

If you’re used to seeing DNS names on the Internet, you’re probably wondering about the lack of “.com,” “.net,” or other common DNS domain names. Those conventions are needed for computers that are visible on the Internet, such as Web servers, but they’re not required for DNS names on a private TCP/IP network. If you make a point never to make these computers visible on the Internet, you can skip the Internet top-level domains.

NOTE  Don’t get locked into thinking FQDNs always end with names like “.com” or “.net.” True, DNS names on the Internet must always end with them, but private TCP/IP networks can (and often do) ignore this and use whatever naming scheme they want with their DNS names.

Let’s look at another DNS name space example, but make it a bit more complex. This network is not on the Internet, so I can use any domain I want. The network has two domains, Houston and Dallas, as shown in Figure 9-6. Note that each domain has a computer called Server1.

Figure 9-6 Two DNS domains

Because the network has two different domains, it can have two systems (one on each domain) with the same host name, just as you can have two files with the same name in different folders on your PC. Now, let’s add some subdomains to the DNS tree, so that it looks like Figure 9-7.

Figure 9-7 Subdomains adde

EXAM TIP  The DNS naming convention allows for DNS names up to 255 characters, including the separating periods.

You write out the FQDN from left to right, starting with the host name and moving up to the top of the DNS tree, adding all domains until you get to the top of the DNS tree:

Mikes-PC.Support.Houston

Tom.Server1.Houston

Janelle.Sales.Dallas

Server1.Dallas

Name Servers

So where does this naming convention reside and how does it work? The power of DNS comes from its incredible flexibility. DNS works as well on a small, private network as it does on the biggest network of all time—the Internet. Let’s start with three key players:

•  DNS server   A DNS server is a computer running DNS server software.

•  Zone   A zone is a container for a single domain that gets filled with records.

•  Record A record is a line in the zone data that maps an FQDN to an IP address.

Systems running DNS server software store the DNS information. When a system needs to know the IP address for a specific FQDN, it queries the DNS server listed in its TCP/IP configuration. Assuming the DNS server stores the zone for that particular FQDN, it replies with the computer’s IP address.

A simple network usually has one DNS server for the entire domain. This DNS server has a single zone that lists all the host names on the domain and their corresponding IP addresses. It’s known as the authoritative name server for the domain.

If you’ve got a powerful computer, you can put lots of zones on a single DNS server and let that server support them all without a problem. A single DNS server, therefore, can act as the authoritative name server for one domain or many domains (Figure 9-8).

Figure 9-8 A single authoritative name server can support one or more domains.

On the opposite end of the spectrum, a single domain can use more than one DNS server. Imagine how busy the google.com domain is—it needs lots of DNS servers to support all the incoming DNS queries.

A larger-scale domain starts with a primary (master) DNS server and one or more secondary (slave) DNS servers. The secondary servers are subordinate to the primary server, but all support the same domain (Figure 9-9).

Figure 9-9 DNS flexibility

If you have a lot of DNS servers all supporting the same domain, they need to be able to talk to each other frequently. If one DNS server gets a new record, that record must propagate to all the name servers on the domain. To support this, every DNS server in the domain knows the name and address of the primary name server(s) as well as the name and address of every secondary name server in the domain. The primary name server’s job is to make sure that all the other name servers are updated for changes.

Let’s say you add to the totalsem.com domain a new computer called ftp.totalsem.com with the IP address 192.168.4.22. As an administrator, you typically add this data to the primary name server. The primary name server then automatically distributes this information to the other name servers in the domain (Figure 9-10).

Figure 9-10 New information passed out

Now let’s see how root servers work in DNS. What if Mikes-PC.Support.Dallas needs the IP address of Server1.Houston? Refer to Figure 9-11 for the answer. The image shows two DNS servers: DNS1.Dallas and DNS1.Houston. DNS1.Dallas is the primary DNS server for the Dallas domain and DNS1.Houston is in charge of the Houston domain.

Figure 9-11 Root server in action

NOTE  In the early days of DNS, you had to enter manually into your DNS server the host name and IP address of every system on the network. See “Dynamic DNS,” later in this chapter, for the way it’s done today.

As a root server, the Dallas server has a listing for the primary name server in the Houston domain. This does not mean it knows the IP address for every system in the Houston network. As a root server, it only knows that if any system asks for an IP address from the Houston side, it will tell that system the IP address of the Houston server. The requesting system will then ask the Houston DNS server (DNS1.Houston) for the IP address of the system it needs. That’s the beauty of DNS root servers—they don’t know the IP addresses for all of the computers, but they know where to send the requests!

EXAM TIP  Just because most Web servers are named www doesn’t mean they must be named www! Naming a Web server www is etiquette, not a requirement.

The hierarchical aspect of DNS has a number of benefits. For example, the vast majority of Web servers are called www. If DNS used a flat name space, only the first organization that created a server with the name www could use it. Because DNS naming appends domain names to the server names, however, the servers www.totalsem.com and www.microsoft.com can both exist simultaneously. DNS names like www.microsoft.com must fit within a worldwide hierarchical name space, meaning that no two machines should ever have the same FQDN.

Figure 9-12 shows the host named accounting with an FQDN of accounting.texas.totalsem.com.

Figure 9-12 DNS domain

NOTE  Technically, the texas.totalsem.com domain shown in Figure 9-12 is a child domain of totalsem.com (the parent domain).

These domain names must be registered for Internet use with ICANN (www.icann.org). They are arranged in the familiar second level.top level domain name format, where the top level is .com, .org, .net, and so on, and the second level is the name of the individual entity registering the domain name.

Name Resolution

In the early years of the Internet, DNS worked interchangeably with IP addressing. You could surf to a Web site, in other words, by typing in the FQDN or the IP address of the Web server. Figure 9-13 shows a browser accessing the awesome tech site AnandTech by IP address rather than by typing www.anandtech.com.

Figure 9-13 Accessing a Web site via IP address rather than name

Modern Web sites don’t really function well without DNS. A Web server that houses a company’s domain name, for example, might host a dozen or more domain names. If you try to access the Web site by IP address, the Web server won’t know which domain is being requested!

You’ll still find this 1:1 correlation of DNS name to IP address with simpler devices like IP security cameras. These are cameras with an Ethernet connection, a public IP address, and a built-in interface for viewing and control.

Once you get into how computers communicate on the Web, name resolution becomes an integral part of the process. When you type in a Web address, your browser must resolve that name to the Web server’s IP address to make a connection to that Web server. In the early days, it could resolve the name by broadcasting or by consulting the locally stored hosts text file. Today, the browser consults the host’s DNS resolver cache (more on this in a moment) or queries a DNS server.

To broadcast for name resolution, the host sent a message to all the machines on the network, saying something like, “Hey! If your name is JOESCOMPUTER, please respond with your IP address.” All the networked hosts received that packet, but only JOESCOMPUTER responded with an IP address. Broadcasting worked fine for small networks, but was limited because it could not provide name resolution across routers. Routers do not forward broadcast messages to other networks, as illustrated in Figure 9-14.

Figure 9-14 Routers don’t forward broadcasts!

As discussed earlier, a hosts file functions like a little black book, listing the names and addresses of machines on a network, just like a little black book lists the names and phone numbers of people. Clients in early TCP/IP networks consulted the hosts file for name resolution.

Modern hosts automatically map the hosts file to the host’s DNS resolver cache, a memory area that also includes any recently resolved addresses. When a host looks for an IP address that corresponds to a Web site name, it first checks the DNS resolver cache. Getting the address locally is obviously much more efficient than going out to a DNS server. Which leads us to . . . .

The final way to resolve a name to an IP address is to use DNS. Let’s say you type www.microsoft.com in your Web browser. To resolve the name www.microsoft.com, the host contacts its DNS server and requests the IP address, as shown in Figure 9-15.

Figure 9-15 A host contacts its local DNS server.

To request the IP address of www.microsoft.com, your PC needs the IP address of its DNS server. You must enter DNS information into your system. DNS server data is part of the critical basic IP information such as your IP address, subnet mask, and default gateway, so you usually enter it at the same time as the other IP information. You configure DNS in Windows using the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box. Figure 9-16 shows the DNS settings for my system. Note that I have more than one DNS server setting; the second one is a backup in case the first one isn’t working. Two DNS settings is not a rule, however, so don’t worry if your system shows only one DNS server setting.

Figure 9-16 DNS information in Windows

Every operating system has a way for you to enter DNS server information. Just about every version of Linux has some form of graphical editor, for example, to make this an easy process. Figure 9-17 shows Ubuntu’s Network Configuration utility.

Figure 9-17 Entering DNS information in Ubuntu

Every operating system also comes with a utility you can use to verify the DNS server settings. The tool in Windows, for example, is called ipconfig. You can see your current DNS server settings in Windows by typing ipconfig /all at the command prompt (Figure 9-18). In UNIX/Linux, type the following: cat /etc/resolv.conf.

Figure 9-18 The ipconfig /all command showing DNS information in Windows

Now that you understand how your system knows the DNS server’s IP address, let’s return to the DNS process.

The DNS server receives the request for the IP address of www.microsoft.com from your client computer. At this point, your DNS server checks its resolver cache of previously resolved FQDNs to see if www.microsoft.com is there (Figure 9-19). In this case, www.microsoft.com is not in the server’s DNS resolver cache.

Figure 9-19 Checking the DNS resolver cache

Now your DNS server needs to get to work. The local DNS server may not know the address for www.microsoft.com, but it does know the addresses of the DNS root servers. The 13 root servers (composed of hundreds of machines), maintained by 12 root name server operators, know all the addresses of the top-level domain DNS servers. The root servers don’t know the address of www.microsoft.com, but they do know the address of the DNS servers in charge of all .com addresses. The root servers send your DNS server an IP address for a .com server (Figure 9-20).

Figure 9-20 Talking to a root server

The .com DNS server also doesn’t know the address of www.microsoft.com, but it knows the IP address of the microsoft.com DNS server. It sends that IP address to your DNS server (Figure 9-21).

Figure 9-21 Talking to the .com server

The microsoft.com DNS server does know the IP address of www.microsoft.com and can send that information back to the local DNS server. Figure 9-22 shows the process of resolving an FQDN into an IP address.

Figure 9-22 Talking to the microsoft.com DNS server

Now that your DNS server has the IP address for www.microsoft.com, it stores a copy in its cache and sends the IP information to your PC. Your Web browser then begins the HTTP request to get the Web page.

NOTE  A local DNS server, like the one connected to a LAN, is not authoritative, but rather is used just for internal queries from internal clients, and caching.

Your computer also keeps a cache of recently resolved FQDNs, plus all entries from the hosts file. In Windows, for example, open a command prompt and type ipconfig /displaydns to see them. Here’s a small part of the results of typing ipconfig /displaydns:

DNS Servers

I’ve been talking about DNS servers for so long, I feel I’d be untrue to my vision of a Mike Meyers’ book unless I gave you at least a quick peek at a DNS server in action. Lots of operating systems come with built-in DNS server software, including Windows Server and just about every version of UNIX/Linux. A number of third-party DNS server programs are also available for virtually any operating system. I’m going to use the DNS server program that comes with Microsoft Windows Server, primarily because (1) it takes the prettiest screen snapshots and (2) it’s the one I use here at the office. You access the Windows DNS server by selecting Start | Administrative Tools | DNS. When you first open the DNS server, you won’t see much other than the name of the server itself. In this case, Figure 9-23 shows a server, imaginatively named TOTALHOMEDC2.

Figure 9-23 DNS server main screen

EXAM TIP  The most popular DNS server used in UNIX/Linux systems is called BIND.

The DNS server has (at least) three folder icons visible: Forward Lookup Zones, Reverse Lookup Zones, and Cached Lookups. Depending on the version of Windows Server you’re running and the level of customization, your server might have more than three folder icons. Let’s look at the three that are important for this discussion, starting with the Cached Lookups.

Every DNS server keeps a list of cached lookups—that is, all the IP addresses it has already resolved—so it won’t have to re-resolve an FQDN it has already checked. The cache has a size limit, of course, and you can also set a limit on how long the DNS server holds cache entries. Windows does a nice job of separating these cached addresses by placing all cached lookups in little folders that share the first name of the top-level domain with subfolders that use the second-level domain (Figure 9-24). This sure makes it easy to see where folks have been Web browsing!

Figure 9-24 Inspecting the DNS cache

Now let’s watch an actual DNS server at work. Basically, you choose to configure a DNS server to work in one of two ways: as an authoritative DNS server or as a cache-only DNS server. Authoritative DNS servers store IP addresses and FQDNs of systems for a particular domain or domains. Cache-only DNS servers are never the authoritative server for a domain. They are only used to talk to other DNS servers to resolve IP addresses for DNS clients. Then they cache the FQDN to speed up future lookups (Figure 9-25).

Figure 9-25 Authoritative vs. cache-only DNS server

NOTE  Microsoft DNS servers use a folder analogy to show lookup zones even though they are not true folders.

The IP addresses and FQDNs for the computers in a domain are stored in special storage areas called forward lookup zones. Forward lookup zones are the most important part of any DNS server. Figure 9-26 shows the DNS server for my small corporate network. My domain is called “totalhome.” I can get away with a domain name that’s not Internet legal because none of these computers are visible on the Internet. The totalhome domain only works on my local network for local computers to find each other. I have created a forward lookup zone called totalhome.

Figure 9-26 Forward lookup zone totalhome

Let’s look at the contents of the totalhome domain. First, notice a number of folders: _msdcs, _sites, _tcp, and _udp. These folders are unique to Microsoft DNS servers, and you’ll see what they do in a moment. For now, ignore them and concentrate on the individual rows of data. Each row defines a forward lookup zone record. Each record consists of Name, Type, and Data. While Name and Data (showing IPv6 and IPv4 addresses, for the most part) are obvious, the DNS record type—Type—needs a bit of discussion.

DNS Record Types

Part of the power and flexibility of DNS comes from the use of record types. Each record type helps different aspects of DNS do their job. Let’s take a moment and review all the DNS record types you’ll see on the CompTIA Network+ exam.

Individual hosts each get their own unique A record. A records are the workhorse records in any forward lookup zone. There are some common conventions here. A Web server on a forward lookup zone, for example, usually gets an A record called www, if for no other reason than users expect a Web site URL to start with www.

While A records are the most common, every forward lookup zone contains other very important record types. These are, in no specific order: SOA, NS, CNAME, AAAA, MX, SRV, and TXT. Let’s go through each one of these.

SOA   Every forward lookup zone requires a Start of Authority (SOA) record that defines the primary name server in charge of the forward lookup zone. The SOA record in the folder totalhome in Figure 9-26, for example, indicates that my server is the primary DNS server for a domain called totalhome. The primary and any secondary name servers are authoritative.

NS   The NS record in Figure 9-26 shows the primary name server for totalhome. My network could (and does) have a second name server to provide redundancy. These secondary name servers are also authoritative for the totalhome domain. Having two DNS servers ensures that if one fails, the totalhome domain will continue to have a DNS server.

Every DNS forward lookup zone will have one SOA and at least one NS record. In the vast majority of cases, a forward lookup zone will have some number of A records. You will also see other records in a standard DNS server. Figure 9-27 shows additional types of DNS records: CNAME and AAAA. You’ll also see MX records in domains that have a mail server.

Figure 9-27 Additional DNS record types

CNAME   A canonical name (CNAME) record acts like an alias. My computer’s name is mikesdesktop.totalhome, but you can also now use mike.totalhome to reference that computer. A ping of mike.totalhome returns the following:

If your computer is a member of a domain and you are trying to access another computer in that domain, you can even skip the domain name, because your PC will simply add it back:

A different tool, dig, shows the process more clearly. (I cover dig more completely in the “Troubleshooting DNS” section, later in this chapter.) Figure 9-28 shows the text output of a dig query. Querying the CNAME (mike.totalhome) returns the host (mikesdesktop.totalhome), which is recognized as an A record. The query finishes with the IP address for the host.

Figure 9-28 Results of running dig on a CNAME

AAAA    AAAA records are the equivalent of A records, but reserved for a newer type of IP addressing called IPv6. You’ll learn a lot more about IPv6 in Chapter 12, “IPv6.”

MX    MX records are used exclusively by SMTP servers to determine where to send mail. I have an in-house SMTP server on a computer I cleverly called mail. If other SMTP servers wanted to send mail to mail.totalhome (although they can’t because the SMTP server isn’t connected to the Internet and lacks a legal FQDN), they would use DNS to locate the mail server.

NOTE  MX stands for Mail eXchanger.

SRV   The idea of creating MX records to directly support e-mail motivated the Elders of the Internet to develop a generic DNS record that supports any type of server, the SRV record. SRV records have a different look than most other DNS records. The basic format of an SRV record is as follows:

•   service Name of the service supported by this record

•   proto TCP or UDP

•   name The domain name for this server (ends with a period)

•   TTL Time to live in seconds

•   priority The priority of the target host; this is used when multiple servers are present (value is 0 when only one server)

•   weight An arbitrary value to give certain services priority over others

•   port The TCP or UDP port on which the service is to be found

•   target The FQDN of the machine providing the service, ending in a dot

Here is an example of an SRV record for a Session Initiation Protocol (SIP) service:

Several common services use SRV records. These include Kerberos servers, LDAP, SIP, and, surprisingly, the popular game Minecraft!

TXT   A TXT record is a freeform type of record that can be used for … anything. TXT records allow any text to be added to a forward lookup zone. One use of TXT records is documentation. A TXT record might look like this:

TXT records can support protocols designed to deter e-mail spoofing. Solutions such as DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) use special TXT records that enable domains to verify that e-mail being received by a third-party e-mail server is sent by a legitimate server within the domain. The following is an example of SPF information stored in a TXT record:

Primary and Secondary Zones

There are two common types of forward lookup zones: a primary zone and a secondary zone. Primary zones are created on the DNS server that will act as the primary name server for that zone. Secondary zones are created on other DNS servers to act as backups to the primary zone. It’s standard practice to have at least two DNS servers for any forward lookup zone: one primary and one secondary, both of which are authoritative. Even in my small network, I have two DNS servers: TOTALDNS1, which runs the primary zone, and TOTALDNS2, which runs a secondary zone (Figure 9-29). Any time a change is placed on TOTALDNS1, TOTALDNS2 is quickly updated.

Figure 9-29 Two DNS servers with updating taking place

NOTE  If you’re looking at a Windows server and adding a new forward lookup zone, you’ll see a third type called an Active Directory–integrated forward lookup zone. I’ll cover that in just a moment.

A reverse lookup zone (Figure 9-30) enables a system to determine an FQDN by knowing the IP address; that is, it does the exact reverse of what DNS normally does! Reverse lookup zones take a network ID, reverse it, and add a unique domain called “in-addr.arpa” to create the zone. The record created is called a pointer record (PTR).

Figure 9-30 Reverse lookup zone

A few low-level functions (like mail) and some security programs use reverse lookup zones, so DNS servers provide them. In most cases, the DNS server asks you if you want to make a reverse lookup zone when you make a new forward lookup zone. When in doubt, make one. If you don’t need it, it won’t cause any trouble.

Microsoft added some wrinkles to DNS servers with the introduction of Windows 2000 Server, and each subsequent version of Windows Server retains the wrinkles. Windows Server can do cached lookups, primary and secondary forward lookup zones, and reverse lookup zones, just like UNIX/Linux DNS servers. But Windows Server also has a Windows-only type of forward lookup zone called an Active Directory–integrated zone.

EXAM TIP  Make sure you know the difference between forward vs. reverse zones. Forward enables a system to determine an IP address by knowing the FQDN; reverse enables a system to determine an FQDN by knowing the IP address.

Enter Windows

DNS works beautifully for any TCP/IP application that needs an IP address for another computer, but based on what you’ve learned so far, it has one glaring weakness: you need to add A records to the DNS server manually. Adding these can be a problem, especially in a world where you have many DHCP clients whose IP addresses may change from time to time. Interestingly, it was a throwback to the old Microsoft Windows NetBIOS protocol that fixed this and a few other problems all at the same time.

The solution was simple. Microsoft managed to crowbar the NetBIOS naming system into DNS by making the NetBIOS name the DNS name and by making the SMB protocol (which you learned about at the beginning of this chapter) run directly on TCP/IP without using NetBT.

EXAM TIP  SMB running atop NetBIOS over TCP uses the same ports UDP 137 and 138, TCP 137 and 139. Without NetBIOS, SMB uses TCP port 445.

Microsoft has used DNS names with the SMB protocol to provide folder and printer sharing in small TCP/IP networks. SMB is so popular that other operating systems have adopted support for SMB. UNIX/Linux systems come with the very popular Samba, the most popular tool for making non-Windows systems act like Windows computers (Figure 9-31).

Figure 9-31 Samba on Ubuntu (it’s so common that the OS doesn’t even use the term in the dialog)

Living with SMB   SMB makes most small networks live in a two-world name resolution system. When your computer wants to access another computer’s folders or files, it uses a simple SMB broadcast to get the name. If that same computer wants to do anything “Internety,” it uses its DNS server. Both SMB and DNS live together perfectly well and, although many alternatives are available for this dual name resolution scheme, the vast majority of us are happy with this relationship.

Well, except for one little item we’re almost happy: Windows continues to support an old organization of your computers into groups. There are three types of groups: workgroup, Windows domain, and Active Directory. A workgroup is just a name that organizes a group of computers. A computer running Windows (or another operating system running Samba) joins a workgroup, as shown in Figure 9-32. When a computer joins a workgroup, all the computers in the Network folder are organized, as shown in Figure 9-33.

Figure 9-32 Joining a workgroup

Figure 9-33 Network folder with a single workgroup

A Windows domain is a group of computers controlled by a computer running Windows Server. This Windows Server computer is configured as a domain controller. You then have your computers join the domain.

All the computers within a domain authenticate to the domain controller when they log in. Windows gives you this very powerful control over who can access what on your network (Figure 9-34).

Figure 9-34 Logging into the domain

Note that a Windows domain is not the same as a DNS domain. In the early days, a Windows domain didn’t even have a naming structure that resembled the DNS hierarchically organized structure. Microsoft eventually revamped its domain controllers to work as part of DNS, however, and Windows domains now use DNS for their names. A Windows domain must have a true DNS name. DNS domains that are not on the Internet should use the top-level name .local (although you can cheat, as I do on my totalhome network, and not use it).

On a bigger scale, a Windows network can get complicated, with multiple domains connecting over long distances. To help organize this, Windows uses a type of super domain called Active Directory. An Active Directory domain is an organization of related computers that shares one or more Windows domains. Windows domain controllers are also DNS servers.

The beauty of Active Directory is that it has no single domain controller: all the domain controllers are equal partners, and any domain controller can take over if one domain controller fails (Figure 9-35).

Figure 9-35 If one domain controller goes down, another automatically takes over.

Active Directory–Integrated Zones   Now that you have an understanding of Windows domains and Active Directory, let’s return to forward lookup zones and DNS. A standard primary zone stores the DNS information in text files on the DNS server. You then use secondary zones on other DNS servers to back up that server. If the primary DNS server goes down, the secondary servers can resolve FQDNs, but you can’t add any new records. Nothing can be updated until the primary DNS server comes back up.

In an Active Directory–integrated zone, all of the domain controllers (which are all also DNS servers) are equal and the whole DNS system is not reliant on a single DNS server. The DNS servers store their DNS information in the Active Directory. The Active Directory is stored across the servers in the domain. All Active Directory–enabled DNS servers automatically send DNS information to each other, updating every machine’s DNS information to match the others. This eliminates zone transfers.

Placing DNS Servers

Every host that connects to the Internet needs access to a DNS server. Additionally, if an internal network uses a DNS server, then every host needs access to that DNS server just to find other computers on the local network. So, the question is: where do we place DNS servers to do the job they need to do? There are many options and best practices to follow here depending on what’s required for a DNS server, as well as options for offloading DNS server administration.

NOTE  DNS is incredibly flexible, making server placement a challenge. In many cases there’s more than one good option and it’s little more than a matter of preference.

The biggest first question that must be asked when deciding on server placement is whether the individual hosts need DNS to resolve hosts on the local network. Most homes and small offices use SMB for local resolution and do not need a DNS server. Organizations that use DNS to enable individual local computers to resolve names need an internal DNS server. For example, any organization using Windows domains must have a local DNS server (Figure 9-36). Let’s call this local DNS.

Figure 9-36 If one domain controller goes down, another automatically takes over.

The second question is usually easy: do the individual hosts need DNS to resolve Internet names? No matter how small or how large the network, if hosts need the Internet, the answer is always yes. Let’s call this Internet DNS (Figure 9-37).

Figure 9-37 If one domain controller goes down, another automatically takes over.

Local DNS   The traditional method to provide DNS resolution for a local network is an internal DNS server. An internal DNS server is an on-premises DNS server owned and administered by in-house personnel. An internal DNS server contains a forward lookup zone for the in-house domain (like totalhome.local), providing DNS name resolution for all hosts on the network (Figure 9-38). It is standard procedure to have both a primary and a secondary internal DNS server.

Figure 9-38 Internal DNS servers

A local DNS server can also handle Internet naming needs. To do this, a DNS server may be configured to forward any DNS request for which the DNS server is not authoritative. This is called DNS forwarding. As Figure 9-39 shows, a DNS request for the local domain is handled by the local DNS server, while all other DNS requests are forwarded to another DNS server.

Figure 9-39 Internal DNS servers

In small networks that don’t require a DNS server for local resolution, it’s very common to use a gateway router that contains a rudimentary DNS server that only performs DNS forwarding and caching. Any DNS server that has no forward lookup zones and contains no root hints is called a cache-only (or caching-only) DNS server.

Private vs. Public DNS   A DNS server will be either private or public. Internal DNS servers that provide DNS to domains like totalhome.local are private. The computers of totalhome.local are invisible to the Internet. Therefore, the DNS server itself is also behind a firewall and in many cases resolving computers with private IP addresses. Public DNS servers are exposed to the Internet and resolve legitimate, registered, fully qualified domain names. These public servers are never behind a firewall and must have public IP addresses.

Every DNS server that resolves legitimate, registered Internet domains is public, but there is also a type of public DNS server that’s designed to handle all requests for any FQDN equally, known as public DNS servers. These public DNS servers often offer faster DNS resolution, are all but guaranteed to never go down, and many times avoid DNS redirections that some ISPs do to their customers. Here’s a small sampling of the more famous public DNS servers:

External DNS Servers   Any DNS server that is not internal to an organization is an external DNS server. External DNS servers are an integral part of the DNS structure if for no other reason than every DNS server except for root DNS servers must connect to other DNS servers that are always external to their organization.

There are, however, certain forms of external DNS servers that can take on jobs often handled by internal DNS servers. These servers can handle private or public domains, and other functions. There are two places we see these servers. First are third-party DNS server companies. These companies provide public and private DNS servers. They may also provide other products such as Web hosting, e-mail, etc. One example is Namecheap.com, one I use a lot (Figure 9-40).

Figure 9-40 DNS settings for a domain with Namecheap

Another type of DNS server is exclusively cloud-based. Third-party cloud services such as Amazon AWS and Microsoft Azure provide cloud-hosted DNS servers to support your own cloud servers and, in some cases, even support private domains.

Dynamic DNS

In the early days of TCP/IP networks, DNS servers required manual updates of their records. This was not a big deal until the numbers of computers using TCP/IP exploded in the 1990s. Then every office had a network and every network had a DNS server to update. DHCP helped to some extent. You could add a special option to the DHCP server, which is generally called the DNS suffix. This way the DHCP clients would know the name of the DNS domain to which they belonged. It didn’t help the manual updating of DNS records, but clients don’t need records. No one accesses the clients! The DNS suffix helps the clients access network resources more efficiently.

NOTE  All DHCP servers provide an option called DNS server that tells clients the IP address of the DNS server or servers.

Today, manual updating of DNS records is still the norm for most Internet-serving systems like Web servers and e-mail servers. DNS has moved beyond Internet servers; even the smallest Windows networks that run Active Directory use it. Whereas a popular Web server might have a phalanx of techs to adjust DNS settings, small networks in which most of the computers run DHCP need an alternative to old-school DNS. Luckily, the solution was worked out over a decade ago.

The TCP/IP folks came up with a new protocol called Dynamic DNS (DDNS) in 1997 that enabled DNS servers to get automatic updates of IP addresses of computers in their forward lookup zones, mainly by talking to the local DHCP server. All modern DNS servers support DDNS, and all but the most primitive DHCP servers support DDNS as well.

Windows leans heavily on DDNS. Windows networks use DDNS for the DHCP server to talk to the DNS server. When a DHCP server updates its records for a DHCP client, it reports to the DNS server. The DNS server then updates its A records accordingly. DDNS simplifies setting up and maintaining a LAN tremendously. If you need to force a DNS server to update its records, use the ipconfig /registerdns command from the command prompt.

DNS Security Extensions

If you think about what DNS does, you can appreciate that it can be a big security issue. Simply querying a DNS server gives you a list of every computer name and IP address that it serves. This isn’t the kind of information we want bad guys to have. The big fix is called DNS Security Extensions (DNSSEC). DNSSEC is an authorization and integrity protocol designed to prevent bad guys from impersonating legitimate DNS servers. It’s implemented through extension mechanisms for DNS (EDNS), a specification that expanded several parameter sizes but maintained backward compatibility with earlier DNS servers.

Dynamic DNS on the Internet

I’d like to apologize on behalf of the Network industry. There’s another kind of Dynamic DNS that has nothing to do with Microsoft’s DDNS and it’s called Dynamic DNS. To make it worse, Internet-based DDNS is also very popular, so it’s important for you to recognize the difference between the two. Let’s look at Dynamic DNS on the Internet.

The proliferation of dedicated high-speed Internet connections to homes and businesses has led many people to use those connections for more than surfing the Web from inside the local network. Why not have a Web server in your network, for example, that you can access from anywhere on the Web? You could use Windows Remote Desktop to take control of your home machine. (See Chapter 14 for more details on Remote Desktop.)

The typical high-speed Internet connection presents a problem in making this work. Most folks have a cable or DSL modem connected to a router. The router has a DHCP server inside, and that’s what dishes out private IP addresses to computers on the LAN. The router also has an external IP address that it gets from the ISP, usually via DHCP. That external address can change unless you pay extra for a static IP address. Most people don’t.

IPAM

Running DNS and DHCP at the same time creates some syncing challenges. To work together, the DHCP server must work closely with the DNS server, letting the DNS server know every time a host is given a DHCP lease so that the DNS server can then update the host’s DNS record with the correct A or AAAA records.

To deal with the issue, a number of companies provide software, known as IP Address Management (IPAM), that includes at a minimum a DHCP server and a DNS server that are specially designed to work together to administer IP addresses for a network. Windows Server deploys IPAM, for example. You’ll find it used to support SQL databases, from MySQL to Oracle to Microsoft SQL Server.

Troubleshooting DNS

As I mentioned earlier, most DNS problems result from a problem with the client systems. This is because DNS servers rarely go down, and if they do, most clients have a secondary DNS server setting that enables them to continue to resolve DNS names. DNS servers have been known to fail, however, so knowing when the problem is the client system, and when you can complain to the person in charge of your DNS server, is important. All of the tools you’re about to see come with every operating system that supports TCP/IP, with the exception of the ipconfig commands, which I’ll mention when I get to them.

So how do you know when to suspect DNS is causing the problem on your network? Well, just about everything you do on an IP network depends on DNS to find the right system to talk to for whatever job the application does. E-mail clients use DNS to find their e-mail servers; FTP clients use DNS for their servers; Web browsers use DNS to find Web servers; and so on. The first clue something is wrong is generally when a user calls, saying he’s getting a “server not found” error. Server not found errors look different depending on the application, but you can count on something being there that says in effect “server not found.” Figure 9-41 shows how this error appears in an FTP client.

Figure 9-41 DNS error

Before you start testing, you need to eliminate any DNS caches on the local system. If you’re running Windows, run the ipconfig /flushdns command now.

Your best friend when testing DNS is ping. Run ping from a command prompt, followed by the name of a well-known Web site, such as ping www.microsoft.com. Watch the output carefully to see if you get an IP address. You may get a “request timed out” message, but that’s fine; you just want to see if DNS is resolving FQDNs into IP addresses (Figure 9-42).

Figure 9-42 Using ping to check DNS

EXAM TIP  When troubleshooting, ping is your friend. If you can ping an IP address but not the name associated with that address, check DNS.

If you get a “server not found” error, you need to ping again using just an IP address. If ping works with the IP address but not with the Web site name, you know you have a DNS problem.

Once you’ve determined that DNS is the problem, check to make sure your system has the correct DNS server entry. Again, this information is something you should keep around. I can tell you the DNS server IP address for every Internet link I own—two in the office, one at the house, plus two dial-ups I use on the road. You don’t have to memorize the IP addresses, but you should have all the critical IP information written down. If that isn’t the problem, run ipconfig /all to see if those DNS settings are the same as the ones in the server; if they aren’t, you may need to refresh your DHCP settings. I’ll show you how to do that next.

If you have the correct DNS settings for your DNS server and the DNS settings in ipconfig /all match those settings, you can assume the problem is with the DNS server itself. The nslookup (name server lookup) tool enables DNS server queries. All operating systems have a version of nslookup.

EXAM TIP  Make sure you know how to use nslookup to determine if a DNS server is active!

You run nslookup from a command prompt. With nslookup, you can (assuming you have the permission) query all types of information from a DNS server and change how your system uses DNS. Although most of these commands are far outside the scope of the CompTIA Network+ exam, you should definitely know nslookup. For instance, just running nslookup alone from a command prompt shows you some output similar to the following:

Running nslookup gives me the IP address and the name of my default DNS server. If I got an error at this point, perhaps a “server not found” error, I would know that either my primary DNS server is down or I might not have the correct DNS server information in my DNS settings. I can attach to any DNS server by typing server, followed by the IP address or the domain name of the DNS server:

This new server has two IP addresses; it has two multihomed NICs to ensure there’s a backup in case one NIC fails. If I get an error on one DNS server, I use nslookup to check for another DNS server. I can then switch to that server in my TCP/IP settings as a temporary fix until my DNS server is working again.

Those using UNIX/Linux have an extra DNS tool called domain information groper (dig). The dig tool is very similar to nslookup, but it runs noninteractively. In nslookup, you’re in the command until you type exit; nslookup even has its own prompt. The dig tool, on the other hand, is not interactive—you ask it a question, it answers the question, and it puts you back at a regular command prompt. When you run dig, you tend to get a large amount of information. The following is a sample of a dig command run from a Linux prompt:

SIM  Check out the excellent Chapter 9 “Name Resolution” Type! over at http://totalsem.com/007. Working with the command line is cool!

Diagnosing TCP/IP Networks

I’ve dedicated all of Chapter 21, “Network Troubleshooting,” to network diagnostic procedures, but TCP/IP has a few little extras that I want to talk about here. TCP/IP is a pretty robust protocol, and in good networks, it runs like a top for years without problems. Most of the TCP/IP problems you’ll see come from improper configuration, so I’m going to assume you’ve run into problems with a new TCP/IP install, and I’ll show you some classic screw-ups common in this situation. I want to concentrate on making sure you can ping anyone you want to ping.

I’ve done thousands of IP installations over the years, and I’m proud to say that, in most cases, they worked right the first time. My users jumped on the newly configured systems, fired up their My Network Places/Network, e-mail software, and Web browsers, and were last seen typing away, smiling from ear to ear. But I’d be a liar if I didn’t also admit that plenty of setups didn’t work so well. Let’s start with the hypothetical case of a user who can’t see something on the network. You get a call: “Help!” he cries. The first troubleshooting point to remember here: it doesn’t matter what he can’t see. It doesn’t matter if he can’t see other systems in his network or can’t see the home page on his browser—you go through the same steps in any event.

Remember to use common sense wherever possible. If the problem system can’t ping by DNS name, but all the other systems can, is the DNS server down? Of course not! If something— anything—doesn’t work on one system, always try it on another one to determine whether the problem is specific to one system or affects the entire network.

One thing I always do is check the network connections and protocols. I’m going to cover those topics in greater detail later in the book, so, for now, assume the problem systems are properly connected and have good protocols installed. Here are some steps to take:

1. Diagnose the NIC. If you’re lucky enough to own a higher-end NIC that has its own Control Panel applet, use the diagnostic tool to see if the NIC is working.

2. Check your NIC’s driver. Replace if necessary.

3. Diagnose locally. If the NIC’s okay, diagnose locally by pinging a few neighboring systems by both IP address and DNS name. If you’re using NetBIOS, use the net view command to see if the other local systems are visible (Figure 9-43). If you can’t ping by DNS, check your DNS settings. If you can’t see the network using net view, you may have a problem with your NetBIOS settings.

Figure 9-43 The net view command in action

4. Check IP address and subnet mask. If you’re having a problem pinging locally, make sure you have the right IP address and subnet mask. Oh, if I had a nickel for every time I entered those incorrectly! If you’re on DHCP, try renewing the lease—sometimes that does the trick. If DHCP fails, call the person in charge of the server.

5. Run netstat. At this point, another little handy program comes into play called netstat. The netstat program offers a number of options. The two handiest ways to run netstat are with no options at all and with the –s option. Running netstat with no options shows you all the current connections to your system. Look for a connection here that isn’t working with an application—that’s often a clue to an application problem, such as a broken application or a sneaky application running in the background. Figure 9-44 shows a netstat command running.

Figure 9-44 The netstat command in action

6. Run netstat –s. Running netstat with the –s option displays several statistics that can help you diagnose problems. For example, if the display shows you are sending but not receiving, you almost certainly have a bad cable with a broken receive wire.

NOTE  netstat can display the executable the connection goes to using the -b option. This requires elevated privileges, but is better than -s.

7. Diagnose to the gateway. If you can’t get on the Internet, check to see if you can ping the router. Remember, the router has two interfaces, so try both: first the local interface (the one on your subnet) and then the one to the Internet. You do have both of those IP addresses memorized, don’t you? You should! If not, run ipconfig to display the LAN interface address.

8. If you can’t ping the router, either it’s down or you’re not connected to it. If you can only ping the near side, something in the router itself is messed up, like the routing table.

9. Diagnose to the Internet. If you can ping the router, try to ping something on the Internet. If you can’t ping one address, try another—it’s always possible that the first place you try to ping is down. If you still can’t get through, you can try to locate the problem using the traceroute (trace route)utility. Run tracert to mark out the entire route the ping packet traveled between you and whatever you were trying to ping. It may even tell you where the problem lies (see Figure 9-45).

Figure 9-45 Using tracert

Chapter Review

Questions

1. NetBIOS uses what type of name space?

A. Hierarchical name space

B. People name space

C. DNS name space

D. Flat name space

2. The DNS root directory is represented by what symbol?

A. . (dot)

B. / (forward slash)

C. (back slash)

D. $ (dollar sign)

3. What command do you run to see the DNS cache on a Windows system?

A. ping /showdns

B. ipconfig /showdns

C. ipconfig /displaydns

D. ping /displaydns

4. The users on your network haven’t been able to connect to the server for 30 minutes. You check and reboot the server, but you’re unable to ping either its own loopback address or any of your client systems. What should you do?

A. Restart the DHCP server.

B. Restart the DNS server.

C. Replace the NIC on the server because it has failed.

D. Have your users ping the server.

5. A user calls to say she can’t see the other systems on the network when she looks in My Network Places. You are not using NetBIOS. What are your first two troubleshooting steps? (Select two.)

A. Ping the address of a known Web site.

B. Ping the loopback address to test her NIC.

C. Ping several neighboring systems using both DNS names and IP addresses.

D. Ping the IP addresses of the router.

6. What is checked first when trying to resolve an FQDN to an IP address?

A. hosts file

B. LMHOSTS file

C. DNS server

D. WINS server

7. Which type of DNS record is used by mail servers to determine where to send e-mail?

A. A record

B. CNAME record

C. MX record

D. SMTP record

8. Running which command enables you to reset the DNS cache?

A. ipconfig

B. ipconfig /all

C. ipconfig /dns

D. ipconfig /flushdns

9. Running which command enables you to query the functions of a DNS server?

A. ipconfig

B. nslookup

C. ping

D. xdns

10. Where does a DNS server store the IP addresses and FQDNs for the computers within a domain?

A. Forward lookup zone

B. Canonical zone

C. MX record

D. SMTP record

Answers

1. D. NetBIOS uses a flat name space whereas DNS servers use a hierarchical name space.

2. A. The DNS root directory is represented by a dot (.).

3. C. To see the DNS cache on a Windows system, run the command ipconfig /displaydns at a command prompt.

4. C. You should replace the server’s NIC because it’s bad. It doesn’t need either DNS or DHCP to ping its loopback address. Having the users ping the server is also pointless, as you already know they can’t connect to it.

5. B and C. Your first two troubleshooting steps are to ping the loopback address to check the client’s NIC, and then to ping neighboring systems. If the NIC and the local network check out, then you might try pinging the router and a Web site, but those are later steps.

6. A. The hosts file is checked first when trying to resolve an FQDN to an IP address.

7. C. The MX record is used by mail servers to determine where to send e-mail.

8. D. Running the command ipconfig /flushdns resets the DNS cache.

9. B. The tool to use for querying DNS server functions is nslookup.

10. A. A DNS server stores the IP addresses and FQDNs for the computers within a domain in the forward lookup zone.