Abstract
This chapter provides some history on DNS, describes the underlying protocol, and explains how Windows NT Server implements it. The author covers how DNS fits into the naming convention scheme that includes NetBIOS naming, the network considerations for building DNS clients and servers into your network, and provides tips on testing and troubleshooting DNS.
WHY USE DNS?
DNS has lots and lots of problems. So why bother using it on your own network? Because that’s what all the cool kids are doing, and you don’t want to be the last one on the block without it. And because DNS is a key part of the Internet, and the Internet is a key part of the future of most businesses. You could probably get by without using DNS, but instead of saying, “Visit our Web site at www.idgbooks.com, you would wind up saying, “Visit our Web site at 206.80.51.140.” Not nearly as cool, is it?
Or maybe you don’t care about the Internet at all. Even for organizations with an entirely self-contained network (there are a few left out there), DNS may play an important part. DNS allows your users to address servers with friendly names rather than IP addresses, and it is much more flexible than using NetBIOS names, a long-standing standard for Windows-based networking. If nothing else, by using DNS now you will be ready for the inevitable day that your network connects into the public Internet.
Finally, DNS works well for NetBIOS name authentication. By configuring DNS within your organization, you can avoid using the 15-character computer names to identify machines, instead relying on fully qualified domain names. For example, using \\printer.east.mycompany.com to identify a printer is much more logical than identifying it as \\east-mycom-pr. For more information on NetBIOS naming alternatives, please refer to Chapter 10 and Chapter 11.
REVIEWING THE HISTORY OF DNS
When I was in college, professors told me that learning history was important so that we would not make the same mistakes our forefathers did. I suppose that’s a good way to look at it, though it didn’t make the classes much more interesting.
The history of DNS is important to understand, though, because many aspects of the protocol will not seem logical unless you understand its roots. I think it’s important to understand how a protocol came to be in order to understand how and why it does what it does. DNS is one of the oldest protocols commonly used today, and for that reason I am going to teach you a little history. If you have been through this course already, feel free to skip ahead . . . .
In the beginning of the Internet, everyone identified each other’s servers using the IP addresses. This worked out pretty well since there were not many nodes and the people who did the work on it were basically scientists, the first of the network engineers. And you know how network engineers are–they can remember thousands of IP addresses off the top of their heads. Eventually even they became weary of trying to remember all of those 32-bit numbers and came up with the idea to identify systems using host names, such as “ftp.” In doing this, they created a name resolution problem. When they referred to a computer using the host name, the computer had to know what that system’s IP address was. There was no way it could communicate directly with the other system using just the host name, so the translation had to happen somewhere. Initially these engineers implemented a HOSTS file, which is still carried in most computers today. The HOSTS file was a flat-text database consisting of the IP address of the system and the HOSTS name of the system. This worked really well, and so the HOSTS file was placed on every system on the Internet, and the administrators of each system maintained it independently.
Eventually a few problems appeared in this system that in retrospect seem pretty obvious. First, if the text database changed, there was no way to update it automatically on every system. Essentially, the response was to create a centralized HOSTS file, which would be the definitive HOSTS file on the Internet; on a regular basis, everyone checked this file for any changes. If it were changed, they would update the HOSTS files on their local systems. This worked well, but it was an inconvenience and was still plagued with several problems. For example, with only one HOSTS file on the whole Internet, if that site went down, nobody else knew what any of the DNS names were. Second, that HOSTS file started to get really, really big as more and more systems were added, each becoming a new line in the HOSTS file. So the plan did not scale very well. Third, HOSTS names didn’t provide for any kind of hierarchy, so if somebody in one site wanted to have a computer named Tony, nobody else in the whole world could have a computer named Tony. That was it. One host name, one machine.
Even today, a HOSTS file is placed on just about every system connected to an Intranet or the Internet. Windows NT, by default, places an empty HOSTS file in the directory:
<winnt_root>\system32\drivers\etc\
Now, if you examine that file on a brand-new system, you’ll notice that it only contains a single entry for “localhost” that is mapped to the loopback address. This is not all that useful by itself, but it shows that the HOSTS file is ready to go. The HOSTS file in Windows NT is enabled by default.
Most people who use their systems for networking will add entries to this HOSTS file. It’s a very convenient way to allow a handful of friendly names to resolve to IP addresses, but life could get pretty difficult if you had to add every host on the Internet to this one file. Further, you would probably want someone else to take care of that work. If you were clever, you might find a way to centralize the HOSTS file so that you and your neighbors could share the same entries.
This is exactly why DNS was created and what it accomplishes. It allows everyone on the Internet or within an organization’s intranet to resolve the same friendly names to the same IP addresses, without having to place any burden on the users of the system. I feel that I should mention the name of Dr. Paul Mockapetris, the principal designer of the DNS protocol, and extend a “Thanks!” for being one of the first people to get so annoyed with HOSTS files to actually do something about it.
Those of us who work with Microsoft products are already familiar with how a specific vendor or product can influence a protocol. DNS was influenced in this way by the Berkeley Internet Name Domain (BIND), a version of DNS developed by Berkeley Systems to run on their implementation of the UNIX operating system (BSD UNIX 4.3). BIND had such an incredible influence on the DNS protocol that aspects of the product such as the format of the data files are almost considered part of the protocol itself. Indeed, Microsoft’s implementation of the protocol uses the exact same format for its data files, despite the fact that Microsoft is normally inclined to break with tradition, relying on Jet database files instead of a more common text file standard. If Microsoft had not followed the BIND standard, they would have been chastised for being incompatible.
In the years 1986 and 1987, RFCs 974, 1034, and 1035 were written. These RFCs did not define the DNS protocol; they merely reflected its implementation in the real world. The RFCs did help ensure that different vendors’ products would interoperate. Today, modifications and improvements to the protocol must be reflected in an updated RFC to receive any industry support. For example, RFC 2181 solved many problems in RFCs 1034 and 1035.
As the Internet grows, so does the DNS protocol. DNS names have become such an important part of day-to-day life in the United States that congressional committees are currently investigating their assignment. Soon, several top-level domain names will be added to allow for the continued expansion of the name space.
OVERVIEWING DNS
This section will provide some background in the workings of DNS. I am not going to attempt to spell out every single aspect of the DNS standards; however, I do want to ensure that all readers have a baseline of certain knowledge. If you already have a good grasp of DNS, feel free to simply skim through this section and ensure there is nothing you may be weak on.
My Favorite Comparison: DNS and the OSI Model
DNS is an OSI application-layer protocol. It is flexible enough to rely on either the connection-oriented TCP or the connectionless UDP transport-layer protocols for name queries and resolutions. Table 12-1 shows DNS, its underlying protocols, and how they fit into the OSI model. Keep in mind that DNS fits better into the DOD model than the OSI model, and so there is no protocol relating to the presentation or session layers.
DNS on the Internet
DNS is easy to configure, if you don’t bother connecting to the Internet. You can make up your own domain names, assign your hosts whatever names you want, and not worry at all about security.
It gets much more complicated once you want to work and play with others on the public Internet. You will have to register your name with the InterNIC, find an ISP to host your primary and/or backup name servers, and make sure it is all safe and reliable enough not to ever fail.
Your DNS Is No More Reliable Than Your ISP
Ultimately, when someone attempts to contact a server using a fully qualified domain name, the name is resolved to an IP address by the primary or backup name server specified for that domain. If these servers should ever disappear from the Internet, as has been known to happen, people attempting to contact your network will lose touch. Even if your sites are hosted on an entirely independent connection, a failed DNS server or network can make an entire domain unusable.
Therefore, choose the ISP you will use to host your DNS carefully. You are at their mercy, and your network cannot be more reliable than their own.
Even merely finding an available domain name from the InterNIC is difficult. Many companies (often small ISPs) have bought huge numbers of domain names that they think will be wanted by somebody at some date in the future–not because they ever plan to use them, but because they hope to make a profit by selling the domain name to the highest bidder. This practice is commonly called “cyber-piracy.” This illustrates the importance of domain names to an organization’s Internet presence and shows how potentially difficult it can be. Many large companies have engaged companies who buy domain names in legal battles, with varying results. Nonetheless, it is more expensive than it is worth for most small organizations to put up a legal fight for a domain name. Recently, the Ninth U.S. Circuit Court of Appeals ruled that cyber-piracy is a form of extortion and a violation of trademark laws. This ruling may drastically change the way domain names are registered.
For more information on registering a domain name on the Internet, read the section titled “Integrating your DNS into the Internet” later in this chapter.
Domain Hierarchy
One of the keys to understanding how DNS works is understanding that it is intended to be highly distributed. In this way, DNS servers throughout the Internet store only a portion of the entire Internet namespace. Because they store only a small part but are required to resolve names for any host on the Internet, there must be a way for DNS servers to find their neighbors and ask each other for information about a specific host.
This distribution is given order through the DNS hierarchy. Domains, starting with the top-level domains and branching out below, divide the total DNS name space. In this way, the DNS hierarchy looks more like the roots of a tree than the branches of a tree, as illustrated in Figure 12-1.
The top-level domain names are closely controlled by the InterNIC, a division of the Internet Assigned Numbers Authority (IANA) responsible for assigning these names. For more information on the IANA, please refer to Chapter 2. In the United States, most people will recognize top-level names because they are part of most URLs: “.com,” “.edu,” “.net,” “.gov,” and “.org” to name a few. These top-level domains contain the basis for the rest of the domain naming structure. Individual organizations are granted second-level domain names within one or more of these top-level domains.
When an organization wishes to acquire a second-level domain name, it must submit a request to the Internet Network Information Center (InterNIC). If the domain name is available and the InterNIC doesn’t have a problem with the name, it is assigned to the organization in exchange for a biannual fee of $100. The organization itself is responsible for assigning third-level and lower domains.
For example, an organization may register the second-level domain name company under the first-level domain .com. This would allow the organization to call itself company.com on the public Internet. Further, it would be able to create third-level domain names below company.com, such as accounting.company.com or marketing.company.com. Besides creating subdomains, most organizations will add hosts to various domains. For example, when a Web server with the hostname www is added to the accounting subdomain, its fully qualified domain name becomes www.accounting.company.com.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
