HP-UX IP Address and Client Management Administrator’s Guide HP-UX 11i v2, HP-UX 11i v3 HP Part Number: 5969-7067 Published: October 2009 Edition: Edition 4
Legal Notices © Copyright 2004–2007 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.................................................................................................................41 The server Statement..................................................................................................................41 The zone Statement....................................................................................................................42 The view Statement..................................................................................
Choosing the Type of Name Server.................................................................................................65 Choosing Master Servers and Slave Servers...................................................................................65 Types of Resource Records..............................................................................................................65 Configuring a Master Name Server...................................................................................
Name Server Debugging............................................................................................................93 Dumping the Name Server Database.........................................................................................94 Problem Symptoms.........................................................................................................................94 Name Server Problems................................................................................................
5 Configuring DHCPv6................................................................................................131 Configuring the Server........................................................................................................................131 The dhcpv6d Server Daemon........................................................................................................131 Invoking dhcpv6d.................................................................................................
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...........................................................................................................45 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.......................................................
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.
HP-UX Release Name and Release Identifier Each HP-UX 11i release has an associated release name and release identifier. The uname(1) command with the -r option returns the release identifier. The following table lists the releases available for HP-UX 11i. Release Identifier Release Name Supported Processor Architecture B.11.11 HP-UX 11i v1 PA-RISC B.11.20 HP-UX 11i v1.5 Intel® Itanium® Processor Family B.11.22 HP-UX 11i v1.6 Intel Itanium Processor Family B.11.23 HP-UX 11i v2.
• HP-UX Mailing Services Administrator’s Guide at: http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services • HP-UX Remote Access Services Administrator’s Guide at: http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services • HP-UX ramD Administrator’s Guide at: http://docs.hp.com/en/netcom.html#Routing • Request for Comments (RFC) at: http://www.ietf.org/rfc.
Include the document title, manufacturing part number, and any comment or error found in this document. Also, include what we did right, so we can incorporate it into other documents.
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 44) “DHCP Overview” (page 46) “DHCPv6 Overview” (page 49) “SLP Overview” (page 54) 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.
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. -y key Identifies the key ID from the configuration file.
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.conf configuration file, run the following command: $ rndc reload This connects to the 127.0.0.1 port 953 and reloads the name server if the name server on the local machine is running with the following controls statement and if the configuration file /etc/named.
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.
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. BIND provides the following utilities to examine the syntax of the configuration file and zone: • named-checkconf The named-checkconf utility verifies the syntax of the configuration file named.conf. However, it does not check for the semantics of the configuration file. named-checkconf returns 0 on success and 1 if it detects errors.
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.
Specifying the Number of Log File Backups You can specify the number of backup versions of a log file by using the version (number | unlimited) option in the logging statement. If you specify version 4, named retains four backup versions of the log file. When you open a file, named retains the backup versions by renaming the original file to a backup file, the backup file to the previous backup file, and so on. For example, if you choose to retain three old versions of the file lame.
• default_stderr Sends messages of severity info and higher to standard error. • null Discards everything it receives. Message Categories You can assign a list of channels to each message category, and send messages to all the channels from each message category. Table 1-3 describes the different types of message categories.
The options Statement The options statement in the /etc/named.conf file controls global server configuration options used in BIND. This statement can appear only once in a configuration file. If more than one occurrence is found, the first occurrence determines the actual options used. Also, a warning is generated if you define more than one options statement. If there is no options statement, an options block with each option set to its default value is used.
[ dual-stack-servers [ port ip_port ] { ( ( domain_name [ port ip_port ] | ip_addr [ port ip_port ] ) ; )... }; ] // Forwarding Options [ forward ( only | first ) ; ] [ forwarders { ( ip_addr [ port ip_port ] ; )...
[ [ [ [ [ [ [ [ [ notify-source-v6 ( ip6_addr | * ) [ port ip_port ] ; ] serial-query-rate number ; ] transfer-format ( one-answer | many-answers ) ; ] transfer-source ( ip4_addr | * ) [ port ip_port ] ; ] transfer-source-v6 ( ip6_addr | * ) [ port ip_port ] ; ] transfers-in number ; ] transfers-out number ; ] transfers-per-ns number ; ] use-alt-transfer-source yes_or_no ; ] }; The following sections explain the various options.
Table 1-5 Boolean Options Option Description auth-nxdomain yes_or_no; If this option is set to yes, the AA bit is always set on NXDOMAIN responses, even though the server is not authoritative. The default value is yes. deallocate-on-exit yes_or_no; If this option is set to yes, the server deallocates all the objects it has allocated and writes a memory usage report to the file specified by the memstatistics-file.
Table 1-5 Boolean Options (continued) Option Description provide-ixfr Determines whether the local server, that is acting as a master, responds with an incremental zone transfer when the remove slave server requests an IXFR. If the provide-ixfr option is set to yes, incremental transfer is provided whenever possible. If this option is set to no, all transfers to the remote server is non-incremental.
Name-Checking Option The server checks the domain names based on their expected client contexts. For example, you can check whether a domain name used as a host name complies with the RFCs that define valid host names: check-names (master | slave | response )(warn | fail | ignore); The server can check names in three areas: • • • master – Checks master zone files. slave – Checks slave zone files. response – Checks the query’s response when the server has initiated the query.
listen-on [port ip_port] {address_match_list}; The listen-on option specifies the interfaces and ports from which the server answers queries. You can specify an optional port and an address_match_list in the listen-on option. The server listens on all interfaces allowed by the address_match_list. If you do not specify a port, port 53 is used. If you do not specify the listen-on option, the server listens on port 53 on all interfaces. You can specify multiple listen-on statements.
Table 1-8 Zone Transfer Options (continued) Option Description transfers-per-ns number; This option specifies the maximum number of inbound zone transfers (named-xfer processes) that run concurrently from a given remote name server. The default value is 2. Increasing the value of transfers-per-ns speeds up the convergence of slave zones. It also increases the load on the remote name server. You can override the transfers-per-ns on a per-server basis by using the transfers option of the server statement.
Table 1-10 Server Resource Limit Options Option Description recursive-clients This option specifies maximum number of simultaneous recursive lookups the server performs on behalf of the clients. The default value is 1000. tcp-clients This option specifies maximum number of simultaneous client TCP connections that the server accepts. The default value is 100. max-cache-size This option specifies maximum amount of memory (in bytes) that a server’s cache can use.
DNSSEC Options Section describes the DNSSEC options in the options statement in the /etc/named.conf file. Table 1-13 DNSSEC Options Option Description dnssec-enable yes_or_no; Enables or disables DNSSEC support. If this option is set to yes, named supports the DNSSEC feature. By default, the DNSSEC feature is not enabled. dnssec-lookaside domain trust-anchor domain; Provides the validation with an alternate method to validate DNSKEY records at the top of a zone.
Table 1-16 Query Address Options Option Description query-source [ address (ip_addr |*)] [port(ip_port|*)] ; Specifies the address and the port used to query other name servers if a server is unable to answer a query. query-source-v6 [ address (ip_addr |*)] [port(ip_port|*)] ; Specifies the address and the port used for queries that are sent over an IPv6 connection.
the public and private keys from files in the working directory. In most cases, the key name must be the server’s host name. • port This option specifies the port number. The sortlist Statement The response to a DNS query consists of multiple resource records forming a resource record set. The name server replies to a query with a resource record set in an indeterminate order.
The zone Statement The zone statement in the /etc/named.conf file defines a zone as a master, slave, stub, or hint. The following are the zone types: • • • • Master – This is the master copy of the data in a zone. Slave – A slave zone is a replica of a master zone. The master list specifies one or more IP addresses that the slave contacts to update its copy of the zone. If you specify a file, the replica is written to the file specified in the slave zone.
The view Statement The view statement enables a name server to answer a DNS query depending on whether the query is internal or external. The view statement is used to implement a split DNS setup without running multiple servers. Each view statement defines a view of the DNS name space that is visible to a subset of clients.
BOOTP and TFTP Overview 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. It allows users to transfer files to and from a remote machine.
• 2. 3. 4. The threshold value ensures that sufficient time is allowed for a bootreply to be received by the client before a subsequent bootrequest for the same client is relayed. It sets the giaddr (gateway IP address) field to 0. If a BOOTP server finds that this field is 0, and the client request is to be relayed, then the BOOTP server fills the giaddr field with its own IP address. The client broadcasts the bootrequest packet on its first LAN interface (lan0).
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. File Transfer The second BOOTP phase, which is the file transfer by the BOOTP client using TFTP, is optional. Some BOOTP clients use BOOTP only for IP address resolution and do not use TFTP. If the boot file is transferred, it must be publicly available.
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. DHCP Clients DHCP server supplies DHCP clients with sufficient information to establish an endpoint for network communications.
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.
5. 6. Before the lease time expires, the DHCP client requests to extend the lease by sending a DHCPREQUEST packet to the server. The server then updates and extends the lease time. It sends a DHCPACK packet to the client to notify that the lease has been extended. These updates and lease extensions continue as long as the client is powered on. If the lease expires and the client is not powered on, and is not able to request an extension on the lease, the IP address is recycled.
DHCPv6 does not require a DHCPv6 server on each link. It works across relays. Ports DHCPv6 uses the following Internet User Datagram Protocol (UDP) ports: • 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.
The client then sends the DHCP REQUEST message to the server, which is able to provide the required configuration parameters. Figure 1-4 depicts how the client and the server, on the same link, communicate with each other. 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 and the server exchange messages with each other via a relay as follows (see numbers 1,2,3,4, and 5 in Figure 1-5): 1. The client sends a DHCP SOLICIT message to the ALL DHCP Agents address to locate servers that are able to offer the required services. 2. The relay forwards the client’s message to servers by sending RELAY-FORW messages. The client message is encapsulated in the RELAY-FORW message. 3. Servers respond to the client’s message by sending a RELAY-RELAY message.
Table 1-18 DHCPv6 Message Types (continued) Message Type Description REPLY A server sends a REPLY message containing assigned addresses and configuration parameters in response to a SOLICIT, REQUEST, RENEW, REBIND message received from a client. A server sends a REPLY message containing configuration parameters in response to an INFORMATION-REQUEST message.
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.
empty. If the client wants to discover all DAs within its multicast radius, it does not include any scope in the service request. DAs are required to reply with their service URLs and the scopes that they support. The response to the service request message, however, is not a service reply, but rather a DA advertisement. The service URL of a DA includes the host name or IP address of the DA as shown in the following examples: service:directory-agent://test.org service:directory-agent://15.10.20.
3. 4. The client queries for a printer service with particular attributes, such as a PostScript printer, including the scope information. The client then connects to the printer with the chosen attribute values within the scope defined and processes the print instruction. Figure 1-8 illustrates this process. Figure 1-8 Protocol Transactions - Schematic Representation SLP Files Table 1-20 describes the files used by SLP.
Table 1-21 Message Types (continued) Message Type Abbreviation Usage DA Advertisement DAAdvert DAs send this message to the SAs and UAs to make them aware of their whereabouts. SA Advertisement SAAdvert SAs send this message to the UAs to make them aware of their whereabouts. Service Acknowledge SrvAck DAs send an acknowledge message to SAs in response to their SrvReg and SrvDeReg messages. Attribute Request AttrRqst UAs send this message to SAs and DAs to request the attributes of a service.
Table 1-22 SLP APIs API Usage SLPReg() Registers a service URL and associated service attributes with SLP. SLPDeReg() Deregisters a registered service. SLPFindSrvs() Finds services based on service type or attributes. SLPFindAddrs() Obtains a list of attributes for services registered with SLP. SLPFindSrvTypes() Obtains a list of the types of services that are registered with SLP. The slpd Daemon The slpd daemon process acts as either a DA or an SA server.
Table 1-23 Startup Options (continued) Option Description [-r registration file] Specifies the file that slpd reads to obtain static registrations. The default registration file is /etc/slp.reg. [-l log file] Specifies the file that receives slpd log messages. The default log file is /var/log/slpd.log. [-p pid file] Specifies the file that holds the slpd process ID. The default pid file is /var/run/slpd.pid. You can use the slpdc script to start, stop, and restart slpdcand also to dump 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. This chapter provides different configuration procedures to configure BIND on your system.
If your organization belongs to several networks, register your domain with only one of them. • If your organization is not connected to a network, you can set up domains without registering them. However, HP recommends that you follow the Internet naming conventions in case you later decide to join a public network. 2. Next, you must decide a name for your domain using the following guidelines: • Use only letters (A-Z), digits (0-9), and hyphens (-) for the domain name.
added benefit of using the forwarding feature is that the forwarding server develops a complete cache of information that all the workstations can use. If you do not want to run a name server on your host, you can configure the resolver to query a name server on another host. By default, the resolver is configured to query the name server on the local host. NOTE: Throughout this document, the terms zone and domain are used interchangeably, though they describe different concepts.
type Specifies an encoded 16-bit value that specifies the resource record type data Specifies the resource data. The format of the data is specific to the type and class of the resource record. Following is a sample resource record: . 3600000 IN NS A.ROOT-SERVERS.NET. Table 2-1 lists the different types of resource records in BIND. Table 2-1 BIND Resource Records Name Description Global Position (GPOS) Specifies the global position. The GPOS record must be superseded by the LOC record.
Configuring a Master Name Server This section explains how to configure a master server in your domain. It also describes the name server data files in the master server configuration. It discusses the following topics: • • • • • • • • • “Creating the Data Files for a Master Server” (page 67) “Setting the Default Domain Name” (page 68) “Master Server Configuration File” (page 68) “Master Server Cache File” (page 70) “The db.127.0.0 File” (page 72) “Master Server db.
• • • conf.cacheonly db.domain (one file for each domain specified with the -d option) db.net (one file for each network number specified with the -n option) Naming these files db.name is an HP convention. You can also create these files manually using a text editor. If you choose to create them manually, you must convert all host names to fully qualified domain names (names containing all the labels from the host to the root, terminated with a dot; for example, indigo.div.inc.com.).
Figure 2-1 shows the structure of a master server and a slave server. In the Figure 2-1, the master server is rabbit.div.inc.com and the slave servers are cheetah.div.inc.com and indigo.div.inc.com. Figure 2-1 Structure of a Master Server and Slave Servers For the setup in Figure 2-1, the /etc/hosts file is as follows: 15.19.8.119 rabbit 127.0.0.1 localhost loopback 15.19.8.64 cheetah 15.19.8.197 indigo incindigo Use the following parameters for the hosts_to_named command to generate the example named.
}; 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. directory Indicates the directory where data files are located. zone Used to define the zone for that domain. type Defines the zone type. file Used to specify the database file for that zone.
; formerly C.PSI.EDU ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.
class The optional class field specifies the protocol group. The protocol group IN, for Internet addresses, is the most common class. If you do not specify this field, the class defaults to the last class specified. All the entries in the example db.cache file are of class IN. type Records of type NS list the name servers. The first field in an NS record is the domain for which the name server has authority. The last field in an NS record is the fully qualified name of the name server.
Serial Indicates the version number of this file, incremented whenever you change the data. Refresh Indicates (in seconds) how often a slave name server must update its data from a master server. Retry Indicates (in seconds) how often a slave server must retry after an attempted refresh fails. Expire Indicates (in seconds) how long the slave name server can use the data before it expires for lack of a refresh.
The /etc/named.conf file denotes that the div.inc.com domain is configured in the db.div file. Therefore, every instance of @ in the db.div file represents div.inc.com. The SOA record specifies the name of the host this data file was created on, an electronic mail address of the name server’s technical contact, and the following values: Serial Indicates the version number of this file, incremented whenever the data is changed.
Master Server db.net Files A master server has one db.net file for each network it serves. net is the network number specified with the -n option in the hosts_to_named command. This file must contain a PTR record for every host in the zone. A PTR record allows BIND to translate an IP address into a host name. BIND resolves the address of a name by tracing down the domain tree and contacting a server for each label of the name. The in-addr.arpa domain is created to allow this inverse mapping. The in-addr.
119.8.19.15.in-addr.arpa. (The current origin is appended to the name 119 in the first field, because it does not end with a dot.) $TTL Indicates (in seconds) the time to live value for records that do not have the ttl value defined in the data field. Adding a Host to the Domain Data Files You can add a host to the /etc/hosts file and run the hosts_to_named command to automatically regenerate all the data files for the domain. You can also manually add the host to all the domain data files.
The advantage of a slave server is that you need to maintain only one set of the DNS database files, and you need not synchronize these data files with other name servers. A slave server can operate in either of the following methods: • • The slave server can store the authoritative data in backup files on its disk. When this type of a slave server reboots, the slave server reads its data from the backup files and does not to rely on loading data from a master server.
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. On the slave server, make the following changes to the configuration file /etc/named.conf, using a text editor: • For every entry in the /etc/named.conf file containing the word primary, except the entry containing db.127.0.0, replace the word primary with the word secondary.
// generated by named-bootconf.pl options { check-names response fail; //do not change this check-names slave warn; directory “/etc/named.data”; //running directory for named /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * questions using port 53, but BIND 8.1 uses an * unprivileged 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.
/usr/bin/hostname indigo.div.inc.com Do not put 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 in the following example: HOSTNAME=indigo.div.inc.com Your default domain is now set. Configuring the Caching-Only Name Server A caching-only name server is a name server not authoritative for any domain except 0.0.127.in-addr.arpa. The only function that a caching-only server performs is to look up data and cache it.
* want to talk to, you might need to uncomment the * query-source directive below. Previous versions of BIND * always asked questions using port 53, but BIND 8.1 uses * an unprivileged 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 “.” { type hint; file “db.cache”; }; 4. If you use an /etc/resolv.conf file on your host, configure the default domain name with the search or domain keyword.
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. search domain_name1, domain_name2, domain_name3, domain_name4, domain_name5, domain_name6 The search option followed by up to six domains separated by spaces or tabs.
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.
The set_resfield() API The syntax for the set_resfield function is as follows: 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.
(that is, if you have created an /etc/resolv.conf file that directs BIND queries to a name server on another host), you need not run the named daemon on your host. Before you start the name server daemon, ensure that syslogd is running. syslogd logs informational and error messages. For information on configuring syslogd, see the HP-UX Internet Services Administrators Guide at the URL http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services. Follow these steps to start the name server daemon: 1.
nslookup must display a list of all the root name servers in the db.cache file. If nslookup does not display the root name servers, see “Troubleshooting the BIND Name Server” (page 92). 6. 7. If you are running syslogd, you can check the error messages in the /var/adm/syslog/syslog.log file. For more information, see “Troubleshooting the BIND Name Server” (page 92). Type exit to exit from nslookup.
For example, div.inc.com contains a host that stores the complete database of employee records, called emp. To put emp in the personnel.div.inc.com domain, add the following records to the db.div.inc.com domain. emp.personnel IN IN A MX 192.253.253.10 emp.personnel.div.inc.com To delegate a subdomain, complete the following steps: 1. 2. Set up the name servers for the subdomain. Edit the existing zone file, db.
Following is an example of the root zone file, db.root. In the example db.root file, hosts rabbit.div.inc.com, denny.dept.inc.com, and sally.doc.inc.com are authoritative name servers for the root domain. Hosts eduardo.inc.com and labs.inc.com are authoritative for the inc.com subdomain. @ IN SOA rabbit.div.inc.com. root.moon.div.inc.com. ( 3 ; Serial 10800 ; Refresh after 3 hours 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.
message if the message’s sender had a cryptographic key shared with the receiver and if the message was not modified after it left the sender. One-Way Hash Function TSIG uses a one-way hash function to provide authentication and data integrity. A one-way hash function, or cryptographic checksum, computes a fixed-size hash value based on an arbitrary large input. Each hash value bit depends on each bit of the input.
zone “div.inc.com” { type master; file “db.div” allow-transfer { key venus-moon.div.inc.com.; }; }; venus.div.inc.com also signs the zone transfer that allows moon.div.inc.com to verify it. For more information on the dnssec-keygen program, type man 1 dnssec-keygen at the HP-UX prompt. 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.
The output of this command is a file named example.com.signedkey, which contains the keys for the domain example.com signed by the com zone’s zone key. Signing the Zone Use the /usr/bin/dnssec-signzone program to sign a zone. A sample directive to invoke the dnssec-signzone to sign the zone example.com follows: # /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.
If the —r option is not included in the command, you must reboot the system manually. During the reboot, the rules are set automatically; you need not enter the setrules command to set the rules. 4. To set the compartment for named, enter the following command at the HP-UX prompt: # setfileexsec –c name /usr/sbin/named This command enables the compartment specified in the /etc/cmpts/named.rules file and starts /usr/sbin/named in that compartment.
If the host name lookup fails, use ping with an IP address to test network connectivity. $ /usr/sbin/ping IP_address The nsquery Command Issue the nsquery command to perform a hosts, passwd, or group lookup, as follows: /usr/contrib/bin/nsquery lookup_typelookup_query 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.
4 This level logs when a master name server uses AXFR because the transferred zone’s journal is not available. 5 This level logs the view used while servicing a particular request. 6 This level logs outbound zone transfer messages, including checks of the query that initiated the transfer. 7 This level logs the journals added and deleted, and a count of the number of bytes returned by a zone transfer.
— — Problem 4, Syntax Errors in /etc/resolv.conf Problem 10, /etc/hosts or NIS contains Incorrect Data • A local name lookup now fails that has completed successfully before. Check the following: — Problem 2, Syntax Errors — Problem 6, Slave Server Unable to Load from Another Slave Server — Problem 4, Syntax Errors in /etc/resolv.conf — Problem 5, Network Connectivity — Problem 10, /etc/hosts or NIS contains Incorrect Data • Names in the local and remote domains are looked up successfully.
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.
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.
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.2 port 53, fd 6, len 119 resp: nlookup(john.dept.inc.com) type=1 resp: forw -> 15.
send_msg -> 15.19.10.14 (UDP 7 4258) id=1 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.
Statistics are appended to the file.
duplicate queries are retransmitted queries for pending lookups that the resolver sends to the name server. The name server detects the duplicate queries and discards them. responses is the number of response packets that the name server receives from queries to other name servers. duplicate responses are response packets from remote name servers for queries that are no longer pending. The name server retransmits queries to remote name servers.
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 104) 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.
xterm01: hn: ht=ether: ha=080009030165: \ ip=15.19.8.37: sm=255.255.248.0: \ gw=15.19.8.1: ds=15.19.8.119: bf=/xterminal: 2. ba Run the bootpquery tool to check how bootpd on your local system responds to a request from xterm01. For the example configuration, you can enter the following (as superuser): /usr/sbin/bootpquery 080009030165 -s hpserver The following output is displayed: Received BOOTREPLY from hpserver.hp.com (15.19.8.
defaults: ht=ether all_hp:\ tc=defaults:\ ha=080009000000:\ hm=FFFFFF000000:\ bp=15.4.3.136 others:\ tc=defaults:\ ha=000000000000:\ hm=000000000000:\ bp=15.4.3.142 The all_hp entry causes bootrequests from HP workstations (machines with hardware addresses that begin with 080009) to be relayed to IP address 15.4.3.136 (Server B). Bootrequests from other hardware addresses (presumed to be machines other than HP machines) are relayed to IP address 15.4.3.142 (Server C).
Configuring the TFTP Server Configuring the TFTP server, tftpd, on your system allows remote clients that support TFTP to access files on your system in a particular location. You can configure tftpd either manually or by using HP SMH. To manually configure tftpd, you must uncomment the tftp entry in the /etc/inetd.conf file. If you do not specify the path options for the tftp entry in the /etc/inetd.conf file, you must create a pseudouser tftp in the /etc/passwd file.
/usr/sbin/inetd -c If you have both an /etc/passwd entry for the user tftp and the files specified in the tftpd entry in the /etc/inetd.conf file, tftpd first looks for a file relative to the user tftp’s home directory. If the file is not found, then tftpd looks for the file relative to the path specified in the tftpd command. If two files with the same name are in both locations, tftpd accesses the file under tftp’s home directory.
Table 3-3 tftp File Transfer Options Option Description ascii Sets the TFTP file transfer type to ASCII. This is the default type. binary Sets the TFTP file transfer type to binary. get remote_file [local_file] Copies remote_file to local_file. If local_file is unspecified, tftpd uses the specified remote_file name as the local_file name. If local_file is specified as “-”, the remote file is copied to standard output.
To view the information that bootpd places in the bootreply, enable a broadcast bootreply by adding the ba tag to the client’s /etc/bootptab entry. Use the bootpquery command to emulate the client’s bootrequest: bootpquery client_link_address -s servername bootpquery prints the reply it receives from the server, which allows you to examine the information supplied to the client. Remove the ba tag from the configuration entry after you have verified that the bootreply is correct.
Cause: The client specified filename as the boot file in its bootrequest, but bootpd could not find the file in the tftp directory. Action: □ □ Make sure that you have configured tftpd with the entry in /etc/passwd for the user tftp. Ensure that the requested file is present in the tftp directory, which is usually the /home/tftpdir directory or in the directory specified with the tftpd command. If not, place the file in the /home/tftpdir directory and reboot the BOOTP client.
vendor magic field is magic_cookie sending RFC1048-style reply Symptom: The client does not receive configuration information for the tags that pertain to RFC 1048 (BOOTP Vendor Information Extensions) vendor information: bs = ds = gw = hn = lg = sm = to = Tnnn boot_file_size domain_nameserver_addresses gateway_addresses hostname log_server_addresses subnet_mask time_offset = generic_information Cause: Many RFC 1048 options are specified for the client’s configuration entry in the /etc/bootptab file.
Symptom: File transfer timed out. The system log contains one of the following messages: User tftp unknown system_call: error Cause: The TFTP server, tftpd, exited prematurely. Action: TFTP may exit due to the following problems: □ □ □ Problem in the network: You can increase the per-packet retransmission and the total retransmission timeouts using the tftpd timeout options -R or -T. For more information, type man 1M tftpd at the HP-UX prompt.
the file the client is reading has read permissions for the user tftp. For example, if the client attempts to read the file xterm, xterm must have the permission 0400 and must be owned by the user tftp.
• vendor magic field is magic_cookie sending CMU-style reply sending RFC1048-style reply Displays the vendor magic cookie in the client’s bootrequest and the corresponding vendor magic cookie used in the bootreply. These messages are logged at debug level 2. • bootptab mtime is time bootpd uses the indicated modification time to determine if the configuration file has been modified and whether the configuration file needs a reread. This message is logged at debug level 3.
• bad IP address for host hostname The formatting for one of the IP addresses listed for the ip tag or any tag requiring a list of IP addresses is incorrect in the configuration file entry for hostname. Correct the configuration entry and reboot the BOOTP client. You must specify the IP address in the standard Internet dot notation. You can use decimal, octal or hexadecimal numbers. Octal numbers begin with 0, and hexadecimal numbers begin with 0x or 0X.
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 121) “Configuring DHCP to Assign and Distribute IP Addresses” (page 122) “Monitoring and Troubleshooting DHCP Operations” (page 126) 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.
ba:\ pool-name=my_first_pool:\ subnet-mask=255.255.255.0:\ addr-pool-start-address= 15.13.100.20\ addr-pool-last-address= 15.13.100.29: where, 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.
DHCP_DEVICE_GROUP:\ class-name=XTERM_GROUP:\ class-id=”Xterminal:”\ subnet-mask=255.255.255.0:\ addr-pool-start-address= 15.13.100.50\ addr-pool-last-address= 15.13.100.59: 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.
DHCP Individual Device Configuration In addition to allowing addresses to be assigned by groups, DHCP allows IP addresses to be individually configured for devices. For administrative or security reasons, you may want certain devices to have fixed addresses. Using HP SMH, you can configure each individual device with the fixed-address device option. You must provide the information about the device, including its own IP address.
Figure 4-4 Relay Agent Scenario Figure 4-4 illustrates a typical scenario of DHCP configuration though a BOOTP relay agent. In Figure 4-4, when client2 broadcasts a boot request and the server containing the booting information belongs to a remote network, the broadcast message is received by the local machine known as the relay agent. The relay agent sends the message across the gateway to the remote server, which in turns sends the boot information for client2 back to the relay agent.
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.log file contains a detailed real-time information of all the operations.
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 131) • “Configuring the Client” (page 134) • “Configuring a Relay” (page 138) • “Troubleshooting DHCPv6” (page 139) 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.
dest-dhcp-server-address = 7ffe:1234::34; ## # DHCP Device specific settings ## DHCP_DEVICE_GROUP;\ vendor-class-id = 1234 "OS = HP-UX B.11.
The dhcpv6clientd Client Daemon dhcpv6clientd is the DHCPv6 client daemon. It sends the DHCP SOLICIT and DHCP REQUEST messages to the DHCPv6 server or servers to select an appropriate server that is able to provide the required services. You need to set the DHCPV6_ENABLE variable in the /etc/rc.config.d/netconf-ipv6 file to a non-zero value to invoke dhcpv6clientd.
NOTE: You need to complete these steps only once, when you install the DHCPv6 client. The dhcpv6client_ui Interface The /usr/bin/dhcpv6client_ui user interface enables you to communicate with the client daemon to obtain IP addresses and other configuration parameters from the server. Figure 5-1 depicts how a client communicates with the DHCPv6 server via dhcpv6client_ui. Figure 5-1 dhcpv6client_ui Interface dhcpv6client_ui helps you do the following: • Obtain only IP addresses from the server.
The options for [-o] to specify various configuration parameters for an interface are as follows: • • • • • • • • dns_sa for DNS server address dns_dl for DNS domain list sip_sa for SIP server address sip_dl for SIP domain list nis_sa for a list of IPv6 addresses of one or more NIS servers available to the client. nis_dl for the NIS domain name of the client. all for all the above options default for all the default options supported by the DHCPv6 client daemon.
dhcpv6clientd updates the /etc/dhcpv6client data file with information obtained from the server. The dhcpv6db2conf Utility /usr/sbin/dhcpv6db2conf is a utility that interprets the contents of the /etc/dhcpv6client.data file into a readable format. You can use dhcpv6db2conf to complete the following tasks: • List the contents of the client database to the screen. • Create a set of configuration-staging files or edit the existing configuration files using the values that the client database contains.
• prefix-length This tag specifies the prefix length for the IPv6 address in hexadecimal notation. • dest-dhcp-server-address This tag specifies the address of the DHCPv6 server that receives the client’s messages forwarded by the relay. See “Sample dhcpv6tab File” (page 133) for more information. Troubleshooting DHCPv6 This chapter describes techniques and files that you can use to troubleshoot the DHCPv6 server and the client.
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.
# should be used. (Default is true) ;net.slp.passiveDADetection = false Sample slp.
Index Symbols @ in BIND data files, 72, 75 A A record, 72, 73, 74, 76, 87 Access Violation message, 116 acl statement, 26 Address record (see A record) ascii option in TFTP, 112 AttrRply message, 60 AttrRqst message, 60 autoconfiguration methods, 49 B ba tag in bootptab file, 106 Berkeley Internet Name Domain (see BIND) bf tag in bootptab file, 105, 106 binary option in TFTP, 112 BIND, 16, 63 advantages, 24 advantages over NIS, 24 caching in, 19 choosing a name server, 65 configuration statements, 26 crea
in bootptab file, 106 C cache file in BIND, 67 in slave server, 77 caching in BIND, 19 caching-only server configuring, 80 callbacks, 129 canonical name record, 74, 76 channel messages, 28 severity, 28 CNAME record (see canonical name record) (see canonical name record) Configuration individual devices, 125 overview, 122 through BOOTP Relay Agents, 125 using HP SMH, 122 configuration BIND, 67 BOOTP, 104 caching-only server, 80 host to query a name server, 82 Name Service Switch, 64 root name server, 87 sla
Expire value in SOA record, 73 file transfer timed out, 115 with TFTP, 46, 111 fixed IP addresses, 125 with BIND, 86 hosts_to_named command, 67, 72, 75, 77, 80 files, 67 HP SMH, 103 hp tag in bootptab file, 107 ht tag in bootptab file, 105, 106, 107 G I gateway address for diskless clients, 106 in bootptab file, 106 in bootrequest, 45 get command in TFTP, 112 gethostbyname routine, 19 giaddr value in bootrequest, 45 gw tag in bootptab file, 106 IA, 52 Identify Associations (see IA) IN class (see Inter
loopback address, 72, 80 lwresd resolver daemon, 21 M mail exchanger record (see MX record) master server configuring, 67 message URL http //www.docs.hp.com/hpux/netcom/index.html#Internet%20Services, 12, 13 minimum ttl value in SOA record, 73 MX record, 76, 92 in BIND, 74 preference field, 74 N .
rlogin password requirement after BIND startup, 92 RMP, 44 rndc utility, 21 rndc-confgen utility, 22 syntax, 23 root name server, 19 configuring, 87 round-robin address rotation example, 19 S SAAdvert message, 60 search option in /etc/resolv.
tools, 128 tracing DHCP packet flow, 127 ttl field in BIND data file, 71 U UDP protocol, 50 UDP-based protocol lightweight resolver protocol, 21 user agent configuration property net.slp.locale, 144 net.slp.maxResults, 144 net.slp.typeHint, 144 User Datagram Protocol, 50 user tftp, 114 V /var/run/slpd.pid file, 59 vendor extension, 115 vendor magic cookie, 115, 119 verbose TFTP option, 112 VUE with BIND, 82 W well known services record, 76 , 74 (see WKS record) WKS record in BIND data file, 74 X X.
