TCP/IP Network Administration- P14

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

0
53
lượt xem
18
download

TCP/IP Network Administration- P14

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'tcp/ip network administration- p14', công nghệ thông tin, quản trị mạng phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:
Lưu

Nội dung Text: TCP/IP Network Administration- P14

  1. [Appendix B] B.10 Control Statements proto proto | all aspath aspath_regexp origin any | igp | egp | incomplete [restrict] | [[metric metric] { route_filter [restrict | metric metric] ; }] ; The source of the routes can be any one protocol (proto) or all (all) protocols. The importation of routes can be controlled by matching their AS paths against the AS path regular expression (aspath_regexp) or by matching their addresses against the route_filter. Route filters and AS path regular expressions are explained above. To export routes learned from RIP and HELLO, use this export list syntax: proto rip | hello [interface interface_list | gateway gateway_list] [restrict] | [[metric metric] { route_filter [restrict | metric metric] ; }] ; The export of RIP and HELLO routes may be controlled by protocol, source interface, source gateway, or route filter. To export routes learned from OSPF, use this export list syntax: proto ospf | ospfase [restrict] | [[metric metric] { route_filter [restrict | metric metric] ; }] ; The export of OSPF and OSPF ASE routes may be controlled by protocol and route filter. Exporting OSPF routes can also be controlled by tag using the syntax shown below: proto proto | all tag tag [restrict] | [[metric metric] { route_filter [restrict | metric metric] ; }] ; OSPF and RIP version 2 provide a tag field. For all other protocols, the tag is always 0. Routes may be selected based on the contents of the tag field. There are other sources of routes that are not true routing protocols, and export lists can be defined for Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (7 of 8) [2001-10-15 09:19:19]
  2. [Appendix B] B.10 Control Statements these sources. The two export lists for these sources are: proto direct | static | kernel [interface interface_list] [restrict] | [[metric metric] { route_filter [restrict | metric metric] ; }] ; The export of these routes can be controlled based on the source "protocol" and the source interface. The "protocols" in this case are routes to direct interfaces, static routes, or routes learned from the kernel. proto default | aggregate [restrict] | [[metric metric] { route_filter [restrict | metric metric] ; }] ; The export of these routes may only be controlled based on source "protocol." default refers to routes created by the gendefault option. aggregate refers to routes created by the aggregate statements, the topic of the next section. Previous: B.9 static TCP/IP Network Next: B.11 The Aggregate Statements Administration Statements B.9 static Statements Book Index B.11 The Aggregate Statements [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (8 of 8) [2001-10-15 09:19:19]
  3. [Appendix B] B.11 The Aggregate Statements Previous: B.10 Control Appendix B Next: C. A named A gated Reference Statements Reference B.11 The Aggregate Statements Route aggregation is used by regional and national networks to reduce the number of routes advertised. With careful planning, large network providers can announce a few aggregate routes instead of hundreds of client network routes. Enabling aggregation is the main reason that CIDR blocks are allocated as contiguous address blocks. Most of us don't have hundreds of routes to advertise. But we may have a classless address composed of a few class C address and we may need to tell gated how to handle it. Older versions of gated automatically generated an aggregate route to a natural network using the old Class A, B, and C concept; i.e., interface address 192.168.16.1 created a route to 192.168.16.0. With the advent of classless interdomain routing, this can be the wrong thing to do. gated does not aggregate routes unless it is explicitly configured with the aggregate statement: aggregate default | address [mask mask | masklen number] [preference preference] [brief] { proto proto [as as_number | tag tag | aspath aspath_regexp] [restrict] | [[preference preference] { route_filter [restrict | (preference preference)]] ; }; Several options are available for the aggregate statement: preference preference; Defines the preference of the resulting aggregate route. The default is 130. brief Specifies that the AS path of the agregate route should be the longest common AS path. The default is to build an AS path consisting of all contributing AS paths. proto proto Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (1 of 3) [2001-10-15 09:19:19]
  4. [Appendix B] B.11 The Aggregate Statements Only aggregate routes learned from the specified protocol. The value of proto may be any currently configured protocol. This includes the "protocols" direct, static, and kernel, discussed in the previous section; all for all possible protocols; and aggregate for other route aggregations. as as_number Only aggregate routes learned from the specified autonomous system. tag tag Only aggregate routes with the specified tag. aspath aspath_regexp Only aggregate routes that match the specified AS path. restrict Indicates routes that are not to be aggregated. Routes that match the route filters may contribute to the aggregate route. A route may only contribute to an aggregate route that is more general than itself. Any given route may only contribute to one aggregate route, but an aggregate route may contribute to a more general aggregate. A slight variation of aggregation is the generation of a route based on the existence of certain conditions. The most common usage for this is to create a default based on the presence of a route from a peer on a neighboring backbone. This is done with the generate statement. generate default | address [mask mask | masklen number] [preference preference] { proto proto [as as_number | tag tag | aspath aspath_regexp] [restrict] | [[preference preference] { route_filter [restrict | preference preference]] ; }; }; The generate statement uses many of the same options as the aggregate statement. These options are described earlier in this appendix. Previous: B.10 Control TCP/IP Network Next: C. A named Statements Administration Reference B.10 Control Statements Book Index C. A named Reference Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (2 of 3) [2001-10-15 09:19:19]
  5. [Appendix B] B.11 The Aggregate Statements [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (3 of 3) [2001-10-15 09:19:19]
  6. [Appendix C] A named Reference Previous: B.11 The Appendix C Next: C.2 named.boot Aggregate Statements Configuration Commands C. A named Reference Contents: The named Command named.boot Configuration Commands Zone File Records This appendix provides detailed information about named syntax and the commands and files used to configure it. This is primarily a reference to use in conjunction with the tutorial information in Chapter 8, Configuring DNS Name Service . This information is useful to any domain administrator. C.1 The named Command The server side of DNS is run by the name server daemon, named. The syntax of the named command is: [1] [1] Sun systems use in.named instead of named. named [-d level] [-p port[/localport]] [[-b] bootfile] [[-q] [[-r] The three options used on the named command line are: -d level Logs debugging information in the file /usr/tmp/named.run. The argument level is a number from 1 to 9. A higher level number increases the detail of the information logged, but even when level is set to 1, the named.run file grows very rapidly. Whenever you use debugging, keep an eye on the size of the named.run file and use SIGUSR2 to close and remove the file if it gets too large. Signal handling is covered in the next section. It is not necessary to turn on debugging with the -d option to receive error messages from named. named displays error messages on the console and stores them in the messages, even if debugging is not specified. The -d option provides additional debugging information. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_01.htm (1 of 3) [2001-10-15 09:19:20]
  7. [Appendix C] A named Reference -p port[/localport] Defines the UDP/TCP port used by named. port is the port number used to connect to the remote name server. localport is the number of the port on which the local name server daemon listens for connections. If the -p option is not specified, the standard port (53) is used. Since port 53 is a well-known port, changing the port number makes the name server inaccessible to standard software packages. Therefore, -p is only used for testing. -b bootfile Specifies the file named uses as its configuration file. By default the configuration file is /etc/named.boot, but the -b option allows the administrator to choose another configuration file. Note that the -b is optional. As long as the filename used for bootfile doesn't start with a dash, the -b flag is not required. Any filename written on the named command line is assumed to be the boot file. -q Logs all incoming queries. named must be compiled with the QRYLOG option set to enable this type of logging. -r Turns off recursion. With this option set, the server will only provide answers for zones for which it is an authoritative server. It will not pursue the query through other servers or zones. C.1.1 Signal Processing named handles the following signals: SIGHUP Causes named to reread the named.boot file and reload the name server database. named then continues to run with the new configuration. This signal is particularly useful for forcing secondary servers to reload a database from the primary server. Normally the databases are downloaded from the primary server on a periodic basis. Using SIGHUP causes the reload to occur immediately. SIGINT Causes named to dump its cache to /usr/tmp/named_dump.db. The dump file contains all of the domain information that the local name server knows. The file begins with the root servers, and marks off every domain under the root that the local server knows anything about. If you examine this file, you'll see that it shows a complete picture of the information the server has learned. SIGUSR1 Turns on debugging; each subsequent SIGUSR1 signal increases the level of debugging. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_01.htm (2 of 3) [2001-10-15 09:19:20]
  8. [Appendix C] A named Reference Debugging information is written to /usr/tmp/named.run just as it is when the -d option is used on the named command line. Debugging does not have to be enabled with the -d option for the SIGUSR1 signal to work. SIGUSR1 allows debugging to be turned on when a problem is suspected, without stopping named and restarting it with the -d option. SIGUSR2 Turns off debugging and closes /usr/tmp/named.run. After issuing SIGUSR2, you can examine named.run or remove it if it is getting too large. Optionally, some other signals can be handled by named. These additional signals require named to be compiled with the appropriate options to support the signals: SIGABRT Writes statistics data to /var/tmp/named.stats. named must be compiled with -DSTATS for this signal to work. SIGSYS Writes profiling data into the /var/tmp directory. named must be compiled with profiling to support this signal. SIGTERM Writes back the primary and secondary database files. This is used to save data modified by dynamic updates before the system is shut down. named must be compiled with dynamic updating enabled. SIGWINCH Toggles logging of all incoming queries via syslogd. named must be compiled with QRYLOG option to support this. Previous: B.11 The TCP/IP Network Next: C.2 named.boot Aggregate Statements Administration Configuration Commands B.11 The Aggregate Book Index C.2 named.boot Configuration Statements Commands [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_01.htm (3 of 3) [2001-10-15 09:19:20]
  9. [Appendix C] C.2 named.boot Configuration Commands Previous: C.1 The named Appendix C Next: C.3 Zone File A named Reference Command Records C.2 named.boot Configuration Commands The /etc/named.boot file defines the name server configuration and tells named where to obtain the name server database information. named.boot contains the following types of records: directory directory-path Defines a default directory used for all subsequent file references anywhere in the named configuration. If named is forced to dump memory, the memory dump is stored in this directory. primary domain-name file-name Declares the local name server as the primary master server for the domain specified by domain-name. As a primary server, the system loads the name server database from the local disk file specified by name in the file-name field. secondary domain-name server-address-list file-name Makes the local server a secondary master server for the domain identified by domain-name. The server-address-list contains the IP address of at least one other master server for this domain. Multiple addresses can be provided in the list, but at least the primary server's address should be provided. The local server will try each server in the list until it successfully loads the name server database. The local server transfers the entire domain database and stores all of the data it receives in a local file identified by file-name. After completing the transfer, the local server answers all queries for information about the domain with complete authority. cache . file-name The cache command points to the file used to initialize the name server cache with a list of root servers. This command starts with the keyword cache, followed by the name of the root domain (.), and ends with the name of the file that contains the root server list. This file can have any name you wish, but it is usually called named.ca, named.root, or root.cache. The cache command is included in every named.boot file. named needs the list of root servers as a starting point from which to locate all other DNS domains. forwarders server-address server-address ... Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_02.htm (1 of 4) [2001-10-15 09:19:21]
  10. [Appendix C] C.2 named.boot Configuration Commands The forwarders command provides named with a list of servers to try if it can't resolve a query from its own cache. In the syntax shown, server-address is the IP address of a server on your network that can perform a recursive name server query for the local host. (A recursive query [2] means that the remote server pursues the answer to the query, even if it does not have the answer itself, and returns the answer to the originator.) The servers listed on the forwarders command line (the servers are also called "forwarders") are tried in order until one responds to the query. The listed servers develop an extensive cache that benefits every host that uses them. Because of this, their use is often recommended. If you plan to use forwarders, your network administrator should define the list of forwarders for your network. The forwarders only develop a rich cache if they are used by several hosts. [2] Chapter 3, Network Services, discusses recursive and nonrecursive name server queries. slave The slave command forces the local server to use only the servers listed on the forwarders command line. The slave command can only be used if a forwarders command is also present in the named.boot file. A server that has a slave command in its named.boot file is called a slave server. A slave server does not attempt to contact the authoritative servers for a domain, even if the forwarding servers do not respond to its query. Regardless of the circumstances, a slave server queries only the forwarders. The slave command is used when limited network access makes the forwarders the only servers that can be reached by the local host. The slave command is not used on systems that have full Internet access because it limits their flexibility. sortlist network network ... The sortlist command causes named to prefer addresses from the listed networks over addresses from other networks. Normally, DNS sorts the addresses in a response only if the host issuing the query and the name server share a network. In that case, the shared network is the preferred network. xfrnets address[&mask] ... The xfrnets command limits zone transfers to hosts with the specified address. The address is written in dotted decimal notation and is intepreted as a network address. The optional mask field is used to change the interpretation of the address. When a bit is on in the mask field, that bit is significant for determining which hosts will be allowed to receive a zone file transfer. For example, xfrnets 172.16.0.0 allows every host on network 172.16 to do zone file transfers, while xfrnets 172.16.12.3&255.255.255.255 limits zone file transfers to the single host 172.16.12.3. For security reasons, many sites do not want to let everyone list all of the hostnames in their domain. xfrnets limits the ability to retrieve your entire domain to specific, trusted hosts. tcplist is an alternative form of this command maintained for compatibility with older server implementations. include file Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_02.htm (2 of 4) [2001-10-15 09:19:21]
  11. [Appendix C] C.2 named.boot Configuration Commands The include command includes the contents of file at the location that the command appears in the boot file. This command can be used for very large configurations that are maintained by different people. bogusns address address ... The bogusns command prevents queries from being sent to the name server specified by address. address must be an IP address, not a domain name. This command is used to avoid cache contamination when you know that a remote name server is providing incorrect informatiom. bogusns is only a temporary fix placed in the boot file until the remote domain administrator has a chance to fix the real problem. limit name value The limit command changes BIND's internal quotas. value is a number that specifies the new quota setting. k, m, or g, for kilobytes, megabytes, and gigabytes, respectively, can be appended to the new quota value number as appropriate. name is the name of the quota being set. There are four possible values for name: datasize sets the process data size quota; [3] transfers-in sets the number of named transfer subprocesses that BIND may spawn at any one time; transfers-per-ns sets the maximum number of simultaneous zone transfers allowed to any one remote nameserver. There can be multiple limit commands in a boot file - one for each quota that is being set. [3] This is a kernel quota and therefore can be set only on systems that provide a kernel call to implement this. options option option ... The options command enables optional features of BIND. The option keywords are Booleans. Specifying an option on the command line turns on the optional behavior. By default, the optional features are turned off. Valid option values are: query-log - logs all queries via syslogd, which produces a very large amount of log data. forward-only - all queries are to be sent to the forwarders; this is exactly the same as the slave command, though this syntax is now preferred over the slave syntax. fake-iquery - the nameserver responds to inverse queries with a fake reply rather than an error; used if you have some clients that cannot properly handle the error. no-recursion - the name server answers a query for data only in a zone for which it is authoritative; all other queries are answered with a referral to another server. no-fetch-glue - the nameserver does not fetch missing glue records for a query response; the resulting response could be incomplete; it is used with no-recursion to limit cache growth and reduce the chance of cache corruption. check-names source action The check-names command tells the name server to check host names against the standards for hostnames defined in RFC 952, and to check non-hostname responses to make sure that they contain nothing but printable characters. The source is the source of the hostname or string data that is being checked. The source can be primary for the primary zone file; secondary for the secondary zone file, or response for the message received during recursive Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_02.htm (3 of 4) [2001-10-15 09:19:21]
  12. [Appendix C] C.2 named.boot Configuration Commands search. The action tells the name server what to do when an error is detected: fail (reject the data; do not load, cache, or forward it); warn (send an error message to the system log); or ignore (process the data as if no error occurred). Multiple check-names commands can appear in a boot file; one for each source of data. The action for each source can be different. max-fetch value The max-fetch command performs exactly the same function as the limit transfers-in command described previously. The limit command is now the preferred syntax. At this writing, an experimental named.boot command is supported in some configurations: stub domain-name server-address-list file-name This command declares that this is a "stub" server for the domain specified by domain- name. The stub information is loaded from a server specified in the server-address- list and is stored in the file identified by file-name. The format of the stub command is the same as the secondary command and the functions of the fields in the command are the same. However, the stub command has very limited applicability. It is only used on a primary host that is not secondary for its subordinate domains. In that limited case, it is used to ensure that the primary host has the correct NS records for its subordinate domains. There is a named.boot command that is no longer widely supported. You'll occasionally encounter descriptions of it in material written about name service, and for that reason it's discussed here. But don't use it in your configurations. It is: domain name This command functions in exactly the same way as the domain command used in the resolv.conf file. It is an obsolete command and may not be available in future releases of BIND. You don't need this command because the default domain name is easily defined in resolv.conf. Previous: C.1 The named TCP/IP Network Next: C.3 Zone File Command Administration Records C.1 The named Command Book Index C.3 Zone File Records [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_02.htm (4 of 4) [2001-10-15 09:19:21]
  13. [Appendix C] C.3 Zone File Records Previous: C.2 named.boot Appendix C Next: D. A dhcpd Reference A named Reference Configuration Commands C.3 Zone File Records Two types of entries are used to construct a zone file: control entries that simplify constructing the file, and standard resource records that define the domain data contained in the zone file. While there are several types of standard resource records, there are only two control statements. These are: $INCLUDE filename Identifies a file that contains data to be included in the zone file. The data in the included file must be valid control entries or standard resource records. $INCLUDE allows a large zone file to be divided into smaller, more manageable units. The filename specified on the command line is relative to the directory named on the directory statement in the named.boot file. For example: if the named.boot file for almond contains a directory /etc statement, and a zone file on almond contains an $INCLUDE sales.hosts statement, then the file /etc/sales.hosts would be included in that zone file. If you don't want the filename to be relative to that directory, specify a fully qualified name, such as /usr/dns/sales.hosts. $ORIGIN domainname Changes the default domain name used by subsequent records in the zone file. Use this command to put more than one domain in a zone file. For example, an $ORIGIN sales statement in the nuts.com zone file sets the domain name to sales.nuts.com. All subsequent resource records would be relative to this new domain. The named software uses $ORIGIN statements to organize its own information. Dumping the named database, with the SIGINT signal, produces a single file containing all the information that the server knows. This file, named_dump.db, contains many $ORIGIN entries used to place all of the domains that named knows about into a single file. These two control entries are helpful for organizing and controlling the data in a zone file, but all of the actual database information comes from standard resource records. All of the files pointed to by named.boot contribute to the DNS database, so all of these files are constructed from standard resource records. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (1 of 16) [2001-10-15 09:19:23]
  14. [Appendix C] C.3 Zone File Records C.3.1 Standard Resource Records The format of standard resource records, sometimes called RRs, is defined in RFC 1033, the Domain Administrators Operations Guide. The format is: [name] [ttl] class type data The individual fields in the standard resource record are: name This is the name of the object affected by this resource record. The named object can be as specific as an individual host, or as general as an entire domain. The string entered for name is relative to the current domain unless a fully qualified domain name is used. [4] Certain name values have special meaning. These are: A blank name field denotes the current named object. The current name stays in force until a new name value is encountered in the name field. This permits multiple RRs to be applied to a single object without having to repeat the object's name for each record. .. Two dots in the name field refer to the root domain. However, a single dot (the actual name of the root) also refers to the root domain, and is more commonly used. @ A single at-sign (@) in the name field refers to the current origin. The origin is a domain name derived by the system from the current domain name or explicitly set by the system administrator using the $ORIGIN command. * An asterisk in the name field is a wildcard character. It stands for a name composed of any string. It can be combined with a domain name or used alone. Used alone, an asterisk in the named field means that the resource record applies to objects with names composed of any string of characters plus the name of the current domain. Used with a domain name, the asterisk is relative to that domain. For example, *.bitnet. in the name field means any string plus the string .bitnet. [4] The FQDN must be specified all the way to the root; i.e., it must end with a dot. ttl Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (2 of 16) [2001-10-15 09:19:23]
  15. [Appendix C] C.3 Zone File Records Time-to-live defines the length of time in seconds that the information in this resource record should be kept in the cache. ttl is specified as a numeric value up to eight characters in length. If no value is set for ttl, it defaults to the value defined for the entire zone file in the minimum field of the SOA record. class This field defines the address class of the resource record. The Internet address class is IN. All resource records used by Internet DNS have IN in this field, but it is possible for a zone file to hold non-Internet information. For example, information used by the Hesiod server, a name server developed at MIT, is identified by HS in the class field, and chaosnet information is identified by a CH in the class field. All resource records used in this book have an address class of IN. type This field indicates the type of data this record provides. For example, the A type RR provides the address of the host identified in the name field. All of the standard resource record types are discussed in this appendix. data This field contains the information specific to the resource record. The format and content of the data field vary according to the resource record type. The data field is the meat of the RR. For example, in an A record, the data field contains the IP address. In addition to the special characters that have meaning in the name field, zone file records use these other special characters: ; The semicolon is the comment character. Use the semicolon to indicate that the remaining data on the line is a comment. ( ) Parentheses are the continuation characters. Use parentheses to continue data beyond a single line. After an opening parenthesis, all data on subsequent lines is considered part of the current line until a closing parenthesis. \x The backslash is an escape character. A non-numeric character following a backslash (\) is taken literally and any special meaning that the character may ordinarily have is ignored. For example, \; means a semicolon - not a comment. \ddd The backslash can also be followed by three decimal numbers. When the escape character is used in this manner the decimal numbers are interpreted as an absolute byte value. For example, \255 means the byte value 11111111. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (3 of 16) [2001-10-15 09:19:23]
  16. [Appendix C] C.3 Zone File Records The same general resource record format is used for each of the resource records in a zone file. Each resource record is described below. C.3.1.1 Start of Authority record The Start of Authority (SOA) record marks the beginning of a zone, and is usually the first record in a zone file. All of the records that follow are part of the zone declared by the SOA. Each zone has only one SOA record; the next SOA record encountered marks the beginning of another zone. Because a zone file is normally associated with a single zone, it normally contains only one SOA record. The format of the SOA record is: [zone] [ttl] IN SOA origin contact ( serial refresh retry expire minimum ) The components of the SOA record are: zone This is the name of the zone. Usually the SOA name field contains an at-sign (@). When used in an SOA record, the at-sign refers back to the domain name declared in the named.boot primary statement that points to this zone file. ttl Time-to-live is left blank on the SOA record. IN The address class is IN for all Internet RRs. SOA SOA is the resource record type. All the information that follows this is part of the data field and is specific to the SOA record. Iorigin This is the hostname of the primary master server for this domain. It is normally written as a fully qualified domain name. For example, almond is the master server for nuts.com, so this field contains almond.nuts.com. in the SOA record for nuts.com. contact Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (4 of 16) [2001-10-15 09:19:23]
  17. [Appendix C] C.3 Zone File Records The email address of the person responsible for this domain is entered in this field. The address is modified slightly. The at-sign (@) that usually appears in an Internet email address is replaced by a dot. Therefore, if david@almond.nuts.com is the mailing address of the administrator of the nuts.com domain, the nuts.com SOA record contains david.almond.nuts.com. in the contact field. serial This is the version number of the zone file. It is an eight-digit numeric field usually entered as a simple number, e.g., 117. However, the composition of the number is up to the administrator. Some choose a format that shows the date the zone was updated, e.g., 92031100. Regardless of the format, the important thing is that the serial number must increase every time the data in the zone file is modified. The serial field is extremely important. It is used by the secondary master servers to determine if the zone file has been updated. To make this determination, a secondary server requests the SOA record from the primary server and compares the serial number of the data it has stored to the serial number received from the primary server. If the serial number has increased, the secondary server requests a full zone transfer. Otherwise it assumes that it has the most current zone data. You must increment the serial number each time you update the zone data. If you don't, the new data will not be disseminated to the secondary servers. refresh This specifies the length of time that the secondary server should wait before checking with the primary server to see if the zone has been updated. Every refresh seconds, the secondary server checks the SOA serial number to see if the zone file needs to be reloaded. Secondary servers check the serial numbers of their zones whenever they restart or receive a SIGHUP signal. But it is important to keep the secondary server's database current with the primary server, so named does not rely on these unpredictable events. The refresh interval provides a predictable cycle for reloading the zone that is controlled by the domain administrator. The value used in refresh is a number, up to eight digits long, that is the maximum number of seconds that the primary and secondary servers' databases can be out of sync. A low refresh value keeps the data on the servers closely synchronized, but a very low refresh value is not usually required. A value set lower than needed places an unnecessary burden on the network and the secondary servers. The value used in refresh should reflect the reality of how often your domain database is updated. Most sites' domain databases are very stable. Systems are added periodically, but not generally on an hourly basis. When you are adding a new system, you can assign the hostname and address of that system before the system is operational. You can then install this information in the name server database before it is actually needed, ensuring that it is disseminated to the secondary servers long before it has to be used. If extensive changes are planned, the refresh time can be temporarily reduced while the changes are underway. Therefore, you can normally set refresh time high, reducing load on the network Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (5 of 16) [2001-10-15 09:19:24]
  18. [Appendix C] C.3 Zone File Records and servers. Two (43200 seconds) to four (21600 seconds) times a day for refresh is adequate for many sites. The process of retrieving the SOA record, evaluating the serial number and, if necessary, downloading the zone file is called a zone refresh. Thus the name refresh is used for this value. retry This defines how long secondary servers should wait before trying again if the primary server fails to respond to a request for a zone refresh. retry is specified in seconds and can be up to eight digits long. You should not set the retry value too low. If a primary server fails to respond, the server or the network could be down. Quickly retrying a down system gains nothing and costs network resources. A secondary server that backs up a large number of zones can have problems when retry values are short. If the secondary server cannot reach the primary servers for several of its zones, it can become stuck in a retry loop. [5] Avoid problems; use an hour (3600) or a half hour (1800) for the retry value. [5] The server may alternate between periods when it fails to respond and when it resolves queries, or it may display the error "too many open files." expire This defines how long the zone's data should be retained by the secondary servers without receiving a zone refresh. The value is specified in seconds and is up to eight digits long. If after expire seconds the secondary server has been unable to refresh this zone, it should discard all of the data. expire is normally a very large value. 3600000 seconds (about 42 days) is commonly used. This says that if there has been no answer from the primary server to refresh requests repeated every retry seconds for the last 42 days, discard the data. 42 days is a good value. minimum This is the value used as the default ttl in all resource records where an explicit ttl value is not provided. This is a number, up to eight digits long, that specifies how many seconds resource records from this zone should be held in a remote host's cache. Make this a large value. Most of the records in a zone remain unchanged for long periods of time. Hosts are added to a zone, but hostnames (if they are well chosen) and addresses are not frequently changed. Forcing remote servers to query again for data that has not changed, just because it had a short ttl, is a waste of resources. If you plan to change a record, put a short ttl on that record; don't set the entire zone to a short ttl by setting a low minimum. Use a short minimum only if the entire database is being replaced. Use at least a week (604800) for normal operation. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (6 of 16) [2001-10-15 09:19:24]
  19. [Appendix C] C.3 Zone File Records A sample SOA record for the nuts.com domain is: @ IN SOA almond.nuts.com. david.almond.nuts.com. ( 92031101 ; serial 43200 ; refresh twice a day 3600 ; retry every hour 3600000 ; expire after 1000 hours 2419200 ; default ttl is one month ) Notice the serial number in this SOA. The serial number is in the format yymmddvv - where yy is the year, mm is the month, dd is the day, and vv is the version written that day. This type of serial number allows the administrator to track what day the zone was updated. Adding the version number allows for multiple updates in a single day. This zone file was created March 11, 1992, and it is the first update that day. This SOA record also says that almond is the primary server for this zone and that the person responsible for this zone can be reached at the email address david@almond.nuts.com. The SOA tells the secondary servers to check the zone for changes twice a day and to retry every hour if they don't get an answer. If they retry a thousand times and never get an answer, they should discard the data for this zone. Finally, if an RR in this zone does not have an explicit ttl, it will default to 1 month. C.3.1.2 Name server record Name server (NS) resource records identify the authoritative servers for a zone. These records are the pointers that link the domain hierarchy together. NS records in the top-level domains point to the servers for the second-level domains, which in turn contain NS records that point to the servers for their subdomains. Name server records pointing to the servers for subordinate domains are required for these domains to be accessible. Without NS records, the servers for a domain would be unknown. The format of the NS RR is: [domain] [ttl] IN NS server domain The name of the domain for which the host specified in the server field is an authoritative name server. ttl Time-to-live is usually blank. IN The address class is IN. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (7 of 16) [2001-10-15 09:19:24]
  20. [Appendix C] C.3 Zone File Records NS The name server resource record type is NS. server The hostname of a computer that provides authoritative name service for this domain. Usually domains have at least one server that is located outside of the local domain. The server name cannot be specified relative to the local domain; it must be specified as a fully qualified domain name. To be consistent, many administrators use fully qualified names for all servers, even though it is not necessary for servers within the local domain. C.3.1.3 Address record The majority of the resource records in a named.hosts zone file [6] are address records. Address records are used to convert hostnames to IP addresses, which is the most common use of the DNS database. [6] Chapter 8 describes the various named configuration files. The address RR contains the following: [host] [ttl] IN A address host The name of the host whose address is provided in the data field of this record. Most often the hostname is written relative to the current domain. ttl Time-to-live is usually blank. IN The address class is IN. A The address resource record type is A. address The IP address of the host is written here in dotted decimal form, e.g., 128.66.12.2. A glue record is a special type of address record. Most address records refer to hosts within the zone, but sometimes an address record needs to refer to a host in another zone. This is done to provide the address of a name server for a subordinate domain. Recall that the NS record for a subdomain server Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/appc_03.htm (8 of 16) [2001-10-15 09:19:24]
Đồng bộ tài khoản