Introducing DNS
| If you have ever connected to a Web site by name, you have used DNS. DNS is a service that is used on the Internet for resolving fully qualified domain names (FQDNs) to their actual Internet Protocol (IP) addresses. For example, suppose you were preparing to take the latest Windows Server 2003 certification exam. You've asked your co-workers about the best study guide available, and they recommend that you check out Que Publishing's Web site to see what is available. Your obvious question is, "Where can I find Que Publishing's Web site?" Before DNS, the answer would have been 63.240.93.132, and if you are like most people, you might have remembered that IP address for about 30 seconds. Given the likelihood of you forgetting that IP address, you never would have been able to use it to find Que Publishing's site (or get that study guide you were looking for). DNS puts a user-friendly face on that obscure numeric address. With DNS, your friend can tell you to go to www.quepublishing.com, and the DNS infrastructure of the Internet translates the name to the correct address, 63.240.93.132. It's like a big phone book. You put in a name, and DNS gives you the correct number. Fortunately for those of us with a limited ability to memorize strings of numbers, the Internet community recognized the benefits of a name resolution system as a critical part of the infrastructure that would make up the original Internet architecture. And DNS was born. Note: Domain Name System or Domain Name Service You may have heard that DNS stands for "Domain Name Service," yet it is referred to as "Domain Name System" in the previous sections of this chapter. These names are interchangeable, although Microsoft tends to use "Service," whereas most Internet users use "System." From here on in the chapter, we use the term "System" for consistency. DNS is a hierarchical database that contains names and addresses for IP networks and hosts, and it is used almost universally to provide name resolution. This is true now more than before because Microsoft has embraced DNS as its name resolution method for Windows Server 2003 (and Windows 2000 Server before it), in place of the more proprietary, less accepted Windows Internet Name System (WINS). Before we tackle DNS in a Windows Server 2003 network, we should cover a little of the history and makeup of DNS in general, how DNS zones work, and what the DNS server roles are. The History of DNSBack in the early days of the Internet, when it was known as the Advanced Research Products Agency Network (ARPAnet) and the number of hosts on the network was less than 100, there used to be a master list of names and IP addresses called the HOSTS file. It was maintained by the Stanford Research Institute's Network Information Center (known as the SRI-NIC at the time), and it worked very well, as long as the number of hosts was low and changes were infrequent. Everyone using the network would periodically download a copy of the HOSTS file, and they would have a local table of names and addresses with which to connect to computers by name. Windows Server 2003 (and most TCP/IP stacks in general) still has this functionality, although it is seldom used in conjunction with the Internet any longer. This method of name resolution was great for a while, but as the number of computers grew, this solution ran into a few problems, including the following:
Exam Alert: Comparing DNS with HOSTS Files For Exam 70-291, you need to be familiar with the advantages of DNS over the flat-file method of name resolution provided by a HOSTS file. The network needed a better answer than a text file for name resolution. In 1983, in RFCs 882 and 883, Paul Mockapetris introduced DNS. These RFCs have since been superseded by RFCs 1034 and 1035, the current DNS specifications. You should also be aware of RFC 2136, which defines the standards for DDNS on which Windows Server 2003 relies. Note: A Note on RFCs Request for Comments (RFC) documents are used to create proposals regarding the Internet and Internet technologies. If an RFC can garner enough interest, it may eventually become a standard. You can review all the existing RFCs by going to www.rfc-editor.org. We reference RFCs for standards-based protocols wherever possible throughout the book. The DNS DatabaseDNS is a distributed database that allows local control of DNS for segments of the namespace while still maintaining a logical architecture to provide the local information throughout the network. Each piece of the DNS database resides on a server known as a name server. The architecture of DNS is designed so that there can be multiple name servers for redundancy, and caching of names to the local server is also supported, further enhancing DNS's robustness. In addition, with parts of the overall namespace placed on separate computers, the data storage and query loads are distributed to thousands of DNS servers throughout the Internet. The hierarchy of DNS is designed in such a way that every computer on or off the Internet can be named as part of the DNS namespace. To effectively install, configure, and support the Windows Server 2003 DNS server service, you must understand the underlying architecture of today's DNS. Rather than having you read the RFCs (although you are encouraged to do so to improve your understanding of DNS), the following sections discuss the DNS namespace architecture and how individual DNS servers support their portions of the overall namespace as well as the specifics of the Windows Server 2003 DNS server service. DNS Domains DefinedAs mentioned earlier in this chapter, you probably have already used DNS, regardless of whether you were familiar with the underlying mechanism. Domain names such as www.microsoft.com or www.quepublishing.com are easy to comprehend. All you need is the ability to read. However, this simplicity comes at a price: The DNS namespace is complex. DNS names are created as part of a hierarchical database that functions much like the directories in a file system. Hierarchies are powerful database structures because they can store tremendous amounts of data while making it easy to search for specific bits of information. Before we examine the specifics of the DNS namespace hierarchy, let's discuss hierarchies in general. Note: A Simple Example of a Hierarchy Microsoft's Active Directory is an excellent example of a hierarchical database. Of course, given that the Active Directory hierarchy is created on top of the existing rules for a DNS namespace, the information on the DNS hierarchy directly relates to the construction of Active Directory. HierarchiesYou need to understand the following terms related to hierarchies:
If you told typical end users that they have been working with a hierarchy since the first time they turned on a computer, many would have no idea what you were talking about. In fact, a fair number of administrators would have to think about it as well. However, it's true: MS-DOS version 2 introduced a hierarchy to PCs in the form of the file system, and systems such as mainframes and Unix used hierarchical file structures much earlier than did MS-DOS. Why do computers need a hierarchical file system? Because storing files as an endless alphabetic listing is inefficient; the files can be stored much more efficiently in related groups. Today all computers use hierarchical structures for organizing file storage. In DNS, the containers are called domains. The hierarchy starts with a root container, called the root domain. The root domain doesn't have a name, so it is typically represented by a single period. Directly below the root domain are the top-level domains (TLD), which are also sometimes called first-level domains. Lower-level domains are second-level, third-level, and so on (see Figure 3.1). Every domain name has a suffix that indicates the TLD to which it belongs. There are only a limited number of such domains. Figure 3.1. This portion of the DNS hierarchy shows the location of www.quepublishing.com in the DNS database in relationship to other parts of the DNS database. The following are some examples of TLDs:
Originally managed by the Internet International Ad Hoc Committee (IAHC), creation and management of TLDs is now done based on the guidelines detailed in the Generic Top Level Domain Memorandum of Understanding (www.gtld-mou.org). This memorandum divides management of the TLDs between the U.S. Department of Commerce's National Telecommunication and Information Administration (NTIA; www.ntia.doc.gov) and Internet Corporation for Assigned Names and Numbers (ICANN; www.icann.org). The ICANN site related to TLDs is www.icann.org/tlds. Management of TLDs varies from name to name; the ICANN site details the organizations responsible for managing each TLD. Unfortunately, due to slow adoption by the general public, the creation of these additional domains has not completely alleviated the crowding of the original com and net domains. People still consider the com namespace to be the only acceptable namespace, and until the new TLDs become more widely accepted, you can expect to work with one of the original TLDs in most situations. As discussed previously, DNS is used to translate a hostname to an IP address. The DNS name typically looks something like this: isaac.publishing.quepublishing.com This DNS name is known as the host's FQDN because it lists the host's precise location in the DNS hierarchy. The DNS name in the example represents the host isaac in the subdomain publishing (this is frequently a department or division in a company), which is in the domain quepublishing (this is frequently the name of the company or organization that has registered the domain), which is in the TLD com. For the name to be complete, you also need a trailing dot, which indicates the root of the namespace. When an organization wants to establish a domain name on the Internet, it must register the domain name with one of the authorized registration authorities. One such organization with which many people are familiar is VeriSign, Inc., which purchased Network Solutions, which was formerly the InterNIC. (You will still find references to the InterNIC in DNS-related documentation, so you need to realize that it is now a defunct TLD registrar.) You can research new domain names and access registration forms at www.networksolutions.com. You can also contact your ISP for assistance; most ISPs offer domain name registration as part of their service. To register a domain, you need at least two name servers to provide resolution information for your domain. Some of the registrars will host your domain on their DNS servers for an additional fee, and most ISPs will also host your zone for you on their DNS servers. That's great, but what exactly is a DNS zone? Read on to find out. Exam Alert: Understanding FQDNs For the exam, make sure you have a good understanding of what an FQDN is and how it is represented. DNS ZonesIt is very easy to get lost in the maze of acronyms and buzz words surrounding DNS, especially if you are having a conversation with someone who has been working with IP networking and DNS for a while. You have primary masters for each zone, which is also a domain, unless it's a reverse lookup zone, and then you have zone transfers happening when you least expect it. To the uninitiated, this can sound alarmingly like some arcane networking ritual in which you pay homage to the DNS deities. However, it's not nearly as bad as it sounds. Before we get any deeper into the Windows Server 2003 DNS infrastructure, we need to discuss what exactly is meant by DNS zone. First, although typically abbreviated in the world of DNS, a zone is actually a zone of authority, which means it contains the complete information on some part of a domain namespace. In other words, it is a subset of a domain. The name server is considered to have authority for that zone, and it can respond to any requests for name resolution from that zone. So when you look at the DNS name www.quepublishing.com, you know that quepublishing.com is a DNS zone within the com hierarchy. www denotes the DNS record of a host contained within the quepublishing.com zone. This conceptual representation of a zone also has a physical counterpart: All the information related to a particular zone is stored in a physical file known as the zone database file or, more commonly, the zone file. If the DNS zone is not stored in Active Directory, under Windows Server 2003, this file will be found in the directory %systemroot%\system32\dns. Note: The Difference Between a Zone and a Domain Although the terms "zone" and "domain" can seem as if they are used interchangeably, there is a difference. A DNS domain is a segment of the DNS namespace. A zone, on the other hand, can contain multiple, contiguous domains. For example, quepublishing.com is a DNS domain. It contains all the information for that specific portion of the DNS namespace. sales.quepublishing.com is another example of a domain, and it is contiguous with the quepublishing.com domainin other words, the two domains "touch." So if you were to create a DNS forward lookup zone on a DNS server, it could contain records for both domains. Zones allow for the logical grouping and management of domains and resource records on DNS servers. Note: Active Directory and DNS We examine the integration and operation of DNS and Active Directory later in this chapter in the section "Integrating Active Directory and DNS." The Windows Server 2003 DNS service supports three basic types of zones:
The following sections take a closer look at these zone types, which make up the underlying structure of DNS. Forward Lookup ZonesForward lookup zones provide the hostname-to-IP address resolution for which DNS is most frequently used. A forward lookup zone contains resource records that contain the information about the resources that are available within that zone. Windows Server 2003 relies on the SRV (service) resource record to provide IP address information about servers and services within a zone, so that workstations can locate needed services such as Lightweight Directory Access Protocol (LDAP). The SRV record is also used to provide a single service over multiple hosts, assign priorities to hosts for a particular service, and move services from host to host easily. More information on the SRV record can be found in RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)." Reverse Lookup ZonesA reverse lookup zone (as you may have guessed from the name) provides the opposite resolution from a forward lookup zone: It resolves IP addresses to hostnames. This is discussed in greater detail later in this chapter, in the section "Reverse Lookups." Stub ZonesMicrosoft introduced support for stub zones for the first time in Windows Server 2003. A stub zone contains only those resource records that are necessary to identify the authoritative DNS servers for that zone. Such resource records include Name Server (NS), Start of Authority (SOA), and possibly glue host (A) records. (Glue host records provide A record pointers to ensure that the master zone has the correct name server information for the stub zone.) Stub zones are frequently used for the following:
As an example of when you might want to use stub zones, consider the scenario where two organizations are closely linked and often need to access resources on each other's networks. If you are the systems administrator in organization A, and you created a stub zone that uses one or more name servers within organization B, your users would simply issue a DNS query to an organization A DNS server, which then forwards the query to one of organization B's name servers to resolve. This solution provides a simpler and more efficient means of helping your users resolve those host names without the burden of maintaining another secondary zone on your DNS servers. Zone DelegationWith zone delegation, one DNS server can assign the administration of a domain to another DNS server. For example, let's look at the quepublishing.com domain. Let's say that the IT Department is responsible for the quepublishing.com zone, which contains the domains quepublishing.com, sales.quepublishing.com, and developers.quepublishing.com. The IT Department maintains the DNS records for all three zones, but the developers who are working on software projects are always adding and removing hosts to and from their domain and want to be able to update their resource records without having to place a request with the IT Department each time. To take care of this, the IT Department can delegate the administration of the developers.quepublishing.com zone to a DNS server that is maintained by the developers. The main zone, quepublishing.com (zones are typically named for the "uppermost" domain in the DNS hierarchy), would maintain a delegation entry that points queries about the developers.quepublishing.com domain to the developers' DNS server. Exam Alert: Zone Delegation Be sure you understand what zone delegation entails. In a distributed environment with local administration, delegation can be critical to a successful DNS implementation. Zone TransfersA zone transfer involves the copying of the zone database from one DNS server to another. This is typically done to ensure name resolution availability and DNS server fault tolerance. Given the critical nature of DNS name resolution in a Windows Server 2003 environment, using a single server to support name resolution is a bad idea. If that server is not responding or is off the network, queries for names in the zone can fail. However, if you are using multiple DNS servers for high availability, you need a mechanism to allow the primary master DNS server (the only server with a read/write copy of the zone database) to replicate and synchronize the zone database on all the DNS servers that host the zone. Windows Server 2003 supports incremental zone transfers by DNS servers. When a new DNS server is added as a host of a zone, a full transfer of the zone database is done. After that, an incremental zone transfer transfers changes to the zone database only, as opposed to the full transfer that is required with many of the older implementations of DNS. This reduces network traffic and speeds the transfer of the zone changes. Exam Alert: Zone Transfer Types Two types of zone transfer are supported by Windows Server 2003: full zone transfer and incremental zone transfer. You might see these types abbreviated as AXFR (full zone transfer) and IXFR (incremental zone transfer). DNS Server RolesThere are a number of roles that a DNS server can perform based both on configuration and on the requirements of the site or network to which the server is connected. These server roles include the following:
After you have identified the two (or more) name servers (or have arranged to have your domain hosted on someone else's DNS servers), you are ready to register your domain. To register a domain name at www.networksolutions.com, you use the process outlined in Step by Step 3.1. (This process is similar at any of the major registrars.) Step By Step3.1. Registering a DNS Domain
Note: Active Directory and DNS Domains Because of Active Directory's critical reliance on the underlying DNS infrastructure, it is a good idea to use a registered DNS name whenever you create a Windows Server 2003 network infrastructure. This ensures that your rights to use that name will never be in question. Conversely, you can also opt to create a private namespace on your internal network using a TLD such as local, corp, or int. In reality, most organizations do not actually use the same exact namespace, such as quepublishing.com, both internally and externally. Externally, quepublishing.com might be a good namespace, but internally, it might be implemented as corp.quepublishing.com or quepublishing.corp, depending on the requirements and desires of the architects planning and implementing the solution. The Name Resolution ProcessWhen you've registered a domain and you understand the DNS hierarchy, the next step is to understand how DNS works. In other words, after you enter a hostname, how does it get translated to an IP address? The DNS name server resolves a name to an IP address by using the following process:
Note: How Root Servers Find a Domain When you register a domain, you are required to provide the names and addresses of two (or more) DNS servers that will be providing DNS services for the domain. The root name servers have access to these names and addresses and thus know where to send the requests. For the process to work in your environment, you need to ensure the following are true:
The rest of the process generally just works. You do not need to maintain the root name servers list or the lookup process, although the list of root name servers is typically updated in service packs if any changes have occurred. Reverse LookupsWe have discussed how to get the most common form of DNS lookups, known as forward lookups, in which you enter a name and the DNS server returns the IP address. As mentioned earlier in this chapter, there is another kind of lookup, known as a reverse lookup. A reverse lookup works much as the name implies: You query the DNS server with an IP address, and it returns (if there is an entry) the DNS name for that host. The ability to perform a reverse lookup can be useful if you are trying to keep track of network usage, trying to track down a host that is causing problems on the network, or trying to verify the identity of a host. At one time, it was popular to use reverse lookups for the downloading of 128-bit software to ensure that the user attempting to download the software was within the United States or Canada. The different record types are discussed later in this chapter, in the "DNS Record Types" section, but for now, it is important for you to know that reverse lookup tables use PTR records to resolve IP addresses to names. (A PTR record is a pointer to a locationan FQDNin the DNS domain.) Note: Reverse Lookups and the nslookupCommand If you want to be able to correctly and completely use the nslookup command, you'll need to have correctly configured and populated reverse lookup zones on your DNS servers. Exam Alert: The Function of the Reverse Lookup Table Because they are used less and thus are less understood than forward lookup tables, reverse lookup tables are an excellent topic for exam questions. SPAM Emails and Reverse LookupsIn today's world, you are likely to find that you are using reverse lookups in the fight against spam, also known as UCE (unsolicited commercial email). Email servers use many tools to reduce the volume of spam; one tool is the reverse lookup, which email servers use to verify the validity of an email domain. When the mail server receives an email message, it checks whether the reverse lookup of the originating IP address matches the domain portion of the email address. If the two do not agree, the filter rejects the email message because this typically indicates that the return address of the email is a fake, commonly referred to as a spoofed address. A lot of spammers have used fictitious or false domains in an attempt to hide their real identities. Spam has become virtually ubiquitous to anyone with an Internet email address, and the flood seems to increase with each passing year. In addition to being annoying for the user, it also eats up significant amounts of network bandwidth and frequently contains false, misleading, or obscene content. What does this mean to you? If you are setting up DNS on the Internet and want to be able to send and receive email from that domain, you need to be sure to include a reverse zone for your mail servers. Otherwise, you can expect your mail to be filtered out as spam in many instances. The naming convention for a reverse lookup zone is this: <first octets of the IP address (reversed)>.in-addr.arpaThus, the address of the reverse table for the IP network 205.133.113.87 is 113.133.205.in-addr.arpa. It is important to know that the Active Directory Installation Wizard does not automatically add a reverse lookup zone and PTR resource records to the server. You need to add them manually because it is possible that another server may control the reverse lookup zone. You will want to add a reverse lookup zone if this is not the case. Although a reverse lookup zone is not necessary for Active Directory to work, it is useful for the reasons listed previously. DNS Record TypesBefore we continue our discussions of DNS, you should take a quick look at Table 3.1, which lists the different types of records you can create in a DNS domain in Windows Server 2003. In the table, you will also find the pertinent RFC for each type, which can help you do additional research.
Exam Alert: Don't Memorize the Table of DNS Record Types Although you must understand the commonly used DNS record types, uncommon entries such as the Andrew File System database server record will not likely be on the exam. The most commonly used record types are A, CNAME, MX, PTR, SRV, and SOA. DNS Naming ConventionsTable 3.2 shows the restrictions for creating a DNS name and an FQDN.
The Windows Server 2003 DNS Server Service Supports Additional StandardsMicrosoft has one problem with its direction of a DNS-based directory service, and it has been a problem for years. NetBIOS, the legacy Microsoft naming mechanism, does not conform to the naming standards in RFC 1123. This means that in some environments, companies could be forced to rename all their Microsoft devices if they want to move to a naming standard supported by Active Directory. To avoid this, Microsoft has included support for RFCs 2181 and 2044, which allows legacy NetBIOS names to be supported under DNS. An example of a character supported by Windows Server 2003 DNS but not by other DNS implementations is the _ (underscore) character, used commonly in NetBIOS naming as a separator; it is not valid under many DNS implementations. There's a catch to Microsoft's proposed support for RFCs 2181 and 2044, however. If you move to a naming convention that takes advantage of the new standards, you might run into problems with non-Windows Server 2003 DNS servers, including Windows NT 4.0 DNS servers. Most servers do not support the standards Microsoft is proposing. The reason for this is that RFC 2044 calls for the support of the character-encoding Unicode Translation Format 8 (UTF-8). UTF-8 supports characters from a variety of foreign languages that are not supported by some non-Windows 2000/Server 2003 versions of DNS. |
EAN: 2147483647
Pages: 196