tyt11fi.htm

快速学习TCP/IP协议

</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&#150;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&#146;s requirements.

<BR>

<P><B><A HREF="11tyt07.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/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" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/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>

<FONT COLOR="#000080">artemis     IN     A    143.23.25.7

merlin      IN     A    143.23.25.9

pepper      IN     A    143.23.25.72</FONT></PRE>

<P>The hostnames are not given as fully qualified domain names because the server can deduce the full name. If you want to use the full domain name, you must follow the name with a period. The machines shown in the preceding example would be given like this using fully qualified domain names:

<BR>

<PRE>

<FONT COLOR="#000080">artemis.tpci.com.     IN     A    143.23.25.7

merlin.tpci.com.      IN     A    143.23.25.9

pepper.tpci.com.      IN     A    143.23.25.72</FONT></PRE>

<P>The Pointer (PTR) resource record is used to map an IP address to a name using IN-ADDR-ARPA. A single PTR RR helps make this clear. The record

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">7.0.120.147.in-addr.arpa IN PTR merlin</FONT></PRE>

<P>indicates that the machine named merlin has the IP address 147.120.0.7.

<BR>

<P>The Name Server resource records point to the name server that has authority for a particular zone. Name Server (NS) records are used when a large network has several subnetworks, each with its own name server. An entry looks like this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">tpci.com   IN   NS  merlin.tpci.com</FONT></PRE>

<P>This record indicates that the DNS server for the tpci.com domain is called merlin.tpci.com. If there were several subnets used in tpci.com, there would be an NS RR for each subnet.

<BR>

<BR>

<A ID="E70E44" NAME="E70E44"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Completing the DNS Files</B></FONT></CENTER></H5>

<BR>

<P>As you saw earlier, DNS uses several files to hold resource records describing the zones used by DNS. The first file of interest is named.hosts, which contains the SOA, NS, and A resource records. All entries in the named.hosts file must begin in the first character position of each line. Here's a sample named.hosts file with comments added to show the records:

<BR>

<PRE>

<FONT COLOR="#000080">; named.hosts files

; Start Of Authority RR

tpci.com.    IN    SOA     merlin.tpci.com

            root.merlin.tpci.com (

            2  ; Serial number

            7200 ; Refresh (2 hrs)

            3600 ; Retry (1 hr)

            151200 ; Expire (1 week)

            86400 ); min TTL

;

; Name Service RRs

tpci.com   IN   NS  merlin.tpci.com

subnet1.tpci.com IN NS goofy.subnet1.tpci.com

;

; Address RRs

artemis     IN     A    143.23.25.7

merlin      IN     A    143.23.25.9

windsor     IN     A    143.23.25.12

reverie     IN     A    143.23.25.23

bigcat      IN     A    143.23.25.43

pepper      IN     A    143.23.25.72</FONT></PRE>

<P>The first section sets the SOA record, which defines the parameters for TTL, expiry, refresh, and so on. It sets the name server for the tpci.com domain to merlin.tpci.com. The second section uses the NS resource records to define the name server for the tpci.com domain as merlin.tpci.com (the same as the SOA) and a subnet of tpci called subnet1, for which the name server is goofy.subnet1.tpci.com. The third section has a list of the address-record-name-to-IP-address mapping. There is an entry in this section for each machine on the network.

<BR>

<P>The named.rev file provides the reverse mapping of IP address to machine name and is composed of Pointer resource records. The same format as the named.hosts file is followed, except for the swapping of name and IP address and the conversion of the IP address to IN-ADDR-ARPA style. The equivalent named.rev file for the named.hosts file shown earlier looks like this:

<BR>

<PRE>

<FONT COLOR="#000080">; named.rev files

; Start Of Authority RR

23.143.in-addr.arpa    IN    SOA     merlin.tpci.com

            root.merlin.tpci.com (

            2  ; Serial number

            7200 ; Refresh (2 hrs)

            3600 ; Retry (1 hr)

            151200 ; Expire (1 week)

            86400 ); min TTL

;

; Name Service RRs

23.143.in-addr.arpa   IN   NS  merlin.tpci.com

100.23.143.in-addr.arpa   IN NS goofy.subnet1.tpci.com

;

; Address RRs

9.25.23.143.in-addr.arpa   IN   PTR merlin

12.25.23.143.in-addr.arpa  IN   PTR windsor

23.25.23.143.in-addr.arpa  IN   PTR reverie 

43.25.23.143.in-addr.arpa  IN   PTR bigcat

72.25.23.143.in-addr.arpa  IN   PTR pepper</FONT></PRE>

<P>There must be a separate named.rev file for each zone or subdomain on the network. These files can have different names or be placed in different directories. If you have only a single zone, one named.rev file is all that's needed.

<BR>

<P>The named.local file contains an entry for the loopback driver (which always has the IP address 127.0.0.1). This file must contain information about the IN-ADDR-ARPA mapping of the loopback driver, as well as a domain again (because the named.rev file doesn't cover the 127 subnet). A named.local file looks like this:

<BR>

<PRE>

<FONT COLOR="#000080">; named.local files

; Start Of Authority RR

0.0.127.in-addr.arpa    IN    SOA     merlin.tpci.com

            root.merlin.tpci.com (

            2  ; Serial number

            7200 ; Refresh (2 hrs)

            3600 ; Retry (1 hr)

            151200 ; Expire (1 week)

            86400 ); min TTL

;

; Name Service RR

0.0.127.in-addr.arpa   IN   NS  merlin.tpci.com

;

; Address RR

1.0.0.127.in-addr.arpa   IN   PTR localhost</FONT></PRE>

<P>This file then provides the mapping from the machine named localhost to the IP address 127.0.0.1.

<BR>

<P>The named.ca file is used to specify name servers that the system can resort to. The machines specified in the named.ca file should be stable and not subject to rapid change. A sample named.ca file looks like this:

<BR>

<PRE>

<FONT COLOR="#000080">; named.ca

; servers for the root domain

;

.  99999999  IN   NS  ns.nic.ddn.mil.

   99999999  IN   NS  ns.nasa.gov.

   99999999  IN   NS  ns.internic.net

; servers by address

;

ns.nic.ddn.mil   99999999   IN  A  192.112.36.4

ns.nasa.gov      99999999   IN  A  192.52.195.10

ns.internic.net  99999999   IN  A  198.41.0.4</FONT></PRE>

<P>In this file only three DNS servers have been specified. A normal named.ca file can have a dozen or so name servers, depending on their proximity to your system. You can get a full list of valid root domain name servers through anonymous FTP to nic.ddn.mil, in the file /netinfo/root-servers.txt. This file can be pasted into named.ca. The servers specified in the named.ca file are each identified by two entries. One gives the root domain (the period) followed by the name server name; the other has the name server IP address. The Time to Live field is set very large because these servers are expected to be always available.

<BR>

<P>The named.boot file is used to trigger the loading of the DNS daemons and to specify the primary and secondary name servers on the network. A sample named.boot file looks like this:

<BR>

<PRE>

<FONT COLOR="#000080">; named.boot

directory    /usr/lib/named

primary    tpci.com    named.hosts

primary    25.143.in-addr.arpa    named.rev

primary    0.0.127.in-addr.arpa    named.local

cache    .    named.ca</FONT></PRE>

<P>The first line of the named.boot file has the keyword directory followed by the directory of the DNS configuration files. Each following line with the keyword primary tells DNS the files that it should use to find configuration information. The first line, for example, sets named.hosts as the file for locating the primary server of tpci.com. The IN-ADDR-ARPA information is kept in the file named.rev for the 143.25 subnet. The localhost information is in named.local, and finally the server and name cache information are in named.ca.

<BR>

<P>A secondary name server is configured only slightly differently than a primary server. The difference is in the named.boot file, which points back to the primary server.

<BR>

<BR>

<A ID="E70E45" NAME="E70E45"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Starting the DNS Daemons</B></FONT></CENTER></H5>

<BR>

<P>The final step in the DNS configuration is to ensure that the DNS daemon called named is loaded when the UNIX system boots. This is usually done through the rc startup scripts. Most versions of UNIX have the routines for DNS startup already entered in the startup script, usually in the form of a check for the file named.boot. If named.boot exists, the DNS daemon named starts. The code usually looks like this:

<BR>

<PRE>

<FONT COLOR="#000080"># Run DNS server if named.boot exists

if [ -f /etc/inet/named.boot -a -x /usr/sbin/in.named ]

then