📄 tyt11fi.htm
字号:
<HTML><HEAD><TITLE>tyt11fi.htm</TITLE><LINK REL=ToC HREF=index-1.htm><LINK REL=Index HREF=tppmsgs/msgs0.htm#37><LINK REL=Next HREF=tyt12fi.htm><LINK REL=Previous HREF=tyt10fi.htm></HEAD><BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#0000FF VLINK=#800080><A ID=I0 NAME=I0></A><P><P ALIGN=CENTER><A HREF=tyt10fi.htm TARGET=_self><IMG SRC=blanprev.gif WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Previous Page"></A><A HREF=index-1.htm TARGET=_self><IMG SRC=blantoc.gif WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT=TOC></A><A HREF=tyt12fi.htm TARGET=_self><IMG SRC=blannext.gif WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Next Page"></A><HR ALIGN=CENTER><P><UL><UL><UL><LI><A HREF=#E68E102>Domain Name Service (DNS)</A></LI><UL><LI><A HREF=#E69E144>DNS Structure</A></LI><LI><A HREF=#E69E145>The Name Server</A></LI><LI><A HREF=#E69E146>Resource Records</A></LI><LI><A HREF=#E69E147>IN-ADDR-ARPA</A></LI><LI><A HREF=#E69E148>Messages</A></LI><LI><A HREF=#E69E149>The Name Resolver</A></LI><LI><A HREF=#E69E150>Configuring a UNIX DNS Server</A></LI><UL><LI><A HREF=#E70E43>Entering the Resource Records</A></LI><LI><A HREF=#E70E44>Completing the DNS Files</A></LI><LI><A HREF=#E70E45>Starting the DNS Daemons</A></LI><LI><A HREF=#E70E46>Configuring a Client</A></LI></UL></UL><LI><A HREF=#E68E103>BOOTP Protocol</A></LI><UL><LI><A HREF=#E69E151>BOOTP Messages</A></LI></UL><LI><A HREF=#E68E104>Network Time Protocol (NTP)</A></LI><LI><A HREF=#E68E105>Summary</A></LI><LI><A HREF=#E68E106>Q&A</A></LI><LI><A HREF=#E68E107>Quiz</A></LI></UL></UL></UL><HR ALIGN=CENTER><A ID=E66E11 NAME=E66E11></A><H1 ALIGN=CENTER><CENTER><FONT SIZE=6 COLOR=#FF0000><B>— 11 —</B><BR><B>Domain Name Service</B></FONT></CENTER></H1><BR><P>TCP/IP uses a 32-bit address to route a datagram to a destination. It is useful to forget these 32-bit addresses and use common names instead, because names are much easier to remember. There are several methods used for this. The most common is examined on Day 7, "TCP/IP Configuration and Administration Basics," employing an ASCII file on the sending machine that had names and corresponding addresses (/etc/hosts on a UNIX device). One major limitation to this system is that the machine can route only to other machines that have an entry in this file, which can be impossible to maintain when there are many target machines or you want to access all the devices on your network.<BR><P>Another approach is to off-load the address resolution to another process that acts like a directory service. There are two such schemes in common use today: Domain Name Service (DNS) and Network Information Service (NIS), which is now part of NFS. Today I look at DNS in more detail. On Day 12, "NFS and NIS," I examine NFS in depth.<BR><P>Also today I look at the BOOTP protocol, a system that is becoming widely adopted as diskless workstations and client/server systems become more common. BOOTP relies on TCP/IP. Anyone working with TCP/IP can eventually expect to run across the BOOTP protocol, so an explanation of it is useful at this stage.<BR><P>Finally, the day closes with a quick look at the Network Time Protocol (NTP), which is used to ensure synchronization of timestamps between machines.<BR><BR><A ID=E68E102 NAME=E68E102></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Domain Name Service (DNS)</B></FONT></CENTER></H3><BR><P>A symbolic name is a character string that is used to identify a machine. A symbolic name can be straightforward (bills_machine or tpci_server1) or more complex, as is often the case in large organizations where the name identifies the type of machine and its location (such as hpws510, where hpws identifies an HP workstation on the fifth floor, room 10).<BR><P>When sending information to remote machines, IP addresses or Internet addresses must be used. Instead of requiring the user to memorize the remote machine's numbers, it is common to use a symbolic name. After all, a simple name is much easier to remember than a 32-bit Internet address.<BR><P>As you saw earlier in this book, the conversion from a symbolic name to an actual IP address is usually performed within the sending machine, using a file such as UNIX's /etc/hosts file. This type of approach works well within a small network, where a limited number of destination machines are involved. When dealing with the entire Internet, however, it is unreasonable to expect an ASCII file to contain all possible symbolic names and their addresses.<BR><P>The sheer size of a file required to hold all possible symbolic domain names and their corresponding unique network addresses is not the only problem. Large networks tend to change constantly, especially on an internetwork the size of the Internet. Hundreds of additions and modifications to existing entries must be performed daily. The time required to update each machine (or even selected gateways to autonomous networks) on the internetwork would be huge.<BR><P>The solution to the problem is to offer a method of moving the management of the lookup tables away from the Network Information Center (NIC), which governs the Internet, and toward the participants and their autonomous networks in such a manner that the load on the network is small but flexibility is not compromised. This is what the Domain Name Service (DNS) does. DNS is sometimes also called the Internet directory service, although the name is somewhat of a misnomer.<BR><P>UNIX implements DNS through a daemon called named, which runs on a <I>name </I><I>server, </I>a machine that handles the resolution of symbolic names using DNS methods. Part of the system is a library of functions that can be used in applications to perform queries on the name server. This query routine is called the <I>resolver</I> or <I>name resolver</I> and can reside on another machine. The name server and resolver are examined in more detail shortly.<BR><BR><A ID=E69E144 NAME=E69E144></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>DNS Structure</B></FONT></CENTER></H4><BR><P>The Domain Name Service, as its name implies, works by dividing the internetwork into a set of domains, or networks, that can be further divided into subdomains. This structure resembles a tree, as shown in Figure 11.1, using some arbitrarily chosen domain names. The first set of domains is called the <I>top-level domains.</I> There are six top-level domains in regular use:<BR><UL><LI>ARPA: For Internet-specific organizations<BR></LI><BR><LI>COM: For commercial enterprises<BR></LI><BR><LI>EDU: For educational organizations<BR></LI><BR><LI>GOV: For governmental bodies<BR></LI><BR><LI>MIL: For military organizations<BR></LI><BR><LI>ORG: For noncommercial organizations<BR></LI><BR></UL><P><B><A HREF=11tyt01.gif>Figure 11.1. The Internet domain structure.</A></B><BR><P>In addition to these top-level domains, there are dedicated top-level domains for each country that is connected. These are usually identified by a short form of the country's name, such as .ca for Canada and .uk for the United Kingdom. These country top-level domains are usually left off diagrams of the Internet structure for convenience (otherwise there would be hundreds of top-level domains). The domain breakdown is sometimes repeated beneath the country domain, so there could be a .com extension coupled with .ca to show a Canadian commercial domain, or an .edu with .uk for a British university.<BR><P>Beneath the top-level domains is another level for the individual organizations within each top-level domain. The domain names are all registered with the Network Information Center (NIC) and are unique to the network. Usually the names are representative of the company or organization, but a few "cute" names do work their way in (usually because of historical reasons).<BR><P>There are two ways to name a target. If the target is on the internetwork, the <I>absolute name </I>is used. The absolute name is unique and unambiguous, specifying the domain of the target machine. A <I>relative </I><I>name </I>can be used either within the local domain, where the name server knows that the target is within the domain and hence doesn't need to route the datagram onto the internetwork, or when the relative name is known by the name server and can be expanded and routed correctly.<BR><BR><A ID=E69E145 NAME=E69E145></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>The Name Server</B></FONT></CENTER></H4><BR><P>Each DNS Name Server manages a distinct area of a network (or an entire domain, if the network is small). The set of machines managed by the name server is called a <I>zone.</I> Several zones can be managed by one name server. Almost every zone has a designated secondary or backup name server, with the two (primary and secondary) name servers holding duplicate information. The name servers within a zone communicate using a <I>zone transfer protocol.</I><BR><P>DNS operates by having a set of nested zones. Each name server communicates with the one above it (and, if there is one, the one below it). Each zone has at least one name server responsible for knowing the address information for each machine within that zone. Each name server also knows the address of at least one other name server. Messages between name servers usually use the User Datagram Protocol (UDP) because its connectionless method provides for better performance. However, TCP is used for database updates because of its reliability.<BR><P>When a user application needs to resolve a symbolic name into a network address, a query is sent by the application to the resolver process, which then communicates the query to the name server. (I examine the resolver in more detail in the next section, "Resource Records.") The name server checks its own tables and returns the network address corresponding to the symbolic name. If the name server doesn't have the information it requires, it can send a request to another name server. This process is shown in Figure 11.2. Both the name servers and the resolvers use database tables and caches to maintain information about the machines in the local zone, as well as recently requested information from outside the zone.<BR><P><B><A HREF=11tyt02.gif>Figure 11.2. Resolving symbolic names.</A></B><BR><P>When a name server receives a query from a resolver, there are several types of operations the name server can perform. Name resolver operations fall into two categories: <I>nonrecursive </I>and <I>recursive. </I>A recursive operation is one in which the name server must access another name server for information.<BR><P>Nonrecursive operations performed by the name server include a full answer to the resolver's request, a referral to another name server (which the resolver must send a query to), or an error message. When a recursive operation is necessary, the name server contacts another name server with the resolver's request. The remote name server replies to the request with either a network address or a negative message, indicating failure. DNS rules prohibit a remote name server from sending a referral to yet another name server.<BR><BR><A ID=E69E146 NAME=E69E146></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Resource Records</B></FONT></CENTER></H4><BR><P>The information required to resolve symbolic names is maintained by the name server in a set of <I>resource records, </I>which are entries in a database. Resource records (often abbreviated RR) contain information in ASCII format. Because ASCII is used, it is easy to update the records. The format of resource records is shown in Figure 11.3.<BR><P><B><A HREF=11tyt03.gif>Figure 11.3. The resource record format.</A></B><BR><P>The Name field is the domain name of the machine the record refers to. If no name is specified, the previously used name is substituted.<BR><P>The Type field identifies the type of resource record. Resource records are used for several purposes, such as mapping names to addresses and defining zones. The Type of resource record is identified by a mnemonic code or a number. These codes and their meanings are shown in Table 11.1. Some of the resource record types are now obsolete (3 and 4), and others are considered experimental at this time (13 and 17–21).<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 11.1. Resource record types.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Number</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Code</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Description</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>1<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>A<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Network address<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>2<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>NS<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Authoritative name server<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>3<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MD<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mail destination; now replaced by MX<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>4<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MF<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mail forwarder; now replaced by MX<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>5<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>CNAME<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Canonical alias name<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>6<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>SOA<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Start of zone authority<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>7<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MB<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mailbox domain name<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>8<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MG<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mailbox member<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>9<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MR<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mail rename domain<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>10<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>NULL<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Null resource record<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>11<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>WKS<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Well-known service<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>12<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>PTR<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Pointer to a domain name<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>13<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>HINFO<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Host information<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>14<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MINFO<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mailbox information<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>15<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MX<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Mail exchange<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>16<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>TXT<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Text strings<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>17<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>RP<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Responsible person<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>18<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>AFSDB<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>AFS-type services<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>19<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>X.25<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>X.25 address<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>20<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>ISDN<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>ISDN address<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>21<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>RT<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Route through</FONT></TABLE></CENTER><BR><P>The Class field in the resource record layout contains a value for the class of record. If no value is specified, the last class used is substituted. Internet name servers usually have the code IN.<BR><P>The Time to Live (TTL) field specifies the amount of time in seconds that the resource record is valid in the cache. If a value of 0 is used, the record should not be added to the cache. If the TTL field is omitted, a default value is used. Usually this field tells the name server how long the entry is valid before it has to ask for an update.<BR><P>The data section of the resource record contains two parts, consisting of the length of the record and the data itself. The Data Length field specifies the length of the data section. The data is a variable-length field (hence the need for a length value) that describes the entry somehow. The use of this field differs with the different types of resource records.<BR><P>Some resource record types have a single piece of information in the data area, such as an address, or at most three pieces of information. The only exception is the Start of Authority resource record. The contents of the resource record data areas (except SOAs) are given in Table 11.2.<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 11.2. The contents of the resource record data areas.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>RR Type</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Fields in Data Area</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>A<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Address: A network address<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>NS<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>NSDNAME: The domain name of host<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MG<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MGNAME: The domain name of mailbox<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>CNAME<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>CNAME: An alias for the machine<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>HINFO<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>CPU: A string identifying CPU type<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><BR></FONT></TD><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>OS: A string identifying operating system<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MINFO<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>RMAILBX: A mailbox responsible for mailing lists<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><BR></FONT></TD><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>EMAILBOX: A mailbox for error messages<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MB<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MADNAME: Now obsolete<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MR<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>NEWNAME: Renames the address of a specific mailbox<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>MX<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>PREFERENCE: Specifies the precedence for delivery<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><BR></FONT></TD><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>EXCHANGE: The domain name of the host that acts as mail exchange<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>NULL<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Anything can be placed in the data field<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>PTR<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>PTRDNAME: A domain name that acts as a pointer to a location<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>TXT<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>TXTDATA: Any kind of descriptive text<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>WKS<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Address: A network address<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><BR></FONT></TD><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Protocol: The protocol used<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><BR></FONT></TD><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Bitmap: Used to identify ports and protocols</FONT></TABLE></CENTER><BR><P><A ID=I2 NAME=I2></A>The Start of Authority (SOA) resource record format is used to identify the machines within a zone. There is only one SOA record in each zone. The format of the SOA data field is shown in Figure 11.4. The fields in the SOA resource record are used mostly for administration and maintenance of the name server.<BR><P><B><A HREF=11tyt04.gif>Figure 11.4. The SOA resource record format.</A></B><BR><P>The MNAME field is the domain name of the source of data for the zone. The RNAME (responsible person name) field is the domain name of the mailbox of the administrator of the zone. The Serial field contains a version number for the zone. It is incremented when the zone is changed; otherwise, it is maintained as the same value for all such messages.<BR><P>The Refresh Time is the number of seconds between data refreshes for the zone. The Retry Time is the number of seconds to wait between unsuccessful refresh requests. The Expiry Time is the number of seconds after which the zone information is no longer valid. Finally, the Minimum Time is the number of seconds to be used in the Time to Live field of resource records within the zone.<BR><P>Some sample resource records show the simple format used. Address resource records consist of the machine name, the type of resource record indicator (A for Address RRs, for example), and the network address. A sample Address resource record would look like this:<BR><BR><PRE><FONT COLOR=#000080>TPCI_SCO_4 IN A 143.23.25.7</FONT></PRE><P>The IN tags the resource record as an Internet class. This format makes it easy to locate a name and derive its address. (The reverse, going from address to name, is not as easy and requires a special format called <I>IN-ADDR-ARPA</I><I>, </I>which is examined in the next section, "IN-ADDR-ARPA.")<BR><P>For Well-Known Service resource records (WKS, or type 11), the data field of the record contains three fields used to describe the services supported at the address the record refers to. A sample WKS resource record might look like this:<BR><PRE><FONT COLOR=#000080>TPCI_SCO.TPCI.COM IN WKS 143.23.1.34. FTP TCP SMTP TELNET</FONT></PRE><P>The full domain name and Internet address are shown, as is the IN to show the Internet class of resource records. The type of record is indicated with the WKS. The protocols supported by the machine at that address are listed after the address. In reality, these are bitmaps that correspond to ports. When the port bit is set to a value of 1, the service is supported. The list of ports and services is defined by an Internet RFC.<BR><BR><A ID=E69E147 NAME=E69E147></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B><I>IN-ADDR-ARPA</I></B></FONT></CENTER></H4><BR><P>The address fields, such as in the Address resource record type, use a special format called <I>IN-ADDR-ARPA</I><I>.</I> This enables reverse mapping from the address to the host name as well as host-to-address mapping. To understand IN-ADDR-ARPA, it is useful to begin with a standard-format resource record. Earlier it was mentioned that resource records are maintained in ASCII format. One of the simplest types of resource record is for the address (type A), as seen earlier. An extract from an address file is shown here:<BR><PRE><FONT COLOR=#000080>TPCI_HPWS1 IN A 143.12.2.50TPCI_HPWS2 IN A 143.12.2.51TPCI_HPWS3 IN A 143.12.2.52TPCI_GATEWAY IN A 143.12.2.100 IN A 144.23.56.2MERLIN IN A 145.23.24.1SMALLWOOD IN A 134.2.12.75</FONT></PRE><P>Each line of the file represents one resource record. In this case, they are all simple entries that have the machine's symbolic name (alias), the class of machine (IN for Internet), A to show it is an Address resource record, and the Internet address. The entry for the machine TPCI_GATEWAY has two corresponding addresses because it is a gateway between two networks. The gateway has a different address on each of the networks, so it has two resource records in the same file. (As with most other code fragments in this book, these example addresses are hypothetical.)<BR><P>This type of file makes name-to-address mapping easy. The name server simply searches for a line with the symbolic name requested by the application and returns the Internet address at the end of that line. The databases are indexed on the name, so these searches proceed very quickly.<BR><P>Searching from the address to the name is not quite as easy. If the resource record files are small, time delays for a manual search are not appreciable, but with large zones there can be thousands or tens of thousands of entries. The index is on the name, so searching for an address can be a slow process. To solve this reverse-mapping problem, IN-ADDR-ARPA was developed. IN-ADDR-ARPA uses the host address as an index to the host's resource record information. When the proper resource record is located, the symbolic name can be extracted.<BR><P>IN-ADDR-ARPA uses the PTR resource record type (see Table 11.1) to point from the address to the name. There might be one of these pointer indexes maintained on each name server. An example of a number-to-name<I> </I>file follows:<BR><PRE><FONT COLOR=#000080>23.1.45.143.IN-ADDR-ARPA. PTR TPCI_HPWS_4.TPCI.COM1.23.64.147.IN-ADDR-ARPA. PTR TPCI_SERVER.MERLIN.COM3.12.6.123.IN-ADDR-ARPA. PTR BEAST.BEAST.COM23.143.IN-ADDR-ARPA PTR MERLINGATEWAY.MERLIN.COM</FONT></PRE><P>The Internet addresses are reversed in the IN-ADDR-ARPA file for ease of use. As shown in the sample file, it is not necessary to specify the complete address for a gateway because the domain name provides enough routing information.<BR><BR><A ID=E69E148 NAME=E69E148></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Messages</B></FONT></CENTER></H4><BR><P>DNS messages are transferred between name servers to update their resource records. The fields of these messages are quite similar to those of the records themselves. The format of a DNS message is shown in Figure 11.5. The header has several subfields that contain information about the type of question or answer being sent. The rest of the message consists of four variable-length fields, which are further subdivided:<BR><UL><LI><B>Question:</B> The information required.<BR></LI><BR><LI><B>Answer:</B> The answer to the query (from the RR).<BR></LI><BR><LI><B>Authority:</B> The name of other name servers that might have the information requested, if it is not readily available on the targeted name server.<BR></LI><BR><LI><B>Additional information:</B> Information that can be provided to answer the query, or the addresses of name servers if the Authority field was used.<BR></LI><BR></UL><P><B><A HREF=11tyt05.gif>Figure 11.5. The DNS message format.</A></B><BR><P>The DNS message header has several different fields itself, as shown in Figure 11.6. The header is present in all DNS messages. The header ID field is 16 bits long and is used to match queries and answers to each other. The single-bit QR field is set to a value of 0 to indicate a query, or a value of 1 to show a response. The OpCode field is 4 bits long and can have one of the values shown in Table 11.3.<BR><P><B><A HREF=11tyt06.gif>Figure 11.6. The DNS message Header format.</A></B><BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 11.3. The DNS message header </B><B>OpCode</B><B> values.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>OpCode</I></B><B><I> Value</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Description</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>0<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Standard query<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>1<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Inverse query<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>2<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Server status request<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>3–15<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Not used</FONT></TABLE></CENTER><BR><P>The AA field is the authoritative answer bit. A value of 1 in a response message indicates that the name server is the recognized authority for the queried domain name. The TC (truncation) bit is set to a value of 1 when the message is truncated because of excessive length. Otherwise, the TC bit is set to 0. The RD (recursion desired) bit is set to 1 when the name server is requested to perform a recursive query. The RA (recursion available) bit is set to 1 in a response when the name server can perform recursions.<BR><P>The Z field is 3 bits long and is not used. The RCODE field is 4 bits long and can be set to one of the values shown in Table 11.4.<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 11.4. The DNS message header </B><B>RCODE</B><B> values.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>RCODE</I></B><B><I> Value</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Description</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>0<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>No errors<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>1<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Format error; name server unable to interpret the query<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>2<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Name server problems have occurred<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>3<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>The name server could not find the domain reference in the query<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>4<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Name server does not support this type of query<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>5<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Name server cannot perform the requested operation for administrative reasons<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>6–15<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Not used</FONT></TABLE></CENTER><BR><P>The QDCOUNT field is a 16-bit field for the number of entries in the Question section. The ANCOUNT field is another 16-bit field for the number of replies in the Answer section (the number of resource records in the answer). The NSCOUNT field is 16 bits and specifies the number of server resource records in the Authority section of the message. The ARCOUNT 16-bit field specifies the number of resource records in the Additional record section.<BR><P>The Question section of the message has three fields of its own, as shown in Figure 11.7. The Question field carries the query, which is identified by these fields. The QNAME field is the domain name requested. The QTYPE is the type of query, using one of the values shown in Table 11.1. The QCLASS is the class of query, which can be set according to the application’s requirements.<BR><P><B><A HREF=11tyt07.gif>Figure 11.7. The DNS message Question field </B><B>format.</A></B><BR><P>The last three fields in the DNS message (Answer, Authority, and Additional information) all have the same format, as shown in Figure 11.8. The Name field holds the domain name of the resource record. The Type field has any of the valid resource record type values. (See Table 11.1.)<BR><P><B><A HREF=11tyt08.gif>Figure 11.8. The format for DNS message Answer, </B><B>Authority, and Additional information fields.</A></B><BR><P>The Class is the class of data in the data field. The Time to Live (TTL) field is the number of seconds the information is valid without an update. The RDLENGTH field is the length of the information in the data field. Finally, the RDATA field is the resource record information or other data, depending on the class and type of the query and reply. There can be many such records in the Answer, Authority, and Additional information sections of the DNS message.<BR><BR><A ID=E69E149 NAME=E69E149></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>The Name Resolver</B></FONT></CENTER></H4><BR><P>As far as user applications are concerned, resolving the symbolic names into actual network addresses is easy. The process has been mentioned earlier. The application sends a query to a process called the <I>name </I><I>resolver, </I>or <I>resolver</I> (which sometimes resides on another machine). The name resolver might be able to resolve the name directly, in which case it sends a return message to the application. If the resolver cannot determine the network address, it communicates with the name server (which might contact another name server).<BR><P>The resolver is intended to replace existing name resolution systems on a machine, such as UNIX's /etc/hosts file. The replacement of these common mechanisms is transparent to the user, although the administrator must know whether the native name resolution system or DNS is to be used on each machine so the correct tables can be maintained.<BR><P>When the resolver acquires information from a name server, it stores the entries in its own cache to reduce the need for more network traffic if the same symbolic name is used again (as is often the case with applications that work across networks). The amount of time the name resolver stores these records is dependent on the Time to Live field in the resource records sent, or on a default value set by the system.<BR><P>When a name server cannot resolve a name, it can send back a message to the resolver with the address of another name server in the Authority field of the message. The resolver must then address a message to the other name server in the hopes of resolving the name. The resolver can ask the name server to conduct the query itself by setting the RD (recursive) bit in the message. The name server can refuse or accept the request.<BR><P>The resolver uses both UDP and TCP in its query process, although UDP is more common, due to its speed. However, iterative queries or transfers of large amounts of information might resort to TCP because of its higher reliability.<BR><P>Under the UNIX operating system, several different implementations of the name resolver are in use. The resolver supplied with the BSD versions of UNIX was particularly limited, offering neither a cache nor iterative query capabilities. To solve these limitations, the Berkeley Internet Name Domain (BIND) server was added. BIND provides both caching and iterative query capabilities in three different modes: as a primary server, as a secondary server, or as a caching-only server (which doesn't have a database of its own, only a cache). The use of BIND on BSD systems enables another process to take over the workload of name resolution, a process that might be on another machine entirely.<BR><BR><A ID=E69E150 NAME=E69E150></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Configuring a UNIX DNS Server</B></FONT></CENTER></H4><BR><P>Configuring a DNS server requires several files and databases to be modified or created. The process is time-consuming, but luckily has to be done only once for each server. The files involved in most DNS setups, and their purposes, are as follows:<BR><UL><UL><P>named.hosts: Defines the domain with hostname-to-IP mappings<BR></UL></UL><UL><UL><P>named.rev: Uses IN-ADDR-ARPA for IP-to-hostname mappings<BR></UL></UL><UL><UL><P>named.local: Used to resolve the loopback driver<BR></UL></UL><UL><UL><P>named.ca: Lists root domain servers<BR></UL></UL><BLOCKQUOTE><BLOCKQUOTE><P>named.boot: Used to set file and database locations<BR></BLOCKQUOTE></BLOCKQUOTE><P>These filenames are used by convention, but they can be changed to suit your own personal needs. The primary file in the list is named.boot, which is read when the system boots up and defines the other files in the set. Therefore, any filename changes are reflected in named.boot. For simplicity, I use the conventional filenames in this chapter. Each of the files listed here is a database with entries in the form of a resource record.<BR><BR><A ID=E70E43 NAME=E70E43></A><H5 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Entering the Resource Records</B></FONT></CENTER></H5><BR><P>For the sample server configuration, I assume a UNIX operating system using fairly standard names and network layouts. DNS lets you get very complex, but it's easier to see what the files and resource records are doing with a simple layout.<BR><P>An SOA resource record is placed in the named.hosts file. Semicolons in the record are used for comments. This resource record has been formatted as one field per line to make its entries clear, although this is not necessary. This resource record defines an upper boundary of the tpci.com domain, with server.tpci.com the primary name server for the domain, root.merlin.tpci.com the e-mail address of the person responsible for the domain, and the rest of the entries identified by comments:<BR><PRE><FONT COLOR=#000080>tpci.com. IN SOA server.tpci.com root.merlin.tpci.com ( 2 ; Serial number 7200 ; Refresh (2 hrs) 3600 ; Retry (1 hr) 151200 ; Expire (1 week) 86400 ); min TTL</FONT></PRE><P>Note that the information from the serial number to the expire field is enclosed in parentheses. This is part of the command syntax and must be included to indicate the parameter order.<BR><P>In addition to the SOA RR, the named.hosts file contains Address records. These records are used for the actual mapping of a host name to its IP address. A few Address resource records show the format of these entries (refer to earlier sections of this chapter for the meanings of each field if you are not sure):<BR><PRE>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -