TCP/IP NamesThe address space for IP addresses is a hierarchical one that allows computers to be grouped into networks and sub-networks. The flat address spaces created by MAC addresses don't allow for any kind of grouping because they only provide an address for the host physical adapter and do not provide any sort of organization that can be used outside a LAN. In a small LAN, it doesn't matter that MAC addresses are not ordered. Each node can recognize a packet that's destined for it by examining the MAC address for every packet that passes on the LAN. This concept would not work on a larger network because every packet would have to be forwarded to every node for examination. Imagine having every packet on the Internet sent to every node! It's also possible to create a hierarchical namespace for nodes on a TCP/IP network by concatenating the hostname with a domain name. For example, the host computer named zira in the domain named nirvana.com is zira.nirvana.com as a fully qualified name. Names are more convenient for humans than the numerical address format implemented in the TCP/IP suite. Just as the numerical address space is a hierarchical one, so is the namespace. However, it's important to understand that the two do not have to be directly related on a one-to-one basis. For example, suppose that a computer named printserver.ono.com has an address of 193.220.113.10. This is a class C IP address, so the network portion of the address is 193.220.113. You might be inclined to think, then, that a computer with a name of fileserver.ono.com is also located in the same network and has an address that begins with 193.220.113. However, there is no direct relation between the two. Not that there can't be. It might be very convenient to set up a small network with a few subnets and create host computer names that all match up to a particular network address or subnet. In practical terms, however, this is hard to maintain as the network grows and changes. Instead, use the TCP/IP namespace to create a logical arrangement of computers that matches some kind of business layout or other type of function. It makes sense to use names such as the following: susan.accounting.zira.com heather.accounting.zira.com holly.shipping.zira.com penny.research.zira.com foster.research.zira.com It's clear from these names that the company or organization is called Zira and that there are computers in the accounting, shipping, and research departments. In this case, however, it might be that Susan works out of the company's office located in the heart of downtown, whereas Heather works in a suburban office. Their TCP/IP hostnames reflect the business organizational unit in which they work. However, their IP addresses can be on completely different subnets or networks, depending on the physical location or other factors. The rules for creating a hostname are not as carefree as those used for NetBIOS names. You cannot use spaces in a TCP/IP name, for example. The following rules must be followed when creating a hostname:
Note These restrictions apply to names you enter in the HOSTS file. When using a DNS server, the restrictions are a little different, as is explained in the following sections. Although you can use names in the TCP/IP networking environment to conveniently organize your host computers, there must again be a mechanism for resolving these names to the actual IP addresses that are associated with the computer. TCP/IP provides the HOSTS file, which was originally a central file maintained by a central authority and periodically distributed to nodes throughout the Internet. You can probably guess that this methodas with the LMHOSTS file used on NetBIOS networkshas been outgrown by the rapid growth of the Internet, and is now used only on small networks or for special cases. The Domain Name System is now the primary means for resolving IP addresses to hostnames on the Internet. In some Unix shops, the Network Information System (NIS) is used. NIS was originally called Yellow Pages, but had to change its name due to a trademark infringement. The HOSTS FileOn Unix systems, the HOSTS file is usually found in the /etc or /etc/inet directory. Like the LMHOSTS file, it has no filename extension. It is a text file that contains IP addresses followed by the hostname or names associated with the address. The # character is used to denote comments. Each line should have only one IP address, followed by a space or tab character, and then the hostname. You can place more than one name on the line (each separated by a space or tab character) to provide multiple names for a host (sometimes called nicknames). For example: #This is the HOSTS file # 127.0.0.1 localhost 10.1.22.13 pkd.ubik.com # Server at Atlanta office. 10.1.22.46 psi.ubik.ocm # Joe's workstation. 192.208.46.158 www.compaq.com # Compaq's homepage. Note that the first entry in the file is the loop-back address for the local adapter. You will find this in many HOSTS files, but it isn't a requirement. The HOSTS file has the same limitations as the LMHOSTS file. Mainly, it doesn't scale very well. Each time a change is made in the network, you need to update the file on each machine to reflect the change. This makes it easy to get different copies out-of-sync on a larger network. In a very small TCP/IP network that doesn't change very often and doesn't use NetBIOS names, using the HOSTS file might be preferable to using DNS. You can get a decent DNS server from everyone from Microsoft to Novell to any Unix/Linux server. But if it means that you have to purchase a server operating system to provide for a small number of clients, you might be better off using a simple LAN without a DNS server. For a growing network or one in a fast-paced business environment where employees are always on the move, DNS or NIS should be used. However, even in a SOHO office, there should be little need to keep using this legacy HOSTS file. If you're connected to the Internet, network names can be translated using a DNS server provided by your Internet provider. Names on the local LAN can be resolved using NetBEUI. Domain Name SystemWhen TCP/IP became the standard protocol used on ARPAnet (which evolved into the Internet), the HOSTS file was maintained by SRI-NIC at a central location. Changes were periodically made to the file as administrators emailed requests to SRI-NIC. The updated HOSTS file then had to be distributed to every node, making the maintenance of this file a major administrative chore. For a few thousand computers in the beginning, this was a difficult enough task. But just imagine trying to coordinate the distribution of text files containing IP to name translation files in today's Internet environment, where there are many millions of users all over the world. In 1984, the Domain Name System (DNS) was adopted for the Internet. DNS is not only a hierarchical database, but also a distributed one. WINS servers use replication with partners to keep a full copy of the WINS database on each WINS server. On the Internet, each registered domain (for example, zira.com or microsoft.com) has a DNS server, which is responsible for managing the database of hostnames within that domain or subdomains. This distribution of the database makes it easier to scale to a larger size than with the WINS model. Administration can also be delegated so that no central management of the entire database is needed. Tip One of the first implementations of DNS was developed at Berkeley for its BSD Unix (version 4.3) operating system. Therefore, you'll often see the term BIND (Berkeley Internet Name Domain) used in place of DNS on many Unix and Linux systems. The topmost entry in the DNS hierarchy is called the root domain and is represented by the period character (.). Underneath this root domain are the top-level directories that fall into two groups: geographical and organizational. Geographical domains are used to specify specific countries. For example, .au for Australia and .uk for the United Kingdom. Under each of the geographical domains, you might find organizational domains. Organizational domains include
The structure of the Domain Name System is similar to an inverted tree. In Figure 29.10, you can see that at the top is the root domain with the com through arpa domains underneath. Under the com domain are individual business organizations that each have their own domain. Under any particular domain there can be subdomains. Figure 29.10. The Domain Name System is a distributed hierarchical structure.
At each level, a fully qualified domain name (FQDN) is created by concatenating the local name with the names of the entities above it in the hierarchy. Thus, msdn.microsoft.com is used to name the msdn subdomain in the microsoft.com domain that falls under the com domain. By using the FQDN, it's possible for a hostname to be used multiple times, as long as it produces a unique FQDN. For example, fileserver.twoinc.com names a host called fileserver. This host cannot become confused with another host of the same name that resides in a different domain such as fileserver.acme.com. There are a number of restrictions to the names you can use in the DNS system:
New Top-Level DomainsSince ICANN took over responsibilities for handling names and numbers used on the Internet, several new top-level domains have been created. Over the next few years, you can expect to see additional top-level domains added to this list. The most recent additions were made in 2000. These are
Note In 2003, NeuStar, Inc. was asked by the U.S. congress to set up a new domain name called .kids.us. All content on any Web site registered for a domain name in .kids.us will be screened to ensure that it contains no adult or other information that might be harmful to kids. Of these domains, some are unsponsored (biz, info, name, and pro), which means that they will be governed by the global Internet community through ICANN, whereas the others (aero, coop, and museum) are sponsored domains. That means they'll be governed by specific entities. For example, the coop domain is sponsored by the National Cooperative Business Association. Note You might have noticed recently that there are other domains that appear to be new, such as the popular tv domain. However, note that the .tv domain is not a new top-level domain. Instead, tv is the country code domain for the country of Tuvalu (a small island in the Pacific Ocean), which has allowed an enterprising company to use its country-style domain name for a fee. The company can market the tv domain to register domains that are associated with, of course, television. However, remember that this is just a country code domain. It isn't one of the new top-level domains that ICANN has authorized. There is nothing that requires a particular country to use its own domain designation for just its use. Whoever thought up this method for establishing what appears to be a new domain should be named Capitalist of the Year! To stay up-to-date on what the current top-level domains are, visit the ICANN Web site at www.icann.org. You'll also find a lot of other valuable information at this site if you administer a network that makes heavy use of the Internet. If you want to use the Internet to increase your business, it's important that the networking staff understand who is responsible for the network numbers, protocols, and so forth on the Internet. Therefore, as many others mentioned in this book, the previous URL should be something you put in your bookmarks or favorites folder. Primary, Secondary, and Caching-Only Name ServersFor each domain on the Internet, there must be a primary server and a secondary server. The primary DNS server for the domain contains a collection of resource records that contain the address mappings for hostnames in the domain. The primary DNS server is the final authority for these mappings. The secondary DNS server contains a copy of the database maintained by the primary server and can continue to resolve names when the primary server is offline. It's important to note that the primary DNS server is where changes are made to the database. Through the use of the zone transfer mechanism, the data is copied to secondary servers. In many cases, a DNS server answers name queries for domains for which it isn't the authority. In that case, the DNS server contacts a DNS server further up the hierarchy until one is found that can resolve the name or that can point to another DNS server that is the authority for the name. The DNS server maintains a cache of names that have been resolved by this method so that it doesn't have to continually poll other servers for names that are frequently queried. A third type of DNS server is a caching-only server. This type of server does not maintain a database for a particular zone. To put it in other terms, a caching-only server isn't authoritative for any zone or domain and does not use the zone transfer mechanism to keep a current copy of the entire database. Instead, a caching-only name server has to contact another DNS server to initially resolve a name, but like the other servers it maintains a cache of names it has resolved so that it doesn't have to keep forwarding the query to another server. This type of server is normally used on a network segment that's connected to the rest of the network by a slower link (or a more expensive one) and is used to reduce network traffic. ZonesIn many cases, it isn't efficient to have a single server maintain the database for an entire domain. Instead, a primary DNS server can be authoritative for only a zone in the domain. A zone is a partition of the domain into subdomains. For example, one DNS server might be the authority for the zone zira.twoinc.com, whereas another might serve as the authority for the zone research.twoinc.com. Both subdomains exist within the same domain: twoinc.com. However, by dividing the domain into subdomains, it becomes easier to manage not only the DNS servers but also the individual business or organizational units that the domain services. A zone transfer occurs when a secondary DNS server contacts a server that is primary for the zone and finds that it needs to obtain changes to the database. This is accomplished by using serial numbers contained in the database. If the secondary server has a lower serial number, a new copy of the database is copied to it. Standard DNS Database FilesThere are three basic types of files used by DNS servers. In most DNS implementations, you need to use a text editor to make changes to these files. Most newer DNS servers, such as Microsoft's DNS server, provide a graphical interface that can be used for adding or changing information in the DNS files. The basic files are
Resource RecordsUntil recently, most DNS databases were usually composed of ASCII text files containing records that could be used to translate a name to an IP address. Several types of records can be used in the database, with each representing a specific type of resource, such as a computer hostname or a mailserver name. Today, many fast DNS servers maintain a database with far greater capabilities than those that used a flat-file format. Therefore, newer DNS servers also contain many newer capabilities, such as dynamic updates. When representing a domain name in DNS, a specific syntax is used. The term label is used in RFC 1035, "Domain NamesImplementation and Specification," when describing this syntax. A label is a one-byte length field followed by a data field. The length field indicates the number of characters in the data field. A domain name is represented by a series of labels and the entire domain name string is terminated with a length field of zero. For example, Figure 29.11 shows the layout of a series of labels that would be used to define the domain name zira.twoinc.com. Figure 29.11. The domain name is represented by a series of labels in DNS.
Tip You can find other RFCs, both standards and proposed standards, by entering DNS as a keyword in the search capability offered on the Web's own archive for RFCs: http://www.rfc-editor.org. Although the string is only 13 bytes long, excluding the periods, it takes 17 bytes to represent it in the database because of the length fields and the terminator field. To avoid repetition for domain names that are used a lot in the database, a pointer record can be used. The general format used for a resource record contains the following fields:
The Type field indicates the type of resource record. Table 29.1 contains a list of the standard record types used in most DNS implementations, along with a description of their use.
In earlier implementations of DNS, other record types were also used. For instance, MD and MF were used to specify mail destination and mail forwarder records. RFC 1035 made obsolete three other RFCs: 882, 883, and 973. Four other record types that are considered experimental are
In addition, RFC 2782, "A DNS RR for Specifying the Location of Services (DNS SRV)," added a new record type that figures heavily into a Windows 2000/.NET network: the SRV or service record. This type of record is used to store records in a DNS database that clients can use to look up services. For example, Windows servers use this type of record to enable clients to use DNS to locate domain controllers and other services. We'll get into more details about that in the next chapter. The Start of Authority (SOA) record is used at the beginning of the database and is used to describe the database. It's used mostly by secondary DNS servers to get zone information. The fields in this record are
All time values in the SOA record are in seconds. The NS record type can be used to indicate that another name server is authoritative for this subdomain. For example, the record zork.twoinc.com IN NS zira.twoinc.com indicates that the name server whose FQDN host name is zira.twoinc.com is the authoritative name server from which to get information about the subdomain zork.twoinc.com. To get the address of the name server zira.twoinc.com, an A type record is needed: zira.twoinc.com IN A 216.65.33.219 The CNAME record is used to specify aliases or nicknames that can be used in addition to a hostname; for example: ftp.zira.twoinc.com IN CNAME zira.twoinc.com Pointer records (PTR class) are used to get the name that's associated with an IP addressa reverse translation. For example 219.33.65.216 IN PTR zira.twoinc.com can be used to perform a query to get the name of this host when only the IP address is known. However, notice that the IP address has been reversed in this record. It is represented in a pointer record as 219.33.65.216 instead of 216.65.33.219. The reverse format is used to make a key lookup in the database function properly. The special domain IN-ADDR.ARPA contains the data used when a server needs to look up the hostname for an address in the domain. The Class field is generally IN, which stands for Internet. The numeric value for this code is 1. In addition to this class type, you might see references to CS, which stands for the obsolete CSNET class. The CH class stands for the CHAOS class and the HS class code stands for the Hesiod class. Configuring a Unix DNS ServerOn most Unix systems, configuring a DNS server involves editing ASCII text files and making the appropriate entries. The actual files to edit depend on the brand of Unix you're using. The most common is the Berkeley Internet Name Domain (BIND) implementation. This server uses a daemon called in.named. In addition to the actual zone database files, you also have to edit
To start the BIND service daemon after you've edited all the appropriate files, you only need to enter the command in.named at the system command prompt (or in a startup file). If you've edited the /etc/named/boot file or its equivalent on your Unix/Linux variant, the server automatically starts the next time the system is booted. The most time-consuming task is the editing of the zone database files and making entries for the hosts in the domain. Configuring DNS ClientsUnix/Linux clients usually get their information about name servers from the /etc/resolv.conf file. (Note that this might be different for your variant of the "universal" Unix operating system. Check the manual pages.) To configure the client, edit this file. To place comments in this file, you can use the semicolon (;) character. The three directives that you configure in this file are
For example: ;This is the /etc/resolv.conf file for local workstations domain twoinc.com ; Name servers nameserver 199.45.32.38 nameserver 151.197.0.39 nameserver 216.645.33.219 ; search lists search twoinc.com biznesnet.com ; end of file A client using this file to try to resolve the name of a host named zira would first search the domain twoinc.com and then the domain biznesnet.com. The first match found is the one that will be used to resolve the name to an IP address. To configure a Microsoft client to use a DNS server, you only need to enter the IP addresses of the DNS servers when you perform the initial client network setup (or set your DHCP server to provide this information to the client). Using nslookupThe nslookup utility is generally employed to find the IP address associated with a name. However, the utility can be used to interrogate the DNS database to find not only IP addresses, but also information stored in other records in the database. The utility can be used either in interactive mode, where the user can continue to issue commands, or in a one-shot, non-interactive mode where a single query is executed. The basic syntax for the command is nslookup [[-option ...] [hostname to locate]] - [server] If you omit the last item in this syntax (- server), the local DNS server is queried. However, when you have multiple servers or if you want to query a server outside your organization, specify it with this parameter. A simple example of the command is nslookup twoinc.com, which returns the following information: Name: twoinc.com Address: 216.65.33.219 If you want to retrieve more information about the server, you can use options and specify the info records: nslookup -query=hinfo -timeout=10 www.twoinc.com twoinc.com primary name server = ns1.tentex.com responsible mail addr = hostmaster.twoinc.com serial = 1342 refresh = 3600 (1 hour) retry = 600 (10 mins) expire = 86400 (1 day) default TTL = 3600 (1 hour) As you can see, this tool is useful for looking up addresses, but can also be used to query the DNS database and help you debug configuration problems. With this simple query, you can see the serial number of the current database along with other information stored in the SOA record. The syntax for the options of this command varies depending on your operating system. Dynamic DNSEarlier in this chapter, I discussed Microsoft's WINS servers. These NetBIOS name servers can be used to dynamically accept information from clients so that the network administrator does not have to make edits to the database each time a node is added to the network or a workstation is moved to a new location. The Dynamic Host Configuration Protocol (DHCP) has eliminated the necessity of manually configuring each computer host with network information. Microsoft's DNS server can be configured to query the WINS server when it needs to resolve a name it cannot find in its own databases. This solution does not help if you have a multivendor network with workstations running different operating systems. There are several relevant RFCs that address these problems associated with standard DNS implementations, such as
Offerings for a DNS server that's truly dynamic and a corresponding DHCP server capable of making updates are becoming more widespread at this time. Portions of the technology are implemented here and there, while some vendors offer both and DNS and DHCP solutions that work well together. For example, The Internet Software Consortium (ISC), which maintains BIND, releasedon March 4, 2003version 9.2.2 of BIND, which supports RFC 2136. You can download documentation or the kit files from the ISC Web site at http://www.isc.org. At the same site, you will also find a version of DHCP, along with a list of products developed by other developers that are based on or can work with these products. For network administrators who already have DNS servers running on the network but are concerned about whether these servers can be used in conjunction to the Windows 2000 version of DNS, please note that Windows 2000 DNS server also supports the following RFCs in addition to the dynamic update RFCs listed previously:
Check the documentation for your BIND or DNS server to see which RFCs it supports. You might be surprised to find that this new and improved DNS server from Microsoft might be as good as, or perhaps better than, your current version. |