HP-UX IP Address and Client Management administrator’s guide HP-UX 11i v2 and HP-UX 11i v3 HP Part Number: 5991-0439 Published: September 2010 Edition: Edition 4
Legal Notices © Copyright 2004-2010 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Table of Contents About This Document.......................................................................................................11 New and Changed Information in This Edition...................................................................................11 Intended Audience................................................................................................................................11 HP-UX Release Name and Release Identifier...................................................
The sortlist Statement.................................................................................................................39 The server Statement..................................................................................................................40 The zone Statement....................................................................................................................40 The view Statement..................................................................................
Configuring the Name Service Switch..................................................................................................63 Choosing Name Servers for Your Domain...........................................................................................64 Choosing the Type of Name Server.................................................................................................64 Choosing Master Servers and Slave Servers........................................................................
The nsquery Command..............................................................................................................89 The syslogd Utility.....................................................................................................................90 Name Server Debugging............................................................................................................90 Dumping the Name Server Database.............................................................................
DHCP Troubleshooting Tools........................................................................................................125 Callbacks........................................................................................................................................126 5 Configuring DHCPv6................................................................................................127 Configuring the Server......................................................................................
List of Figures 1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 2-1 3-1 3-2 4-1 4-2 4-3 4-4 4-5 5-1 8 Structure of the DNS Name Space................................................................................................16 Bootrequest Relay Example...........................................................................................................43 DHCP Client and Server Transaction............................................................................................
List of Tables 1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 1-9 1-10 1-11 1-12 1-13 1-14 1-15 1-16 1-17 1-18 1-19 1-20 1-21 1-22 1-23 1-24 2-1 2-2 3-1 3-2 3-3 4-1 5-1 6-1 6-2 6-3 6-4 6-5 rndc Commands............................................................................................................................22 Advantages of Using BIND over Other Name Services................................................................24 Channel Message Categories.......................................................
List of Examples 2-1 10 mknod Command Usage...............................................................................................................
About This Document This document describes the IP Address and Client Management implementations in the HP-UX 11i v2 and HP-UX 11i v3 operating systems. It is one of the documents available for the Internet Services suite of products. For a list of other Internet Services documents, see “Related Information” (page 12). These documents replace the document Installing and Administering Internet Services (B2355-90685), which was shipped with releases prior to the HP-UX 11i v2 operating system.
Document Manufacturing Part Number Operating System Supported Publication Date 5991-0439 11i v2, 11i v3 March 2010 5991-0439 11i v2, 11i v3 September 2010 Document Organization The HP-UX Mailing Services Administrator’s Guide is organized as follows: Chapter 1 Overview Provides an overview of the IP address and client management implementations. Chapter 2 Configuring and Administering the BIND Name Service Describes how to configure the master server, slave server, and caching-only server.
audit(5) An HP-UX manpage. In this example, audit is the name and 5 is the section in the HP-UX Reference. On the web and on the Instant Information CD, it may be a link to the manpage itself. From the HP-UX command line, you can enter “man audit” or “man 5 audit” to view the manpage. See man (1). Book Title The title of a book. On the web and on the Instant Information CD, it may be a link to the book itself. ComputerOut Text displayed by the computer.
1 Overview This manual discusses the IP address and client management techniques implemented in the HP-UX 11i v2 and HP-UX 11i v3 operating systems. With the success of the Internet, an ever-increasing demand for IP addresses and IP address management has presented a challenging task for administrators. In the past, administrators could manage the IP addresses in a single file containing all the host information, that is, name-to-address mappings for every host connected to the network.
• • • • • “BIND Name Service Overview” (page 16) “BOOTP and TFTP Overview” (page 42) “DHCP Overview” (page 44) “DHCPv6 Overview” (page 47) “SLP Overview” (page 52) BIND Name Service Overview The Berkeley Internet Name Domain (BIND) is a Berkeley implementation of the Domain Name System (DNS). It is a distributed network information lookup service that maps host names to Internet addresses and maps Internet addresses to host names.
NOTE: Throughout this document, the terms zone and domain are used interchangeably, though they describe different concepts. A zone describes the domain name space that a name server has authority over. Normally, a zone does not contain any delegated subdomains, whereas a domain can contain data delegated to other name servers. Therefore, as long as subdomains are not delegated, a zone and a domain contain the same data.
whenever the master changes and sends a notification to other servers, the 4.x servers ignore this notification because they do not understand the DNS Notify protocol. Dynamic DNS Update Dynamic DNS update is the ability to add, modify, or delete resource records in the master zone files under a specified zone. Dynamic update is based on RFC 2136 (Dynamic Updates in the Domain Name System (DNS UPDATE)). Resource records provide a set of information about each of the domain names.
The request-ixfr clause determines whether the local server, acting as a slave, requests incremental zone transfers from the given remote server (a master server). If set to yes, incremental transfer is requested from the given remote server (master server). If set to no, all transfers to the remote server are non-incremental. If this clause is not set, the value of the request-ixfr option in the global options block is used as the default.
applications and services call gethostbyname() for rainbow, an array of IP addresses is returned and applications typically use the first IP address in the array. With the round-robin address rotation, the name server rotates the order of the addresses returned, so connections to rainbow are balanced among red, blue, and green. Round-robin address cycling also affects multi-homed hosts (hosts with multiple IP addresses).
export HOSTALIASES=/home/andrea/myaliases • If the input host name does not end with a dot, BIND looks it up with domain names appended to the host name. You can configure the domain names that BIND appends to the host name using the following methods: — The LOCALDOMAIN environment variable. — The hostname command. — The search option in the /etc/resolv.conf file. — The domain option in the /etc/resolv.conf file. If you set the LOCALDOMAIN variable as in the following example, export LOCALDOMAIN="nmt.
The rndc utility is of the following format: rndc [-c config] [-s server] [-p port] [-y key] command [command...] where -c config file Specifies an alternate configuration file. The default configuration file is /etc/rndc.conf. -s server Specifies the server whose operation needs to be controlled. -p port Instructs rndc to send commands to the TCP port number port on the system running the name server instead of to BIND’s default control channel port number 953.
Generating the rndc.conf File You can generate the configuration file rndc.conf using the rndc-confgen utility. A sample configuration file rndc.conf is distributed with this release of BIND. An example configuration file /etc/rndc.conf is as follows: key rndckey { algorithm “hmac-md5”; secret “IbtRYdcP8k2mVtel6aYfbQ==”; }; options { default-server localhost; default-key rndckey; }; With this example as the /etc/rndc.
For more information, type man 1 rndc-confgen at the command prompt. Benefits of Using BIND Table 1-2 explains the advantages of BIND over other name services available on the HP-UX operating system (NIS and the /etc/hosts file). Table 1-2 Advantages of Using BIND over Other Name Services Advantage Disadvantage You can store information for the hosts only in your local If you use the /etc/hosts file or the NIS hosts domain.
The hosts_to_named command creates the configuration file named.conf and other data files in the working directory. For a detailed description of the configuration file and all the data files generated by hosts_to_named, see “Creating the Data Files for a Master Server” (page 66) and “Master Server Configuration File” (page 68). For more information on the hosts_to_named command, type man 1m hosts_to_named at the HP-UX prompt.
The /etc/named.conf Statements The following statements are supported in the /etc/named.conf file: • • • • • • • • • The acl Statement The include Statement The key Statement The logging Statement The options Statement The server Statement The zone Statement The view Statement The sortlist Statement The acl Statement The acl statement gets its name from the primary use of address match lists, that is, Access Control Lists (ACLs). The acl statement in the /etc/named.
NOTE: You cannot use an include statement within another statement. Therefore, an entry such as the following is incorrect: acl internal_hosts {include internal_hosts.acl}; Also, do not type #include as you would in a C program. The pound sign (#) is used to start a comment in the /etc/named.conf file. The key Statement The key statement in the /etc/named.conf file defines a shared secret key for use with TSIG.
An example logging statement is as follows: logging{ channel lname { file lame-servers.log; size 10M; severity info; }; channel log ( syslog local0;); category lame-server {lame;}; category default {log;}; }; If a list of channels is not specified for a category, then log messages in that category are sent to the default category. For most of the categories, the default is default_syslog and default_debug. Channels and Channel Messages A channel describes a destination (a file, syslog, or the bit bucket).
Table 1-3 Channel Message Categories Message Category Description config High-level configuration file processing parser Low-level configuration file processing queries Incoming queries lame-servers Messages about lame servers cname Messages about cname records ncache Negative caching xfer-in Zone transfers that the server receives xfer-out Zone transfers that the server sends eventlib Debugging information from the event system packet Dumps of packets received and sent notify The NOT
port ip_port ; ] [ preferred-glue ( A | AAAA | NONE ) ; ] [ random-device path_name ; ] [ root-delegation-only [ exclude { namelist } ] ; ] [ statistics-file path_name ; ] [ tkey-dhkey key_name key_tag ; ] [ tkey-domain domainname ; ] // Boolean Options [ additional-from-auth yes_or_no ; ] [ additional-from-cache yes_or_no ; ] [ auth-nxdomain yes_or_no ; ] [ check-names ( master | slave | response ) ( warn | fail | ignore ) ; ] [ dialup dialup_option ; ] [ dnssec-enable yes_or_no ; ] [ flush-zones-on-shutdo
Table 1-4 Pathname Options Option Description directory path_name; This option specifies the working directory of the server. Any non-absolute pathnames in the configuration file are considered relative to this directory. directory specifies the default location for most of the server output files (for example, named.run). If you do not specify a directory, the working directory defaults to ‘.’, the directory from where the server is started. The directory specified must be an absolute path.
Table 1-5 Boolean Options (continued) Option Description fetch-glue yes_or_no; If this option is set to yes (the default value) the sever fetches glue resource records that it does not posses, while constructing the additional data section of a response. You can use fetch-glue no with the recursion no option to prevent the server’s cache from increasing in size or getting corrupted (at the cost of requiring more work from the client).
Table 1-5 Boolean Options (continued) Option Description ixfr-from-differenc es yes_or_no; Loads a new version of a master zone from the zone file of the server or receives a new version of a slave file by a non-incremental zone transfer. The server compares the new version of the master zone with the previous version of master zone and calculates the set of differences.
Following are the options available for check-names: • • • ignore – No checking is done. warn – Names are checked against their expected client contexts. Invalid names are logged, but processing continues normally. fail – Names are checked against their expected client contexts. Invalid names are logged, and the offending data is rejected.
Table 1-8 Zone Transfer Options Option Description also-notify { ( ip_addr [ port ip_port ] ; )... }; This option defines a global list of IP addresses of name servers to which NOTIFY messages are sent, in addition to the servers listed in the zone's NS records when a fresh copy of the zone is loaded.
Resource Limit Options Resource limit options enable you to limit the server’s usage of the system resources. If a given operating system does not support a specific limit, a warning is issue. You can use scaled values to specify resource limits. For example, you can use 1G instead of 1073741824 to specify a limit of one gigabyte. Specifying unlimited specifies unlimited usage, or the maximum available amount. default specifies the limit that was in effect when the server was started.
Table 1-11 Periodic Task Interval Options Option Description cleaning-interval number; This option specifies (in minutes) how frequently the server removes the expired resource records from the cache. The default value is 60 minutes. If cleaning-interval is set to 0, periodic cleaning does not occur. interface-interval number; This option specifies how frequently the server scans the network interface list (in minutes).
Server Information Zone Options Table 1-14 describes the server information zone options in the /etc/named.conf file. Table 1-14 Server Information Zone Options Option Description hostname hostname_string; Specifies the host name to which the server must report, using the hostname.bind query with type TXT and class CHAOS. This option defaults to the host name of the system that host the name server. server-id server_id_string; Specifies the server ID to which the server must report, using the ID.
Dual-Stack Server Option BIND provides transition support for IPv4 and IPv6 to solve problems caused by the lack of support for either IPv4 or IPv6 address on a host system. It also provides the dual-stack-servers option to enable the transition support for IPv4 and IPv6 addresses. This option specifies host names or addresses of systems that have access to both IPv4 and IPv6 transports. If the host name is specified, a name server resolves a host name using the transport supported by the name server.
The server Statement The server statement in the /etc/named.conf file defines the remote name server characteristics. For example, if a name server is giving incorrect data, you can label the name server to prevent further queries to it. The server supports the following types of zone transfer methods, which you can define in the transfer-format phrase in the server statement. • transfer-format one-answer; Each resource record receives its own DNS message. This format is widely accepted but not efficient.
[ also-notify { ip_addr; [ ip_addr; ... ] }; }; The slave or stub zone statement is of the following format: zone domain_name [ ( in hs hesiod chaos ) ] { type ( slave stub ) ; [ file path_name; ] master { ip_addr; [ ip_addr; ... ] } [ check-names ( warn fail ignore ) ; ] [ allow-update { address_match_list }; ] [ allow-query { address_match_list }; ] [ allow-transfer { address_match_list}; ] [ allow-update { address_match_list } ; ] [ forwarders { ip_addr [port ip_port ] ; [ ip_addr [port ip_port] ; ...
zone “example.com” { type master; file “example-internal.db”; }; }; view “external” { match-clients { any; }; // Refuse recursive service to external clients. recursion no; // Provide a restricted view of the example.com zone // containing only publicly accessible hosts. zone “example.com” { type master; file “example-external.
• • 2. 3. 4. the maximum hop value configured for this client on a BOOTP server, the bootrequest is dropped. The hops value limits the number of times a bootrequest can be relayed. It sets the secs field of the bootrequest packet to 0 for a first-time request. If the client does not receive a reply to this request, it sets the value of this field to the number of seconds since the first request was sent.
A bootrequest from Client 1 is relayed from Server A to Server C through Server B. Server C finds the client’s boot information in its database, and sends the bootreply back to server A. Server A then sends the bootreply to the client. NOTE: BOOTP clients can be booted over a gateway; however, the BOOTP server with the relay information for the client must be on the same side of the gateway as the client.
network. The server is responsible for the pool of IP addresses and can give out an IP address to a client requesting a new configuration from the pool of IP addresses for which it is responsible. When a client requests for confirmation of its existing configuration, the server confirms the configuration. DHCP is a superset of the BOOTP bootstrap protocol. The DHCP server services the BOOTP clients. And DHCP servers and clients from different vendors interoperate very well with one another.
Figure 1-3 DHCP Client and Server Transaction The following describes the interaction between the client and the DHCP server in the Figure 1-3 and the steps involved in assigning an IP address to a client on the network: 1. 2. 3. A DHCP transaction begins when a client sends out a DHCP DISCOVER packet which is usually a broadcast packet. The packet contains only the client’s hardware address. The server receives the DHCP DISCOVER packet.
6. The DHCP server sends a DHCPACK packet to extend the lease on the IP address. DHCPv6 Overview Dynamic Host Configuration Protocol (DHCP) is an extension of BOOTP that defines a protocol for passing configuration information to hosts on a network. DHCPv6 supports IPv6, the next-generation Internet protocol. DHCPv6 enables DHCP servers to transmit configuration parameters using extensions to IPv6 nodes.
• 546 DHCP servers use this client port as the destination port to send messages to clients and relays. In addition, the relays or agents use this port as the destination port for messages sent to the clients. • 547 DHCP clients use this agent port as the destination port to send messages to agents or relays. In addition, relays use this port as the destination port for messages sent to the servers. For more information on port reference, refer to the following link: http://www.iana.
Figure 1-4 When Client and Server Are on the Same Link The client and the server communicate with each other by exchanging packets as follows (see the numbers 1,2,3,4, and 5 in Figure 1-4): 1. The client sends a DHCP SOLICIT message to the ALL DHCP Agents address (FF02::1:2) to locate suitable servers. 2. Multiple servers respond to the SOLICIT message by sending a DHCP ADVERTISE message to the client. 3. The client sends a DHCP REQUEST message to the DHCPv6 server that has the highest preference value. 4.
1. 2. 3. 4. The client sends a DHCP SOLICIT message to the ALL DHCP Agents address to locate servers that are able to offer the required services. The relay forwards the client’s message to servers by sending RELAY-FORW messages. The client message is encapsulated in the RELAY-FORW message. Servers respond to the client’s message by sending a RELAY-RELAY message. The server message is encapsulated in the RELAY-RELAY message.
Table 1-18 DHCPv6 Message Types (continued) Message Type Description RELEASE Clients use this message to return one or more IP addresses to servers. DECLINE A client sends a DECLINE message to a server to indicate that the client has determined that one or more addresses assigned by the server are already in use on the link to which the client is connected.
Table 1-19 DHCPv6 Files Name and Location Server /etc/dhcpv6tab X You can use this file to specify the default client, pool group, and relay settings. /etc/dhcpv6db X Files in this directory contain the client lease information. The DHCPv6 server reads these files to build its internal database and to maintain the leases. /etc/dhcpv6client.data Client X Use This file contains the configuration parameters obtained from the server.
Dynamic Service Tracking When service instances like printers or fax machines are added to a network, they are quickly visible to clients. When they are removed from the network, they are no longer visible to the clients. You can describe a service by configuring values for the attributes that are possible for that service. Clients can detect the entry and exit of services faster.
• • • SLP uses multicast ports for discovering Directory Agents and for issuing requests to Service Agents by default. SLP listens on port 427. SLP uses UDP for service request messages by the User Agents. However, in the following cases, a TCP connection is required: — The User Agent issues requests larger than the path MTU (largest packet size when communicating with a remote machine).
Figure 1-6 SLP Architecture In Figure 1-6, SAs contain service advertisements describing the services they represent. The advertisement consists of service type, attributes, and service access point. UAs transmit queries to the network about what services their clients require. The SAs intercept these queries and return the service access point information if the query matches the service type and attributes of the services they represent.
service:directory-agent://test.org service:directory-agent://15.10.20.2 • • Passive Discovery In passive DA discovery, DAs multicast periodic unsolicited advertisements of their services in case any SAs or UAs fail to receive the initial advertisement sent by the DAs. Using DHCP Options for SLP DA A host that uses DHCP may use it to obtain a DA’s IP address. The DHCP options, SLP Directory Agent, and SLP Service Scope can be used to discover the DA.
Figure 1-8 Protocol Transactions - Schematic Representation SLP Files Table 1-20 describes the files used by SLP. Table 1-20 SLP Files Name and Usage Location Configuration file - to configure slpd /etc/slp.conf Registration file /etc/slp.reg Pid file /var/run/slpd.pid Default log file /var/log/slp.log SLP daemon slpd Script to start, stop, restart slpd, and also to dump the database. slpdc Library calls libslp Error codes SLPError SLP Messages SLP is a string protocol.
Table 1-21 Message Types (continued) Message Type Abbreviation Usage Attribute Reply AttrRply SAs and DAs send this message to UAs in response to theirAttrRqst message. This contains the list of attributes of a requested service. Service Registration SrvReg SAs send this message to register their services with DAs. Service Deregistration SrvDeReg SAs send this message to DAs if they no longer want to make a service available, causing the advertisement to be removed from the DA immediately.
The slpd Daemon The slpd daemon process acts as either a DA or an SA server. Service processes on a host register their service advertisements with slpd. These service processes contain an SA client library that communicates with slpd, acting as the SA server. slpd forwards all service registrations and withdrawals to DAs and times out invalid or expired service advertisements. The SLP library (libslp.
Table 1-24 slpdc Commands 60 Command Description slpdc start Starts slpd.The command line options to be passed to slpd can be specified as: slpdc slpdc stop Stops slpd. slpdc restart Restarts slpd. slpdc dump Dumps the database.
2 Configuring and Administering the BIND Name Service The Berkeley Internet Name Domain (BIND) is a distributed network information lookup service. It allows you to retrieve host names and Internet addresses for any node on the network. It also provides mail routing capability by supplying a list of hosts that accept mail for other hosts.
# cp -p # cp -p /usr/lib/libcrypto.sl /usr/lib/libdld.2 /chroot/named/usr/lib/ /chroot/named/usr/lib/ Additionally, for a PA-RISC system, create a hard link for libc.2 in the usr/lib directory of the chroot directory: # ln 6. /usr/lib/libc.2 /chroot/named/usr/lib/libc.2 Obtain the major and minor numbers of the device special poll and random files using the ls command.
1. To assign Internet addresses to the hosts in your domain, you must ask the appropriate person or organization for a range of Internet addresses. • If your organization already has a domain on a public network, you must set up a subdomain. • If your organization does not have a domain on a public network, and you want to set one up, you can request a domain registration form from Government Systems, Inc., at the following address: Government Systems, Inc.
Choosing Name Servers for Your Domain You can configure your host as any of the following types of BIND name servers: • Master Server A master server is the authority for its domain and contains data corresponding to its domain. The master server obtains its information from a master file on the disk. On previous versions of BIND, the master server was referred to as a primary server.
Choosing Master Servers and Slave Servers Follow these guidelines while selecting a master server and slave server: • • • • You must have at least two master servers per domain: a primary master and one or more slaves for redundancy. You can configure one host as a master for multiple domains (primary for some domains and secondary for other domains). You must choose hosts that are as independent as possible for redundancy. For example, choose hosts that use different power sources or cables.
Table 2-1 BIND Resource Records (continued) Name Description Well Known Service (WKS) Describes the well known services supported by a particular protocol on a particular Internet address. This record must be superseded by the service record. Key Exchanger (KX) Provides a method to delegate authorization for one node, to provide key exchange services on behalf of one or more nodes.
3. Issue the following command to generate the name server data files from the /etc/hosts file: /usr/sbin/hosts_to_named -d domainname -n network_number Following is an example hosts_to_named statement: /usr/sbin/hosts_to_named -d div.inc.com -n 15.19.8 4. Issue the following command to move the /etc/named.data/named.conffile to the /etc directory: mv /etc/named.data/named.conf /etc/named.conf 5. 6. Copy the /usr/examples/bind/db.cache file to the /etc/named.data directory.
Do not insert a trailing dot at the end of the domain name. 2. Set the HOSTNAME variable in the /etc/rc.config.d/netconf file to the same value, as specified in the following example: HOSTNAME=indigo.div.inc.com Master Server Configuration File The configuration file, /etc/named.conf, informs the master server of the location of all the required data files. The master name server loads its database from these data files. The hosts_to_named program creates the named.conf file.
* a privileged port by default. /* // query-source address *port 53; }; // // type domain source file // // zone “0.0.127.IN.ADDR.ARPA” { type master; file “db.127.0.0”; }; zone “div.inc.com” { type master; file “db.div”; }; zone “8.19.15.IN.ADDR.ARPA” { type master; file “db.15.19.8”; }; zone “.” { type master; file “db.root”; }; The following describes the various fields used in the named.conf file: // Lines beginning with // are comments.
; ; temporarily housed at ISI (IANA) ; . 3600000 L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 NS L.ROOT-SERVERS.NET The following describes the fields in the db.cache file: ; Lines beginning with a semicolon (;) are comments. name For NS records, name specifies the name of the domain served by the name server listed in the data column. A period (.
type The start of authority (SOA) record designates the start of a domain and indicates that this server is authoritative for the data in the domain. The NS record designates a name server for the current origin (0.0.127.in-addr.arpa). PTR records are usually used to associate an address in the in-addr.arpa domain with the canonical name of a host. The PTR record in the example db.127.0.0 file associates the name localhost with the address 1, that is, 1.0.0.127.in-addr.arpa. (The current origin 0.0.127.
rabbit rabbit IN IN IN IN WKS 15.19.8.64 TCP (telnet smtp ftp shell domain) MX 5 rabbit.div.inc.com MX 10 indigo.div.inc.com A 15.19.8.119 The example file db.div contains the following types of records: SOA Start of Authority record. The SOA record designates the start of a domain, and indicates that this server is authoritative for the data in the domain. The at sign (@) in the data file represents the current origin.
for a given host. A low preference value indicates a higher precedence for the mail exchanger. In the example db.div file, mail for rabbit must go to rabbit.div.inc.com first. If rabbit is down, its mail must be sent to the host indigo.div.inc.com. See HP-UX Mailing Services Administrator’s Guide for information on Sendmail and how Sendmail uses the name server’s MX records for routing mail.
NS Name Server records. The NS records specifies the names of the name servers and the domains for which the domain has authority. The domain for the name servers in the example is the current origin (8.19.15.in-addr.arpa), because @ was the last domain specified. PTR Pointer records. PTR records are usually used to associate an address in the in-addr.arpa domain with the canonical name of a host. The first PTR record in the example file db.15.19.8 associates the name rabbit.div.inc.
Configuring a Slave Name Server After configuring the master name server, you must set up the slave server to share the load with the master server, or to handle the entire load if the master server is down. The /etc/named.boot file informs the server whether it is a master or a slave server. The difference between a master server and a slave server is the source from which they obtain the data. The master server reads its data from files.
An example named.conf configuration file for a slave server is shown in “Creating the Slave Server’s Data Files Manually” (page 76). For more information on hosts_to_named, type man 1M hosts_to_named at the HP-UX prompt. Creating the Slave Server’s Data Files Manually To create the slave server’s data files manually, complete the following steps: 1. 2. Copy the files /etc/named.conf, /etc/named.data/db.cache, and /etc/named.data/db.127.0.0 from the master server to the slave server.
masters { 15.19.8.119; }; }; zone “8.19.15.IN-ADDR.ARPA” { file “db.15.19.8”; masters { 15.19.8.119; }; }; zone “.” { type hint; file “db.cache”; }; type slave; In this example, the slave server uses the file db.div to store the database information. The slave server uses this file as a backup file. When the slave server reboots, it reads the authoritative data from the backup file, and later contacts the master server to verify the data.
1. 2. Copy the files /etc/named.data/db.127.0.0 and /etc/named.data/db.cache from the master server to the caching-only server. When you run the hosts_to_named command to create the master server configuration files, a file conf.cacheonly is created in the working directory of hosts_to_named. Copy this file to the caching-only server, and rename it /etc/named.conf.
You can include most of the resolver configurations in the /etc/resolv.conf file. Table 2-2 describes the options in the /etc/resolv.conf file that you can use to configure the resolver’s behavior. Table 2-2 The /etc/resolv.conf Options Option Description domain default_domain_name; The domain option followed by the default domain name.The domain entry is required only when the local system’s host name (as returned by the hostname command) is not a domain name, and the search option is not configured.
Configuring the Resolver to Set Timeout Values You can configure the timeout value for clients that use DNS to resolve a host name. The timeout value specifies the number of retransmissions of a query and the time (in milliseconds) between each retransmission. The performance of the resolver improves with smaller timeout values. You can configure the timeout values by defining environment variables, editing the /etc/resolv.conf configuration file, or using the resolver APIs.
set_resfield(int field, void *value) The set_resfield() function contains two parameters: field and *value. You can set the resolver option using the field parameter and the value for the field using the value parameter. The set_resfield() function returns either 0 or -1. It returns a value0 if the function successfully sets the value for the resolver option in the instance of the_res_state structure, which holds all the resolver options. A value of -1 denotes a failure to set the resolver option.
1. In the /etc/rc.config.d/namesvrs file, set the NAMED environment variable to 1, as follows: NAMED=1 2. Issue the following command to determine whether named is already running: ps -ef grep named 3. If named is not running, issue the following command to start named: /sbin/init.d/named start For more information, type man 1M named at the HP-UX prompt.
Updating Network-Related Files After you configure your system to use BIND, you must update the following network-related configuration files: • • • • /etc/hosts.equiv $HOME/.rhosts /var/adm/inetd.sec $HOME/.netrc The entries that use simple host names in these network-related files are assumed to be in the local domain. Therefore, you must clearly state the fully qualified domain name for all the hosts in these files, when the hosts are outside your local domain. Updating /etc/hosts.equiv and $HOME/.
1. 2. Set up the name servers for the subdomain. Edit the existing zone file, db.domain on the name server for the parent domain, as follows: • Add an NS resource record for each name server of the new subdomain. • Add A records to specify the Internet addresses of the name servers listed in the NS records. 3. After modifying the domain data files, issue the following command to restart the name server for the parent domain: /usr/sbin/sig_named restart This causes named to reload its databases.
3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum ttl of 1 day IN NS rabbit.div.inc.com. IN NS denny.dept.inc.com. IN NS sally.dept.inc.com. rabbit.div.inc.com. 86400 IN A 15.19.8.119 denny.dept.inc.com. 86400 IN A 15.19.15.33 sally.doc.inc.com. 86400 IN A 15.19.9.17 ; ; set ttl to 3 days ; inc.com. 259200 IN 2592 IN NS labs.inc.com. 15.in-addr.arpa. 259200 IN NS eduardo.inc.com. 259200 IN NS labs.inc.com. eduardo.inc.com. 259200 IN A 15.19.11.2 labs.inc.com. 259200 IN A 15.19.13.
value changes the hash value drastically, so that it is computationally infeasible to reverse the function and recalculate the input that generated the output. Configuring TSIG You must configure one or more TSIG keys on either end of the transaction before using TSIG for authentication. If you want to use TSIG to secure zone transfers between the master and slave name servers for div.inc.com, you must configure both the name servers with a common key as follows: key venus-mars.div.inc.com.
The nsupdate program with the -k and -y options provide the shared secret required to generate the TSIG record for authenticating a dynamic DNS update request. For more information on the -k and -y options, type man 1M nsupdate at the HP-UX prompt. DNSSEC – A DNS Security Extension Authentication of DNS information in a zone is possible through the DNS Security (DNSSEC) extensions defined in RFC 2535 (Domain Name System Security Extensions). BIND provides several tools to set up a DNSSEC secure zone.
# /usr/bin/dnssec-signzone example.com Kexample.com.+003+26160 Kexample.com.+003+26160 is the key identifier generated by the dnssec-keygen program. dnssec-signzone creates a file named example.com.signed, the signed version of the example.com zone. Now you can reference this file in a zone statement in /etc/named.conf so that it can be loaded by the nameserver. Configuring Servers In contrast to BIND 8.1.2, BIND 9.2.0 does not verify data on load.
Disabling Compartments in BIND To disable compartments in BIND, complete the following steps: 1. To delete security information for /usr/sbin/named from the /etc/named.conf configuration file and the kernel, enter the following command at the HP-UX prompt: # setfilexsec –d /usr/sbin/named 2. 2.
The nsquery command displays the Name Service Switch configuration that is currently in use. Then it displays the results of the query. For more information, type man 1 nsquery at the HP-UX prompt. The syslogd Utility The syslogd utility logs all the informational and error messages to the file /var/adm/syslog/syslog.log. You can configure syslogd to log the messages to a different destination. See the HP-UX Internet Services Administrator’s Guide at the URL http://www.docs.hp.com /hpux/netcom/index.
7 This level logs the journals added and deleted, and a count of the number of bytes returned by a zone transfer. 8 This level logs the following dynamic update messages: prerequisite checks, writing journal entries, and rollbacks. This level also logs several low-level zone transfer messages and the resource records sent in a zone transfer. 10 This level logs zone timer activity messages. 20 This level logs updates to a zone’s refresh timer.
— — • Problem 5, Network Connectivity Problem 10, /etc/hosts or NIS contains Incorrect Data Names in the local and remote domains are looked up successfully. However, other servers not in your domain cannot look up names within your domain. Check the following: — Problem 7, Incorrect Delegation of Subdomain Name Server Problems This section explains the problems that may cause the symptoms listed above, and suggests ways to solve the problems. 1. Incorrect parameters supplied to hosts_to_named.
This asks for the NS records for the root. If no records for root servers are present, it returns Can't find ".": Server failed. • ping hostname Names in the local domain are found, while names in remote domains are not found. — Name server debugging output Set debugging to level 1. Use ping on a host name not in the local domain. The debugging output in /var/tmp/named.run contains the following: No root name servers for class 1. (Class 1 is the IN class.
6. Slave master is unable to load from another master. This may be caused by a configuration error or problems with network connectivity. Verify that the domain being loaded and the address of the remote server are correct in the configuration file. • syslogd An error message is logged indicating the master server for the secondary zone is unreachable. • Name server debugging output Start the slave server at debugging level 2 or 3. Watch for error messages in the debug output.
Set query type to ns (name server). Look up the div.inc.com domain. Non-authoritative answer: div.inc.com nameserver = walleye.div.inc.com div.inc.com nameserver = friday.div.inc.com Name server records for div.inc.com, the delegated subdomain. Authoritative answers can be found from: walleye.div.inc.com friday.div.inc.com inet address = 15.19.13.197 inet address = 15.19.10.74 Address records for the name servers for div.inc.com.
Example 1: No Retransmissions Debug turned ON, Level 1 datagram from 15.19.10.14 port 4258, fd 6, len 35 req: nlookup(john.dept.inc.com) id 1 type=1 req: found ‘john.dept.inc.com’ as ‘inc.com’ (cname=0) forw: forw -> 192.67.67.53 6 (53) nsid=29 id=1 0ms retry 4 sec datagram from 192.67.67.53 port 53, fd 6, len 166 resp: nlookup(john.dept.inc.com) type=1 resp: found ‘john.dept.inc.com’ as ‘inc.com’ (cname=0) resp: forw -> 15.19.11.2 6 (53) nsid=32 id=1 0ms datagram from 15.19.11.
The response was sent back to host 15.19.10.14 on port 4258. Example 2: Retransmissions The next example shows a successful lookup that involves retransmissions. Retransmissions take place from the resolver and the name server. The resolver retransmits to the local name server, and the local name server retransmits to remote name servers during the process of looking up a name.
214 duplicate queries 50109 responses 70 duplicate responses 220220 OK answers 63919 FAIL answers 0 FORMERR answers 23 system queries 4 prime cache calls 4 check_ns calls 0 bad responses dropped 0 martian responses 0 Unknown query types 47921 A queries 2054 CNAME queries 8216 SOA queries 35909 PTR queries 10569 MX queries 424 AXFR queries 179263 ANY queries The first two lines print out the number of seconds that the name server has been running and the number of second
FAIL answers is the number of responses indicating either that the name does not exist or that there is no data of the requested type for this name. FORMERR answers is the number of malformed response packets from other name servers. A message is sent to the syslog daemon listing the sender of the malformed response packet. system queries are queries generated by the name server. These usually occur when the name server detects another name server listed for a domain for which there is no address data.
3 Configuring the BOOTP and TFTP Servers The Bootstrap Protocol (BOOTP) allows certain systems to discover network configuration information (such as an IP address and a subnet mask) and boot information automatically. The Trivial File Transfer Protocol (TFTP) is a simple protocol used to read and write files to or from a remote system. Together, TFTP and BOOTP allow a system to provide boot information for client systems that support BOOTP, such as an HP 700/X terminal.
You are now ready to add client or relay information to the configuration file /etc/bootptab. See “Adding Client or Relay Information” (page 102) for information on adding client or rely information to the /etc/bootptab file. NOTE: HP SMH does not add relay information to the configuration file. You must manually configure relay information on a BOOTP server. Verifying bootpd Installation To verify that you have properly configured bootpd to handle boot requests, perform the following steps: 1.
Collecting Client Information To insert an entry for the client in the /etc/bootptab file, you need to collect the following information about the client: • • • • • • • Host name — the name of the client’s system. Hardware type — the type of network interface. Link level address — the client’s hardware address. IP address — the client’s assigned Internet address. Subnet mask — the mask (IP address) that identifies the network where the client resides.
You can enter the tags in any order, with the following exceptions: • • • The client’s host name must be the first field of an entry. The ht (hardware type) tag, if specified, must precede the ha (hardware address) and hm (hardware mask) tags. If you specify the gw (gateway IP address) tag, you must also specify the sm (subnet mask) tag. Additional points to know when adding an entry in the /etc/bootptab file include the following: • • • IP addresses listed for a single tag must be separated by a space.
Table 3-2 Tags for Defining Relay Options in bootptab Tag Name Description bp List of boot servers to which the client’s bootrequests will be forwarded. The list can contain individual IP addresses, hostnames, or network broadcast addresses. ha Client’s hardware address. hm Mask for the link level address. This value is combined with the ha value to determine a match for a group relay entry. If you specify this tag, you must also specify the ha and ht tags. hp Maximum number of hops for the entry.
The following output is displayed: Received BOOTREPLY from hpserver.hp.com (15.19.8.119) Hardware Address: 08:00:09:03:01:65 Hardware Type: ethernet IP Address: 15.19.8.37 Boot File: /xterminal RFC 1048 Vendor Information: Subnet Mask: 255.255.248.0 Gateway: 15.19.8.1 Domain Name Server: 15.19.8.119 Host Name: term01.hp.com This shows that the BOOTP server responded with information that corresponds to the entry in the /etc/bootptab file. 3. Remove the ba tag entry from the /etc/bootptab file.
The gateway address (gw=15.19.8.1) is passed back to the client in the bootreply and allows the client to send a TFTP request to the BOOTP server to get its boot file. To verify the new /etc/bootptab entry, do the following: 1. Add the ba (broadcast address) tag to the xterm02 entry as follows on the BOOTP server that contains the client’s boot entry (Server B): xterm02: ht=ether: ha=08000902CA00:\ ip=15.19.8.39: sm=255.255.248.0:\ gw=15.19.8.1: ds=15.19.8.
The example indicates that the user tftp has access only to the /home/tftpdir directory on the client system. If you do not specify the user tftp in the /etc/passwd file, tftpd has root access to the files or directories that you specify in the entry for tftp in the/etc/inetd.conf file. If a tftp entry exists in the /etc/passwd file, tftpd cannot read or write files unless they are readable or writeable by the user tftp.
You can specify either the IP address or name of the remote host. To get a file from a directory specified as an argument to the tftpd entry in the /etc/inetd.conf file, you must specify the full path name of the file. If this step fails, see “Troubleshooting BOOTP and TFTP Servers” (page 109). 3.
Helpful Configuration Changes To ease troubleshooting, configure your system as follows: • Ensure that syslogd is configured to log daemon information messages to the file /var/adm/syslog/syslog.log. To check this configuration, make sure that /etc/syslog.conf includes one of the following entries: *.info /var/adm/syslog/syslog.log or daemon.info /var/adm/syslog/syslog.log • Configure bootpd to start with debug logging set to level 2.
□ □ Verify that the server starts using the bootpquery command. Check whether the client is on the same network as the BOOTP server. If the client is not on the same network, ensure that intervening BOOTP servers are configured to relay bootrequest broadcasts. Symptom: The system log file /var/adm/syslog/syslog.
Action: □ □ □ Ensure you have specified the correct IP address for the client in the /etc/bootptab file. Correct the entry and reboot the BOOTP client. If the server must reply directly to the client, it must reside on the same network or subnet as the client. If the client resides on another network, ensure that intervening servers are configured to relay the bootrequests. Ensure that the IP address you have chosen for the client is a valid IP address for the server’s network.
Common tftpd Problems This section discusses the common tftpd problems and possible resolutions. Symptom: A file transfer ‘timed out’ message is displayed. inetd connection logging (enabled with the inetd -l command) does not show any connection to the TFTP server. Cause: The TFTP server, tftpd, did not start. Action: □ □ □ Ensure that the /etc/inetd.conf file contains the appropriate tftp entry. Ensure you have reconfigured inetd with the command inetd -c.
Action: Ensure that the full path name, which the client is requesting from the server, exists within the tftp directory or in a path specified with the tftpd command. For example, if the tftp directory is /home/tftpdir and the TFTP client is requesting the file /usr/lib/X11/700X/C2300A, the file must exist as /home/tftpdir/usr/lib/X11/700X/C2300A. If no entry exists for the user tftp in the /etc/passwd file, you must specify at least one file or directory with the tftpd command.
bootpd is reading or rereading the configuration information from the indicated configuration_file. • read number entries from configuration_file Indicates that bootpd successfully read number configuration entries, including table continuation entries, from the configuration_file. • request from hardware address hardware_address bootpd received a bootrequest from a client with the indicated hardware_address. This message is logged at debug level 1.
Error Log Level When you find any of these error messages, you must correct the indicated configuration entry in the /etc/bootptab file and reboot the BOOTP client. The following errors are logged at the error log level: • bad bootp server address for host hostname A value specified for the bp tag is invalid. Values can be individual IP addresses separated by a space, and an optional one or more network broadcast addresses.
• duplicate hardware address: hardware_address More than one configuration entry is specified for the client with the indicated hardware_address. Ensure that only one configuration entry exists for the hardware address in the /etc/bootptab file. Then, reboot the BOOTP client. • missing ha values for host hostname You must specify the hardware address in hexadecimal notation and the hardware address must precede the ht tag. If you specify the hm tag, you must also specify the ha and ht tags.
4 Configuring DHCP This chaper describes how to configure the Dynamic Host Configuration Protocol (DHCP) servers and troubleshoot potential problems with DHCP servers. It discusses the following topics: • • • “Dynamic Updates to the DHCP Server” (page 119) “Configuring DHCP to Assign and Distribute IP Addresses” (page 120) “Monitoring and Troubleshooting DHCP Operations” (page 124) Dynamic Updates to the DHCP Server DHCP dynamically updates the DNS server with the host name and IP address of the client.
Configuring the DHCP Server to Perform Dynamic Updates To configure the DHCP server to update the DNS server dynamically, add the tag ddns-address to the dhcp_pool_group or the dhcp_device_group keywords. The ddns-address tag specifies the address of the DNS server to which dynamic updates are to be sent. Additionally, you can specify the pcsn tag, if the name sent by the client must be given preference. If you set the pcsn tag, it causes DHCP to accept the host name sent by the DHCP client.
In this example, the presence of the ba tag indicates that the broadcast flag is turned on. Many clients need this flag, therefore it exists in most pool group entries. The pool-name is a label that helps the system administrator identify the pool group. The client is not aware of this name. The beginning and end of the address range in the pool is defined by addr-pool-start-address and addr-pool-last-address. The pool group in this example contains 10 addresses on the 15.13.100 subnet: 15.13.100.
NOTE: It is not very common for the class_id field to be defined. Therefore, most clients are anonymous and are grouped as a pool group. Complex DHCP Pool and Device Group Files Apart from the fields discussed in the previous sections, you can define additional fields for both the pool groups and device groups in the /etc/dhcptab file. Following is an example of a POOL_GROUP file with additional fields defined: DHCP_POOL_GROUP:\ class-name=MEGA_OPTION_GROUP:\ addr-pool-start-address= 192.11.22.
DHCP Configuration through BOOTP Relay Agent In this method, DHCP distributes IP addresses to clients through a BOOTP Relay Agent. A BOOTP Relay Agent is a machine on the local network that forwards boot requests from a DHCP or BOOTP client to a configured DHCP or BOOTP server. Figure 4-4 Relay Agent Scenario Figure 4-4 illustrates a typical scenario of DHCP configuration though a BOOTP relay agent.
Monitoring and Troubleshooting DHCP Operations This section describes techniques and tools that you can use to troubleshoot problems encountered with the DHCP server. Troubleshooting Techniques You can use one of the following techniques for monitoring DHCP: • • • • Syslog with debugging turned on Trace DHCP packets flowing in and out Dump the internal state of the daemon Review the contents of the /etc/dhcpdb file Using Syslog with Debugging Turned On The /var/adm/syslog/syslog.
NOTE: You must always use the ct=NN option, because the default number of packets to trace is zero. The maximum number of packets to trace is 100. Dumping the Internal State of the Daemon You can use the following dhcptools command to dump the internal state of the daemon: # /usr/sbin/dhcptools -d This command dumps dynamic information into the file /tmp/dhcp.dump.other. Other information is dumped into the files /tmp/dhcp.dump.bootptab and /tmp/ dhcp.dump.dhcptab.
NOTE: The dump operation does not kill the daemon. It is not like a core dump. Using the dump operation does not interfere with the bootp daemon. Callbacks DHCP server provides a powerful facility that enables you to customize the DHCP server, known as callbacks. These are user-defined actions that are executed for different types of transactions which can either be a success or a failure.
5 Configuring DHCPv6 This chaper describes how to configure the Dynamic Host Configuration Protocol for the IPv6 (DHCPv6) software. It discusses the following topics: • “Configuring the Server” (page 127) • “Configuring the Client” (page 129) • “Configuring a Relay” (page 134) • “Troubleshooting DHCPv6” (page 134) Configuring the Server This section describes how to configure the DHCPv6 server.
dhcpv6d updates the server database files located in the /etc/dhcpv6db directory. The DHCPv6 server uses these files to build its internal database and to maintain the leases. For more information, type man 1m dhcpv6d at the HP-UX prompt. NOTE: You can use the -k and -r options only if a DHCPv6 server is already running on the system. Server Configuration File You can use the /etc/dhcpv6tab file to configure the DHCPv6 server. dhcpv6d reads the dhcpv6tab file to build its internal database file.
NOTE: You need to complete these steps only once, when you install the DHCPv6 server. Sample dhcpv6tab File You can use the sample dhcpv6tab file, available in the /etc/ directory, as your server configuration file. The sample dhcpv6tab file is as follows: ## # # @(#)dhcpv6tab $Revision: 1.002 $ $Date: 06/02/04 18:49:16 $ # # dhcpv6d reads its configuration information from this file # upon execution. # # See the dhcpv6d(1M) manual page for more information.
is the length of the information, followed by a space. is the data representing the information denoted by the option code, followed by a newline character. The DHCPv6 client uses dhcpv6client.data to build its internal database and to maintain the leases. This file contains information about the IP address leases and other configuration parameters. The dhcpv6clientd Client Daemon dhcpv6clientd is the DHCPv6 client daemon.
$ /sbin/dhcpv6config • If you want the DHCPv6 client daemon to start automatically with the -d and -l arguments upon each reboot, set the DHCPV6CLNTD_ARGS variable in the /etc/rc.config.d/netdaemons file as follows: DHCPV6CLNTD_ARGS=”-d -dns_sa sip_sa -l” For more information on the DHCPv6 client arguments, type man 1m dhcpv6clientd at the HP-UX prompt. NOTE: You need to complete these steps only once, when you install the DHCPv6 client.
-t Gets the temporary IPv6 addresses from the DHCPv6 client daemon. -T Gets both temporary and permanent IPv6 addresses from the client daemon. -I Request only the configuration parameters. Do not get IPv6 addresses. If you do not specify the -t or -T, dhcpv6client_ui obtains only permanent IPv6 addresses.
5. The following message is displayed while the script invokes the dhcpv6client_ui interface: Trying to get address(es) for <>... 6. Finally, the script invokes dhcpv6db2conf, which updates the /etc/rc.confid.d/netconf-ipv6 and /etc/resolv.conf files. The script obtains one IPv6 address for an interface. For example, to obtain an IP address for the lan4 interface, edit the /etc/rc.config.
Configuring a Relay This section describes how to configure a host as a DHCPv6 relay. To configure a host on the DHCPv6 network to function as a relay, set the following tags in the /etc/dhcpv6tab file: • DHCP_RELAY_SETTINGS; This tag indicates the start of the DHCPv6 relay settings. • subnet-prefix This tag specifies the IPv6 subnet prefix in hexadecimal notation in the form address/prefix-length. • prefix-length This tag specifies the prefix length for the IPv6 address in hexadecimal notation.
DHPv6 2.001 Server and Client Recovery When the DHCPv6 server is shutting down, it reads the files in the/etc/dhcpv6db directory to build its internal database and to maintain the client leases. The server deletes the expired leases in the database. When a DHCPv6 client is shutting down, it reads the /etc/dhcpv6client.data file to build its internal database and to maintain the leases.
6 Configuring SLP This chapter describes how to configure and troubleshoot the Service Location Protocol (SLP). You can use the /etc/slp.conf, the default configuration file, to configure the SLP daemon, slpd. The following are some of the agent properties that you can configure on a host through the/etc/slp.
Table 6-2 Static Scope Configuration Properties Property Description net.slp.useScopes A value list of strings that indicates the scopes that a User Agent (UA) or Service Agent (SA) can use to make requests or registrations, or the scopes that a DA must support. In the absence of a DA and SA, or when scope information is not available from DHCP, SLP uses the default scope, DEFAULT.
Table 6-4 Network Configuration Properties Property Description net.slp.isBroadcastOnly A Boolean value that indicates if broadcast is used instead of multicast. This setting is seldom necessary because SLP automatically uses broadcast if multicast is not available. Default is false. net.slp.passiveDADetection A Boolean value that indicates if passive DA detection needs to be used. Default is true. net.slp.multicastTTL A positive integer less than or equal to 255 that represents the multicast TTL.
Table 6-5 UA Configuration Properties Property Description net.slp.locale An RFC 1766 language tag for the language locale. Setting this property causes the property value to become the default locale for SLP messages. Default is en. Additionally, you can use this property to configure the SA and DA. Currently SLP recognizes only en (English language) and ignores any other language tag. net.slp.
Index Symbols @ in BIND data files, 70, 73 A A record, 70, 71, 72, 74, 84 Access Violation message, 114 acl statement, 26 Address record (see A record) ascii option in TFTP, 109 AttrRply message, 58 AttrRqst message, 57 autoconfiguration methods, 47 B ba tag in bootptab file, 104 Berkeley Internet Name Domain (see BIND) bf tag in bootptab file, 103, 104 binary option in TFTP, 109 BIND, 16, 61 advantages, 24 advantages over NIS, 24 caching in, 19 choosing a name server, 65 chroot environment, 61 configurat
for testing BOOTP, 104 bs tag in bootptab file, 104 C cache file in BIND, 67 in slave server, 75 caching in BIND, 19 caching-only server configuring, 77 callbacks, 126 canonical name record, 72, 74 channel messages, 28 severity, 28 chroot environment, 61 CNAME record (see canonical name record) Configuration individual devices, 122 overview, 120 through BOOTP Relay Agents, 123 using HP SMH, 120 configuration BIND, 66 BOOTP, 102 caching-only server, 77 host to query a name server, 79 Name Service Switch, 63
error messages in bootpd, 112 /etc/hosts file, 66, 83 Expire value in SOA record, 71 file transfer timed out, 113 with TFTP, 44, 109 fixed IP addresses, 122 HOSTALIASES variable, 20 hostname fallback, 63 hosts.
BOOTP, 114 in BIND, 85 logging statement, 27 loopback address, 70, 77 lwresd resolver daemon, 21 M mail exchanger record (see MX record) master server configuring, 66 message URL http //www.docs.hp.com/hpux/netcom/index.html#Internet%20Services, 12 minimum ttl value in SOA record, 71 MX record, 74, 89 in BIND, 73 preference field, 73 N .
RFC 2136, 18 RFC 2535, 87 RFC 952, 24 rlogin password requirement after BIND startup, 89 RMP, 42 rndc utility, 21 rndc-confgen utility, 23 syntax, 23 root name server, 19 configuring, 84 round-robin address rotation example, 19 S SAAdvert message, 57 search option in /etc/resolv.
name server, 92 syslog, 124 TFTP, 109 tools, 125 tracing DHCP packet flow, 124 ttl field in BIND data file, 70 U UDP protocol, 47 UDP-based protocol lightweight resolver protocol, 21 user agent configuration property net.slp.locale, 140 net.slp.maxResults, 140 net.slp.typeHint, 140 User Datagram Protocol, 47 user tftp, 111 V /var/run/slpd.
