[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 file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (7 of 8) [2001-10-15 09:19:19] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [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 Statements TCP/IP Network Administration Next: B.11 The Aggregate Statements B.9 static Statements Book Index B.11 The Aggregate Statements [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/mynapster/Downloads/warez/tcpip/appb_10.htm (8 of 8) [2001-10-15 09:19:19] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Appendix B] B.11 The Aggregate Statements Previous: B.10 Control Statements Appendix B A gated Reference Next: C. A named 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 file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (1 of 3) [2001-10-15 09:19:19] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [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 Statements TCP/IP Network Administration Next: C. A named Reference B.10 Control Statements Book Index C. A named Reference file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (2 of 3) [2001-10-15 09:19:19] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Appendix B] B.11 The Aggregate Statements [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/mynapster/Downloads/warez/tcpip/appb_11.htm (3 of 3) [2001-10-15 09:19:19] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Appendix C] A named Reference Previous: B.11 The Aggregate Statements Appendix C Next: C.2 named.boot 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. file:///C|/mynapster/Downloads/warez/tcpip/appc_01.htm (1 of 3) [2001-10-15 09:19:20] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [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. file:///C|/mynapster/Downloads/warez/tcpip/appc_01.htm (2 of 3) [2001-10-15 09:19:20] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [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 Aggregate Statements TCP/IP Network Administration Next: C.2 named.boot Configuration Commands B.11 The Aggregate Statements Book Index C.2 named.boot Configuration Commands [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/mynapster/Downloads/warez/tcpip/appc_01.htm (3 of 3) [2001-10-15 09:19:20] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Appendix C] C.2 named.boot Configuration Commands Previous: C.1 The named Command Appendix C A named Reference Next: C.3 Zone File 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 . file:///C|/mynapster/Downloads/warez/tcpip/appc_02.htm (1 of 4) [2001-10-15 09:19:21] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [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 file:///C|/mynapster/Downloads/warez/tcpip/appc_02.htm (2 of 4) [2001-10-15 09:19:21] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... subnet shares the same physical network In most cases, different subnets are on different physical networks The name, which must be provided, can be any descriptive name It is used only in debugging messages Parameters and options associated with the shared network are declared within the curly braces and apply to all subnets in the shared network The subnets in a shared network must be defined within... option statements that apply to every network served by this server The documentation calls these "global parameters." group {[parameters] [options]} The group statement groups together shared -network, subnet, host, or other group statements to apply a set of parameters or options to all members of the group shared -network name {[parameters] [options]} The shared -network statement is used only if more... Parameters and options specified outside of a specific topology statement apply to all networks served by this server Those specified in the group statement apply to all of the shared networks, subnets or hosts grouped together by the statement The shared -network statement options and parameters apply to all subnets on the shared network Subnet options and parameters apply to everything on the subnet Host options... curly braces of the shared -network statement It is assumed that each shared -network statement contains at least two subnet statements; otherwise there is no need to use the shared-subnet statement dhcpd cannot tell on which subnet of a shared network a client should boot Therefore, dynamically allocated addresses are taken from the available range of all subnets on the shared network and assigned as needed... hostnames that resolve to addresses Statements in the configuration file define the topology of the network being served In the documentation these statements are called "declarations" because they declare something about the network topology The statements that define the topology are: server-identifier, shared -network, subnet, group, and host When used, there is only one server-identifier All the other... don't need this command because the default domain name is easily defined in resolv.conf Previous: C.1 The named Command C.1 The named Command TCP/IP Network Administration Book Index Next: C.3 Zone File Records 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... [2001-10-15 09:19:24] [Appendix C] C.3 Zone File Records Previous: C.2 named.boot Configuration Commands C.2 named.boot Configuration Commands TCP/IP Network Administration Next: D A dhcpd Reference Book Index D A dhcpd Reference [ 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... configuration steps was clearly defined in the README file Read it before you try to run dhcpd Previous: C.3 Zone File Records C.3 Zone File Records TCP/IP Network Administration Book Index Next: D.2 The dhcpd Command D.2 The dhcpd Command [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this... touch /var/db/dhcpd.leases Create a configuration and store it in dhcpd.conf Previous: D.1 Compiling dhcpd D.1 Compiling dhcpd TCP/IP Network Administration Book Index Next: D.3 The dhcpd.conf Configuration File D.3 The dhcpd.conf Configuration File [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com... 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 . flexibility. sortlist network network . The sortlist command causes named to prefer addresses from the listed networks over addresses from other networks. Normally,. 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