Network+ Ch. 9, Network Naming

__ records are the equivalent of A records, but reserved for a newer type of IP addressing called IPv6.

AAAA

Forward lookup zone record types: AAAA

AAAA records are the equivalent of A records, but reserved for a newer type of IP addressing called IPv6.

he 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

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.

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).

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).

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

Troubleshooting DNS: 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.

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.

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. 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.

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.

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

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. 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. 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"

Troubleshooting DNS: 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. 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 of or the domain name of the DNS server:

Note: netstat can display the executable the connection goes to using the __option. This requires elevated privileges, but is better than -s.

-b

The basic format of an SRV record is as follows: _service.proto.name. TTL IN SRV priority weight port target : Explain the parts

-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

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).

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: (9):

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. 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. 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 -boption. 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).

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. 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 (year) 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.

1997

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

255

Exam tip: DNS servers primarily use UDP port

53

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 __ records.

A

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.

Forward lookup zone record types: 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 Mike Meyers set up the AAAA records on 6/6/19 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: v=spf1 include:spf.protection.outlook.com ip4:99.16.129.16 -all

Forward lookup zone 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:

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

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: Record :

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

__ are the workhorse records in any forward lookup zone.

A records

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: Zone:

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

Where does a DNS server store the IP addresses and FQDNs for the computers within a domain? Forward lookup zone Canonical zone MX record SMTP record

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

The DNS root directory is represented by what symbol? . (dot) / (forward slash) \ (back slash) $ (dollar sign)

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

What is checked first when trying to resolve an FQDN to an IP address? hosts file LMHOSTS file DNS server WINS server

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

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 cantake 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).Another type of DNS server is exclusively cloud-based. Third-party cloud services such as __ and __ provide cloud-hosted DNS servers to support your own cloud servers and, in some cases, even support private domains.

Amazon AWS and Microsoft Azure

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.

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!

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: (): 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.

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.) Ping the address of a known Web site. Ping the loopback address to test her NIC. Ping several neighboring systems using both DNS names and IP addresses. Ping the IP addresses of the router.

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.

Running which command enables you to query the functions of a DNS server? ipconfig nslookup ping xdns

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

Exam tip: The most popular DNS server used in UNIX/Linux systems is called

BIND

Which type of DNS record is used by mail servers to determine where to send e-mail? A record CNAME record MX record SMTP record

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

What command do you run to see the DNS cache on a Windows system? ping /showdns ipconfig /showdns ipconfig /displaydns ping /displaydns

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

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? Restart the DHCP server. Restart the DNS server. Replace the NIC on the server because it has failed. Have your users ping the server.

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.

Exam tip: Getting NetBIOS to play nicely with TCP/IP requires proper protocols. NetBIOS over TCP/IP uses TCP ports __ and __, and UDP ports __ and __.

TCP ports 137 and 139, and UDP ports 137 and 138.

NetBIOS uses what type of name space? Hierarchical name space People name space DNS name space Flat name space

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

Running which command enables you to reset the DNS cache? ipconfig ipconfig /all ipconfig /dns ipconfig /flushdns

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

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

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. __ helped to some extent.

DHCP

DNSSEC stands for

DNS Security Extensions (DNSSEC)

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.

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).

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.

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.

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. 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. 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.

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. 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.

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 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:\Sounds\Thunder\mynewcobra.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.

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. 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 __, a memory area that also includes any recently resolved addresses.

DNS resolver cache,

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

DNS server

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: a __ is a computer running DNS server software.

DNS server

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.

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

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. 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.

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.

DNS stands for

Domain Name Sysetm

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 Mike Meyers set up the AAAA records on 6/6/19 TXT records can support protocols designed to deter e-mail spoofing. Solutions such as __ and __ 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: v=spf1 include:spf.protection.outlook.com ip4:99.16.129.16 -all

DomainKeys Identified Mail (DKIM) ; Sender Policy Framework (SPF)

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

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. 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.

Forward lookup zone record types: 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.

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.commust fit within a worldwide hierarchical name space, meaning that no two machines should ever have the same

FQDN

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 cantake 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).

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.. The DNS server has (at least) three folder icons visible:

Forward Lookup Zones, Reverse Lookup Zones, and Cached Lookups.

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.

__ are the most important part of any DNS server.

Forward lookup zones

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 __—enough information to prevent confusion among the various people named Ron.

Fully Qualified Person Name

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. 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:\Program1\Current\data.txt and C:\Program1\Backup\data.txt. Although both files have the same basic filename—data.txt—their fully qualified names are different: C:\ Program1\Current\data.txt and C:\Program1\Backup\data.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:\Program1\Data and C:\Program2\Data folders. Folks like this because they often want to give the same name to multiple folders doing the same job for different applications.

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.commust fit within a worldwide hierarchical name space, meaning that no two machines should ever have the same FQDN. 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.

IPAM stands for

IP Address Management (IPAM)

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. 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.

n 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. 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.

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: (9): 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.

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: (9): 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).

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: (9): 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.

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: (9): 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.

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: (9):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.

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. 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.

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. 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.

Several common services use SRV records. These include (3):

Kerberos servers, LDAP, SIP, and, surprisingly, the popular game Minecraft!

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 __ records in domains that have a mail server.

MX

Forward lookup zone record types: 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.

MX stands for

Mail eXchanger

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. 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).

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.

The __ in Figure 9-26 shows the primary name server for totalhome.

NS record

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

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 cantake 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 __, one I use a lot (Figure 9-40).

Namecheap.com

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 __ folder are organized, as shown in Figure 9-33.

Network

Does DNS differentiate between uppercase and lowercase letters?

No

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: (9): 2. Check your NIC's driver.

Replace if necessary.

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: (9): 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 -boption. This requires elevated privileges, but is better than -s.

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. 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 __ for local resolution and do not need a DNS server.

SMB

MX records are used exclusively by

SMTP servers to determine where to send mail

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: (7):

SOA, NS, CNAME, AAAA, MX, SRV, and TXT. Let's go through each one of these.

Every DNS forward lookup zone will have one __ and at least one __

SOA; NS record

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. 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.

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 __ record.

SRV

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 __, the most popular tool for making non-Windows systems act like Windows computers

Samba

Every forward lookup zone requires a __ record that defines the primary name server in charge of the forward lookup zone.

Start of Authority (SOA)

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.

A __ record is a freeform type of record that can be used for ... anything.

TXT

Forward lookup zone record types: 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.

Forward lookup zone record types: 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._proto.name. TTL IN SRV priority weight port target. 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

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.

Exam tip: SMB running atop NetBIOS over TCP uses the same ports: __ Without NetBIOS, SMB uses TCP port __

UDP 137 and 138, TCP 137 and 139; 445

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. 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.

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.

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 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). 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.

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.

A __ is a group of computers controlled by a computer running Windows Server.

Windows domain

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 basic format of an SRV record is as follows:

_service.proto.name. TTL IN SRV priority weight port target -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

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. 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.

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.

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: 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.

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. 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. 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.

Troubleshooting DNS: 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. 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:

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.

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:\Sounds\Thunder\mynewcobra.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.

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.

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. 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.

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).

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.

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). 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).

There are two common types of forward lookup zones:

a primary zone and a secondary zone.

As I mentioned earlier, most DNS problems result from

a problem with the client systems.

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.

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.

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.

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

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.

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. 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.

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). 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).

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. 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!

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: 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.

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.

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. 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.

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.

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.

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. 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.

An Active Directory domain is

an organization of related computers that shares one or more Windows domains. Windows domain controllers are also DNS servers.

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 Mike Meyers set up the AAAA records on 6/6/19

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

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.

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 __ for the domain.

authoritative name server

.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

CNAME stands for

canonical name

Forward lookup zone record types: A __ record acts like an alias.

canonical name (CNAME) record

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

Troubleshooting DNS: 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. 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). 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.

Technically, the texas.totalsem.com domain shown in Figure 9-12 is a __ of totalsem.com

child domain

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.

DNS relies on that time-tested bureaucratic solution:

delegation!

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. 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. 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).

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 Mike Meyers set up the AAAA records on 6/6/19

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 __ is like a folder—a __ is not a single computer, but rather a holding space into which you can add computer names.

domain

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.

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: C:\>nslookup Default Server: totalhomedc2.totalhome Address: 192.168.4.155 > 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: > server totalhomedc1 Default Server: totalhomedc1.totalhome Addresses: 192.168.4.157, 192.168.4.156 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:

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.

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.

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:\Sounds\Thunder\mynewcobra.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

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 Mike Meyers set up the AAAA records on 6/6/19 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: v=spf1 include:spf.protection.outlook.com ip4:99.16.129.16 -all

Troubleshooting DNS: 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. 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.

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.

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.

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.

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:\Sounds\Thunder\mynewcobra.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!

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 cantake 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).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.

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.

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.

EDNS stands for

extension mechanisms for DNS (EDNS)

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.

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.

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.

Troubleshooting DNS: 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.

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

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

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. 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. 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 __ and contains no root hints is called a cache-only (or caching-only) DNS server.

forward lookup zones

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). 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.

. 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:\Program1\Current\data.txt and C:\Program1\Backup\data.txt. Although both files have the same basic filename—data.txt—their __ are different: C:\ Program1\Current\data.txt and C:\Program1\Backup\data.txt

fully qualified names

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:

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.

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.

With a __ 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.

hierarchical

The DNS __ is an imaginary tree structure of all possible names that could be used within a single system.

hierarchical name space

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 "__" in the DNS naming convention—fit into domains

host names

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!

Diagnosing TCP/IP Networks: 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.

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.

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

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 __ commands, which I'll mention when I get to them.

ipconfig

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

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 __ at the command prompt

ipconfig /all

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. Your computer also keeps a cache of recently resolved FQDNs, plusall entries from the hosts file. In Windows, for example, open a command prompt and type __ to see them.

ipconfig /displaydns

Troubleshooting DNS: 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. Before you start testing, you need to eliminate any DNS caches on the local system. If you're running Windows, run the__ command now

ipconfig /flushdns

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 "__" command from the command prompt.

ipconfig /registerdns

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

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. 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.

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

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).

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. 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 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).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).

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:

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.

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.

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.

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). 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.

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.

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.

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. 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. The second question is usually easy:

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.

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.

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. 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 ....

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. 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.

Troubleshooting DNS: 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. 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.

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: 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 __ 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 __you may have a problem with your NetBIOS settings.

net view

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.

Exam tip: Make sure you know how to use __ to determine if a DNS server is active!

nslookup

Troubleshooting DNS: 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 __ tool enables DNS server queries. All operating systems have a version of __.

nslookup (name server lookup)

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:

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.

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.

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.

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.

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

parent domain

Troubleshooting DNS: 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. 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). 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.

Exam tip: When troubleshooting, ping is your friend. If you can __, check DNS

ping an IP address but not the name associated with that address

Troubleshooting DNS: 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. 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).

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: 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.

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!

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).

A DNS server will be either private or public. Internal DNS servers that provide DNS to domains like totalhome.local are

private

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 cantake 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).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

A DNS server will be either

private or public

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

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:

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.

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: a __ is a line in the zone data that maps an FQDN to an IP address.

record

Part of the power and flexibility of DNS comes from the use of

record types

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: 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.

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.

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.

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.

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 __ 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.

resolves legitimate, registered Internet domains is

A __(Figure 9-30) enables a system to determine an FQDN by knowing the IP address;

reverse lookup zone

Troubleshooting DNS: 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. 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). 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.

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.commust fit within a worldwide hierarchical name space, meaning that no two machines should ever have the same FQDN. These domain names must be registered for Internet use with ICANN (www.icann.org). They are arranged in the familiar __ 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.

second level.top level

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). 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).

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.

DNS Security Extensions: If you think about what DNS does, you can appreciate that it can be a big

security issue

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: 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.

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.

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.

Note: DNS is incredibly flexible, making __ a challenge.

server placement

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

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.

When the Internet was very young and populated with only a few hundred computers, name resolution was pretty

simple

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 few low-level functions (like mail) and __ use reverse lookup zones, so DNS servers provide them.

some security programs

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: 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.

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).

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. 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 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).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). 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.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.

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.

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 __ to create the zone. The record created is called a pointer record (PTR).

take a network ID, reverse it, and add a unique domain called "in-addr.arpa"

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). 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.

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. 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.

Note: All DHCP servers provide an option called DNS server that

tells clients the IP address of the DNS server or servers.

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.

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). 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.

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.

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.

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.

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.

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.

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.

Troubleshooting DNS: 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. 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.

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.

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. 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.

n 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. 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!

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. 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 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).

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. 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).

Troubleshooting DNS: 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.

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).

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:\Sounds\Thunder\mynewcobra.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 __ of each FQDN!

the far right Mikes-PC.ABCDEF. Janelle.ABCDEF.

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.

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. 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 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).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). 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.

Troubleshooting DNS: 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. 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).

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. 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.

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:\Sounds\Thunder\mynewcobra.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.

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.

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).

Troubleshooting DNS: 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.

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

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:\Sounds\Thunder\mynewcobra.wav.

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.

The DNS naming convention allows for DNS names up to 255 characters, including

the separating periods.

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.commust fit within a worldwide hierarchical name space, meaning that no two machines should ever have the same FQDN. 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.

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: 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).

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.commust fit within a worldwide hierarchical name space, meaning that no two machines should ever have the same FQDN.

The Internet stopped using hosts files and replaced them with

the vastly more powerful DNS. The hosts file still has a place today.

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.

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.

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.

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.

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. 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. 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.

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). 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.

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: C:\>nslookup Default Server: totalhomedc2.totalhome Address: 192.168.4.155 > 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: > server totalhomedc1 Default Server: totalhomedc1.totalhome Addresses: 192.168.4.157, 192.168.4.156 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.

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.

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.

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.

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. 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.

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: 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.

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.

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.

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.

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.

Troubleshooting DNS: 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. 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). 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.

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.

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:

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). 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.

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: 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.

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: a __ is a container for a single domain that gets filled with records.

zone

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.

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. 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 (7):

.com, .org, .net, .edu, .gov, .mil, and .int.

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 \Windows\System32\Drivers\Etc in Windows 10. On macOS and Linux systems, you usually find hosts in the __ folder.

/etc

Note: The DNS root for the entire Internet consists of

13 powerful DNS server clusters scattered all over the world.

A DNS name can have a maximum of __ characters

255

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 __(#) hosts.

40

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

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.

The CompTIA Network+ objectives list __ 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.

DNS service

DNS stands for

Domain Name System

All TCP/IP networks, including the Internet, use a name resolution protocol called

Domain Name System (DNS).

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.

ICANN stands for

Internet Corporation for Assigned Names and Numbers (ICANN)

Note: The __ 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.

Internet Corporation for Assigned Names and Numbers (ICANN)

The __ 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.

Internet Corporation for Assigned Names and Numbers (ICANN)

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.

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.

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 __ on the CompTIA Network+ exam.

NetBEUI

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 __ names to support the sharing and access process.

NetBIOS

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.

NetBT stands for

NetBIOS over TCP/IP

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, __,runs NetBIOS on top of TCP/IP. In essence, Microsoft created its own name resolution protocol that had nothing to do with DNS.

NetBIOS over TCP/IP (NetBT)

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.

SMB stands for

Server Message Block

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 __ that ran on top of NetBT to support sharing folders and files. __ used NetBIOS names to support the sharing and access process. __ isn't dependent on NetBIOS and today runs by itself using TCP port 445.

Server Message Block (SMB)

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 \Windows\System32\Drivers\Etc 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:

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 \Windows\System32\Drivers\Etc 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:

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. 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.

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 __ in Windows 10.

\Windows\System32\Drivers\Etc

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. 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.

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.

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.

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. 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.

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.

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.

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

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.

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.

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.

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 \Windows\System32\Drivers\Etc 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:

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.

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.

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.

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.

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).

Note: A lot of anti-malware software solutions use a custom hosts file to

block known malicious or pesky sites

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.

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 __ for name resolution.

broadcasts

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:

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. 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.

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.

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.

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.

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

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 __ 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:

hosts file

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 _(#) 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

hudreds of thousands (maybe millions by now?)

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

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

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.

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. 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.

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.

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.

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.

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 __ that automatically converts computer names to logical addresses or physical addresses (MAC addresses) to make it easier for people to communicate with computers

name resolution

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.ese 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).

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. 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.

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. This means the totalsem.com domain has a computer called www with the IP address of 209.29.33.25. Only __ 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.

the DNS server controlling the totalsem.com domain

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 __ to solve these problems.

the Domain Name System (DNS)

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.

DNS is a powerful, extensible, flexible system that supports name resolution on tiny in-house networks, as well as

the entire Internet.

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.

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

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

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. 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.

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.

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.

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. 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:

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