HP-UX IP Address and Client Management Administrator s Guide

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. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additionaly warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. UNIX is a registered trademark of The Open Group. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Copyright Notice Copyright 2004-2007 Hewlett-Packard Development Company L.P Reproduction, adaptation, or translation of this document without prior written permission is prohibited, except as allowed under the copyright laws. Copyright 1979, 1980, 1983, 1985-93 Regents of the University of California This software is based in part on the Fourth Berkeley Software Distribution under license from the Regents of the University of California Copyright 1980, 1984, 1986 Novell, Inc Copyright 1986-1992 Sun Microsystems, Inc Copyright 1985-86, 1988 Massachusetts Institute of Technology Copyright 1989-93 The Open Software Foundation, Inc. Copyright 1986 Digital Equipment Corporation. Copyright 1990 Motorola, Inc. Copyright 1990, 1991, 1992 Cornell University Copyright 1989-1991 The University of Maryland Copyright 1988 Carnegie Mellon University

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...12 Publishing History...12 Document Organization...12 Related Information...12 Typographical Conventions...13 HP Welcomes Your Comments...13 1 Overview...15 BIND Name Service Overview...16 DNS Name Space...16 IPv6 Support...17 DNS Change Notification...17 Dynamic DNS Update...18 Incremental Zone Transfer...18 How BIND Works...19 Round-Robin Address Rotation...19 How BIND Resolves Host Names...20 Lightweight Resolver Library and Daemon...21 The rndc Utility...21 Generating the rndc.conf File...22 Benefits of Using BIND...24 BIND Configuration File...24 The /etc/named.conf Statements...26 The acl Statement...26 The include Statement...26 The key Statement...27 The logging Statement...27 Specifying the Number of Log File Backups...28 Channels and Channel Messages...28 The options Statement...30 Pathname Options...32 Boolean Options...32 Forwarding Options...34 Name-Checking Option...35 Access Control Options...35 Interface Options...35 Zone Transfer Options...36 Resource Limit Options...37 Periodic Task Interval Options...38 Tuning Options...38 DNSSEC Options...39 Server Information Zone Options...39 Bad UDP Port List Options...39 Query Address Options...39 RR Set Ordering Option...40 Dual-Stack Server Option...40 Additional Options...40 Table of Contents 3

The sortlist Statement...41 The server Statement...41 The zone Statement...42 The view Statement...43 BOOTP and TFTP Overview...44 How BOOTP Works...44 Address Determination and Bootfile Selection...44 File Transfer...46 DHCP Overview...46 Benefits of Using DHCP...46 DHCP Components and Concepts...46 DHCP Servers...46 DHCP Clients...47 DHCP Leases...47 DHCP Transactions: Basic Operation...47 DHCPv6 Overview...49 DHCPv6 Components...49 Autoconfiguration...49 Ports...50 Multicast Addresses...50 How DHCPv6 Works...50 Client/Server Operation...50 Identifying and Managing IPv6 Addresses...52 DHCPv6 Features...52 Message Types...52 Multiple IP Address Request...53 Configuration Parameters from a DHCPv6 Server...53 Reconfiguration Messages...53 DHCPv6 Files...53 SLP Overview...54 Salient Features...54 Dynamic Service Tracking...55 Ease of Administration...55 Ease of Development...55 SLP Components...55 User Agent...55 Service Agent...55 Directory Agent...55 UDP and Multicast Ports...55 SLP Architecture...56 SLP Attributes...57 Discovering a Directory Agent...57 How SLP Works...58 SLP Files...59 SLP Messages...59 Assigning Scopes...60 SLP APIs...60 The slpd Daemon...61 Startup Options...61 2 Configuring and Administering the BIND Name Service...63 Creating and Registering a New Domain...63 Configuring the Name Service Switch...64 Choosing Name Servers for Your Domain...64 4 Table of Contents

Choosing the Type of Name Server...65 Choosing Master Servers and Slave Servers...65 Types of Resource Records...65 Configuring a Master Name Server...67 Creating the Data Files for a Master Server...67 Setting the Default Domain Name...68 Master Server Configuration File...68 Master Server Cache File...70 The db.127.0.0 File...72 Master Server db.domain Files...73 Master Server db.net Files...75 Adding a Host to the Domain Data Files...76 Deleting a Host from the Domain Data Files...76 Configuring a Slave Name Server...76 Creating Slave Server Data Files Using hosts_to_named...77 Creating the Slave Server s Data Files Manually...77 Setting the Default Domain Name...79 Configuring the Caching-Only Name Server...80 Configuring the Resolver to Query a Remote Name Server...81 Configuring the Resolver to Set Timeout Values...83 Configuring Timeout Values Using Environment Variables...83 Configuring Timeout Values Using the Configuration File...83 Configuring Timeout Values Using APIs...83 The set_resfield() API...84 The get_resfield() API...84 Sample Program with Timeout Values...84 Starting the Name Server Daemon...84 Verifying the Name Server...85 Updating Network-Related Files...86 Updating /etc/hosts.equiv and $HOME/.rhosts...86 Updating /var/adm/inetd.sec and $HOME/.netrc...86 Updating /etc/hosts...86 Delegating a Subdomain...86 Example of Delegating a Subdomain...87 Configuring a Root Name Server...87 BIND Logging System...88 BIND Security...88 TSIG-Based Security...88 One-Way Hash Function...89 Configuring TSIG...89 Generating Keys...89 Using TSIG...89 DNSSEC A DNS Security Extension...90 Creating a Keyset...90 Signing the Child s Keyset...90 Signing the Zone...91 Configuring Servers...91 Compartmentalizing BIND...91 Enabling Compartments in BIND...91 Disabling Compartments in BIND...92 Troubleshooting the BIND Name Server...92 Troubleshooting Tools and Techniques...92 The ping Command...92 The nsquery Command...93 The syslogd Utility...93 Table of Contents 5

Name Server Debugging...93 Dumping the Name Server Database...94 Problem Symptoms...94 Name Server Problems...95 Understanding Name Server Debugging Output...98 Example 1: No Retransmissions...98 Example 2: Retransmissions...100 Name Server Statistics...100 3 Configuring the BOOTP and TFTP Servers...103 Configuring the BOOTP Server...103 Procedure for Configuring bootpd...103 Verifying bootpd Installation...104 Adding Client or Relay Information...104 Collecting Client Information...105 Collecting Relay Information...105 Understanding Boot File Configurations...105 Parameter Tags and Descriptions...106 Examples of Adding BOOTP Clients...107 Example 1: Adding an HP 700/X Terminal as a Client...107 Example 2: Adding a Relay Entry...108 Configuring the TFTP Server...110 Procedure for Configuring tftpd...110 Verifying the tftpd Installation...111 Command Options for Using TFTP...111 Troubleshooting BOOTP and TFTP Servers...112 Helpful Configuration Changes...112 Common bootpd Problems...112 Common tftpd Problems...115 Error Logging...117 Information Log Level...117 Notice Log Level...118 Error Log Level...118 4 Configuring DHCP...121 Dynamic Updates to the DHCP Server...121 Dynamic DNS Server Update Pre-Requisites...121 Configuring the DHCP Server to Perform Dynamic Updates...122 Configuring DHCP to Assign and Distribute IP Addresses...122 DHCP Device and Pool Group Configuration...122 Pool Groups...122 DHCP Device Group...123 Complex DHCP Pool and Device Group Files...124 DHCP Individual Device Configuration...125 DHCP Configuration through BOOTP Relay Agent...125 Configuring PING Timeouts...126 Monitoring and Troubleshooting DHCP Operations...126 Troubleshooting Techniques...127 Using Syslog with Debugging Turned On...127 Tracing DHCP Packet Flow...127 Dumping the Internal State of the Daemon...128 DHCP Troubleshooting Tools...128 Callbacks...129 6 Table of Contents

5 Configuring DHCPv6...131 Configuring the Server...131 The dhcpv6d Server Daemon...131 Invoking dhcpv6d...131 Server Configuration File...132 Setting Up the DHCPv6 Server...132 Sample dhcpv6tab File...133 Configuring the Client...134 The dhcpv6client.data File...134 The dhcpv6clientd Client Daemon...135 Invoking dhcpv6clientd...135 Setting Up the DHCPv6 Client...135 The dhcpv6client_ui Interface...136 The dhcpv6config Script...137 The dhcpv6db2conf Utility...138 Configuring a Relay...138 Troubleshooting DHCPv6...139 The syslog.log File...139 Error Messages...139 DHPv6 2.001 Server and Client Recovery...139 6 Configuring SLP...141 Directory Agent Configuration Properties...141 Static Scope Configuration Properties...141 Tracing and Logging Configuration Properties...142 Network Configuration Properties...142 Service Agent Configuration Properties...143 User Agent Configuration Properties...143 Static Registration...144 Sample slp.conf File...144 Index...147 Table of Contents 7

List of Figures 1-1 Structure of the DNS Name Space...16 1-2 Bootrequest Relay Example...45 1-3 DHCP Client and Server Transaction...48 1-4 When Client and Server Are on the Same Link...51 1-5 When Client and Server Are on Different Links...51 1-6 SLP Architecture...57 1-7 Active and Passive DA Discovery...58 1-8 Protocol Transactions - Schematic Representation...59 2-1 Structure of a Master Server and Slave Servers...69 3-1 Example Configuration: HP 700/X Terminal as Client...107 3-2 Example Configuration: Relay Entry...108 4-1 DHCP Server and DNS Server running on HP-UX...121 4-2 Devices Configured in a DHCP Group...123 4-3 DHCP Devices Can Have Fixed IP Addresses...125 4-4 Relay Agent Scenario...126 4-5 Callback Script Example...129 5-1 dhcpv6client_ui Interface...136 8 List of Figures

List of Tables 1-1 rndc Commands...22 1-2 Advantages of Using BIND over Other Name Services...24 1-3 Channel Message Categories...29 1-4 Pathname Options...32 1-5 Boolean Options...33 1-6 Forwarding Options...34 1-7 Access Control Options...35 1-8 Zone Transfer Options...36 1-9 Resource Limit Options...37 1-10 Server Resource Limit Options...38 1-11 Periodic Task Interval Options...38 1-12 Tuning Options...38 1-13 DNSSEC Options...39 1-14 Server Information Zone Options...39 1-15 Bad UDP Port List Options...39 1-16 Query Address Options...40 1-17 DHCPv6 Components...49 1-18 DHCPv6 Message Types...52 1-19 DHCPv6 Files...54 1-20 SLP Files...59 1-21 Message Types...59 1-22 SLP APIs...61 1-23 Startup Options...61 1-24 slpdc Commands...62 2-1 BIND Resource Records...66 2-2 The /etc/resolv.conf Options...82 3-1 Tags for Defining Client Options in the /etc/bootptab File...106 3-2 Tags for Defining Relay Options in bootptab...107 3-3 tftp File Transfer Options...112 4-1 Common Errors Found in Syslog...127 5-1 dhcpv6d Error Messages...139 6-1 DA Configuration Properties...141 6-2 Static Scope Configuration Properties...142 6-3 Tracing and Logging Properties...142 6-4 Network Configuration Properties...143 6-5 UA Configuration Properties...144 9

10

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. New and Changed Information in This Edition Following are the new and changed information in this document: Updated the following sections: The rndc Utility (page 21) Message Categories (page 29) Pathname Options (page 32) Boolean Options (page 32) Zone Transfer Options (page 36) Pool Groups (page 122) DHCPv6 Overview (page 49) Added the following sections: IPv6 Support (page 17) DNSSEC Options (page 39) Server Information Zone Options (page 39) Bad UDP Port List Options (page 39) Query Address Options (page 39) Query Address Options (page 39) RR Set Ordering Option (page 40) Dual-Stack Server Option (page 40) Types of Resource Records (page 65) Compartmentalizing BIND (page 91) Intended Audience This manual is intended for system and network administrators responsible for configuring and maintaining the Internet Services software on the HP-UX 11i v2 or HP-UX 11i v3 operating system. Administrators are expected to have knowledge of operating system concepts, commands, and the various routing protocols. It is also helpful to have knowledge of Transmission Control Protocol/Internet Protocol (TCP/IP) networking concepts and network configuration. This manual is not a TCP/IP tutorial. New and Changed Information in This Edition 11

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 B.11.11 B.11.20 B.11.22 B.11.23 B.11.31 Release Name HP-UX 11i v1 HP-UX 11i v1.5 HP-UX 11i v1.6 HP-UX 11i v2.0 HP-UX 11i v3 Supported Processor Architecture PA-RISC Intel Itanium Processor Family Intel Itanium Processor Family Intel Itanium Processor Family PA-RISC Intel Itanium Processor Family PA-RISC Publishing History The following table lists the publishing details of this document for various HP-UX releases. Document Manufacturing Part Number B2355-90776 5991-0707 B2355-91064 Operating System Supported 11i v2 11i v1, 11i v2 11i v2, 11i v3 Publication Date September 2004 February 2005 February 2007 Document Organization The HP-UX Mailing Services Administrator s Guide is organized as follows: Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Related Information 12 Overview Provides an overview of the IP address and client management implementations. Configuring and Administering the BIND Name Service Describes how to configure the master server, slave server, and caching-only server. This chapter also describes the steps involved in configuring the BIND name service and provides certain troubleshooting measures. Configuring the BOOTP and TFTP Servers Describes how to configure the BOOTP and TFTP servers. This chapter also describes how BOOTP works and provides certain troubleshooting measures. Configuring DHCPv6 Describes the steps to configure the DHCP server, client, and relay for the IPv6 software. Configuring SLP Describes how to configure the Directory Agent, the Service Agent, and the User Agent, the three major SLP components. For more information about the Internet Services suite of products, see the following documents: HP-UX Internet Services Administrator s Guide at: http://www.docs.hp.com/hpux/netcom/index.html#internet%20services HP-UX Routing Services Administrator s Guide at: http://www.docs.hp.com/hpux/netcom/index.html#internet%20services

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.html Other Documents For detailed technical and conceptual information about BIND, as well as information about planning a BIND hierarchy and using Sendmail with BIND, HP recommends that you read Paul Albitz and Cricket Liu, 2001. DNS and BIND. O'Reilly and Associates, Inc. The O'Reilly books are available at: http://www.ora.com Typographical Conventions This document uses the following typographic conventions: 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 ComputerOut Command The title of a book. On the web and on the Instant Information CD, it may be a link to the book itself. Text displayed by the computer. A command name or qualified command phrase, daemon, file, or option name. $ The system prompt for the Bourne, Korn, and POSIX shells. # The superuser prompt. daemon Variable Courier font type indicates daemons, files, commands, manpages, and option names. The name of a variable that you may replace in a command or function or information in a display that represents several possible values. [ ] The contents are optional in formats and command descriptions. If the contents are a list separated by, you can choose one of the items. {} The contents are required in formats and command description. If the contents are a list separated by, you must choose one of the items. (Ctrl+A) Bold This symbol indicates that you hold down the first named key while pressing the key or mouse button that follows the plus. The defined use of an important word or phrase.... The preceding element can be repeated an arbitrary number of times. Separates items in a list of choices. HP Welcomes Your Comments HP welcomes your comments concerning this document. We are committed to providing documentation that meets your needs. Send your comments or suggestions to: netinfo_feedback@cup.hp.com Typographical Conventions 13

14 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. Now, due to an explosive growth in the networks, assigning and maintaining new IP addresses and resolving domain names to IP addresses have become difficult and cumbersome tasks. An effective solution to this problem is the Domain Name System (DNS), a distributed database that implements the machine name hierarchy for TCP/IP-based networks. DNS defines the rules for name syntax in a hierarchical name space and for delegation of authority over names. A name server is a server program that maps domain names to IP addresses. A set of DNS name servers operating at multiple sites co-operatively solve the domain name to IP address mapping problem and provide other information.every time you use a domain name, a DNS service translates the name into the corresponding IP address. For example, the domain name www.sample.com translates to 188.135.212.3.The Berkeley Internet Name Domain server (BIND) is a commonly used DNS implementation. The client software, called a name resolver, uses one or more name servers when translating a name.at its current rate of development, the present system, which can support 4 billion addresses, might run out of space in a few years. Researchers claim that switchover to IPv6, which has a huge address space, is the optimal solution to the overcrowded system. To overcome this problem, the Dynamic Host Configuration Protocol (DHCP) is used to assign IP address dynamically. DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP, based on the Bootstrap Protocol (BOOTP), adds the capability of automatic allocation of reusable network addresses and additional configuration options. DHCPv6 supports IPv6, the next-generation Internet protocol, and enables DHCP servers to pass configuration parameters using extensions of IPv6 nodes.client management involves identifying services on the network. To locate services on the network, users of network applications are required to supply the host name or network address of the machine that provides the desired service. The Service Location Protocol (SLP) eliminates the need for users to know the description of the service offered by the network. With SLP, a user only needs to know the description of the service required. Based on this description, SLP returns the desired service.the IP address management implementations in the HP-UX 11i v2 and HP-UX 11i v3 operating systems are as follows: BIND BOOTP and TFTP DHCPv6 SLP is the client management implementation in the HP-UX 11i v2 and HP-UX 11i v3 operating systems. A detailed description of the IP address and client management implementations is provided in this manual. NOTE: System Administration Manager (SAM) is deprecated in HP-UX 11i v3. HP System Management Homepage (HP SMH) is the system administration tool for managing HP-UX. HP SMH provides systems management functionality, at-a-glance monitoring of system component health and consolidated log viewing. HP SMH provides Graphical User Interface (GUI), Text User Interface (TUI), and Command Line Interface (CLI) for managing HP-UX. You can access these interfaces using the /usr/sbin/smh command. When you run either the /usr/sbin/sam or /usr/sbin/smh command and the DISPLAY environment variable is set, HP SMH opens in the default web browser. If the DISPLAY environment variable is not set, HP SMH opens using its terminal interface. This chapter contains information about the following topics: 15

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. It also facilitates Internet mail routing by supplying a list of hosts that accept mail for other hosts. This section describes the BIND features and components and how they work. It contains the following topics: DNS Name Space (page 16) How BIND Works (page 19) How BIND Resolves Host Names (page 20) Benefits of Using BIND (page 24) BIND Configuration File (page 24) DNS Name Space The DNS name space is a hierarchical organization of all the hosts on the Internet. It is a tree structure, similar to the structure of UNIX directories. The root of the hierarchy is represented by a dot (.). Under the root, the top-level Internet domains com (commercial businesses), edu (educational institutions), gov (government agencies), mil (military and defense), net (network-related organizations), and org (other organizations) are included. Under each top-level domain are subdomains. For example, the edu domain has subdomains like purdue, ukans, and berkeley. In turn, each subdomain contains other subdomains. For example, the purdue subdomain can contain econ, cs, and biol subdomains. At the deepest level of hierarchy are the hosts, which are the leaves of the name space. A fully qualified host name begins with the host s canonical name and continues with a list of the subdomains in the path from the host to the root of the name space. For example, the fully qualified host name of the host arthur in the cs domain at Purdue University is arthur.cs.purdue.edu. Figure 1-1 shows the hierarchical structure of the DNS name space. Figure 1-1 Structure of the DNS Name Space 16 Overview

IPv6 Support 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. The current support for the storage of Internet addresses in DNS is not easily extended to support IPv6 addresses because most of the applications still assume that address queries return 32-bit IPv4 addresses only. To support the storage of IPv6 addresses, BIND contains many types of resource records such as AAAA. BIND also uses the ip6.arpa domain to support lookups based on IPv6 address, instead of the ip6.int domain. However, BIND continues to support the ip6.int domain for backward compatibility. BIND also uses the ip6.arpa domain for storing IPv6 addresses in the DNS. The existing queries that perform additional section processing to locate IPv4 addresses are redefined to perform additional section processing on both IPv4 and IPv6 addresses. The existing support for IPv4 addresses is retained. The ip6.arpa domain is a special domain defined to look up a record given an IPv6 address. This domain provides a method to map an IPv6 address to a host name. An IPv6 address is represented as a name in the ip6.arpa domain by a sequence of nibbles separated by dots with the suffix.ip6.arpa. The sequence of nibbles is encoded in reverse order wherein the low-order nibble is encoded first, followed by the next low-order nibble and so on. Each nibble is represented by a hexadecimal digit. For example, consider the following IPv6 address: 4321:0:1:2:3:4:567:89ab Following is the reverse lookup domain name in the ip6.arpa domain: b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3. 4.ip6.arpa. DNS Change Notification BIND supports DNS change notification, also known as DNS Notify, which allows master servers to inform slave servers that new information is available. In the original DNS protocol, slave servers (secondaries) polled the master server at an interval of time as defined in the Start of Authority (SOA) record. At these defined intervals, the slave checked the SOA record on the master server to find out if the serial number has changed. If it detected a change, the slave initiated a zone transfer. The disadvantage of this approach is that slaves do not receive new information in the interim period. The DNS Notify operation provides a method for the master server to notify slave servers that a zone transfer is necessary. DNS Notify uses a new DNS opcode. The notification is sent to all the hosts listed as name servers in the name server(ns) records for the zone. Additionally, BIND allows you list additional servers to accommodate stealth servers, which are not listed in any name server records. You can use the zone statement to list these additional servers in the configuration file, /etc/named.conf. When a slave server receives the notify packet, it sends an acknowledgment. It then behaves as if its refresh timer for that zone has expired, undergoing the same process used during expiration time (that is, first retrieving the SOA record from the master, then initiating a zone transfer if the record has changed). The DNS Notify feature is enabled in the master server by default. In some environments, the master server in a zone may be an 8.1.2 or later server with DNS Notify enabled, while the other servers in the zone are 4.x servers (without the DNS Notify feature). In such environments, BIND Name Service Overview 17

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. You can enable dynamic update on a zone-by-zone basis by including an allow-update or update-policy clause in the zone statement. Using this feature, you can add or remove resource records from a zone without manually editing the zone file. Do not edit the zone files manually because the zone files on the disk at any given time may not contain the latest changes performed by other dynamic updates. A single update request can contain requests to add or remove more than one resource record. You can use the nsupdate utility to submit dynamic DNS update requests to a name server. For more information on using this tool, type man 1 nsupdate at the command prompt. Incremental Zone Transfer The Incremental Zone Transfer Protocol (IXFR) is a mechanism for slave servers to transfer only the changed data, instead of transferring the entire zone data every time the zone data changes. This is defined in RFC 1995. During a dynamic update and the NOTIFY announcement, the zones are updated according to the changes in the network, and these changes are immediately propagated to all the authoritative name servers for the zones. Each time the master server receives an update that increments the zone s serial number, the master server sends a NOTIFY announcement to its slaves. And each time the slaves receive NOTIFY announcements, they check the serial number of the zone on their master server and transfer the zone. If the zone is large, the transfer can take a considerable amount of time, within which another update may arrive. As a result, the slave servers transfer the zone contents continuously, and the name servers spend more time transferring the entire zone even when the change to the zone is minor. Incremental zone transfer solves this problem by allowing slave name servers to inform their master servers about the version of a zone they currently hold, and to request just the changes to the zone between that version and the current version. This reduces the size and duration of a zone transfer. While acting as a master, BIND supports IXFR for the zones where the change history information is available. These include master zones maintained by dynamic updates and slave zones whose data was obtained by IXFR. BIND does not support incremental zone transfer for master zones maintained manually, or for slave zones obtained by an AXFR (the type of query that initiates a full zone transfer). When acting as a slave, BIND attempts to use IXFR unless incremental zone transfer is explicitly disabled. The option statements used to enable and disable IXFR are: [provide-ixfr yes_or_no;] [request-ixfr yes_or_no;] You can set these options manually in the /etc/named.conf configuration file to yes or no to enable or disable the incremental zone transfer. The provide-ixfr clause determines whether the local server, acting as a master, responds with an incremental zone transfer when the given remote server (a slave) requests a zone transfer. If set to yes, incremental transfer is provided whenever possible. If set to no, all transfers to the remote server are non-incremental. If this clause is not set, the value of the provide-ixfr option in the global options block is used as the default. 18 Overview

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. How BIND Works This section describes how the name server resolves host names. Consider the structure of the DNS name space illustrated in Figure 1-1. When a user logged in to host venus in the nmt.edu domain types the following command, telnet indigo.div.inc.com the following events occur: 1. The telnet process calls the gethostbyname routine to obtain the Internet address of indigo.div.inc.com. 2. The gethostbyname routine invokes the BIND resolver, which consists of a set of routines for querying name servers. 3. The resolver constructs a query and sends it to a name server. If the local host is not running a name server, the local host must contain a file called /etc/resolv.conf, which contains one or more Internet addresses for name servers that serve the local domain. If the local host does not have an /etc/resolv.conf file, the resolver sends the query to the local name server. 4. The name server daemon, named, receives the query from the resolver. Because the name server has information about only the hosts in its local domain (nmt.edu), it cannot answer the query with the information in its local database. 5. The local name server queries a root name server to find the address of indigo.div.inc.com. The root name server serves the root domain. It typically stores information about hosts and name servers one and two levels below the root. 6. If the root name server cannot resolve the host name, it returns the address of a name server for the inc.com domain. 7. The local name server queries the server for the inc.com domain to find the address of indigo.div.inc.com. 8. The name server for the inc.com domain may not contain information for the div.inc.com domain. If so, it returns the address of a name server for the div.inc.com domain. 9. The local name server queries the server for the div.inc.com domain to find the address of indigo.div.inc.com. 10. The server for the div.inc.com domain returns the address of indigo.div.inc.com to the local name server. 11. The local name server passes host indigo s address to the resolver, which passes it to gethostbyname, which returns it to the telnet process. The local name server in the nmt.edu domain caches the addresses of the remote name servers, so that the next time a local user needs the address of a host in the inc.com domain, the local name server sends its query directly to the name server for inc.com instead of querying the root name server. Round-Robin Address Rotation Round-robin address rotation provides an inexpensive load-balancing solution.you can map a virtual host name to the addresses of multiple systems. When the name server supplies address information for a virtual host name, it rotates the returned order of the addresses. This provides a mechanism for load-balancing network traffic to each host. For example, the virtual host name rainbow is created for three systems named red, blue, and green. The host name rainbow maps to the IP addresses of red, blue, and green. When BIND Name Service Overview 19

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). However, if a multi-homed host belongs to multiple subnets, the address records are sorted by the resolver to favor the addresses to which the querying host is directly connected, or those that correspond to the networks in the querying host s sort list (specified in /etc/named.conf). For multi-homed hosts with multiple interfaces attached to the same subnet, load sharing is not done for outbound traffic. The transport software selects an interface for outbound traffic according to the target IP address and uses that interface consistently, regardless of the interfaces on which it receives inbound traffic from the target IP address. Round-robin address cycling is enabled by default. To disable this feature, you can add the following entry to the /etc/named.conf file: options no-round-robin. How BIND Resolves Host Names This section describes the steps BIND undertakes to resolve the host name. BIND allows you to enter host names that are not fully qualified (that is, host names that do not contain every label from the host to the root and end with a dot), because typing complete domain names is cumbersome. NOTE: It is always correct to use a name that contains all the labels from the host to the root and does not end with a dot. Names that end in a dot are not allowed in the following places: mail addresses, the hostname command, and network-related configuration files. You can use names that contain all the name components and end with a dot in commands like nslookup, ping, and telnet, to facilitate the lookup process. To resolve a host name, BIND uses the following methods: If the input host name ends with a dot, BIND looks it up as is, without appending any domains to the host name. If the input host name contains the number of dots specified by the ndots option in the /etc/resolv.conf file, BIND looks it up as is, before appending any domains to the host name. (The default value of ndots is 1; therefore, if the input host name contains one dot, it is looked up as is before any domains are appended to it.) If the input host name contains a single component (that is, host name without any dots), and you have set up a host aliases file, BIND looks in your aliases file to translate the alias to a fully qualified host name. You can create a host aliases file for frequently used host names, as shown in the following example file, myaliases: john melody zircon.chem.purdue.edu fermata.music.purdue.edu The alias (the first field on each line) must be a single word, without any dots. john is an alias name for zircon.chem.purdue.edu. To use the file, set the HOSTALIASES environment variable to the name of the file, as in the following example: 20 Overview

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.edu div.inc.com inc.com" the LOCALDOMAIN variable overrides the hostname and any search or domain option in the /etc/resolv.conf file, for BIND requests within the context of your shell environment. The input host name is looked up in each of the domains in the variable, in the order they are listed. If you set the local hostname to a fully qualified domain name, and you do not specify the search and domain options in the /etc/resolv.conf file, the input host name is looked up in the domain configured in the fully qualified hostname. The search option specifies a list of domains to search. Following is an example of a search option in the /etc/resolv.conf file: search div.inc.com inc.com You can set the search option to any list of domains, but the first domain in the list must be the domain of the local host. BIND looks up the host names in each domain, in the order they are listed in the search option. BIND uses the search option only when you do not set the LOCALDOMAIN variable. The domain option specifies the local domain. If you use the domain option, BIND searches only the specified domain to resolve the host names. BIND uses the domain option for host name lookups only if you do not set the LOCALDOMAIN variable and if you do not specify the search option. If you use both the domain and search options in the /etc/resolv.conf file, only the option that appears last is used and the previous option is ignored. Therefore, do not use both the options domain and search in the /etc/resolv.conf file. For more information on how BIND resolves host names, type man 5 hostname or man 4 resolver at the HP-UX prompt. Lightweight Resolver Library and Daemon The rndc Utility BIND provides resolution services to local clients by using a combination of a lightweight resolver library and a resolver daemon process running on the local host. These resolution services communicate using a simple UDP-based protocol called the lightweight resolver protocol, which is different from and simpler than the full DNS protocol. The applications that require address-to-name lookups are linked with a stub resolver library that sends recursive DNS queries to a local caching name server. To use the lightweight resolver interface, the system must run the resolver daemon lwresd. For more information, type man 1m lwresd at the command prompt. The remote name daemon control (rndc) utility enables you to control the operation of a name server. The rndc utility is of the following format: BIND Name Service Overview 21

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. command Table 1-1 rndc Commands Table 1-1 describes the rndc commands. Command reload reload zone [class [view]] refresh zone [class [view]] retransfer zone [class [view] freeze zone [class [view]] thaw zone [class [view]] stats querylog dumpdb stop halt reconfig trace trace level notrace flush flush [view] status Description Reload configuration file and zones. Reload the given zone. Schedule maintenance for the given zone. Retransfer the given zone from the master name server Suspend updates to a dynamic zone. This command enables manual edits to a zone that is usually updated dynamically. It also modifies the journal file to be synchronized with the master and the journal file to be removed. All dynamic update attempts are denied permission if the zone is frozen. Enable updates to a frozen dynamic zone. This causes the server to reload the zone from the disk. Dynamic updates are re-enabled after the load is complete. Write server statistics to the statistics file. Toggle query logging. Dump the current contents of the cache into the file specified by the dump-file option in the named.conf file. Stop the server after saving recent changes to the master files of the updated zones. Stop the server immediately without saving recent changes to the master files. Reload only the configuration file and new zones. Increment the debugging level by 1. Change the debugging level. Set the debugging level to 0. Flush all the server s caches. Flush the server s cache for a particular view. Display the status of the server. For more information, type man 1 rndc at the HP-UX prompt. 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. 22 Overview

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.conf has a key statement for rndckey similar to the key statement in the /etc/rndc.conffile: controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { rndckey; }; }; For more information, type man 4 rndc.conf at the HP-UX prompt. You can also run rndc-confgen with the -a option to set up a rndc.key file to avoid the need for a rndc.conf file and a control statement. The syntax for rndc-confgen is as follows: rndc-confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address] [-t chrootdir] [-u user] -a Configures rndc automatically. This option creates the file rndc.key in the /etc directory, which is read by both rndc and named upon startup. -b keysize Specifies the size of the authentication key (in bits). The value ranges from 1 512 and the default value is 128 bits. -c keysize Used with the -a option to specify an alternate location for the rndc.key file. -h Prints a short summary of the options and arguments to the rndc-confgen utility. -k keyname Specifies the key name of the rndc authentication key. The default value is rndc-key. -p port Specifies the command channel port where named listens for connections from rndc. The default value is 953. -r random file Specifies a source file of random data for generating authorization. The default value is the keyboard input. -s address Specifies the IP address where named listens for command channel connections from rndc. The default value is the loopback address 127.0.0.1. -t chrootdir Used with the -a option to specify a directory where named runs chroot. An additional copy of the rndc.key file is written relative to this directory for the chrooted named to identify the rndc.key file. -u user Used with the -a option to set the owner of the generated rndc.key file. If you specify the -t option along with the -u option, the owner of the file in the chroot area is changed. For more information, type man 1 rndc-confgen at the command prompt. BIND Name Service Overview 23

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 domain. In your local domain, you need to configure only the hosts in your own domain and the addresses of name servers in other domains. When your name server fails to resolve a host name from its local database, it can contact these other name servers to resolve the host names. If you use the /etc/hosts file or the NIS hosts database to resolve host name, you must explicitly configure every host you might need to contact. You can store all the host information on one host. You can configure only one machine as a name server, and all other machines query the name server. Information must be up-to-date on only one host instead of many. You can contact almost any host on the Internet. Because BIND spans network boundaries, you can locate almost any host on the network by starting at the root server and working down. If you use the /etc/hosts file for host name resolution, you must keep an up-to-date copy of the file on every host in your domain. If you use NIS, you must ensure that your NIS slave servers receive regular updates from the master server. A NIS server can serve only the hosts on its local LAN. NIS clients send out broadcasts to locate and bind to NIS servers, and broadcasts do not cross network boundaries. Each NIS server is able to answer all the host name queries from the hosts on its local LAN. Because the /etc/hosts file contains only a few host names, it is nearly impossible to contact every host on the Internet. BIND is used mostly for host information, and NIS is used for other configuration information, like the passwd and group databases. The only advantage that NIS has over BIND is that NIS can easily manage many different types of information otherwise must be maintained separately on each host. However, NIS does not easily span networks, so the hosts in an NIS domain do not have access to information on other domains. BIND Configuration File The BIND configuration file, /etc/named.conf, enables you to specify a number of different features using statements and comments. Each statement in the configuration file ends with a semicolon. Many statements contain a block of substatements, which also end with a semicolon. You can give comments using the C syntax (with /* and */), the C++ syntax (where // starts the comment), and the shell syntax (where # starts the comment). IMPORTANT: A detailed understanding of the BIND configuration file statements discussed in this section is a prerequisite for configuring the master, slave or caching-only server. The utility hosts_to_named runs the named-bootconf.pl Perl script to generate the master and slave servers configuration files using the /etc/hosts file as input. The named-bootconf.pl script sets the check-names directives by default in the options statement to enforce proper handling of non-standard host names that do not comply with RFC 952 (DoD Internet host table specification), for example, names with underscore _ characters and other non-alphanumeric characters. To generate the configuration file for the domain div.inc.com and network 15.19.8, issue the following command: # hosts_to_named -d div.inc.com -n 15.19.8 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 67) 24 Overview

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 syntax for named-checkconf is as follows: /usr/sbin/named-checkconf [-v] [-t directory] [filename] -t directory Specifies named to change directory to directory to process the include directives in the configuration file, similar to a chrooted named. -v Prints the version number of the named-checkconf utility before exit. filename Specifies the configuration file to be checked. The default file name is /etc/named.conf. -z Performs a check load on the master zone files in the /etc/named.conf file. -j Reads the journal while loading a zone file. named-checkzone The named-checkzone utility performs syntax and consistency checks on the zone contents. named-checkzone returns 0 on success and 1 if it detects errors. The syntax for named-checkzone is as follows: /usr/sbin/named-checkzone [-dq] [-c class] zone [filename] -d Enables debugging. -q Enables quiet mode only for the exit code. j Reads the journal while loading a zone file. k Performs check-name checks with the specified failure mode. The values for the failure modes are fail, warn (default), and ignore. The default value is warn. n mode Specifies if the name server (NS) records must be checked to verify whether they are addresses. The values for this option are fail, warn, and ignore. The default value is warn. o filename Writes the zone output to the directory. -t directory Specifies the directory under which the named-checkzone command is chrooted. The include directives in the configuration file are also processed as if they are run by a similar chrooted named. w directory Specifies named to change to directory so that relative filenames in the master file $INCLUDE directives are functional. This option is similar to the directory clause in the /etc/named.conf file. -D Specifies the dump zone file in the canonical format. c class zone filename Specifies the class of the zone. Specifies the zone whose contents are to be checked. Specifies the file used for checking the contents of a zone. BIND Name Service Overview 25

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.conf file is typically used to define a named IP address matching list, for the purpose of access control. This statement is typically used inside a zone statement. The acl statement is of the following format: acl name {address_match_list}; Before using the address match list, you must define it with the acl statement because forward references are not allowed. The following ACLs are predefined: any Allows all hosts. none Denies all hosts. localhost Allows the IP addresses of all interfaces on the system. localnets Allows any host on a network for which the system has an interface. An example acl statement is as follows: acl can_query {1.2.3; any;}; The acl statement can_query allows queries from any host in the 1.2.3 network. The include Statement The include statement in /etc/named.conf inserts the specified file at the particular location where the include statement is encountered in the configuration file. You can use this statement to break the configuration file into easily manageable groups. The include statement is of the following format: include path_name; An example include statement is as follows: include /etc/security/keys.bind; include /etc/acls.bind; 26 Overview

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. The key statement can occur at the top level of the configuration file or inside a view statement. You can use the keys defined in the top-level key statements in all the views. You must define keys intended for use in a controls statement at the top level. The key statement is of the following format: key key_id {algorithm algorithm_id; secret secret_string; }; The key_id, also known as the key name, is a domain name uniquely identifying the key. The algorithm_id is a string that specifies a security or authentication algorithm. The secret_string is a base-64 encoded secret string used by the algorithm. An example key statement is as follows: key sample_key { algorithm hmac-md5; secret secret here ; }; You can use the key ID defined in the key statement to associate an authentication method with a particular name server. You must create a key ID in the key statement before using it in a server definition. The logging Statement The logging statement in the /etc/named.conf file specifies what messages the server logs and where the log messages are sent. The logging statement also configures a variety of logging options for the name server. The logging statement configures the logging system, which sends messages to one or more channels. The logging statement is of the following format: logging { [ channel channel_name { ( file path name [ versions ( number unlimited ) ] [ size size spec ] null stderr syslog syslog_facility ) ; [ severity ( critical error warning notice info debug [ level ] dynamic ) ; ] [ print-category yes_or_no ; ] [ print-severity yes_or_no ; ] [ print-time yes_or_no ; ] }; ]... [ category category_name { ( channel_name ; )... }; ]... }; The logging keyword contains a list of statements enclosed in braces. BIND Name Service Overview 27

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.log, then just before it is opened, lame.log is renamed to lame.log.0, lame.log.0 is renamed to lame.log.1, and lame.log.1 is renamed to lame.log.2. 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). A channel associates output methods, format options, and severity levels with a name. You can use this name to select how various categories of messages are logged. Channels perform the following tasks: Limit incoming messages to a given severity level. Limit the size of the logging file. Manage multiple versions of the logging file (to maintain historic data). Direct the logging messages to any of the syslog facilities. There are many default channels, and you can define more channels in the logging statement in the configuration file. You must use a single logging statement to define all channels and categories. If there are multiple logging statements in a configuration, the first defined statement determines the logging configuration and warnings that are issued for the others. Message Severity Levels The severity levels include all the syslog severities as well as multiple debug levels. These levels correspond to the different debugging levels in named (the BIND daemon) and are ranked so that higher levels are less severe. If you configure a channel for debug level 3, then in addition to level 3, it accepts and logs messages at levels 2 and 1. The default channels are as follows: default_syslog Sends messages to the daemon facility at severity info and higher (info is a predefined severity level that logs messages of its severity level or higher to the channel). default_debug Sends messages to the file named.run and tracks the daemon s current dynamic debug level. 28 Overview

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. Table 1-3 Channel Message Categories Message Category config parser queries lame-servers cname ncache xfer-in xfer-out eventlib packet notify security insist db os maintenance load response-checks delegation-only dispatch unmatched update-security default Description High-level configuration file processing Low-level configuration file processing Incoming queries Messages about lame servers Messages about cname records Negative caching Zone transfers that the server receives Zone transfers that the server sends Debugging information from the event system Dumps of packets received and sent The NOTIFY protocol Approved and unapproved requests Internal consistency check failures Database operations Operating system problems Periodic maintenance events Zone loading messages Messages arising from response checking Logs queries forced to NXDOMAIN as a result of the delegation-only zone, or the delegation-only in a hint or stub zone declaration. Dispatches incoming packets to the server modules, where the packets are processed. Specifies messages for which named is unable to determine the class, or a matching view is not available. A one-line summary is also logged to the client category, and this category is sent to a file or standard error. By default, the category is sent to the null channel. Indicates approval and denial of update requests. Unclassified messages and categories that do not have a channel list explicitly defined BIND Name Service Overview 29

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. The options statement is of the following format: options { // General Options [ directory path_name ; ] [ disable-algorithms domain { algorithm ; [ algorithm ; ] }; ] [ dnssec-lookaside domain trust-anchor domain ; ] [ dnssec-must-be-secure domain yes_or_no ; ] [ dump-file path_name ; ] [ key-directory path_name ; ] [ memstatistics-file path_name ; ] [ pid-file path_name ; ] [ 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-shutdown yes_or_no ; ] [ match-mapped-addresses yes_or_no ; ] [ minimal-responses yes_or_no ; ] [ notify ( yes_or_no explicit ) ; ] [ provide-ixfr yes_or_no ; ] [ querylog yes_or_no ; ] [ recursion yes_or_no ; ] [ request-ixfr yes_or_no ; ] [ zone-statistics yes_or_no ; ] // Access Control Options [ allow-notify { address_match_list }; ] [ allow-query { address_match_list }; ] [ allow-recursion { address_match_list }; ] [ allow-transfer { address_match_list }; ] [ allow-update-forwarding { address_match_list }; ] [ blackhole { address_match_list }; ] // Bad UDP Port List Options [ avoid-v4-udp-ports { port_list }; ] [ avoid-v6-udp-ports { port_list }; ] // Built-In Server Information Zone Options [ hostname hostname_string ; ] [ server-id server_id_string ; ] [ version version_string ; ] // Dual-Stack Server Option 30 Overview

[ 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 ] ; )... }; ] // Interface Options [ listen-on [ port ip_port ] { address_match_list }; ] [ listen-on-v6 [ port ip_port ] { address_match_list }; ] // Obsolete Option [ allow-v6-synthesis yes_or_no ; ] // Operating System Resource Limit Options [ coresize size_spec ; ] [ datasize size_spec ; ] [ files size_spec ; ] [ stacksize size_spec ; ] // Periodic Task Interval Options [ cleaning-interval number ; ] [ heartbeat-interval number ; ] [ interface-interval number ; ] // Query Address Options [ query-source [ address ( ip_addr * ) ] [ port ( ip_port * ) ] ; ] [ query-source-v6 [ address ( ip_addr * ) ] [ port ( ip_port * ) ] ; ] // RRset Ordering Option [ rrset-order { order_spec ; [ order_spec ; ]... }; ] // Server Resource Limit Options [ max-cache-size size_spec ; ] [ max-journal-size size_spec ; ] [ recursive-clients number ; ] [ tcp-clients number ; ] [ tcp-listen-queue number ; ] // Sorting Option [ sortlist { address_match_list }; ] // Tuning Options [ edns-udp-size number ; ] [ lame-ttl number ; ] [ max-cache-ttl number ; ] [ max-ncache-ttl number ; ] [ max-refresh-time number ; ] [ max-retry-time number ; ] [ min-refresh-time number ; ] [ min-retry-time number ; ] [ sig-validity-interval number ; ] // Zone Transfer Options [ also-notify { ( ip_addr [ port ip_port ] ; )... }; ] [ alt-transfer-source ( ip4_addr * ) [ port ip_port ] ; ] [ alt-transfer-source-v6 ( ip6_addr * ) [ port ip_port ] ; ] [ max-transfer-idle-in number ; ] [ max-transfer-idle-out number ; ] [ max-transfer-time-in number ; ] [ max-transfer-time-out number ; ] [ notify-source ( ip4_addr * ) [ port ip_port ] ; ] BIND Name Service Overview 31

}; [ 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. Pathname Options The pathname options specify information such as the working directory of the server, the pathname of the dump file, the memory statistics file and so on for the various options in the options statement. Table 1-4 describes all the available pathname options. Table 1-4 Pathname Options Option directory path_name; named-xfer path_name; dump-file path_name; memstatistics-file path_name; statistics-file path_name; pid-file path_name; key-directory path_name; memstatistics-file path_name; Description 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. This option specifies the pathname to the named-xfer program used by the server for inbound zone transfers. If you do not specify the pathname, the default pathname is system dependent (for example /usr/sbin/name-d-xfer). This option specifies the pathname of the file to which the server dumps the database with the rndc dumpdb command. The default file name is dump.db. This option specifies the pathname of the file to which the server writes memory statistics on exit, if the value for the deallocate-on-exit option is yes. If you do not specify the pathname, the default file is named.memstats. This option specifies the pathname of the file to which the server appends statistics using the rndc stats command. If you do not specify a file name in the pathname, the default file used is named.stats. This option specifies the pathname of the file to which the server writes its process ID. If you do not specify the path name, the default pathname is /var/run/named.pid or /etc/named.pid. The pid-file is used by programs that send signals to the running name server. Specifies the directory where the public and private key files can be found, if the current directory is not the working directory. Specifies the path name of the file to which the server writes memory usage statistics. The default file name is named.memstats. Boolean Options Boolean options are options in the options statement for which you can specify either the value yes or the value no, to active or deactivate the option, respectively. Table 1-5 describes all the available Boolean options. 32 Overview

Table 1-5 Boolean Options Option auth-nxdomain yes_or_no; deallocate-on-exit yes_or_no; fake-iquery yes_or_no; fetch-glue yes_or_no; host-statistics yes_or_no; multiple-cnames yes_or_no; notify yes_or_no; recursion yes_or_no; request-ixfr Description 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. 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. The default value is no because the operating system deallocates objects faster than the server. However, you can use the deallocate-on-exit option to detect memory leaks. If this option is set to yes, the server simulates the obsolete DNS query type IQUERY. The default value is 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). If this option is set to yes, then for every host that the name server interacts with, the statistics are maintained. The default value is no. Setting host-statistics to yes consumes memory. If this option is set to yes, then multiple CNAME resource records are allowed for a domain name. HP recommends that you do not allow multiple CNAME records for a domain name due to nonconformance with the standard. The default value is no. Multiple CNAME support is available because previous versions of BIND allowed multiple CNAME records, and these records have been used in the previous versions for load balancing. If this value is set to yes (the default value), DNS NOTIFY messages are sent when a zone for which the server is authorized changes. The NOTIFY message speeds the convergence between the master server and its slave servers. A slave server that receives a NOTIFY message contacts the master server for a zone and determines if a zone transfer is necessary. If a zone transfer is necessary, the slave server initiates the zone transfer immediately. You can also specify the notify option in the zone statement. This overrides the options notify statement. See DNS Change Notification (page 17) for more information. If this option is set to yes, and a DNS query requests recursion, the server attempts to answer all the queries. If recursion is set to no, and the server is not aware of the answer, it returns a referral response to the client. The default value is yes. See the option fetch-glue yes_or_no for more information. This option determines whether the local server, acting as a master, responds with an incremental zone transfer when the remote server (a slave) requests the transfer. If this option is set to yes, incremental transfer is provided whenever possible. If set to no, all transfers to the remote server are non-incremental. If not set, the value of the provide-ixfr option in the global options block is used as default. BIND Name Service Overview 33

Table 1-5 Boolean Options (continued) Option provide-ixfr request-ixfr yes_or_no; ixfr-from-differenc es yes_or_no; flush-zones-on-shut down yes_or_no; check-names ( master slave response ) ( warn fail ignore ); querylog yes_or_no; Description 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. If the provide-ixfr option is not set, the value of provide-ixfr in the view or global options statement is used as default. Determines whether the local server, acting as a slave, requests incremental zone transfers from a remote master server. If this option is not set, the value of request-ixfr in the view or global options statement is used as a default. 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. The differences are then logged in the journal file of the zone such that the changes can be transmitted to downstream slaves as an incremental zone transfer. Flushes pending zone writes if the name server exits, because of the SIGTERM signal. The default value is no if the pending zone writes are not flushed when the name server exits, because of a SIGTERM signal. Restricts the character set and syntax of certain domain names in the master files and the DNS responses received from the network. The default differs according to the zone type. For master zones, the default is fail. For slave zones, the default is warn. Specifies whether query logging must start when named starts. If querylog is not specified, query logging is determined by the presence of the logging category queries. Forwarding Options You can use the forwarding facility to create a large site-wide cache on some servers, reducing traffic over links to external name servers. You can also use this option to allow queries by servers that intend to look up exterior names but do not have direct access to the Internet. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache. Table 1-6 describes the forwarding options. Table 1-6 Forwarding Options Option forward (only first); Description This option is effective only if you specify the IP addresses in the forwarders option for forwarding. A value of first (the default value) causes the server to first query the IP addresses specified in the forwarders list. If this query is not successful, the server by itself searches the answer. If the value is set as only, the server queries only the forwarder IP addresses. forwarders { [ in_addr ; [ in_addr ;... ] ] }; This option specifies the IP addresses used for forwarding. The default value is an empty list (that is, no forwarding). 34 Overview

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. 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. The default values for the check-names option are: check-names master fail; check-names slave warn; check-names response ignore; If you specify check-names response fail, the server sends a REFUSED response code to the client. You can also specify the check-names option in the zone statement, but this overrides the options check-names statement. When you specify check-names in a zone statement, the area is not specified, because it can be deduced from the zone type. Access Control Options You can restrict access to the server based on the IP address of the requesting system. Table 1-7 describes the access control options. Table 1-7 Access Control Options Option allow-query { address_match_list}; allow-transfer { address_match_list}; allow-recursion { address_match_list}; blackhole { address_match_list}; Description This option specifies the hosts that are allowed to ask simple questions. You can also specify the allow-query option in the zone statement, which overrides the options allow-query statement. By default, it allows queries from all hosts. This option specifies the hosts that are allowed to receive zone transfers from the server. You can also use the allow-transfer option in the zone statement, which overrides the options allow-transfer statement. By default, it allows transfers from all hosts. This option specifies which hosts are allowed to make recursive queries through the server. If not specified, recursive queries from all the hosts are allowed. This option specifies a list of addresses that the server does not use to resolve a query and from which the server does not accept any queries. Interface Options The interface option is of the following format: BIND Name Service Overview 35

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. An example listen-on option is as follows: listen-on { 5.6.7.8; }; listen-on port 1234 { 11.2.3.4; 1.2/16; }; Zone Transfer Options Table 1-8 describes the zone transfer options. Table 1-8 Zone Transfer Options Option also-notify { ( ip_addr [ port ip_port ] ; )... }; alt-transfer-source ( ip4_addr * ) [ port ip_port ]; alt-transfer-source-v6 (ip6_addr * ) [ port ip_port ]; max-transfer-time-in number; max-transfer-idle-in; max-transfer-time-out; max-transfer-idle-out; transfer-format (one-answer many-answers ); transfer-in number; transfers-out number; Description 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. This option specifies an alternate transfer source IPv4 address, if the transfer source address listed in transfer-source option fails and if the use-alt-transfer-source option is set. This option specifies an alternate transfer source IPv6 address, if the transfer source address listed in transfer-source-v6 fails and if use-alt-transfer-source is set. Specifies the time period after which inbound zone transfers (named-xfer processes) must be terminated. The default value is 120 minutes (2 hours). This option terminates inbound zone transfers making no progress in the specified period. The default value is 60 minutes. This option terminates outbound zone transfers running longer than the specified time. The default value is 120 minutes. This option terminates outbound zone transfers making no progress in the specified period. The default value is 60 minutes. The server supports two zone transfer methods: one-answer and many-answers. The first method uses one DNS message for every resource record transferred. The second method packs many resource records into one message. many-answers is more efficient than one-answer, but is only compatible with BIND 8.1.2 and patched versions of BIND 4.9.7. The default is one-answer. You can override a transfer-format statement with a server statement on a per-server basis. This option specifies the maximum number of inbound zone transfers that can run concurrently. The default value is 10. Increasing the value of the transfer-in option speeds up the coverage of slave zones. It also increases the load on the local system. This option specifies the maximum number of outbound zone transfer that run concurrently. 36 Overview

Table 1-8 Zone Transfer Options (continued) Option transfers-per-ns number; transfer-source transfer-source-v6 use-alt-transfer-sourc e yes_or_no; Description 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. This option specifies the IPv4 address for inbound zone updates, which is also the source address for refresh queries and forwarded dynamic updates. If not set, it defaults to a system-controlled value, which is usually the address of the interface close to the remote end. This option is similar to transfer-source, except that zone transfers are performed using an IPv6 address. This option specifies whether the name server must use the alternate transfer sources. This option defaults to no if views are specified; otherwise, this option defaults to yes (for BIND 8 compatibility). 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-9 describes the resource options available. Table 1-9 Resource Limit Options Option coresize size_spec ; datasize size-spec ; file size_spec ; stacksize size_spec ; Description This option specifies the maximum size of a core dump. The default value is default. This option specifies the maximum amount of data memory the server uses. The default value is default. This option specifies the maximum number of files the server can open concurrently. The default value is unlimited. NOTE: The server cannot set an unlimited value for certain operating systems and cannot determine the maximum number of open files the kernel can support. On such systems, specifying unlimited causes the server to use rlim_max for RLIMIT_NOFILE or the value returned by sysconf(_sc_open_max), depending on which contains the higher value. If the actual kernel limit is larger than this value, use limit files to specify the limit explicitly. Specifies the maximum amount of stack memory the server can use. The default value is default. Server Resource Limits The server resource limit options set limits on the server s resource consumption that are enforced internally by the server rather than by the operating system. Table 1-10 describes the server resource limit options. BIND Name Service Overview 37

Table 1-10 Server Resource Limit Options Option recursive-clients tcp-clients max-cache-size tcp-listen-queue number; max-journal-size size_spec; Description This option specifies maximum number of simultaneous recursive lookups the server performs on behalf of the clients. The default value is 1000. This option specifies maximum number of simultaneous client TCP connections that the server accepts. The default value is 100. This option specifies maximum amount of memory (in bytes) that a server s cache can use. When the amount of data in the cache reaches this limit, the server causes the records to expire prematurely so that the limit is not exceeded. This option specifies the length of the listen queue. The default and minimum values are 3. If the kernel supports the dataready accept filter, this option also controls the number of TCP connections that are queued in the kernel space waiting for data before data is passed to the accept filter. This option sets the maximum size for each journal file. When the journal file approaches the specified limit, older transactions in the journal are automatically removed. The default value is unlimited. Periodic Task Interval Options Table 1-11 describes the periodic task interval options. Table 1-11 Periodic Task Interval Options Option cleaning-interval number; interface-interval number; statistics-interval number; Description 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. This option specifies how frequently the server scans the network interface list (in minutes). If this option is set to 0, interface scanning occurs only when the configuration file is loaded. After the scan, listeners are started on any new interface (provided they are allowed by the listen-on configuration). Listeners on interfaces that have expired are removed. This option specifies how frequently the name server statistics are logged. The default value is 60. If this option is set to 0, statistics are not logged. Tuning Options Table 1-12 describes the tuning options. Table 1-12 Tuning Options Option max-cache-ttl max-ncache-ttl sig-validity- interval edns-udp-size Description This option sets the maximum time for which the server caches ordinary answers. The default value is 1 week. The server stores negative answers to reduce network traffic and to increase performance. max-ncache-ttl sets a maximum retention time (in seconds) for these answers in the server. This option specifies the number of days after which DNSSEC signatures that are automatically generated due to dynamic updates expire. The default value is 30 days. This option sets the advertised Extended DNS (EDNS) UDP buffer size in bytes. The valid values range from 512 to 4096 bytes (values outside this range are silently adjusted). The default value is 4096. 38 Overview

DNSSEC Options Section describes the DNSSEC options in the options statement in the /etc/named.conf file. Table 1-13 DNSSEC Options Option dnssec-enable yes_or_no; dnssec-lookaside domain trust-anchor domain; dnssec-must-be-secure domain yes_or_no; disable-algorithms domain { algorithm; [ algorithm; ] }; sig-validity-interval number; Description 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. Provides the validation with an alternate method to validate DNSKEY records at the top of a zone. Specifies hierarchies that might be secure (signed and validated). If this option is set to yes, named only accepts answers if they are secure. If this option is set to no, named applies the standard DNSSEC validation. Disables the specified DNSSEC algorithms at and below the specified name. Multiple disable-algorithms statements are allowed, but only the most specific is applied. Specifies the number of days until which DNSSEC signatures automatically generated as a result of dynamic updates expire. The default value is 30 days. The maximum value is 3660 days (10 years). 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 hostname hostname_string; server-id server_id_string; version version_string; Description 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. Specifies the server ID to which the server must report, using the ID.SERVER query with type TXT and class CHAOS. The default value of this option is none. Specifies the version to which the server must report, using the version.bind query with type TXT and class CHAOS. The default value is the real version number of the server. Bad UDP Port List Options Section describes the bad UDP port list options. Table 1-15 Bad UDP Port List Options Option avoid-v4-udp-ports {port_list }; avoid-v6-udp-ports {port_list }; Description Specifies a list of IPv4 and IPv6 UDP ports that are not used as system assigned source ports for UDP sockets. These lists prevent named from choosing a port, which is blocked by a firewall, as the random source port. If a query passes through a source port that is blocked by the firewall, the response does not get across the firewall and the name server must query again. Query Address Options Table 1-16 describes the query address options. BIND Name Service Overview 39

Table 1-16 Query Address Options Option query-source [ address (ip_addr *)] [port(ip_port *)] ; query-source-v6 [ address (ip_addr *)] [port(ip_port *)] ; Description Specifies the address and the port used to query other name servers if a server is unable to answer a query. Specifies the address and the port used for queries that are sent over an IPv6 connection. RR Set Ordering Option When multiple records are returned in a answer, you must configure the order of the records placed in the response. The rrset-order option enables you to configure the order of the records in a multiple record response. Following is the syntax of the rrset-order option: rrset-order { [ class class_name ] [ type type_name ] [ name "domain_name" ] order ordering} Following is an example of the rrset-order option: rrset-order { class IN type A name "host.example.com" order random; order cyclic; }; 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 dual-stack-servers option does not have any affect in a dual-stacked system, if access to the IPv4 or IPv6 transport is disabled using the named -4 or named -6 command. The syntax for the dual-stack-servers option in the options statement in the /etc/ named.conf file is as follows: [ dual-stack-servers [port ip_port] { ( domain_name [port ip_port] ip_addr [port ip_port] ) ;... }; ] Additional Options Following are some additional options in the options statement: tkey-domain This option specifies the domain name that is appended to the shared keys generated by TKEY. When a client requests a TKEY exchange, it may or may not specify the desired name for the key. If the client specifies the desired name for the key, the shared key name is a combination of the client-specified part and the tkey-domain; otherwise, the shared key name is a combination of the random hexadecimal digits and the tkey-domain. In most cases, the domain name must be the server s domain name. tkey-dhkey This option specifies the Diffie-Hellman key used by the server to generate shared keys with clients using the Diffie-Hellman mode of TKEY. The server must be able to load 40 Overview

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 The sortlist Statement This option specifies the port number. 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 client resolver code must rearrange the resource records appropriately on the local network depending upon a particular preference. You can use the sortlist statement to specify the preference of an IP address over other IP addresses. The sortlist statement contains the address_match_list option, which is a list of addresses that specify the preference. Each top-level statement in the sortlist statement must be an explicit addresses_match_list with one or two elements. The first element, which can be an IP address, IP prefix, acl name, or a nested address_match_list, is checked against the source address of the query until a match is found. When the source address of the query is matched, if the top-level statement contains only one element, the actual element that matches the source address is used to select the address in the response to move to the beginning of the response. Each top-level statement element is assigned a distance, and the address in the response with the minimum distance is moved to the beginning of the response. For more information on the sortlist statement, type man 1M named.conf at the HP-UX prompt. 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. transfer-format many-answers; Each DNS message accommodates as many resource records as possible. This format is efficient when compared to the transfer-format one-answer option. You can specify any of the transfer-format options for a server using the transfer-format option within the server statement. If you do not specify the transfer-format option, the transfer-format specified by the options statement is used. The server statement is of the following format: server ip_addr { [ bogus yes_or_no ; ] [ edns yes_or_no ; ] [ keys { string ; [ string ; ]... }; ] [ provide-ixfr yes_or_no ; ] [ request-ixfr yes_or_no ; ] [ transfer-format ( one-answer many-answers ) ; ] [ transfer-source ( ip4_addr * ) [ port ip_port ] ; ] [ transfer-source-v6 ( ip6_addr * ) [ port ip_port ] ; ] [ transfers number ; ] }; BIND Name Service Overview 41

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. HP recommends that you use a file because it speeds the server startup and prevents unnecessary wastage of bandwidth. Stub A stub zone is similar to a slave zone, except that it replicates only the name server records of a master zone instead of the entire zone. Hint A hint zone specifies the initial set of root name servers. Upon startup, the server uses the root hints to find a root name server and gets the latest list of root name servers. You can specify the following access limitations for the zone in the zone statement: Updates Queries Transfers The zone statement is of the following format: zone domain_name [ ( in hs hesiod chaos ) ] { type master; file path_name; [ check-names ( warn fail ignore ); ] [ allow-update { address_match_list }; ] [ allow-query { address_match_list }; ] [ allow-transfer { address_match_list }; ] [ update-policy { update_policy_rule [...] ; } [ notify yes_or_no; ] [ 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] ;... ] }; ] [ max-transfer-time-in number; ] [ max-transfer-time-out number ; ] [ max-transfer-idle-out number ; ] [ notify yes_or_no; ] [ sig-validity-interval number ; ] [ also-notify { ip_addr; [ip_addr;... ] }; }; The hint zone statement is of the following format: zone. [ (in hs hesiod chaos ) ] { type hint; file path_name; [ check-names ( warn fail ignore ); ] }; 42 Overview

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. A client matches a view if its source IP address matches the address_match_list of the view s match-clients clause, and if its destination IP address matches the address_match_list of the view s match-destinations clause. If you do not specify both the clauses, match-clients and match-destinations default to match all the addresses. You can also specify a view statement as match-recursive-only, where only recursive requests from matching clients match that view. Zones defined within a view statement are accessible only to clients that match the view. You can use the options defined in the options statement in the view statement to resolve queries for a view. If you do not specify a view value, the options statement value is used as the default. Views are class-specific. The default value is the IN class. If you do not specify view statements in the configuration file, a default view that matches any client is created in the IN class, and the zone statements specified in the beginning of the configuration file are considered to be part of this default view. If an explicit view statement exists, all the zone statements must occur within the view statement. The view statement is of the following format: view view_name [class] { match-clients { address_match_list } ; match-destinations { address_match_list } ; match-recursive-only { yes_or_no } ; [ view_option;... ] [ zone-statistics yes_or_no ; ] [ zone-statement;...] }; An example of a typical split DNS setup implemented using the view statement is as follows: view internal { // This should match our internal networks. match-clients { 10.0.0./8; }; // Provide recursive service to internal clients only. recursion yes; // Provide a complete view of the example.com zone // including addresses of internal hosts. 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.db ; }; }; BIND Name Service Overview 43

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. You can specify the remote host on the command line, and the TFTP server, tftp, uses the host as the default host for future transfers. Otherwise, tftp issues a prompt and expects the user to connect to a host. If you want to connect to a particular port, you can specify the port number as an optional parameter. TFTP does not require user login or validation. Diskless clusters use TFTP to transfer required files while booting. Together, TFTP and BOOTP allow a system to provide boot information for client systems that support BOOTP, such as HP s 700/X terminal. These protocols are implemented on the Internet User Datagram Protocol (UDP). Therefore, you can use these protocols across networks that support UDP. How BOOTP Works The Bootstrap Protocol (BOOTP) allows a client system to discover its IP address, the address of a BOOTP server, and the name of a file that is loaded into memory and executed. BOOTP operates in two phases: Address determination and bootfile selection File transfer In the first phase, the address determination and bootfile selection occur. This phase uses the BOOTP server, bootpd. After the address and file name information is obtained, control passes to the second phase of bootstrap, where a file transfer occurs. This phase uses the TFTP server, tftpd. NOTE: HP recommends that Remote Maintainance Protocol (RMP) clients upgrade to bootp or DHCPv6 to obtain the IP address and other configuration information. Address Determination and Bootfile Selection The first phase of BOOTP involves a bootrequest packet that is broadcast by the BOOTP client. A BOOTP server that receives the bootrequest sends a bootreply to the client if the BOOTP server finds the client s boot information in its database; otherwise, the BOOTP server relays the bootrequest to other BOOTP servers if it finds relay information for the client in its database. The steps performed by the BOOTP server and the client in the process of address determination and bootfile selection are as follows: 1. The BOOTP client broadcasts a bootrequest on the network. Before sending the bootrequest, the client does the following: It sets the hops field of the bootrequest packet to 0. Each time a BOOTP server relays the client s bootrequest, the hops field is incremented by 1. If the hops value exceeds 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. If the value of the secs field is less than the threshold value configured for this client on a BOOTP server, the bootrequest is dropped. 44 Overview

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. 2. The client broadcasts the bootrequest packet on its first LAN interface (lan0). The bootrequest also contains the client s hardware address, and, if known, its IP address. 3. The BOOTP server detertimes whether boot information for the client exists in its database. If boot information for the client is available in the server s database, the server answers the bootrequest with a bootreply packet. 4. If the BOOTP server does not find boot information for the client in its database, the BOOTP server determines whether relay information for the client is available in its database. If the relay information is not available for the client in the database, the bootrequest is dropped. If relay information is available and the relay function is enabled for the client, the server checks the following: If the hops value in the bootrequest packet exceeds the maximum configured for the client, the request is dropped else the hops field in the bootrequest is incremented. If the secs value in the bootrequest packet is less than the threshold value configured on the server for the client, the request is dropped. If the request is not dropped during the previous checks, the server relays the bootrequest to the BOOTP servers that are configured for the client. If the giaddr field of the bootrequest packet is 0, the server enters its IP address in the field. Steps 3 and 4 are repeated until either the bootrequest is received by a BOOTP server that finds boot information about the client in its database, or the request is dropped. When a server finds client information about a particular client in its database, the server answers the bootrequest with a bootreply packet. The client s IP address is placed into a field in the bootreply. The bootreply can also contain the boot file name, which the client must load with TFTP. Other information that the bootreply can contain include the client s subnet mask, the addresses of nameservers, and the addresses of gateways. If the bootrequest is relayed to one or more BOOTP servers, the bootreply is sent to the IP address in the giaddr field, which is the IP address of the BOOTP server that initially relayed the bootrequest. This BOOTP server sends the bootreply to the client. Figure 1-2 shows a typical example of a bootrequest relay. Figure 1-2 Bootrequest Relay Example 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. BOOTP and TFTP Overview 45

File Transfer 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. 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. DHCP Overview DHCP (Dynamic Host Configuration Protocol) is an extension of the BOOTP protocol that defines a protocol for passing configuration information to hosts on a TCP/IP network. The DHCP and BOOTP daemons are a subsidiary of inetd, and are started or restarted automatically (that is, as requests are passed to it). The main advantage of DHCP is its capability to automatically allocate IP addresses to clients booting on the TCP/IP network for the first time. The DHCP server passes the IP information and other start-up information to clients, including the name of the Domain Name Service (DNS) server. Additionally, DHCP passes the following startup information: IP Subnet Mask IP Routes Broadcast IP Address DNS Server NIS Server NTP Server Benefits of Using DHCP Using DHCP reduces the labor involved in managing the network. Before DHCP, the network administrator had to manually connect and configure every computer in a network. Because the DHCP server automatically dispenses IP addresses and other configuration information, the process of connecting a new computer to the network is much simpler. DHCP is very flexible and allows the network administrator to set up the server one time to serve many thousands of clients. DHCP Components and Concepts DHCP Servers The primary components of DHCP are as follows: DHCP server DHCP client DHCP leases The DHCP server dispenses and manages network IP addresses. It assigns IP addresses to clients that are connecting to the network for the first time. When a client connects to the network, the server automatically assigns it an IP address from an appropriate pool of IP addresses. You can have multiple DHCP servers on your network provided their subnet pools do not overlap. However, it is recommended that you have only one DHCP server for your entire 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. 46 Overview

DHCP Clients DHCP Leases 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 server supplies DHCP clients with sufficient information to establish an endpoint for network communications. It also supplies other parameters required by the system- and application-level software. HP-UX workstations can run DHCP clients automatically. The autoparms script, /sin/auto_parms, enables HP-UX systems to run DHCP clients automatically. The autoparms script does not run, if you edit the configuration file /etc/rc.config.d/netconf. DHCP clients can include TCP/IP network printers, X terminals, and Microsoft Windows machines. In addition to supporting new DHCP clients, the DHCP server supports new and existing BOOTP clients. DHCP clients are currently supported on 10 BaseT and 100 BaseT ethernets. It is not supported on FDDI and Token Ring networks. The DHCP server controls the IP address block. It grants permission to DHCP clients to use IP addresses on a lease basis. The IP address is leased to the client for a fixed amount of time. The administrator sets the lease time, which can last from 120 seconds to infinity. During the lease period, DHCP guarantees that the IP address assigned to the client is not reassigned to another client. Before the lease time expires, the DHCP client automatically requests an extension on its lease. As long as the client can contact the DHCP server, the server renews the lease. For example, when client A reboots, it attempts to renew the lease it had before being powered off. If client A was powered off when the renewal time elapsed, it can be assigned a different IP address. If the IP address is still unassigned when client A comes back online, the server can assign the same IP address to client A. But if the server assigned the IP address to client B while client A was offline, client A will be assigned a different IP address. DHCP Transactions: Basic Operation Figure 1-3 illustrates the interaction between the DHCP client and server. DHCP Overview 47

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. 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. 2. The server receives the DHCP DISCOVER packet. If an IP address on the client subnet is available and the server is willing to grant a lease, it makes an offer by sending a DHCP OFFER packet to the client. The offer packet contains the following information: Proposed IP address for the client Server name Server IP address Other configuration information 3. The client receives the DHCP OFFER packet. The client may receive more than one offer if more than one DHCP server exists on the network. HP recommends that you have only one DHCP server on the network. If the client is interested in the offer, it sends a DHCPREQUEST packet to the server. This indicates a formal request to lease the IP address offered by the server. NOTE: The client rejects offers for IP addresses with short lease times. For example, the client rejects an offer with a lease time of 10 seconds. 4. The DHCP server receives the DHCPREQUEST packet and leases an IP address to the client. The server sends a DHCPACK packet to the client. This is an official notification that the address has been granted. 48 Overview

5. 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. 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. It automatically allocates reusable network addresses and reduces the cost of managing IPv6 nodes in environments where administrators require more control over the allocation of IP addresses. DHCPv6 manages network resources such as IP addresses, Network Time Protocol (NTP), Domain Name System (DNS), and other server addresses at a centralized location. NOTE: All references to DHCPv6 in this document refers to DHCPv6 2.001 This section discusses the following topics: DHCPv6 Components (page 49) Autoconfiguration (page 49) Ports (page 50) Multicast Addresses (page 50) DHCPv6 Components Table 1-17 describes the components that the DHCPv6 framework includes. Table 1-17 DHCPv6 Components Component DHCP client DHCP server DHCP relay or agent Description The host that needs to be configured. The server that caters to the DHCP client s configuration requirements. The host that facilitates initial communication between the DHCP server and the client when they are on different links. Autoconfiguration Autoconfiguration is a mechanism that does not require any manual intervention to configure a host in a network environment. Following are the types of autoconfiguration methods: Stateless address autoconfiguration Stateless autoconfiguration does not require a manually configured server but enables IPv6 hosts to configure their own addresses using a local IPv6 router. This method is easy to use. However, this autoconfiguration method lacks network access control capabilities and manages only addresses. It does not make the optimum use of the available address space. Stateful address autoconfiguration Stateful autoconfiguration involves a client and a server. An unconfigured node checks for router advertisements on the network. If there are no router advertisements on the network, the node determines that it needs to use DHCPv6 to configure an interface. DHCPv6 Overview 49

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 547 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. 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.org/assignments/port-numbers Multicast Addresses DHCPv6 uses the following multicast addresses: All DHCP Agents address - FF02::1:2 DHCP clients use this link-scoped multicast address to communicate with the on-link agent. All agents within the same DHCP domain belong to this multicast group. All DHCP Servers address - FF05::1:3 How DHCPv6 Works DHCP clients or relays use this site-scoped multicast address to communicate with servers in one of the following scenarios: When they need to send messages to all servers. When they do not know the server s unicast address. All servers within the site belong to this multicast group. See HP-UX IPv6 Porting Guide, available at http://www.docs.hp.com/en/netcom.html#ipv6, for more information about link-local and site-local addresses. This section describes how the DHCPv6 software works. It discusses the following topics: Client/Server Operation (page 50) Identifying and Managing IPv6 Addresses (page 52) Client/Server Operation 50 Overview This section describes how the DHCPv6 server and the client communicate with each other. Servers and clients on the same link communicate directly with each other. The DHCPv6 client initiates the message interaction by sending a SOLICIT message. It uses the SOLICIT message to locate DHCPv6 servers, which are able to provide an IPv6 address and other configuration parameters. Multiple servers respond to the client s message with a DHCP ADVERTISE message. The DHCP ADVERTISE message contains a preference value, which indicates the server s ability to offer services to the client. You need to set this preference value for a server. See The dhcpv6d Server Daemon (page 131) for more information. The server preference variable is an unsigned single octet value, with the lowest preference value being 0 and the highest 255. Clients choose higher preference servers over lower preference servers to configure their interfaces.

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 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. The server responds to the client s message by sending a DHCP REPLY message. The DHCP REPLY message contains the IPv6 address and configuration parameters required by the client. The server sends the DHCP REPLY message to respond to the client s REQUEST, RENEW, REBIND, RELEASE, RECONFIGURE, CONFIRM, and INFORMATION REQUEST messages. 5. The client sends a DHCP RELEASE message to return one or more IPv6 addresses to the server when it has completed using an IPv6 address. See Message Types (page 52) for more information about message types. DHCPv6 requires relays to be set up on the client s link when the client and the server are on different links. Relays receive messages from the client and forward them verbatim to a set of servers that the DHCP domain includes. Relays forward the client s messages to servers using any of the following addresses: All DHCP Servers Site-local multicast address Other site-local multicast addresses set up within the DHCP domain to include the servers in that domain A list of unicast addresses for servers Figure 1-5 depicts how the client and the server, on different links, communicate with each other. Figure 1-5 When Client and Server Are on Different Links DHCPv6 Overview 51

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. The server message is encapsulated in the RELAY-RELAY message. 4. The relay forwards the server message to the client s message by sending ADVERTISE messages. NOTE: All other message interactions are identical to those explained in the previous scenario. Identifying and Managing IPv6 Addresses Servers and clients manage IPv6 addresses in groups called Identity Associations (IAs). A unique identifier identifies each IA. DHCPv6 servers allocate IPv6 addresses to clients as IAs. Clients use the addresses in an IA to configure interfaces. Each address in an IA has its own preferred and valid lifetimes. DHCPv6 Features Message Types This section describes the features that the DHCPv6 software supports. It discusses the following topics: Message Types (page 52) Multiple IP Address Request (page 53) Configuration Parameters from a DHCPv6 Server (page 53) Reconfiguration Messages (page 53) Table 1-18 describes the messages exchanged between the client and the server through a relay. Table 1-18 DHCPv6 Message Types Message Type SOLICIT ADVERTISE REQUEST CONFIRM RENEW REBIND Description A client uses this message to locate servers. A server uses this message to respond to SOLICIT messages. A client uses this message to request addresses and configuration parameters from servers. A client sends a CONFIRM message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected. A client uses this message to renew addresses from the server when the lease on an identify association (IA) is about to expire. A client uses this message to renew addresses from all available DHCPv6 servers when the lease on an IA is about to expire. 52 Overview

Table 1-18 DHCPv6 Message Types (continued) Message Type REPLY RELEASE DECLINE RECONFIGURE INFORMATION-REQUEST RELAY-FORW SERVER-FORWARD Description 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. A server sends a REPLY message in response to a CONFIRM message confirming or denying that the addresses assigned to the client are appropriate to the link to which the client is connected. A server sends a REPLY message to acknowledge receipt of a RELEASE or DECLINE message. Clients use this message to return one or more IP addresses to servers. 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. Servers send his message to inform clients that the server has new or updated configuration parameters, and that the clients need to initiate a Request/Reply transaction with the servers in order to receive the updated information. A client sends an INFORMATION-REQUEST message to a server to request configuration parameters without the assignment of any IP addresses to the client. A relay agent uses this to forward client messages to servers. A server sends a RELAY-REPL message to a relay agent containing a message that the relay agent delivers to a client. The RELAY-REPL message can be relayed by other relay agents for delivery to the destination relay agent. The server encapsulates the client message as an option in the RELAY-REPL message, which the relay agent extracts and relays to the client. Multiple IP Address Request DHCPv6 allows clients to request multiple IP addresses to configure an interface. Configuration Parameters from a DHCPv6 Server DHCPv6 clients do not need to obtain all the configuration parameters for an interface from the same DHCPv6 server. They can communicate with different servers within the same DHCP domain to obtain this information. Reconfiguration Messages DHCPv6 Files The DHCPv6 server sends reconfiguration messages to the client to inform the client that the server has new or updated configuration parameters. It also indicates that the client can initiate a Request or Reply transaction with the server in order to obtain the new information. The clients listen on a specific port to receive the DHCP Reconfigure messages from the server. Table 1-19 describes the files and daemons that the DHCPv6 software contains. DHCPv6 Overview 53

Table 1-19 DHCPv6 Files Name and Location Server Client Use /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 X This file contains the configuration parameters obtained from the server. The client daemon reads this file to build its internal database and to maintain the leases. SLP Overview The Service Location Protocol (SLP) framework simplifies the discovery and use of network resources such as printers, web servers, fax machines, video cameras, file systems, backup devices (tape drives), databases, directories, mail servers, and calendars. Typically, in order to locate services on the network, users of network applications are required to supply the host name or network address of the machine that supplies a desired service. SLP eliminates the need for a user to know the name of a network host supporting a service offered by the network. The user is required to specify the following details pertaining to the desired service: Type of the desired service A set of attributes that describe the service Based on this information, SLP resolves the network address of the host that supports the service. It uses Uniform Resource Locators (URLs) to locate the services. See SLP Attributes (page 57) for more information. SLP facilitates the following: Client application requests for network service location information Advertisement of services Segregation of services and users into logical or functional groups Managed recovery from primary server failures SLP implementation on HP-UX is based on OpenSLP Version 0.8.0, developed by Caldera Systems, Inc. This section containes the following topics: Salient Features (page 54) SLP Components (page 55) SLP Architecture (page 56) Salient Features This section describes the salient features of SLP. 54 Overview

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. For example, you can describe a printer as a PostScript printer, a printer that has blue paper available, or a printer on the same floor as the user s office. You can track a service by specifying the values of the attributes if services are replaced or removed from the network; user agents discover alternate or replicated servers and continue to operate. Ease of Administration You do not need to configure clients to find new services or to remove services when they are no longer available. Ease of Development SLP s well-defined APIs and protocol semantics allow service developers to rapidly provide network services. SLP Components User Agent Service Agent Directory Agent The SLP framework comprises the following agents and processes: The User Agent (UA) issues a service request on behalf of the client application, specifying the characteristics of the service that the client requires. The user agent can directly issue a multicast request to Service Agents. The Service Agent (SA) works on behalf of one or more services to advertise the service on the network. Service agents advertise their service through service agent advertisements. In the absence of Directory Agents (DAs), the SA responds to multicast requests sent by the User Agents. If a DA is available, the SA registers and, optionally, withdraws services with DAs that support its scopes. All the network services are grouped together by using scopes that indicate a particular location, administrative grouping, and proximity in a network topology or any other category. For more information about scopes, see Assigning Scopes (page 60). The HP-UX implementation of SLP includes a Service Agent Server, with which the services register their service information. Therefore, instead of having multiple individual Service Agents running on a host, there is only one Service Agent Server advertising multiple services. The Directory Agent (DA) is an optional SLP agent that maintains a cache of service advertisements sent by the SA. The DA provides this information to the clients that are trying to discover the services. A DA sends periodic unsolicited advertisements through which SAs and UAs discover the DA within shared scopes. UDP and Multicast Ports SLP uses UDP and multicast ports in the following scenarios: SLP Overview 55

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). The Service Agent sends replies larger than the path MTU, and User Agents are not configured to accept the replies with the OVERFLOW flag set (this flag enables the UA to only make use of the truncated reply or to reformulate the request to limit the reply). Directory Agents must be able to respond to UDP and TCP requests. SLP Architecture The SLP architecture, at its most basic level, includes the following players in a typical service location problem: A client or user that is searching for a service to satisfy particular requirements or that requires information on the characteristics of a particular service. A server or service provider that is advertising a service having particular characteristics. At the simplest level, an architecture for service location must provide a way for the UA to obtain a set of services having particular characteristics from SAs advertising those services. The information provided by SAs describing services is called a service advertisement. A service advertisement is a URL and a collection of attribute-list pairs that describe a service. All service advertisements have a valid lifetime. Upon expiry of this lifetime, the service advertisements become invalid, unless they are reregistered. Service advertisements characterize an instance of a service through a collection of attributes that describe the service. One of those attributes is the type of service being offered, known as the service type. The service type attribute describes a class of services that share the same attributes. It also includes information about what protocol clients must use when contacting the service. The service advertisement also contains another important piece of information: the service access point, which helps the UA to access the service. Normally, the service access point encapsulates the machine s host name or IP address and perhaps a port number. Figure 1-6 illustrates SLP architecture for a network. 56 Overview

Figure 1-6 SLP Architecture SLP Attributes 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. The UA clients then utilize the services through the service access point information. Attributes in SLP are transmitted in text string lists. The lists contain parenthesized expressions assigning an attribute tag to a value or a set of values. The syntax for the attribute string list is as follows: attrlist = *WS attr-assign *WS / *WS attr-assign *WS, ; attrlist Attributes are formed into a list consisting of comma-separated expressions. The assignment expressions contain the attribute tag, followed by "=", followed by a comma-separated list of one or more values. An example of attribute list is as follows: (submission day=wednesday),new_copy,(month=1,2,3,4,5,6) In this list, the submission day is assigned a string value of wednesday; the month attribute is assigned a list of integer values. The new_copy attribute is a keyword attribute and is not part of an attribute assignment expression. SAs send attribute lists in this format to DAs in response to a UA request for attribute values. Discovering a Directory Agent Following are the different ways in which UAs and SAs find DAs: Active DiscoveryIn active DA discovery, the UA and the SA send a multicast SLP request to the network. The service type of the request is directory-agent, and the query is SLP Overview 57

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.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-7 illustrates how active and passive DA discovery work. Figure 1-7 Active and Passive DA Discovery How SLP Works The UA and SA at the top of the figure have initiated active discovery by multicasting a service request (SrvRqst) with service type service:directory-agent. The DA at the bottom of the figure responds by unicasting a DA advertisement (DAAdvert) with its URL and the list of scopes that it supports. At the bottom of the figure, the DA periodically multicasts a DAAdvert with its URL and scope list. The UA and SA listen on port 427 for the unsolicited DAAdvert and add the DA to their list of active DAs. Consider the example of a user who needs to use the printer services on a network. The following series of events occur at the server and the client side: 1. A printer initializes and registers its URL with the SA and the DA server. 2. Service Agents register current attribute information periodically, allowing User Agents to ascertain their status and other characteristics. 58 Overview

3. The client queries for a printer service with particular attributes, such as a PostScript printer, including the scope information. 4. 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-20 SLP Files Name and Usage Configuration file - to configure slpd Registration file Pid file Default log file SLP daemon Script to start, stop, restart slpd, and also to dump the database. Library calls Error codes Location /etc/slp.conf /etc/slp.reg /var/run/slpd.pid /var/log/slp.log slpd slpdc libslp SLPError SLP Messages SLP is a string protocol. Every SLP message consists of a header and a body. The body contains both string and binary fields. All the SLP messages are prefixed by a common header. The header contains the type, length, and other related information about the message. Table 1-21 describes the SLP message types. Table 1-21 Message Types Message Type Service Type Request Service Type Reply Abbreviation SrvTypeRqst SrvTypeRply Usage UAs send this message to SAs and DAs to request the types of services available. SAs and DAs send these messages to the UAs in response to their requests. These contain the service types requested by the client. SLP Overview 59

Table 1-21 Message Types (continued) Message Type DA Advertisement SA Advertisement Service Acknowledge Attribute Request Attribute Reply Service Registration Service Deregistration Abbreviation DAAdvert SAAdvert SrvAck AttrRqst AttrRply SrvReg SrvDeReg Usage DAs send this message to the SAs and UAs to make them aware of their whereabouts. SAs send this message to the UAs to make them aware of their whereabouts. DAs send an acknowledge message to SAs in response to their SrvReg and SrvDeReg messages. UAs send this message to SAs and DAs to request the attributes of a service. SAs and DAs send this message to UAs in response to theirattrrqst message. This contains the list of attributes of a requested service. SAs send this message to register their services with DAs. 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. Assigning Scopes A scope is a cluster of services that allows the services to be associated with a set of users administratively. A scope indicates a particular location, administrative grouping, and proximity in a network topology or any other category. SAs and DAs are always assigned a scope string. The UA is normally assigned a scope string, through which it discovers that particular group of services. This allows a network administrator to provide the desired service to users. If the UA is configured with no scope, it discovers all available scopes and allows the client application to issue requests for any service available on the network. There are no hard and fast rules for the assignment of scopes. They may be assigned by geographical location or by logical or administrative groupings. For example, you can assign the administrative scope of Marketing to a scanner. It is also possible for the same scanner to be advertised within the local scope Engineers, if all engineers must have access to the resource as well. Following is an example of how to configure scopes:. # Scopes to use for this agent net.slp.usescopes=corp,eng You can use scopes for the physical location of services. You can also use a physical location attribute within a particular service with scopes. Following is an example of expanded scope associated with a service: # Scopes to use for this agent net.slp.usescopes=building-5, Building-12 This configuration allows services to be advertised to users that are in the Building-5 scope, as well as to users that are assigned to Building-12 scope. This is a logical configuration for physically dependent services, such as scanners or printers. SLP APIs Table 1-22 describes the APIs that the SLP software contains. 60 Overview

Table 1-22 SLP APIs API SLPReg() SLPDeReg() SLPFindSrvs() SLPFindAddrs() SLPFindSrvTypes() Usage Registers a service URL and associated service attributes with SLP. Deregisters a registered service. Finds services based on service type or attributes. Obtains a list of attributes for services registered with SLP. 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. 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.sl) provides the UA functionality on a per-process basis without the need to communicate with slpd running on local machines. This means that in certain cases, you do not have to load the SLP daemon on every machine. This helps to minimize the overhead for SLP for those machines that need only UA capabilities. slpd must be running on all the machines that need to register services. In other words, slpd is required on all machines that run applications and make calls to either SLPReg() orslpdereg() APIs. slpd accepts registration requests for services from SAs and maintains this information internally. It shares this information with clients represented by their UAs when queried. In addition, slpd allows older applications that are not SLP-enabled to advertise the services offered by them. You can use the -r option to specify the file that contains static registrations. By default, slpd reads static registrations from the file /etc/slp.reg. You need to run slpd in order to make the registrations for the /etc/slp.reg file available to other machines. Additionally, slpd must be running for automatic DA and scope discovery to work correctly. If slpd is not running, then DAs and scopes can be discovered only via DHCP or the /etc/slp.conf file. NOTE: In the absence of a standard DHCP API, discovery via DHCP is currently not supported. slpd is not required if a machine requests only services. In other words, slpd is not required on machines if a call is never made to SLPReg() or SLPDeReg(). Additionally, slpd is not needed on a machine if either manual or DHCP type of DA or scope discovery is sufficient. Startup Options You can invoke slpd with various options. Run the following command on the command line to invoke slpd: slp [-d] [-c config file] [-r registration file] [-l log file] [-p pid file] Table 1-23 contains the list of command-line options that SLP supports at startup. Table 1-23 Startup Options Option [-d] [-c config file] Description Prevents detaching from the controlling tty. Specifies the file that slpd uses to read configuration information. The default configuration file is /etc/slp.conf. SLP Overview 61

Table 1-23 Startup Options (continued) Option [-r registration file] [-l log file] [-p pid file] Description Specifies the file that slpd reads to obtain static registrations. The default registration file is /etc/slp.reg. Specifies the file that receives slpd log messages. The default log file is /var/log/slpd.log. 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. Table 1-24 contains the list of commands that slpdc supports. Table 1-24 slpdc Commands Command slpdc start slpdc stop slpdc restart slpdc dump Description Starts slpd.the command line options to be passed to slpd can be specified as: slpdc <options> Stops slpd. Restarts slpd. Dumps the database. 62 Overview

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. It discusses the following topics: Creating and Registering a New Domain (page 63) Configuring the Name Service Switch (page 64) Choosing Name Servers for Your Domain (page 64) Types of Resource Records (page 65) Configuring a Master Name Server (page 67) Configuring a Slave Name Server (page 76) Configuring the Caching-Only Name Server (page 80) Configuring the Resolver to Query a Remote Name Server (page 81) Configuring the Resolver to Set Timeout Values (page 83) Starting the Name Server Daemon (page 84) Updating Network-Related Files (page 86) Delegating a Subdomain (page 86) Configuring a Root Name Server (page 87) BIND Logging System (page 88) BIND Security (page 88) Troubleshooting the BIND Name Server (page 92) Creating and Registering a New Domain To set up a new domain, follow the steps described in this section. If you already have a domain, you need only add hosts to the existing domain. The following steps describe how to create a new domain: 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. ATTN: Network Information Center Chantilly, VA 22021 phone: (703) 802-8400 email: hostmaster@nic.ddn.mil Creating and Registering a New Domain 63

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. Domain names do not distinguish between uppercase and lowercase letters. Avoid labels longer than 12 characters. (A label is a single component of a fully qualified name, like indigo or com.) If a host connects to more than one network, it must have the same name on each network. Do not use nic or other well-known acronyms as the leftmost (most specific) label in a domain name. Contact Government Systems, Inc., for a list of top-level and second-level domain names already in use. 3. After you have registered your domain, you can create subdomains without registering them with the public network. Configuring the Name Service Switch The Name Service Switch determines where your system looks for host information to resolve a host name to an IP address. For all types of information except host information, you can configure your system to use NIS (one of the NFS Services) or the local /etc file, in any order. HP recommends not to configure your system to use NIS. For host information, you can configure your system to use BIND (DNS), NIS, or the /etc/hosts file. As mentioned earlier, HP recommends not to configure your system to use both NIS. See HP-UX Internet Services Administrator s Guide at the URL http://www.docs.hp.com/ hpux/netcom/index.html#internet%20services for more information on the Name Service Switch. 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. Slave Server A slave server is also the authority for its domain and contains the domain s data, but it receives data over a network from another master server. On previous versions of BIND, the slave server was referred to as a secondary server. Caching-Only Server A caching-only server is not authoritative for any domain. The only function that a caching-only server performs is to look up data from an authoritative server and store the data in its cache. Forwarding Server A forwarding server always forwards queries that it cannot satisfy from its authoritative data or cache to a fixed list of other servers. A forwarding server is typically used when you do not want all the servers at a given site to interact with the rest of the Internet servers. An 64 Configuring and Administering the BIND Name Service

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. A zone describes the domain name space that a name server has authority over. As such, 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. Choosing the Type of Name Server You can use any server configuration on a host. Following are some suggestions for the configuration: You must configure timeshare machines or cluster servers as master or slave servers. If you want the benefits of a name server but do not want to maintain authoritative data, you can set up a caching-only server. Running a caching-only server provides you better performance than querying a name server on a remote system, especially if the remote system is on the other side of a gateway or router. You must configure PCs, workstations that do not want to maintain a server, and other small networked systems to query a name server on another host. Cluster nodes must query the name server on the cluster server. If your network is isolated from the Internet, and your host is the only BIND name server in your organization, you must configure a root name server. See Configuring a Root Name Server (page 87) for information. 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. You must choose hosts that have the most reliable Internet connectivity with the best gateway connections. Name servers for a particular zone need not physically reside within the same domain. In general, zones are more accessible to the rest of the Internet if their name servers are widely distributed, instead of on the premises of the organization that manages the domain. Types of Resource Records Resource records (RRs) are entries in the data files in a name server. Typically, a resource record is of the following format: name ttl class type data Where: name ttl class Specifies the domain name where the RRs are found Specifies the time after which a resource record becomes inactive Specifies an encoded 16-bit value that identifies a protocol family or an instance of a protocol Choosing Name Servers for Your Domain 65

type data Specifies an encoded 16-bit value that specifies the resource record type 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 Global Position (GPOS) Location Information (LOC) Naming Authority Pointer (NAPTR) Network Service Access Point (NSAP) Mail Mapping Information (PX) Responsible Person (RP) Well Known Service (WKS) Key Exchanger (KX) Address (A) Canonical Name (CNAME) Mail Exchanger (MX) Name Server (NS) Pointer (PTR) Service (SRV) Signature (SIG) Start of Authority (SOA) Next (NXT) Key (KEY) Domain Name (DNAME) Quad A record (AAAA) Description Specifies the global position. The GPOS record must be superseded by the LOC record. Specifies the geographic location of the service. LOC enables DNS to carry location information about hosts, networks, and subnets. The LOC record supersedes the GPOS record. Provides rules for mapping certain parts of uniform resource identifiers (URIs) to domain names. By changing the mapping rules, the host that is contacted to resolve a URI can be changed. Maps a domain name to an OSI network service access point address as described in RFC 1706 (The Naming Authority Pointer (NAPTR) DNS Resource Record). NSAP to name translation is accomplished using the PTR RR as described in RFC 1035 (Domain Names - Implementation and Specification). The PTR RR can be used with any NSAP address format. Maps between RFC 822 (Standard for the format of ARPA Internet text) and X.400 addresses. Specifies the responsible person for a domain. Describes the well known services supported by a particular protocol on a particular Internet address. This record must be superseded by the service record. Provides a method to delegate authorization for one node, to provide key exchange services on behalf of one or more nodes. Map host names to IP addresses Specifies an alias for official name of the host, also called the canonical name Specifies a weighted list of hosts that Sendmail tries while sending a mail to a destination Specifies the name servers authoritative for a given domain Maps the IP addresses back to host names Defines the hosts that support the defined services Stores the private key of a key pair in the form of a digital signature on an RRset Designates the start of a domain and specifies that the server is authoritative for the data in the domain Provide a negative response to a domain name search by indicating that the next domain name in lexicographical order is the one specified in this particular RR Stores different kinds of cryptographic keys Provides the capability to map an entire subtree of the DNS name space to another domain Stores the 128-bit IPv6 addresses with an IPv6 reverse mapping domain, ip6.int 66 Configuring and Administering the BIND Name Service

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.domain Files (page 73) Master Server db.net Files (page 75) Adding a Host to the Domain Data Files (page 76) Deleting a Host from the Domain Data Files (page 76) Creating the Data Files for a Master Server The following lists the steps to configure the master name server: 1. Ensure that the /etc/hosts file is updated on the host that you want to configure as the master server. 2. On the host that you want to configure as the master server, create a temporary directory /etc/named.data, where you want to store the name server data files, and make it the current directory: mkdir /etc/named.data cd /etc/named.data 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. Copy the /usr/examples/bind/db.cache file to the /etc/named.data directory. This file is a list of root name servers. You can also use anonymous ftp to get the current list of root name servers from rs.internic.net. Instructions are included in the /usr/examples/bind/db.cachefile. 6. Use the list of root name servers from the /usr/examples/bind/db.cache file or from rs.internic.net to update the /etc/named.data/db.cache file. The hosts_to_named program creates this file but does not add any data to it. The format of the db.cache file is described in Master Server Cache File (page 70). If your network is isolated from the Internet, contact the BIND administrator for your domain to obtain the names and addresses of the root name servers. The hosts_to_named program creates the following data files in the working directory: named.conf db.cache (initially empty) named.boot db.127.0.0 db.ip6.int boot.cacheonly Configuring a Master Name Server 67

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.). The hosts_to_named program completely rewrites the db.domain and db.net files. All the manual modifications to these files are lost when you run the hosts_to_named program again, except the changes to the SOA records. For more information, type man 1M hosts_to_named or man 1M named at the HP-UX prompt. Setting the Default Domain Name If you are using an /etc/resolv.conf file on your host, configure the default domain name with the search or domain keyword. See Configuring the Resolver to Query a Remote Name Server (page 81) for more information. If you are not using an /etc/resolv.conf file, complete the following steps to set the default domain name: 1. Set the default domain name using the hostname command, by appending the domain name to the host name, as shown in the following example: /usr/bin/hostname indigo.div.inc.com 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. Following is an example configuration file for a master server authoritative for the domain div.inc.com, and for the network 15.19.8. # # type domain source file # option { directory /etc/named.data ; }; 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 hint; file db.cache ; }; 68 Configuring and Administering the BIND Name Service

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.conf file for the master server rabbit from the /etc/hosts file: -d div.inc.com name domain -n 15.19.8 net address domain -s rabbit master server -s cheetah slave servers -s indigo -Z 15.19.8.119 master server address -d div.inc.com The configuration file named.conf is as follows: // 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 the nameservers you * 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 * 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 ; Configuring a Master Name Server 69

}; 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 zone type file Indicates the directory where data files are located. Used to define the zone for that domain. Defines the zone type. Used to specify the database file for that zone. NOTE: If you are moving your name server data and configuration files from earlier versions of BIND 8 to this version, then you must migrate your old configuration file format to the new file format. The configuration file in versions prior to BIND 8 was called named.boot. You can convert named.boot to named.conf by executing the following command: /usr/bin/named-bootconf.pl Master Server Cache File named.boot>named.conf The cache file, /etc/named.data/db.cache, lists the root name servers for the root domain. Each name server must have a cache file. When a name server cannot resolve a host name query from its local database or its local cache, the name server queries a root server. The hosts_to_named program creates the db.cache file, but does not enter any data into the db.cache file. To add data to this file, copy data from the file /usr/examples/bind/db.cache. You can also use anonymous ftp to obtain the list of root name servers from rs.internic.net. Following is an example db.cache file for a master server: ; This file holds the information on root name servers ; needed to initialize cache of Internet domain name servers ; (e.g. reference this file in the cache.<file> ; configuration file of BIND domain name servers). ; This file is made available by InterNIC registration ; services under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; ; last update: Nov 5, 2002 ; related version of root zone: 2002110501 ; ; formerly NS.INTERNIC.NET ; name ttl class type data ;. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ;. 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; 70 Configuring and Administering the BIND Name Service

; 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.4 ; ; formerly AOS.ARL.ARMY.MIL ;. 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ;. 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; operated by VeriSign, Inc ; ;. 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 ; ; housed in LINX, operated by RIPE NCC ; ;. 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ;. 3600000 NS L.ROOT-SERVERS.NET 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 The following describes the fields in the db.cache file: ; Lines beginning with a semicolon (;) are comments. name ttl For NS records, name specifies the name of the domain served by the name server listed in the data column. A period (.) in the name column represents the root domain (the root of the DNS name space hierarchy). For A records, the name column contains the name of the name server whose address appears in the data column. The optional time-to-live (ttl) indicates how long (in seconds) a server caches the data received in response to a query. Configuring a Master Name Server 71

class type data 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. 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. For records of type A list, the first field in an A record is the name of the name server. The last field in an A record is the Internet address of the name server. The data field for an NS record provides the fully qualified name of a name server. The data field for an A record specifies an Internet address of the name server. The db.127.0.0 File Each name server must have an /etc/named.data/db.127.0.0 file. Hosts running Berkeley networking use 127.0.0.1 as the address of the loopback interface. Because the network number 127.0.0 is not assigned to any site but is used by all hosts running Berkeley networking, you must configure each name server as authoritative for the network 127.0.0. The file /etc/named.data/db.127.0.0 contains the resource record that maps 127.0.0.1 to the name of the loopback address, usually localhost. The hosts_to_named program creates the /etc/named.data/db.127.0.0 file. The following is an example db.127.0.0 file: ;name class type data $TTL 86400 @ IN SOA rabbit.div.inc.com root.moon.div.inc.com ( 1 ; Serial 10800 ; Refresh every 3 hours 3600 ; Refresh every hour 604800 ; Expires after a week 86400 ) ; Minimum ttl of 1 day IN NS rabbit.div.inc.com 1 IN PTR localhost The following explains the fields in the db.127.0.0 file: name class type This field specifies the name of the subdomain. In the SOA record, the at sign (@) represents the domain name when the domain name and the origin are the same. In the expanded notation, @ represents 0.0.127.in-addr.arpa. Similarly, for the PTR record, 1 represents 1.0.0.127.in-addr.arpa. in the expanded notation. The optional class field specifies the protocol group. IN, for Internet addresses, is the most common class. 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.in-addr.arpa is appended to the 1 in the name field because it does not end with a dot.) data For an SOA record, data includes the name of the host this data file was created on, the mailing address of the person responsible for the name server, and the following values: 72 Configuring and Administering the BIND Name Service

Serial Refresh Retry Expire Minimum ttl Indicates the version number of this file, incremented whenever you change the data. Indicates (in seconds) how often a slave name server must update its data from a master server. Indicates (in seconds) how often a slave server must retry after an attempted refresh fails. Indicates (in seconds) how long the slave name server can use the data before it expires for lack of a refresh. Indicates (in seconds) the minimum number of seconds the name server is allowed to cache data. After the ttl (time to live) value expires, the name server must discard the cached data and obtain new data from the authoritative name servers. The NS data is the fully qualified name of the name server. The PTR data is the loopback address of localhost, in the in-addr.arpa domain. $TTL Indicates (in seconds) the time to live value for records that do not have the ttl value defined in the data field. Master Server db.domain Files A master server has one /etc/named.data/db.domain file for each domain for which it is authoritative. domain is the first part of the domain specified with the -d option in the hosts_to_named command. This file must contain an A (address) record for every host in the zone. The following is an example db.div file: ; ; db.div ; $TTL 86400 @ IN SOA rabbit.div.inc.com root.moon.div.inc.com ( 1 ; Serial 10800 ; Refresh every 3 hours 3600 ; Retry every hour 604800 ; Expires after a week 86400 ; Minimum ttl of 1 day IN NS rabbit.div.inc.com IN NS indigo.div.inc.com localhost IN A 127.0.0.1 indigo IN A 15.19.8.197 IN A 15.19.13.197 IN HINFO HP9000/840 HPUX incindigo IN CNAME indigo cheetah IN A 15.19.8.64 IN HINFO HP9000/850 HPUX IN WKS 15.19.8.64 UPD syslog domain route IN WKS 15.19.8.64 TCP (telnet smtp ftp shell domain) rabbit IN MX 5 rabbit.div.inc.com IN MX 10 indigo.div.inc.com rabbit IN 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. @ is used to represent the domain name when the domain name and the origin are the same. The origin is the domain configured in this file, according to the /etc/named.conf configuration file. Configuring a Master Name Server 73

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 Refresh Retry Expire Minimum ttl Indicates the version number of this file, incremented whenever the data is changed. Indicates (in seconds) how often a slave name server must try to update its data from a master server. Indicates (in seconds) how often a slave server must retry after an attempted refresh fails. Indicates (in seconds) how long the slave name server can use the data before it expires for lack of a refresh. Indicates (in seconds) the minimum number of seconds the name server is allowed to cache data. After the ttl (time to live) value expires, the name server must discard the cached data and obtain new data from the authoritative name servers NS A HINFO CNAME WKS MX $TTL Name Server records. The NS records provide the names of the name servers and the domains for which the domain has authority. The domain for the name servers in the example db.div file is the current origin (div.inc.com), because @ was the last domain specified. Address records. A records provide the Internet addresses for all the hosts in the domain. The current origin is appended to names that do not end with a dot. For example, localhost in the first A record is interpreted as localhost.div.inc.com. Host Information records. The HINFO records indicate the hardware and operating system of the host. Canonical Name record. The CNAME record specifies an alias for a host name. When a name server looks up a name and finds a CNAME record, it replaces the name with the canonical name and looks up the new name. All other resource records must use the canonical name instead of the actual host name. Well Known Service records. The WKS record describes the services provided by a particular protocol on a particular interface. The protocol is any of the entries in the /etc/protocols file. The list of services is as specified in the host s /etc/services file. You can specify only one WKS record per protocol per address. Mail Exchanger records. MX records specify a list of hosts to try when mailing to a destination on the Internet. The MX data indicates an alternate host or list of hosts that accept mail for the target host if the target host is down or inaccessible. The preference field specifies the order a mailer must follow if there is more than one mail exchanger 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. Indicates (in seconds) the time to live value for records that do not have the ttl value defined in the data field. 74 Configuring and Administering the BIND Name Service

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.arpa domain is preceded by four labels corresponding to four bytes (octets) of an Internet address. You must specify each byte even if it is zero. For example, the address 143.22.0.3 has the domain name 3.0.22.143.in-addr.arpa. The four octets of the address are reversed. ; ; db.15.19.8 ; $TTL 86400 @ IN SOA rabbit.div.inc.com. root.moon.div.inc.com.( 1 ; Serial 10800 ; Refresh every 3 hours 3600 ; Retry every hour 604800 ; Expire after a week 86400) ; Minimum ttl of 1 day IN NS rabbit.div.inc.com. IN NS indigo.div.inc.com. 119 IN PTR rabbit.div.inc.com. 64 IN PTR cheetah.div.inc.com. 197 IN PTR indigo.div.inc.com. The example file, db.15.19.8, contains the following records: SOA Start of Authority record. The SOA record indicates that this server is authoritative for the data in the domain. The at sign (@) in the data file represents the current origin. The current origin is the domain configured in this file, according to the configuration file /etc/named.conf. The configuration file indicates that the 8.19.15.in-addr.arpa domain is configured in the db.15.19.8 file. Therefore, every instance of @ in the db.15.19.8 file represents 8.19.15.in-addr.arpa. The SOA record indicates the name of the host this data file was created on, an electronic mailing address of the name server s technical contact, and the following values: Serial Refresh Retry Expire Minimum ttl Indicates the version number of this file, incremented whenever the data is changed. Indicates (in seconds) how often a slave name server should try to update its data from a master server. Indicates (in seconds) how often a slave server should retry after an attempted refresh fails. Indicates (in seconds) how long the slave name server can use the data before it expires for lack of a refresh. Indicates the minimum number of seconds for the time to live field on other resource records for this domain. NS PTR 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. 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.com with the address Configuring a Master Name Server 75

$TTL 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.) 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. Use the following procedure to manually add a host to the domain data files: 1. Edit the db.domain file and add an address (A) resource record for each address of the new host, and add CNAME, HINFO, WKS, and MX resource records as necessary. Then, increment the serial number in the SOA resource record by 1. 2. Edit the db.net file and add a PTR resource record for each host address. Then, increment the serial number in the SOA resource record by 1. 3. Add the host to the /etc/hosts file. CAUTION: If the host is not listed in the /etc/hosts file, and you accidently run the hosts_to_named command, the db.domain and db.net files are overwritten, and the host is lost. See the sections Master Server db.domain Files (page 73) and Master Server db.net Files (page 75) for examples of the db.domain and db.net files. 4. After modifying the domain data files, issue the following command to restart the name server, which forces the name server to reload its databases: /usr/sbin/sig_named restart Deleting a Host from the Domain Data Files You can delete the host from the /etc/hosts file and run the hosts_to_named command to regenerate all the data files for the domain. You can also delete the host manually from all the data files. Use the following procedure to manually delete a host from the domain data files: 1. Edit the db.domain file and delete the A, CNAME, HINFO, WKS, and MX resource records associated with the host. Then, decrement the serial number in the SOA resource record by 1. 2. Edit the db.net file and delete all the PTR resource records for the host. Then, decrement the serial number in the SOA resource record by 1. 3. After modifying the domain data files, issue the following command to restart the name server and force it to reload its databases: /usr/sbin/sig_named restart 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. A slave server loads its data over the network from another name server, usually the master name server, using a zone transfer. The slave server cannot load data from another slave name server. 76 Configuring and Administering the BIND Name Service

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. After it is booted, the slave server checks with the master server to verify that its data is up to date. The slave server can store the authoritative data only in the memory. When this type of slave server boots, it always loads its data from a master server. To set up a slave server, you need the following files: named.conf db.127.0.0 db.cache This section explains how to configure a slave server in your domain. It discusses the following topics: Creating Slave Server Data Files Using hosts_to_named (page 77) Creating the Slave Server s Data Files Manually (page 77) Setting the Default Domain Name (page 79) Creating Slave Server Data Files Using hosts_to_named This section discusses the steps involved in creating the slave server configuration files using the hosts_to_named command. 1. If you want your slave server to store its data in backup files on its disk, run the hosts_to_named command on the slave server as follows: /usr/sbin/hosts_to_named -z primary_server s_ip_address If you want your slave server to always load its data from the master server, run hosts_to_named on the slave server as follows: /usr/sbin/hosts_to_named -Z primary_server s_ip_address 2. If you run hosts_to_named with the -z option, copy the file conf.sec.save from the current directory on the master server to the /etc directory on the slave server. If you run hosts_to_named with the -Z option, copy the file conf.sec from the current directory on the master server to the /etc directory on the slave server. 3. On the slave server, rename /etc/conf.sec.save or /etc/conf.sec to /etc/named.conf. 4. Copy the files /etc/named.data/db.cache and /etc/named.data/db.127.0.0 from the master server to the slave server. The format of the data files copied from the master server is described in Configuring a Master Name Server (page 67). An example named.conf configuration file for a slave server is shown in Creating the Slave Server s Data Files Manually (page 77). 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: Configuring a Slave Name Server 77

1. 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. 2. 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. In every entry containing the word secondary, add the Internet address of the master server after the domain name. If you do not want the slave server to store backup files on disk, delete the last field of every secondary line (the field that specifies the file name). Following are the example /etc/named.conf configuration files for a slave server. Example 1 The following example is a named.conf configuration file for a slave server that does not store the database information in a local file. // 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 * 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 div.inc.com ; { type slave; masters { 15.19.8.119; }; }; zone 8.19.15.IN-ADDR.ARPA { type slave; masters { 15.19.8.119; }; }; zone. { }; Example 2 type hint; file db.cache ; The following example is a named.conf configuration file for a slave server that stores the database information in a local file. 78 Configuring and Administering the BIND Name Service

// 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.0 ; }; zone div.inc.com ; { type slave; file db.div ; masters { 15.19.8.119; }; }; zone 8.19.15.IN-ADDR.ARPA { type slave; file db.15.19.8 ; masters { 15.19.8.119; }; }; zone. { }; type hint; file db.cache ; 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. If the master server contains new data, the slave server saves this new data in the backup file. The format of the data files copied from the master server is described in Configuring a Master Name Server (page 67). Setting the Default Domain Name You can initialize the default domain name either by specifying the domain name in the /etc/resolv.conf file or by specifying the host name using the hostname command in the /etc/rc.config.d/netconf file. If you use an /etc/resolv.conf file on your host, configure the default domain name with the search or domain keyword. See Configuring the Resolver to Query a Remote Name Server (page 81). If you do not use an /etc/resolv.conf file to configure the default domain name, follow these steps: 1. Set the default domain name with the hostname command by appending the domain name to the host name. For example, type the following at the HP-UX prompt to set the default host name to indigo.div.inc.com: Configuring a Slave Name Server 79

/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. The caching-only name server has only one primary entry for the 0.0.127.in-addr.arpa domain (the loopback interface) in the configuration file, and does not have any other entries for primary and secondary. Every time a caching-only server queries other name servers and receives an answer, it caches the responses. Over a period of time, the cache grows to include answers to almost all the queries requested by resolvers querying the caching-only name server. Because the information is not stored in the local files, the additional overhead of zone transfers is not necessary. Hosts running Berkeley networking use 127.0.0.1 as the address of the loopback interface. Because the network number 127.0.0 is not assigned to any one site but is used by all hosts running Berkeley networking, each name server must be authoritative for the network 127.0.0. To create a caching-only server, complete the following steps: 1. 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. 2. Execute the more command on the /etc/named.data/db.127.0.0 file copied from the master server. The following output is displayed: # more db.127.0.0 $TTL 86400 @ IN SOA myhostname.mydomain.com. root.myhostname.mydomain.com. ( 1 ; Serial 10800 ; Refresh every 3 hours 3600 ; Retry every hour 604800 ; Expire after a week 86400 ) ; Minimum ttl of 1 day IN NS myhostname.mydomain.com. 1 IN PTR localhost. In this output, the value for myhostname refers to the hostname of the master server on which the hosts_to_named command was originally run. Replace this value with the hostname of the caching-only server (the local machine). Another alternative would be to replace myhostname.mydomain.com with localhost. 3. 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. If you have created the master server configuration files manually, without runningthe hosts_to_named command, create the configuration file /etc/named.conf for the caching-only server as follows: // generated by named-bootconf.pl options { check-names response fail; //do not change this check-names slave warn; //running directory for named directory /etc/named.data ; //running directory for named /* * If there is a firewall between you and nameservers you 80 Configuring and Administering the BIND Name Service

* 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. See Configuring the Resolver to Query a Remote Name Server (page 81). If you do not use an /etc/resolv.conf file to configure the default domain name, follow these steps: a. Set the default domain name with the hostname command by appending the domain name to the host name. For example, type the following at the HP-UX prompt to set the default host name to indigo.div.inc.com: /usr/bin/hostname indigo.div.inc.com /usr/bin/hostname indigo.div.inc.com b. 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 Do not put a trailing dot at the end of the domain name. Your default domain is now set. Configuring the Resolver to Query a Remote Name Server A name server constitutes the server portion of BIND s client/server mechanism. Resolvers are clients that access the name server. Name servers contain complete information about a particular network segment. Resolvers are library routines that create queries and send them across a network to a name server. A resolver translates a program s request for host information into a query, sends the query to a name server, and translates the response into an answer. Programs running on a host use a resolver to obtain information about a domain. A resolver can perform the following functions: Query a name server. Interpret a response. Return the information to the program. A resolver allows you to configure three aspects of its behavior: the default domain, the search list, and the name servers that the resolver queries. 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. Configuring the Resolver to Query a Remote Name Server 81

Table 2-2 The /etc/resolv.conf Options Option domain default_domain_name; Description 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. The first domain in the search list must be the local domain. The resolver appends these domains, one at a time, to a host name that does not end in a dot, when the resolver constructs queries to send to a name server. The domain and search keywords are mutually exclusive. If you do not specify the search option, the default search list contains only the local domain. nameserver Internet_address The nameserver option followed by the Internet address (in dot notation) of a name server that the resolver must query. You can configure up to three nameserver entries. For information on other /etc/resolv.conf option, type man 4 resolv.conf at the HP-UX prompt. To configure a host to query a name server on a remote host, complete the following steps: 1. Create a file called /etc/resolv.conf on the host and specify the options domain and nameserver. The following is an example /etc/resolv.conf file: domain div.inc.com nameserver 132.22.0.4 nameserver 132.22.0.12 2. If you do not specify the local domain with the search or domain option, set the default domain name with the hostname command, as shown in the following example: /usr/bin/hostname indigo.div.inc.com 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 Do not put a trailing dot at the end of the domain name. NOTE: If you want to run both BIND and HP VUE, you must have an /etc/resolv.conf file on your system, or HP VUE does not start. If you set the LOCALDOMAIN environment variable, any BIND requests made within the context of your shell environment use the search list specified in the LOCALDOMAIN variable. The LOCALDOMAIN variable overrides the domain and search options in /etc/resolv.conf. CAUTION: In order to avoid situations that may cause connections to unintended destinations, you must carefully select the domains that you put in the search list in the /etc/resolv.conf file. HP recommends that you limit the domains in the search list to the domains administered within your trusted organization. For more information on the security implications of search lists, see RFC 1535 (A Security Problem and Proposed Correction With Widely Deployed DNS Software). For more information, type man 4 resolver or man 5 hostname at the HP-UX prompt, or see How BIND Resolves Host Names (page 20). 82 Configuring and Administering the BIND Name Service

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. Configuring Timeout Values Using Environment Variables You can set the retransmission value and the time between each retransmission by using the environment variables RES_RETRY and RES_RETRANS, respectively. The valid values for the RES_RETRY and RES_RETRANS environment variables are positive non-zero integers. By default, the system attempts to retransmit 4 times, and the time interval between each retransmission is 5000 milliseconds. NOTE: You can set the timeout values with the environment variables RES_RETRY and RES_RETRANS only for individual clients. If the environment variables RES_RETRY and RES_RETRANS contain invalid values, the default values are set and an error message is logged in the /var/adm/syslog/syslog.log file. To set the environment variables, type the following export commands at the HP-UX prompt: # export RES_RETRY=1 # export RES_RETRANS=300 This sets the retransmission value to 1 and the time between each retransmission to 300 milliseconds. You can specify the export commands again to change the values for both the environment variables. Do not specify a value less than 200 milliseconds for the RES_RETRANS environment variable. Configuring Timeout Values Using the Configuration File You can specify the retransmission time and the time between each retransmission by using the options retrans and retry, respectively, in the /etc/resolv.conf configuration file. NOTE: You can set the timeout values in the configuration file /etc/resolv.conf only for a specific system. To set the timeout values, add the following lines to the /etc/resolv.conf configuration file after the domain and name server entries. retry 1 retrans 600 This sets the retransmission value to 1 and the time between each retransmission to 600 milliseconds. Configuring Timeout Values Using APIs You can configure the timeout values using the following APIs: set_resfield() get_resfield() Using these two APIs, you can set and get values for the retransmission time and the time between each retransmission in the instance of the a _res_state structure. When you configure the timeout values using the APIs, you must make certain changes to the code and recompile the code. The returned values of the APIs indicate if the specified values are correct. Configuring the Resolver to Set Timeout Values 83

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. 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. The get_resfield() API The syntax for the get_resfield() function is as follows: get_resfield(int field, void *value, sizeof value) The get_resfield() function contains three parameters: field, *value, and value. The parameter field contains the resolver option. The parameter *value is the pointer to the location where the option value is stored. The value parameter specifies the memory (in bytes) allocated for a variable when a function is invoked. The get_resfield() function returns either 0 or -1. It returns a value of 0 if the function successfully gets the value of the field in the value parameter and returns a value -1 on failure. Sample Program with Timeout Values A sample program with timeout values is as follows: main() { int retrans = 600; int retry =1; struct hostent *hp; struct in_addr ia; char *name = localhost ; res_init(); set_resfield(res_retrans, &retrans); set_resfield(res_retry, &retry); hp = gethostbyname (name); if (hp == NULL ) { printf ( gethostbyname failed\n ); herror( Error ); } else { int i; for (i=o; hp->h_addr_list[i]; i++) { memcpy((caddr_t)&ia, hep->h_addr_list[i],\ sizeof(ia)); printf( %s, inet_ntoa(ia)); } } } get_resfield (RES_RETRANS, &retrans, sizeof retrans); get_resfield (RES_RETRY, &retry, sizeof retry); printf ( retry = %d \n retrans = %d\n, retry,retrans); Starting the Name Server Daemon The name server daemon, /usr/sbin/named, must be running on all the master, slave, and caching-only name servers. If you have configured your system to query a remote name server 84 Configuring and Administering the BIND Name Service

(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. 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. Verifying the Name Server You can use nslookup to query the name server interactively by specifying either the host name or the respective IP address of the host. nslookup displays the host name and IP address of the queried host. To check whether the name server is configured properly, perform the following steps: 1. Start nslookup using the following command: /usr/bin/nslookup 2. At the > prompt, specify the name server you want to test in the server command as follows: > server BIND_server_hostname > server indigo.div.inc.com The server command causes nslookup to use the host indigo.div.inc.com as the name server for all the queries. 3. At the > prompt, type the host name for the name server to look up, as in the following example: > charlie charlie is a host in the domain div.inc.com, where indigo.div.inc.com is configured as the name server. Therefore, the following output is displayed at the > prompt: Name Server: indigo.div.inc.com Addresses: 15.19.14.100, 15.19.15.100 Name: charlie.div.inc.com Address: 15.19.9.100 4. In the name server s domain (that is, div.inc.com), look up several host names and IP addresses of hosts and check whether the respective host names and IP addresses displayed are correct. 5. At the > prompt, type the following commands to verify that your name server queries root name servers: > set type=ns. Starting the Name Server Daemon 85

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. 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). 7. Type exit to exit from nslookup. 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/.rhosts You must convert flat or string-type host names that are not hosts in the local domain to fully qualified domain names in the /etc/hosts.equiv file and in all the $HOME/.rhosts files. The shell script convert_rhosts, in the /usr/examples/bind directory, accepts input conforming to the syntax in the /etc/hosts.equiv file and converts it to fully qualified domain names. The comments specified in the beginning of the script file provide instructions on how to use this utility. Updating /var/adm/inetd.sec and $HOME/.netrc You must convert flat or string-type host names that are not hosts in the local domain to fully qualified domain names in the /var/adm/inetd.sec file and in all the $HOME/.netrc files. An automated utility for performing this task is not available, therefore, you must do it manually. Updating /etc/hosts To provide an alternate means of lookup when the name server is down, you must maintain a minimal /etc/hosts file. It must contain the host names and the Internet addresses of the hosts in your local domain. Delegating a Subdomain When your domain reaches a certain size, or you decide to distribute the management of parts of your domain to various entities within your organization, you can divide the domain into subdomains. Within your own domain, you can delegate any number and level of subdomains to distribute control and management responsibility. You need not register these subdomains with the parent network. The organization that owns a zone or subdomain is responsible for maintaining the data and ensuring that up-to-date data is available from multiple, redundant servers. You can create a subdomain without delegating it by specifying resource records that refer to the subdomain within the parent s zone. 86 Configuring and Administering the BIND Name Service

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 A 192.253.253.10 IN MX emp.personnel.div.inc.com To delegate a subdomain, complete the following steps: 1. Set up the name servers for the subdomain. 2. 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. Example of Delegating a Subdomain Consider the domain nmt.edu. and the subdomain plt.nmt.edu. The hosts venus.nmt.plt.edu and moon.plt.nmt.edu are the name servers for the plt.nmt.edu. subdomain. After you set up the name servers for the subdomain plt.nmt.edu, add the following entries in the db.nmt.edu. file to delegate the plt.nmt.edu. subdomain to the new plt.nmt.edu. name servers on venus and moon: plt.nmt.edu 86400 IN NS venus.plt.nmt.edu. 86400 IN NS moon.plt.nmt.edu. venus.plt.nmt.edu. 86400 IN A 123.4.5.678 moon.plt.nmt.edu. 86400 IN A 67.8.9.10 Configuring a Root Name Server The root name servers contain information about where the authoritative name servers for each of the top-level zones are situated. Given a query about a domain name, the root name servers provide at least the names and addresses of the name servers that are authoritative for the top-level zone that the domain name ends with. The top-level name servers also provide the list of the authoritative name servers for the second-level zone that the domain name ends with. Every query to the name server provides information about how to reach the final destination, or provides the actual answer. If you are connected to the Internet, you can use the root servers already available (For a list of root servers, use anonymous ftp to get the file /domain/named.root from rs.intenic.net.) However, if you are on an isolated network, you must set up your own root servers. A root server does not have a cache entry in its configuration file. Instead, it has an entry like the following, which indicates that the server is a master for the root domain: zone. { type master; file db.root ; }; The db.root file typically contains only NS and A resource records for the authoritative name space tree. You can use the hosts_to_named command with the -r option to create the db.root file. For more information, type man 1M hosts_to_named at the HP-UX prompt. The db.cache file on the other name servers in the domain must contain an entry for this root server. A domain can have more than one root name server. Configuring a Root Name Server 87

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.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 NS eduardo.inc.com. 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.7 BIND Logging System The BIND logging system provides control over how the server logs events. The logging system is configured using the logging statement in the /etc/named.conf file. You can do the following using the logging system: Limit incoming messages to a given severity level. Place a limit on the size of the logging file. Manage multiple versions for the logging file (to maintain historic data). Direct the logging messages to any of the syslog facilities. Specify where messages belonging to specific categories are logged. See the section The logging Statement (page 27) for more information and how to use the logging statement. The logging mechanism is established only after the entire configuration file is parsed. When you start named with the -g option, the log messages regarding the configuration file syntax errors are put in stderr. BIND Security This section discusses the security mechanisms implemented in BIND to secure DNS messages and name servers. It discusses the following topics: TSIG-Based Security (page 88) DNSSEC A DNS Security Extension (page 90) TSIG-Based Security Transaction signatures (TSIG) is a mechanism used to secure DNS messages and to provide secure server-to-server communication. This includes zone transfer, notify, and recursive query messages. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages, particularly responses and updates. TSIG is simple to configure, lightweight for resolvers and name servers to use, and flexible to secure DNS messages and dynamic updates. When you configure TSIG, a name server adds a TSIG record to the additional data section of a DNS message. The TSIG record signs the DNS 88 Configuring and Administering the BIND Name Service

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. A minor change to an input 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. { algorithm hmac-md5; secret skrkc4twy/cigiykqu7jza== ; }; The argument to the key statement, venus-mars.div.inc.com, is the name of the key. It is essential that the name of the key (in addition to the binary data the key points to) is identical on both ends of the transaction because the recipient attempts to verify the TSIG record with the same key. The algorithm is hmac-md5 and the secret is base 64 encoding of the binary key. Generating Keys Using TSIG You can use the /usr/bin/dnssec-keygen program to generate keys. A sample directive to invoke the dnssec-keygen program to generate a 768-bit DSA key for the domain example.com is as follows: # /usr/bin/dnssec-keygen -a DSA -b 768 -n ZONE example.com The preceding command generates the key identification string Kexample.com.+003+26160, indicating a DSA key with an identifier 26160. Use the -a option to specify the encryption algorithm. Use the -b option to specify the key size, and use the -n option to specify the nametype. A nametype can be a ZONE, HOST, ENTITY, or USER. The /usr/bin/dnssec-keygen program creates two files in the following format: Knnnn.+aaa+iiiii.key Knnnn.+aaa+iiiii.private For a detailed description of all the supported functions, type man 1 dnssec-keygen at the HP-UX prompt. You can configure the name server to use the keys configured with the TSIG keys by using the keys substatements. The keys substatements inform a name server to sign queries and zone transfer requests sent to a particular remote name server. The following server substatement informs the local name server, moon.div.inc.com, to sign all requests to the host 192.249.249.1 (venus.div.inc.com) with the key venus-moon.div.inc.com: server 192.249.249.1 { keys { venus-moon.div.inc.com. ; }; }; Next, on venus.div.inc.com, you must restrict zone transfers to those signed with the venus-moon.div.inc.com key as follows: BIND Security 89

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. 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. There must be communication with administrators of the parent and the child zone to transmit keys and signatures. To trust its data, the parent zone for a DNSSEC-capable resolver must indicate a zone s security status. For other servers to trust data in this zone, they must either be statically configured with this zone s zone key or with the zone key of another zone above this on in the DNS tree. Validation for wildcard records in secure zones is not fully supported. In particular, a name does not exist response validates successfully even if it does not contain the NXT records to prove the existence of a matching wildcard. You must generate the key files using the dnssec-keygen program. See Creating a Keyset (page 90) for a description of how to generate these key files. NOTE: For using DNSSEC Public Key Cryptography functionality, the OpenSSL library must be installed. However, named continues to run without the OpenSSL library. The OpenSSL libraries are available as part of the core operating system. Creating a Keyset Use the /usr/bin/dnssec-makekeyset program to create a keyset from one or more keys. A sample directive to invoke the dnssec-makekeyset for the key Kexample.com.+003+26160 (generated by the dnssec-keygen program) follows: # /usr/bin/dnssec-makekeyset -t 86400 -s 20007011200000 -e +2592000 Kexample.com+003+26160 The output of this command is a file named example.com.keyset, containing a SIG and KEY record for the ZONE example.com. The option -t is used to specify the TTL value that is assigned to the assembled KEY and SIG records in the output file. The options -s and -e are used to indicate the start time and the end time or expiry date for the SIG records, respectively. For a detailed description of the options, type man 1 dnssec-makekeyset at the HP-UX prompt. Signing the Child s Keyset Use the /usr/bin/dnssec-signkey program to sign a keyset for a child zone. To sign a keyset for a child zone example.com, type the following at the HP-UX prompt: # /usr/bin/dnssec-signkey example.com.keyset Kcom.+003+51944 90 Configuring and Administering the BIND Name Service

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.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. Hence, you need not specify the zone keys for the authoritative zones in the configuration file. The public key for any security root must exist in the configuration file s trusted-keys statement. Compartmentalizing BIND The UNIX operating system has traditionally used a single compartment model. The relatively free access in traditional single compartment systems can lead to problems with malicious software or with compromised programs. Intruders can gain considerable access to the system if they discover a method to exploit the daemon process. If the daemon process runs with an effective UID of 0 while being exploited, this can translate to complete system access. With the use of compartments, you can limit access to only what the process needs. This reduces the amount of damage malicious or exploited programs can cause to the system. You can create one or more ASCII files in the /etc/cmpt directory to define compartments. However, only file names ending with.rules are parsed for compartment definitions. When the system boots up, the compartment configuration is read from the files in the /etc/cmpt directory. The /etc/cmpt/*.rules files define compartments and compartment access rules for local system objects. System objects with compartment access controls defined include file system objects, inter-process communication objects, and network objects. For more information on compartments, enter man 5 compartments or man 4 compartments at the HP-UX prompt. NOTE: system. The HP-UX Security Containment product is available in the core HP-UX operating Enabling Compartments in BIND To enable compartments in BIND, complete the following steps: 1. Copy the sample /usr/examples/bind/named.rules file to the /etc/cmpts directory on the system where you want to run BIND in compartments. 2. To check the rule files, enter the following command at the HP-UX prompt: #setrules p This command previews the setting of rules and parses the rule files. It checks the syntax and semantic errors, but does not rectify the errors. Resolve errors, if any, in the /etc/ cmpts/named.rules file. 3. To enable compartments, enter the following command at the HP-UX prompt: #cmpt_tune e r BIND Security 91

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. 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. To disable the compartments and to reboot the system, enter the following command at the HP-UX prompt: # cmpt_tune d -r Troubleshooting the BIND Name Server This section describes how to identify and correct problems with the BIND name server. It discusses the following topics: Troubleshooting Tools and Techniques (page 92) Problem Symptoms (page 94) Name Server Problems (page 95) Understanding Name Server Debugging Output (page 98) Name Server Statistics (page 100) NOTE: After you configure the BIND name service on your network, the following failures may occur: rcp and remsh may fail with permission denied messages. rlogin may prompt you for a password. These problems are the result of switching to domain names. To correct these problems, you must update other network files. See Updating Network-Related Files (page 86). If you want to run both BIND and HP VUE, you must have an /etc/resolv.conf file on your system, or HP VUE does not start. See Configuring the Resolver to Query a Remote Name Server (page 81). After you configure the BIND name service, sendmail uses the name server s mail exchanger (MX) records for mail routing. See the HP-UX Mailing Services Administrator s Guide at the URL http://www.docs.hp.com /hpux/netcom/index.html#internet%20services for information on Sendmail. Troubleshooting Tools and Techniques This section describes the available tools for troubleshooting the BIND name server. The ping Command Use the ping command to test whether you can look up a specific host name. You can also use it to check network connectivity to the name server. $ /usr/sbin/ping hostname 92 Configuring and Administering the BIND Name Service

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. 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.html#internet%20services for more information on syslogd. Name Server Debugging By default, all the error messages are logged in the /var/adm/syslog/syslog.log file. You can configure named to log only the name server messages by specifying the debug level when you start named. To turn on named debugging, issue the following command: # named -d debug_level The debugging output is written to the named.run file in the name server s working directory. You must use controls to start the name server debugging when named is already running, or if you want to turn off debugging. To change the debugging level of the name server that is already running at debug level 1, run the following command: # rndc trace 2 To turn off debugging on a name server that is already running at debug level 2, run the following command: # rndc notrace You can also kill the named process and restart named with or without the debugging option. See Understanding Name Server Debugging Output (page 98) for more information on the debugging output. For more information on rndc, see The rndc Utility (page 21). Depending on the amount of information the name server provides, BIND offers various debugging levels. The lower the debugging level, the less information is written to the named.run file. Higher debugging levels provide more information, but occupy more disk space. The default debugging level is 0. The debugging information is cumulative, that is, level 2 includes all of level 1 s debugging information, and so on. BIND provides the following debugging levels: 1 This is the most useful debug level. It logs the basic name server operations: zone loading, maintenance (including SOA queries, zone transfers and zone expiration, and cache cleaning), NOTIFY messages, queries received, and high-level tasks dispatched. 2 This level logs multicast requests. 3 This level logs the low-level task creation and operation and journal activity, such as when the name server writes a record of a zone change to the zone s journal or when the name server applies a journal to a zone at startup. This level also logs the operation of the DNSSEC validator and checking of TSIG signatures. Troubleshooting the BIND Name Server 93

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. 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. 90 This level logs low-level operation of the BIND 9 task dispatcher. At certain debugging levels, the actual packets are displayed. See RFC 1035 (Domain Names Implementation and Specification) for the format of DNS packets. Dumping the Name Server Database You can also track BIND problems by understanding the name server s internal database dump. You can use the rndc command to dump named s authoritative data, cached data, and hints data to the file, named_dump.db, in BIND s working directory. Issue the following command to generate the dump file, named_dump.db: # rndc dumpdb For more information on the rndc command, type man 1M rndc at the HP-UX prompt. Problem Symptoms This section describes symptoms of common name server problems, and lists possible problems to check for. A description of the problems appears in Name Server Problems (page 95). After configuring the master server for the first time, names in the local domain cannot be found. Check the following: Problem 2, Syntax Errors Problem 1, Incorrect hosts_to_named Parameters Problem 8, Local Domain Not Set After configuring the master server for the first time, names in the local domain can be found, but names in remote domains fail. Check the following: Problem 3, Missing Cache Information Problem 5, Network Connectivity Problem 7, Incorrect Delegation of Subdomain After configuring the local host to use a remote server, all name lookups fail, or only names in the NIS database or /etc/hosts are found. The server on the remote host is configured properly. Check the following: Problem 4, Syntax Errors in /etc/resolv.conf Problem 8, Local Domain Not Set Problem 9, /etc/nsswitch.conf Not Configured Correctly A remote name lookup now fails that has completed successfully before. Check the following: Problem 5, Network Connectivity Problem 2, Syntax Errors 94 Configuring and Administering the BIND Name Service

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. 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. Check the domain data files to be sure they contain records for the hosts in your domain. If localhost is the only host listed, you may have supplied incorrect domain names or network numbers to hosts_to_named. 2. Syntax error in the named.conf file or a data file. syslogd Syntax error messages are logged indicating the file name and line number. Name server debugging output Start the name server at debug level 1. Look for syntax error messages in /var/tmp/named.run indicating the file name and line number. ping hostname If ping indicates that the host is unknown and the local name server should be authoritative for that name, the syntax error is probably in the file that maps host names to Internet addresses, db.domain. 3. Missing cache information about the root servers. Without information about the root servers, names outside of the local domain cannot be looked up because the local server relies on the root servers to direct it to servers for other domains. syslogd Queries for names outside of the local domain cause syslogd to log the following message: No root name servers for class 1. (Class 1 is the IN class.) nslookup nslookup may fail to look up the local host s name on startup and give a servfail message. To verify root server information, execute the following: $ nslookup > set type=ns >. Troubleshooting the BIND Name Server 95

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.) Dumping the name server database No root server data appears in the Hints section at the end of the file /var/tmp/named_dump.db. 4. Syntax errors in /etc/resolv.conf (for remote server configuration only). This assumes that the server on the remote host is configured properly. Errors in /etc/resolv.conf are silently ignored by the resolver code. ping IP_address or ping hostname Only names in the NIS database or /etc/hosts file can be looked up. ping the remote server s address to verify connectivity. Name server debugging output Turn on debugging on the remote server. Verify that it is receiving queries from the local host. If queries are not being received, examine the name server entries in /etc/resolv.conf and verify network connectivity to the remote server. 5. Network connectivity problems may cause certain lookups to fail. See the Installing and Administering LAN/9000 Software manual for information on troubleshooting network connectivity. Name server debugging output Turn on debug level 1. Use ping on the host name. Examine the name server debugging output in /var/tmp/named.run for lines like this: req: found `cucard.med.columbia.edu as `columbia.edu resend(addr=1 n=0) -> 128.59.32.1 6 (53) nsid=18 id=1 0ms resend(addr=2 n=0) -> 128.59.40.130 6 (53) nsid=18 id=1 0ms resend(addr=3 n=0) -> 128.103.1.1 6 (53) nsid=18 id=1 764ms In this case the name server tries to contact the columbia.edu name servers but does not get a response. Use ping on the addresses the server is trying to contact to verify network connectivity. If the addresses being tried are the root name servers, either the host does not have connectivity to these machines, or the root server addresses are wrong. nslookup nslookup times out while trying to look up the name. ping hostname A message is returned saying that the host is unknown. 96 Configuring and Administering the BIND Name Service

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. These could show that the other server is unreachable, the other server is not authoritative for the domain, or the local SOA serial number is higher than the remote SOA serial number for this zone. ping IP_address Verify connectivity to the server the secondary is trying to load from. If the host is temporarily unreachable, the slave server will load when it is reachable. nslookup Use nslookup and set the name server to the master the secondary is trying to load from. $ nslookup > server server_name or IP_address > ls domain The ls command initiates a zone transfer. If the error message is No response from server, then no server is running on the remote host. If the ls command succeeds, the secondary should be able to load the data from this server. 7. Incorrect subdomain delegation may be caused by missing or incorrect NS or A records in the parent server for the subdomain. nslookup Use nslookup to query the parent server for delegation information. Execute the following: $ nslookup > server parent_server_name or IP_address > set type=ns > subdomain_name This must show you the NS and A records for the subdomain servers, as seen in the following example. In the example, the subdomain is delegated correctly. hershey.div.inc.com:rootk> nslookup Default Name Server: hershey.div.inc.com Addresses: 15.19.14.100, 15.19.15.100 hershey is the default name server for this host. > server eduardo.doc.inc.com. Default Name Server: eduardo.doc.inc.com Address: 15.19.11.2 Set the default name server to be this subdomain s parent server, eduardo. > set type=ns > div.inc.com Name Server: eduardo.doc.inc.com Address: 15.19.11.2 Set query type to ns (name server). Look up the div.inc.com domain. Troubleshooting the BIND Name Server 97

Non-authoritative answer: div.inc.com div.inc.com nameserver = walleye.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 inet address = 15.19.13.197 friday.div.inc.com inet address = 15.19.10.74 Address records for the name servers for div.inc.com. Dumping the name server database Because the name server caches information, a database dump can be searched for the NS and A records for the subdomain. If no NS or A records exist, the parent server for the subdomain or the root servers are not reachable. If NS and A records exist, check their correctness. Then try pinging the addresses of the name servers to see if they are reachable. Name server debugging output Turn on debugging to level 1 and try to look up a name in the domain. Verify the debug output for name server retransmissions. This indicates which servers are not responding. Verify that the servers and their addresses are correct, if possible. 8. The local domain is not set. The local domain is used to complete names that do not end with a dot. To set the local domain, either set the host name (hostname) of the local system to a domain name (without a trailing dot), or add a domain entry to /etc/resolv.conf. nslookup nslookup gives a warning that the local domain is not set. Name server debugging output The debug output at level 1 shows names being looked up that are not domain names. ping hostname hostname is found only when it is a completely specified domain name (with or without a trailing dot). 9. The /etc/nsswitch.conf file, if it exists, is not configured correctly. If you want to query BIND before querying NIS or the /etc/hosts file, make sure dns is listed first on the hosts line. See the HP-UX Internet Services Administrator s Guide for information on how to configure the name service switch. 10. The /etc/hosts file or NIS contains incorrect data. The name service switch (/etc/nsswitch.conf) allows host name lookups in /etc/hosts or NIS, and one of those databases contains incorrect data. For information on configuring the /etc/hosts file, see the HP-UX Internet Services Administrator s Guide for information on how to edit the /etc/hosts file. For information on NIS, see NIS Administrator's Guide. Understanding Name Server Debugging Output To diagnose problems in the debugging output of the name server, you need to know what output from a successful query looks like. The following two examples show output from successful host name lookups. The first example does not involve any retransmissions, while the second example does. Note that debugging output looks the same whether it comes from a master, slave, or caching-only server. Example 1: No Retransmissions Debug turned ON, Level 1 98 Configuring and Administering the BIND Name Service

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.19.15.15 6 (53) nsid=33 id=1 0ms datagram from 15.19.15.15 port 53, fd 6, len 51 send_msg -> 15.19.10.14 (UDP 7 4258) id=1 Debug turned OFF, Level 1 In the first group of four lines, a query is received for john.dept.inc.com. The query is forwarded to a root server, ns.inc.ddn.mil, at address 192.67.67.53 In the second group of four lines, ns.nic.ddn.mil responds with NS records for inc.com. In the third group of four lines, the inc.com server responds with NS records for dept.inc.com. In the fourth group of four lines, the dept.inc.com server responds with the address of john. The local server responds with the answer to 15.19.10.14. Following are detailed explanations of certain lines from the previous example. Debug turned ON, Level 1 The name server was already running. The first level of debugging was turned on with sig_named debug 1. datagram from 15.19.10.14 port 4258, fd 6, len 35 This line shows the IP address of the host that generated the query, the port that the request comes from, the file descriptor that the name server received the query on, and the length of the query. req: nlookup(john.dept.inc.com) ID 1 type=1 This message was logged from the routine that handles requests. Shown are the name looked up, the packet ID (used to determine duplicate requests), and the type (as defined in /usr/include/arpa/nameser.h). Type 1 is an address query. req: found 'john.dept.inc.com' as 'inc.com' (cname=0) Because the server is authoritative for div.inc.com, it has an entry for inc.com in its database. The only data at inc.com is the subdomain entry for div. This line does not indicate what was found at inc.com. Because the server sent the next query to a root name server, you can conclude that there were no NS records for inc.com. For more information, including the domain for which the queried server is authoritative, check Debug level 3. Debug levels are explained in Name Server Debugging (page 93). forw: forw -> 192.67.67.53 6 (53) nsid=29 id=1 0ms retry 4 sec The query was forwarded to 192.67.67.53. The name server tags each query it sends out so that it can detect duplicate responses. Here the assigned ID is 29. The original ID was 1. The query will be retried in four seconds. resp: found 'john.dept.inc.com' as 'inc.com' (cname=0) After the response from the root server, the database is searched again. inc.com is found once again. The next query goes to an inc.com server, so this time there were NS records. datagram from 15.19.11.2 port 53, fd 6, len 119 This datagram is from another name server because it is from port 53. Because the example server sent a query to 15.19.11.2, you can assume this is the response. Troubleshooting the BIND Name Server 99

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. When the local server receives the resolver retransmissions, it discards them as duplicates if it is still processing the first request. datagram from 15.19.10.14 port 4253, fd 6, len 41 req: nlookup(cucard.med.columbia.edu) id 1 type=1 req: found cucard.med.columbia.edu as edu (cname=0) forw: forw -> 128.9.0.107 6 (53) nsid=17 id=1 1478ms retry 4 sec datagram from 128.9.0.107 port 53, fd 6, len 212 resp: nlookup(cucard.med.columbia.edu) type=1 resp: found cucard.med.columbia.edu as columbia.edu (cname=0) resp: forw -> 128.59.16.1 6 (53) nsid=18 id=1 0ms datagram from 15.19.10.14 port 4253, fd 6, len 41 req: nlookup(cucard.med.columbia.edu) id 1 type=1 req: found cucard.med.columbia.edu as columbia.edu (cname=0) resend(addr=1 n=0) -> 128.59.32.1 6 (53) nsid=18 id=1 0ms resend(addr=2 n=0) -> 128.59.40.130 6 (53) nsid=18 id=1 0ms datagram from 15.19.10.14 port 4253, fd 6, len 41 req: nlookup(cucard.med.columbia.edu) id 1 type=1 req: found cucard.med.columbia.edu as columbia.edu (cname=0) resend(addr=3 n=0) -> 128.103.1.1 6 (53) nsid=18 id=1 764ms datagram from 128.103.1.1 port 53, fd 6, len 57 send_msg -> 15.19.10.14 (UDP 7 4253) ID=1 Following are detailed explanations of certain lines from this example. req: nlookup(cucard.med.columbia.edu) id 1 type=1 This message is logged from the routine that handles requests. The following shows the name looked up, the packet ID (used to determine duplicate requests), and the type (as defined in /usr/include/arpa/nameser.h). Type 1 is an address query. resend(addr=1 n=0) -> 128.59.32.1 6 (53) nsid=18 id=1 0ms Because no response is received from 128.59.16.1, the query with nsid 18 is resent to other servers. datagram from 15.19.10.14 port 4253, fd 6, len 41 req: nlookup(cucard.med.columbia.edu) id 1 type=1 This is received from the same IP address and port and has the same length and ID as the preceding datagram. It is a duplicate and thus forw discards it. These two lines are repeated three times throughout the trace. The queries came from the same IP address and port, and have the same ID and length in each case. Thus, these are all the same query. The resolver sends the query three times because the name server did not respond. The name server detects that the second and third are duplicates and discards them because the duplicates did not get to the forw line. Name Server Statistics The name server keeps track of various statistics. You can print these statistics to the file /var/tmp/named.stats by issuing the following command: /usr/sbin/sig_named stats 100 Configuring and Administering the BIND Name Service

Statistics are appended to the file. The statistics look similar to this: 1273431 29802 326031 327165 284353 0 214 50109 70 220220 63919 0 23 4 4 0 0 0 47921 2054 8216 35909 10569 424 179263 time since boot (secs) time since reset (secs) input packets output packets queries iqueries duplicate queries responses duplicate responses OK answers FAIL answers FORMERR answers system queries prime cache calls check_ns calls bad responses dropped martian responses Unknown query types A queries CNAME queries SOA queries PTR queries MX queries AXFR queries ANY queries The first two lines print out the number of seconds that the name server has been running and the number of seconds since the last restart caused by a SIGHUP signal. To convert these values to days, divide by 86,400 (the number of seconds in a day). input packets is the number of datagrams received by the name server. The datagrams come from the resolver code compiled into the services and from queries and responses from other name servers. output packets is the number of datagrams sent by the name server. These datagrams are responses to resolver queries, queries from other name servers, and system queries. Because queries to other name servers may not be answered, there will probably be more output packets than input packets. queries is the number of queries received by this name server. Because the name server can handle datagram and stream connections, there can be more queries than input packets. The total number of queries is the sum of all the counts of different query types listed in this statistics dump, starting with unknown query types. iqueries is the number of inverse queries. Inverse queries can be used to map a host address to a domain name, although PTR queries are the normal method. Some versions of nslookup send inverse queries when they are starting up. Troubleshooting the BIND Name Server 101

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. If the remote server responds to the original query and responds to the retransmitted query, the local name server discards the second response as a duplicate. OK answers is the number of responses to queries that contain some information. 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. The system query is an attempt to find the address data for that name server. System queries are also used to keep up-to-date information about the name servers for the root domain. prime cache calls are calls to update the information about the name servers for the root domain. check_ns calls are calls to check the state of the information about the name servers for the root domain. bad responses dropped are responses from remote name servers that are dropped. These occur most often when the remote name server responds with SERVFAIL, indicating a problem with the server s domain data. martian responses are responses from unexpected addresses. The name server keeps track of how long it takes for a remote name server to respond. If the remote name server is a multi-homed host, a query to one of the addresses may result in a response from another of its addresses. If the local server does not know about this other address, the response is counted as a martian response. unknown query types are queries for data types unknown to this server. A queries are queries for the host address for a domain name. The gethostbyname library routine generates these address queries. CNAME queries are queries for the canonical name for a domain name. Some versions of sendmail query for CNAME records during name canonicalization from $[$] tokens in /var/adm/sendmail/sendmail.cf. SOA queries are queries for the start of authority records. These queries are most often made by slave servers over a stream connection to check if their domain data is current. PTR queries are queries for the domain name for a host address. The gethostbyaddr library routine generates these queries. MX queries are mail exchanger queries made by sendmail during the delivery of electronic mail. AXFR queries are the number of zone transfers done by slave servers. A slave server first makes an SOA query and follows that with an AXFR query if new domain data should be transferred. ANY queries are queries for any data associated with the domain name. Some versions of sendmail make queries for ANY data during name canonicalization from $[$] tokens in /var/adm/sendmail/sendmail.cf. 102 Configuring and Administering the BIND Name Service

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. These protocols are implemented on the Internet User Datagram Protocol (UDP). Therefore, you can use these protocols across networks that support UDP. This chapter explains how to manually configure the BOOTP and TFTP servers for your network from the HP-UX prompt. Examples are provided to help you configure the servers. You can also use HP System Management Homepage (HP SMH), the online configuration interface, to configure BOOTP and TFTP servers. The troubleshooting section explains corrective measures to recover from problems that may occur while using the BOOTP and TFTP servers. DHCPv6 is a superset of BOOTP and you can configure DHCPv6 using HP System Management Homepage (HP SMH). NOTE: BOOTP is not supported over the X.25 link product or networks using the PPL (SLIP) product. The following topics are discussed in this chapter: Configuring the BOOTP Server (page 103) Adding Client or Relay Information (page 104) Configuring the TFTP Server (page 110) Command Options for Using TFTP (page 111) Troubleshooting BOOTP and TFTP Servers (page 112) Configuring the BOOTP Server To manually configure the BOOTP server daemon, bootpd, you need to add entries to the files /etc/services and /etc/inetd.conf. If you use HP SMH to configure the BOOTP server, entries are made to the appropriate files automatically. The following sections explain the manual method for configuring and verifying bootpd. NOTE: You must log in as a root user to configure the BOOTP server. Procedure for Configuring bootpd Configuring bootpd sets up your local system to act as a server of boot information for remote clients. To manually configure bootpd, complete the following steps: 1. Make sure that the BOOTP server and client protocols are added to the /etc/services file: bootps 67/udp # Bootstrap protocol server bootpc 68/udp # Bootstrap protocol client 2. Uncomment the following entry in the /etc/inetd.conf file: bootps dgram udp wait root /usr/lbin/bootpd bootpd 3. Reconfigure /usr/sbin/inetd using the following command: /usr/sbin/inetd -c Configuring the BOOTP Server 103

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. On the host where you configured bootpd, use bootpquery to send a boot request to the server. For example, if you configure bootpd on a system named myhost, enter the following command: /usr/sbin/bootpquery 001122334455 -s myhost A bootrequest is sent to the server, requesting a bootreply for the client with hardware address 001122334455. Ensure that the /etc/bootptab file contains the configuration information for the hardware address queried using bootpquery. For more information on the bootquery command, type man 1M bootpquery at the HP-UX prompt. 2. To determine if the BOOTP server is running, type the following command on myhost: ps -ef grep bootpd The following message displays if bootpd is running: root 20424 494 1 10:51:45? 0.00 bootpd 3. If your system is configured to use syslogd, bootpd logs messages to the daemon facility. For more information, type man 1M syslogd at the HP-UX prompt. In the default configuration, where syslogd sends daemon information messages to the /var/adm/syslog/syslog.log file, the following messages are logged in the /var/adm/syslog/syslog.log file: Mar 23 10:51:09 myhost bootpd[20413]: reading /etc/bootptab Mar 23 10:51:09 myhost bootpd[20413]: read 1 entries from /etc/bootptab Mar 23 10:51:09 myhost bootpd[20413]: reading /etc/dhcpdeny Mar 23 10:51:09 myhost bootpd[20413]: error opening /etc/dhcpdeny : No such file or directory These messages inform that bootpd was able to read the /etc/bootptab configuration file. After verifying that bootpd is configured to start from inetd, you can now add to the configuration file any BOOTP clients that the system is to serve, or any BOOTP clients that are to be relayed to another server. See Adding Client or Relay Information (page 104) for more information on how to add client information or relay information and how to verify that the BOOTP server responds to the client. Adding Client or Relay Information To allow a client to boot from your local system or to allow a bootrequest to be relayed to the appropriate boot server, you must add information about the client in the /etc/bootptab file. bootpd uses the /etc/bootptab file as the database for two types of entries: Client entries: These entries contain information that allows the clients to boot from your system. Relay entries: These entries contain information to relay the bootrequest to one or more BOOTP servers. 104 Configuring the BOOTP and TFTP Servers

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. Gateway address the gateway from the client s local subnet. Boot file the name of the file that the client retrieves using tftp. Collecting Relay Information To make a relay 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 (IEEE 802.3 or Ethernet). Link level address the client s hardware address. Subnet mask the mask that is used to identify the network address where the client resides. Gateway address the address of the gateway that connects the client s local subnet to the BOOTP server s subnet. Boot servers for client the boot servers to which the local system relays the client s bootrequest. Threshold value the number of seconds since the client sent its first request. Maximum hops the maximum number of hops that the client s bootrequest can be forwarded. Understanding Boot File Configurations A configuration entry is a single line in the following format: hostname:tag=value:tag=value:...tag=value Each client parameter is defined with a two-character case-sensitive tag followed by the equals sign (=) and the tag s client-specific value. A colon separates each tag=value parameter definition. bootpd uses these tags and values to recognize a client s bootrequest, supply parameters in the bootreply to the client, or relay the bootrequest. For example, parameters for the BOOTP client xterm01 are represented with the following entry in the /etc/bootptab file: xterm01: ht=ether: ha=080009030166: ip=15.19.8.2:\ sm=255.255.248.0: gw=15.19.8.1: bf=/xterm01 This entry gives bootpd the following information about xterm01: Hardware type is an Ethernet network interface. Hardware address is 080009030166. IP address is 15.19.8.2. Subnet mask is 255.255.248.0. The address of the gateway is 15.19.8.1. The file /xterm01 must be retrieved with TFTP. Adding Client or Relay Information 105

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. You can extend a single client entry over multiple lines if you use a backslash (\) at the end of each line. Blank lines and lines that begin with the pound sign (#) are ignored. Parameter Tags and Descriptions Table 3-1 describes the tags most commonly used to define the client parameters. For more information on the different types of tags, type man 1M bootpd at the HP-UX prompt. Table 3-1 Tags for Defining Client Options in the /etc/bootptab File Tag Name ba bf bs ds gw ha hd hn ht ip sm tc vm Description Forces bootpd to broadcast the bootreply to the client s network. Use this tag only while troubleshooting the bootpquery program. Specifies the boot file name that the client downloads with TFTP. Specifies the boot file size in 512-byte blocks. If you do not specify a value for this tag, the server automatically calculates the boot file size at each request. Specifies the IP addresses of the BIND name servers. Specifies the IP addresses of the gateways for the client s subnet. Specifies the client s hardware address. Specifies the directory to which the boot file is appended (See bf tag). The directory specified must end with a slash (/). The default is the root directory (/). Sends the host name in the bootreply. This tag is strictly Boolean; it does not need an equal sign or an assigned value. Specifies the client s hardware type. You can assign the value ieee or ether. If used, this tag must precede the ha tag. Specifies the BOOTP client s IP address. You must enter only one IP address for this tag. This tag distinguishes a boot entry from a relay entry. Specifies the subnet mask for the client s network. Specifies previously listed entry that contains tag values that are shared by several client entries. Specifies the format of the vendor extensions on the bootrequest and bootreply. Possible values are auto (the bootreply uses the format used in the bootrequest), rfc1048 (the most commonly used format, described in RFC 1048), and cmu (another format used by some BOOTP clients). If you do not specify the vm tag, the bootreply uses the format sent by the client in the bootrequest. Table 3-2 describes the tags most commonly used to define the relay parameters. For more information on these and the other tags available, type man 1M bootpd at the HP-UX prompt. 106 Configuring the BOOTP and TFTP Servers

Table 3-2 Tags for Defining Relay Options in bootptab Tag Name bp ha hm hp ht tc Description 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. Client s hardware address. 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. Maximum number of hops for the entry. Default is 4. Client s hardware type. For information on supported hardware types and the corresponding values, type man 1M bootp at the HP-UX prompt. If used, this tag must precede the ha tag. Specifies previously listed entry that contains tag values that are shared by several client entries. A relay entry can contain relay parameters for an individual system or for a group of systems. If a BOOTP client does not have an individual entry in the BOOTP server s /etc/bootptab file, the group relay entries are searched. The first group relay entry that matches the BOOTP client is used. Examples of Adding BOOTP Clients This section shows examples of adding entries to the /etc/bootptab file. The first example shows how to configure a BOOTP server for an HP 700/X terminal. The second example shows how to configure a BOOTP server to relay a client s bootrequest to another server. Example 1: Adding an HP 700/X Terminal as a Client Figure 3-1 shows the network configuration for this example. Figure 3-1 Example Configuration: HP 700/X Terminal as Client You must add the following information to the /etc/bootptab file on the BOOTP server (hpserver): xterm01: hn: ht=ehter: ha=080009030165: \ ip=15.19.8.37: sm=255.255.248.0: \ gw=15.19.8.1: ds=15.19.8.119: bf=/xterminal To verify the new /etc/bootptab entry, do the following on the BOOTP server: 1. Add the ba (broadcast address) tag to the entry so that the bootreply is not sent directly to xterm01. This allows the bootpquery diagnostic tool to intercept any bootreply packets for xterm01. Adding Client or Relay Information 107

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: ba 2. 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.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. Example 2: Adding a Relay Entry Figure 3-2 shows the network configuration for a BOOTP relay agent. Figure 3-2 Example Configuration: Relay Entry In this example, the network contains HP workstations and other vendors systems. Server B is the BOOTP server that contains boot information for the HP workstations. When Server A receives a bootrequest, it relays requests from HP workstations to Server B. Bootrequests for other vendors systems are relayed to Server C. In this example, Server A (the BOOTP relay agent) is also the gateway between the client s network and the server s network. The following information is added to the /etc/bootptab file on BOOTP Server A: 108 Configuring the BOOTP and TFTP Servers

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). The following information is added to the /etc/bootptab file on BOOTP Server B: xterm02: hn: ht=ether: ha=08000902ca00: \ ip=15.19.8.39: sm=255.255.248.0: \ gw=15.19.8.1: ds=15.19.8.119: bf=/xterminal: 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.119: bf=/xterminal ba The bootreply is not sent directly to xterm02 but broadcasted to ba. This allows the bootpquery diagnostic tool to intercept any bootreply packets for xterm02. 2. If you can boot the client in standalone mode, run the bootpquery tool on the client to check how bootpd on the server responds to a request from xterm02. For the example configuration, you can run the following query (as superuser): # /usr/sbin/bootpquery 08000902CA00 You can also run bootpquery from another machine running on the same subnet as the client. The following output is displayed: Received BOOTREPLY from hpserver.hp.com (15.4.3.136) Hardware Address: 08:00:09:02:CA:00 Hardware Type: ethernet IP Address: 15.19.8.39 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: xterm02.hp.com This shows that the BOOTP server responded with information that corresponds to the client entry in the /etc/bootptab file. You can also conclude that the bootrequest was correctly relayed to the BOOTP server that contains the client s boot information. 3. Remove the ba tag entry from the /etc/bootptab file. Adding Client or Relay Information 109

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. For more information, type man 1M tftpd at the HP-UX prompt. If you use HP SMH to configure your system as a BOOTP server, your system is automatically configured as a TFTP server. The following section explains how to manually configure and verify tftpd. NOTE: You must log in as a root user to configure the TFTP server. Procedure for Configuring tftpd To manually configure tftpd, you can follow either of the following methods: Method 1 Add the user tftp to the /etc/passwd file. For example: tftp:*:510:10:tftp:/home/tftpdir:/usr/bin/false 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. If you create an /etc/passwd entry for the user tftp, tftpd first looks for a file relative to the home directory of the user tftp. If tftpd does not find the file in the home directory, then it looks for the file relative to the paths specified with the tftpd command. If you want to give remote systems permission to retrieve a file through TFTP, the file must be readable by the user tftp. If you want to give remote systems permission to transmit a file to your system through TFTP, the file must be writeable by the user tftp. For example, create a home directory for the user tftp, make the user tftp the directory owner, and ensure that the directory gives the user tftp read, write, and execute permissions. For example: $ mkdir /home/tftpdir$ $ chown tftp /home/ftpdir $ chgrp guest /home/tftpdir $ chmod 700 /home/tftpdir Method 2 Specify the files available to clients in the tftpd entry in the /etc/inetd.conf file as follows: For IPv4 address: tftpd dgram udp wait root /usr/lbin/tftpd tftpd [path...] For IPv4 and IPv6 address tftpd dgram udp6 wait root /usr/lbin/tftpd tftpd [path...] [path...] is a list of the files or directories that you want to make available to TFTP clients. File or directory names are separated by spaces. Each file or directory is assumed to be relative to the root directory (.). Reconfigure /usr/sbin/inetd using the following command: 110 Configuring the BOOTP and TFTP Servers

/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. NOTE: HP recommends that you use Method 1 to configure tftp on your system. Verifying the tftpd Installation To verify the tftpd installation, create a file and use the tftp program to perform a file transfer using the following steps: 1. Create a file that is readable by the user tftp. The file must be in the user tftp s home directory or in a directory specified with the tftpd entry. For example: $ echo Hello, this is a test. > /export/testfile $ chown tftp /export/testfile $ chmod 400 /export/testfile Make sure that an /etc/passwd entry exists for the user tftp. 2. Using a TFTP client, try to retrieve the file: $ tftp localhost tftp> get /export/testfile Received 24 bytes in 0.6 seconds tftp> quit 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 112). 3. Compare the ASCII files to verify data transfer: $ diff testfile /export/testfile $ If the diff command outputs 0 or nothing, both the ASCII files are the same, which means tftp has transferred the data properly. 4. Remove the test file after you have verified the installation. Command Options for Using TFTP Internet Services includes /usr/bin/tftp, a TFTP client implementation. You can use this client to verify if the TFTP server is working properly. For example, to retrieve the file bootf from the TFTP server duncan, run the following command: # /usr/bin/tftp duncan At the tftp prompt, enter: tftp> get bootf The following message displays indicating a successful data transfer: Received 23 bytes in 0.1 seconds Table 3-3 describes the most common tftp commands that you can use when transferring files. For information on other tftp options, type man 1 tftp on the HP-UX prompt. Command Options for Using TFTP 111

Table 3-3 tftp File Transfer Options Option ascii binary get remote_file [local_file] get [IPv6_address]:remotename localname put local_file [remote_file] put localfile [IPv6_address]:remotefile verbose Description Sets the TFTP file transfer type to ASCII. This is the default type. Sets the TFTP file transfer type to binary. 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. Invokes the get command with an IPv6 address. The IPv6 address must be enclosed in a pair of square brackets ([ and ]). Copies local_file to remote_file. If remote_file is unspecified, tftpd assigns the local_file name to the remote_file name. Invoke the put command with an IPv6 address. The IPv6 address must be enclosed in a pair of square brackets ([ and ]). When verbose is on, tftpd displays responses from the server host. When verbose is on and a file transfer completes, tftpd reports information about the efficiency of the transfer. Enter the verbose command at the tftpd> prompt to turn the verbose setting on or off. Troubleshooting BOOTP and TFTP Servers This section outlines techniques that can help you diagnose and correct common problems with the BOOTP and TFTP servers. 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. This logging level causes bootpd to log useful debugging messages about how bootpd replies to BOOTP clients. Follow these steps to set the debug log level: 1. Add the -d 2 option to the bootpd line in the /etc/inetd.conf file as follows: bootps dgram udp wait root /usr/lbin/bootpd bootpd -d 2 2. Reconfigure inetd with the following command: /usr/sbin/inetd -c 3. Kill any bootpd daemon that is still running on your system. For example: Common bootpd Problems $ /usr/bin/ps -e /usr/bin/grep bootpd root 20413 3006 0 10:51:09? 0:00 bootpd $ /usr/bin/kill 20413 This section discusses certain common bootpd problems and possible remedies. 112 Configuring the BOOTP and TFTP Servers

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. Following are the symptoms, causes, and actions for bootpd problems. Symptom: The server s system log file /var/adm/syslog/syslog.log does not contain any log messages from /usr/lbin/bootpd indicating that the server has started. A ps -ef listing does not show a running /usr/lbin/bootpd daemon. Cause: The server may not be started or it may not be receiving the client s bootrequest. Action: Make sure that the /etc/inetd.conf file is configured correctly as specified in the earlier sections. Ensure that you have reconfigured inetd with the command inetd -c. Check inetd s logging in the /var/adm/syslog/syslog.log file to ensure that inetd is configured to start bootpd. 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.log contains one of the following messages: hardware address not found: hardware_address IP address not found: ip_address Cause: bootpd does not have an entry in /etc/bootptab for this client s hardware address or IP address. Action: Check the system log for any indication of syntax errors for the client s configuration entry. Correct the entry in the /etc/bootptab file and reboot the BOOTP client. Ensure that the hardware address that you specified for the ha tag matches the hardware address that /usr/lbin/bootpd is unable to find. Correct the tag and reboot the BOOTP client. Ensure the hardware type tag ht has the correct value for the client. For example, if you have specified ether but the client is reporting ieee in its bootrequest, bootpd rejects the request. Correct the tag and reboot the BOOTP client. Symptom: The system log file /var/adm/syslog/syslog.log contains the following message: requested file not found: filename Troubleshooting BOOTP and TFTP Servers 113

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. If the requested file exists in the directory, be sure it is readable by the user tftp. (See Common tftpd Problems (page 115).) Symptom: The system log /var/adm/syslog/syslog.log contains the following message: cannot route reply to client's_ip_address Cause: The server cannot directly reach the IP address specified for the client. 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. Symptom: The system log contains one or more of the following error messages: duplicate hardware address: link_address bad host name: hostname syntax error in entry for host hostname unknown symbol in entry for host hostname bad IP address for host hostname bad subnet mask for host hostname bad time offset for host hostname bad vendor magic cookie for host hostname bad reply broadcast address for host hostname Cause: Any of these error messages indicates errors in the configuration file entry for the client. Action: For details on the error message, see Error Logging (page 117). Correct the appropriate field for the entry in the /etc/bootptab file and reboot the BOOTP client. Then, use bootpquery to send a bootrequest to the client. Verify the system log file /var/adm/syslog/syslog.log to check if the server replies. At debug level 2 (see Helpful Configuration Changes (page 112)), bootpd logs the following sequence of messages when it responds to a bootrequest: request from hardware address link_address found ip_address hostname 114 Configuring the BOOTP and TFTP Servers

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 = boot_file_size ds = domain_nameserver_addresses gw = gateway_addresses hn = hostname lg = log_server_addresses sm = subnet_mask to = time_offset Tnnn = generic_information Cause: Many RFC 1048 options are specified for the client s configuration entry in the /etc/bootptab file. The BOOTP protocol allows only 64 bytes of vendor extension information. When such extended information is included in the bootreply, bootpd must also add a 4-byte vendor magic cookie to the bootreply, a 1-byte tag indicating the end of the vendor information, and a 1-byte or 2-byte tag for each field (depending on the format of the field) along with the value of the tag itself. The total size of the extended information for a client must not exceed 64 bytes. Action: Ensure that the configuration contains only the necessary information to boot the client. Verify that the BOOTP client contains only the necessary tags and that the tags are supported by the client. For example, if the client supports only one name server address, you need not list three name server addresses with the ds tag. If the client does not support configuring its host name with the hn tag, you need not include the hn tag. 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. Ensure that the bootpd server is configured properly for tftp to transfer the boot file. For information on configuring bootpd, see Configuring the BOOTP Server (page 103). Now, try to transfer a file on a different node on the network, instead of the server node. If the server still fails to start when the client attempts the file transfer, it may be a connectivity problem. See Installing and Administering LAN/9000 Software or the BOOTP client manual (for example HP 700/X documentation). Troubleshooting BOOTP and TFTP Servers 115

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. System call failure: tftpd can exit if a system call failure occurs. The name of the system call and cause for the system call failure are logged in the system log file /var/adm/syslog/syslog.log. For more information about the cause for failure, see the system call in the HP-UX Reference at the URL http://www.docs.hp.com/hpux/os/man_pages.html. Problem with the password database entry: The error message User tftp unknown can occur if the password database entry for the user tftp is either missing or incorrect. Verify if the entry exists and is correct, and transfer the file again. Symptom: File transfer fails with File Not Found, No Such File or Directory, or TFTP Error Code 1 message. Cause: The file that the client is attempting to read from or write to the server does not exist within the home directory of the user tftp or in the path specified with the tftpd command. 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. Make sure that you specify the full path name when attempting to get a file from a directory specified with the tftpd command. Symptom: File transfer fails with Access Violation, Permission Denied, or TFTP Error Code 2 message. Cause: tftpd does not have permission to read the file. Action: If the transfer is a get operation where the client is attempting to read the file from the server, then the server does not have read permissions on the file that it is trying to send. Ensure that 116 Configuring the BOOTP and TFTP Servers

Error Logging 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. $ ll /home/tftpdir/xterm -r-------- 1 tftp guest 438 May 10 1989 xterm During a put operation (which is not something a BOOTP client does as part of the BOOTP protocol), an error message Access Violation, Permission Denied is displayed when a file does not have write permission on the server to write to the file. If the server receives a file, it must exist and be writeable by the user tftp. For example, if a tftp client is sending the file named fontlist, the file must have permission 0600 and must be owned by tftp: $ ll /home/tftpdir/fonts This section explains the error messages that bootpd logs through syslogd. The following logging levels are discussed in this section: Information Log Level (page 117) Notice Log Level (page 118) Error Log Level (page 118) You must set the bootpd debug level for logging these messages. You can set bootpd debugging level using the -d option. Information Log Level The following describes the messages logged at the syslogd information log level: exiting after time minutes of inactivity If bootpd does not receive a bootrequest within time minutes (the timeout set with the -t option), it issues this message and exits. reading configuration_file reading new configuration_file 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. request from IP addr ip_address bootpd received a bootrequest from a client with the indicated ip_address. This message is logged at debug level 1. found ip_address hostname bootpd located information for the specified client in its configuration database. This message is logged at debug level 1. broadcasting reply on ip_address Displays the broadcast address used by bootpd to reply to a client whose configuration entry has the ba flag. This message is logged at debug level 2. Troubleshooting BOOTP and TFTP Servers 117

vendor magic field is magic_cookie sending CMU-style reply sending RFC1048-style reply Notice Log Level Error Log Level 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. There may be cases where bootpd receives a bootrequest but does not send a bootreply. The reason is given in one of the following messages and logged at the notice log level: hardware address not found: hardware_address bootpd could not find a configuration entry for the client with the indicated hardware_address. If bootpd must be aware of the client that is booting, ensure that you have correctly specified the client s hardware address in the configuration file. IP address not found: ip_address bootpd could not find a configuration entry for the client with the indicated ip_address. If bootpd must be aware of the client that is booting, ensure that you have correctly specified the client s IP address in the appropriate configuration file entry. requested file not found: filename bootpd could not locate the boot file requested by the client. Ensure that the boot file is located in the tftp directory on the server system. cannot route reply to ip_address The IP address of the client or gateway to which bootpd sends the bootreply does not exist on a directly connected network. Ensure that you specify a valid IP address for the client or gateway. 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. bad hardware mask value for host hostname The formatting for the hardware address mask tag hm is incorrect in the configuration file entry for hostname. Correct the configuration entry and reboot the BOOTP client. The subnet mask must be specified in hexadecimal notation. bad hardware type for host hostname The value specified for the ht tag is an unsupported hardware type. For a list of the supported hardware types, type man 1M bootpd at the HP-UX prompt. bad hostname: hostname The name given in the hostname field is an invalid host name. Correct the host name and reboot the BOOTP client. A valid host name must begin with a letter followed by any number of letters, digits, periods, or hyphens. 118 Configuring the BOOTP and TFTP Servers

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. If you specify more than one IP address, separate the IP addresses with a white space. bad reply broadcast address for host hostname The formatting for the address in the ba tag is incorrect, or the ba tag value is invalid. Correct the configuration entry and reboot the BOOTP client. For more information, type man 1M bootpd at the HP-UX prompt. bad subnet mask for host hostname The formatting for the subnet mask tag sm is incorrect in the configuration file entry for hostname. Correct the configuration entry and reboot the BOOTP client. You must specify the subnet mask as a single IP address. bad time offset for host hostname The value for the to tag is an invalid number. Correct the configuration entry and reboot the BOOTP client. For the to value, you can specify either a signed decimal integer or the keyword auto, which uses the server s time zone offset. bad vendor magic cookie for host hostname The formatting for the vendor magic cookie, specified with the vm tag, is incorrect. Correct the configuration entry and reboot the BOOTP client. You can specify one of the following values for the vm tag: auto, rfc1048, cmu. can't find tc=label bootpd could not find a table continuation configuration entry with the host field label. Correct the configuration entry and reboot the BOOTP client. For more information, type man 1M bootpd at the HP-UX prompt. 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. syntax error in entry for host hostname The formatting for the host hostname s configuration entry is incorrect. Correct the configuration entry and reboot the BOOTP client. For information about the correct BOOTP configuration file syntax, type man 1M bootpd at the HP-UX prompt. unknown symbol in entry for host hostname The configuration entry contains an unknown tag or invalid character. Correct the configuration entry and reboot the BOOTP client. For information about the correct BOOTP configuration file syntax, type man 1M bootpd at the HP-UX prompt. Troubleshooting BOOTP and TFTP Servers 119

120

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. For every client, DHCP assigns a name and IP address. It also adds an address record (A), a pointer record (PTR), and a resource record (RR) of that client to the DNS server. The boolean tag pcsn is used to assign a name for every IP address. When this tag is set, the DHCP server gives priority to the name (if any) provided by the client. The name must be a fully qualified domain name (FQDN). If a FQDN is not specified, then the DHCP server appends the domain name (if set using the dn tag) else it appends a. (period) and updates the Dynamic DNS server (DDNS). Dynamic DNS Server Update Pre-Requisites The following pre-requisites are essential for a dynamic DNS server to accept updates from the DHCP server. The resource records (RR) must not exist for an add operation. The resource records must exist for a delete operation. These pre-requisites are used when the DHCP server dynimically updates (by either adding or deleting names and IP addresses) the DDNS server. You can configure DHCP to ignore these pre-requisites by adding the sp tag to the /etc/ dhcptab configuration file. To enable dynamic updates to the DNS server, you must configure the DHCP server along with the DNS server. See HP-UX IP Address and Client Management Administrator s Guide for information on how to configure the name server and to enable dynamic updates. NOTE: HP recommends that DHCP servers and DNS server run on the same machine for dynamic updates. Figure 4-1 illustrates a single HP-UX host running both the DHCP and DNS servers. Figure 4-1 DHCP Server and DNS Server running on HP-UX Dynamic Updates to the DHCP Server 121

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. DHCP tries to find the name if the name is not sent by the client. You can also specify the sp boolean tag when an update request is sent to the DNS server so that DHCP does not to use the prerequisite section, which exists in the update packet sent by the DHCP server to the DNS server, in the update request. DHCP_DEVICE_GROUP:\ ba:\ pcsn:\ sp:\ ddns-address=1.2.3.4:\ class-name=subnet_128_xterminal_group:\ class-id="xterminal:"\ subnet-mask=255.255.255.0 :\ addr-pool-start-address= 15.14.128.1 :\ addr-pool-last-address= 15.14.128.254 :\ lease-time=604800 :\ lease-grace-period=5 : Configuring DHCP to Assign and Distribute IP Addresses You can configure and administer the DHCP server using the HP System Management Homepage (HP SMH). You can also edit the configuration files /etc/bootptab and /etc/dhcptab manually. HP recommends you to you HP SMH to modify the configuration files. This section discusses about the steps to configure the DHCP server using HP SMH. You can configure the DHCP server using HP SMH to assign and distribute IP addresses in three different ways: By Device or Pool groups (you define which devices are in these groups). To individual devices. Through a BOOTP Relay Agent. DHCP Device and Pool Group Configuration Pool Groups DHCP allows you to configure groups of similar client devices on a single subnet. Each device in a specific group is automatically assigned an available IP address from its group upon requesting boot information. By creating various groups of devices you can create each group with a device type specific to that group. For example, you may want one group to contain only printers, and another group to contain only servers. The /etc/dhcptab file contains groups of IP addresses that are managed by DHCP. The IP addresses are divided into the following types: Pool Groups Device Groups A pool group is a collection of IP addresses on one subnet, available for anonymous clients (most clients are anonymous). The pool groups are the most common type of IP address groups. Following is an example pool group entry in the /etc/dhcptab file: DHCP_POOL_GROUP:\ 122 Configuring DHCP

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. 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.20 through 15.13.100.29. NOTE: A subnet must contain only one pool group that forms the default IP address group. Figure 4-2 Devices Configured in a DHCP Group In Figure 4-2, assume that a particular group is configured and the clients Client1, Client2, and Client3 belong to this group. Each device in this group has the same group name and an IP address that is within the group s IP address range. The IP addresses within the group s range collectively form a pool of addresses. When Client1, Client2, or Client3 perform a boot request, they are automatically assigned an IP address, which is not in use, from this pool of addresses. DHCP allows you to exclude certain addresses within a group if you do not want them used. You can also define many values for the devices of a group including address lease times, DNS servers, NIS servers, and many other optional parameters. See the example Complex DHCP Pool and Device Group Files (page 124) for more information. DHCP supports the subnet selection option. This option contains a single IPv4 address that specifies the address of a subnet. If this option exists in the DHCP client request, the DHCP server must allocate the address on either the subnet specified in the subnet selection option or a subnet on the same network segment as the subnet that is specified in the subnet selection option. For more information on the subnet selection option, see RFC 3011 (The IPv4 Subnet Selection Option for DHCP). DHCP Device Group You can create a device group by configuring similar client devices and specifying a unique IP address range for the group of client devices. The device group is similar to a pool group, except that in a device group all the clients must be of the same type. For example, all the clients must be printers or X terminals. These clients must match the device type specified in the class-id field in the /etc/dhcptab file. In the following example, all the clients in this device group must be X terminals. Configuring DHCP to Assign and Distribute IP Addresses 123

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. 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.11:\ addr-pool-last-address= 192.11.22.15:\ subnet-mask=255.255.255.0:\ lease-time=1000:\ lease-policy=accept-new-clients:\ allow-bootp-clients=false:\ call-on-assignment=/etc/script.assignment:\ call-on-decline=/tmp/script.decline:\ call-on-release=/tmp/script.release:\ call-on-lease-extend=/tmp/script.lease_extend:\ bf=goofy.bootfile:\ hd=/var/tmp:\ ba:\ cs=192.11.22.36:\ ds=192.99.99.99 15.13.104.13:\ gw=192.44.44.44:\ im=77.77.33.33:\ lg=123.123.123.123 55.55.55.55:\ lp=45.45.45.45:\ ns=66.66.66.66:\ rl=123.77.99.35:\ to=153:\ ts=88.99.88.99:\ vm=rfc1048:\ hn:\ bs=auto:\ md=/tmp/dumpfile.of.the.century:\ dn=cup.hp.com:\ ef=/tmp/extensions:\ nt=194.88.200.244:\ rp=/turnip/onion/carrot:\ ss=200.233.200.233:\ tr=50:\ tv=87:\ xd=77.11.1.244:\ xf=77.11.1.245:\ yd=hp.com:\ ys=9.7.5.3: For more information about the other flags in this example, type man 1 M bootpd at the HP-UX prompt. 124 Configuring DHCP

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. NOTE: Devices that have fixed IP addresses in the /etc/bootptab file have priority over pool groups. Devices with fixed IP addresses are placed first in /etc/bootptab file. Figure 4-3 DHCP Devices Can Have Fixed IP Addresses In Figure 4-3, assume that you have configured a DHCP group (group A) to include Client1 and Client2, meaning that each client receives an IP address from a pool of available addresses at boot request. If you configure Client3 and Client4 to have fixed IP addresses then client3 and client4 are assigned the addresses you configured for them upon boot request. Client3 and Client4 will always be assigned the same addresses unless you change the configuration. DHCP also allows you to define many optional parameter values for clients with fixed addresses. Fixed address devices are configured in the /etc/bootptab file. HP recommends you to use HP SMH to configure the /etc/bootptab file. 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. Configuring DHCP to Assign and Distribute IP Addresses 125

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. The relay agent then broadcasts a message which is received by client2. The message contains the booting information for client2. A gateway can also be configured to serve as a relay agent, if the gateway DHCP-smart. However, if the gateway does not have the knowledge of DHCP, then you must use a dedicated relay agent. In Figure 4-4, client1 does not require a relay agent because client1 is on the same network as the server. NOTE: Most of the modern routers are DHCP-smart. The capability to relay is built into the router, therefore you do not require a machine dedicated as a relay agent. Configuring PING Timeouts The DHCP server optionally sends a PING (ICMP echo) request to check if the IP address it wants to assign to a client is in use. If the server does not receive the reply in a specified time, the server assumes that the IP address is not in use. It then assigns that IP address to the client. The specified time is the timeout value in milliseconds. The timeout value can be set using the -p option. The timeout value can be between 1 and 3000 milliseconds. By default, the timeout value is 3000 milliseconds. You can use the following entry to specify the timeout value in the /etc/inetd.conf file: # bootps dgram udp wait root /usr/lbin/bootpd -p500 Monitoring and Troubleshooting DHCP Operations This section describes techniques and tools that you can use to troubleshoot problems encountered with the DHCP server. 126 Configuring DHCP

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. However, this method is only good for monitoring operations over short periods of time because the /var/adm/syslog/syslog.log file grows quickly. To enable the debugging option perform the following steps: 1. Open the /etc/inetd.conf file in an editor. 2. Insert the -d3 option in the bootp entry in the /etc/inetd.conf file. bootps dgram udp wait root /usr/lbin/bootpd bootpd -d3 3. Reconfigure inetd using the following command: # inetd -c. You must restart bootpd to use the debugging command-line option d3. Terminate bootpd. 4. Tail the syslog file by executing the following command: tail -f /var/adm/syslog/syslog.log grep bootp Perform the following checks on the output: Is the client request reaching the server? Does the server make a reply to the client? Is the reply appropriate for the client? Table 4-1 lists some of the common error messages you may see in the syslog file when a client fails to get an address lease. Table 4-1 Common Errors Found in Syslog Error 304 305 308 316 Cause A client requests an address on a subnet not available or accessible from this DHCP server. The client gets no response from this server. The pool or device group is full, that is the DHCP server has assigned all the addresses available. The client gets no response from this server. An illegal packet received. The DHCP server does not know anything about the client lease or has forgotten about the lease. In this case, the client falls back to request a new lease. Tracing DHCP Packet Flow You can turn on tracing by executing the following command: /usr/sbin/dhcptools -t ct=100 This command writes all contents of 100 packets to a file called /tmp/dhcptrace. Monitoring and Troubleshooting DHCP Operations 127

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. Review the contents of the file /tmp/dhcpdb, which is less verbose than the file /tmp/ dhcp.dump.dhcptab. The file /tmp/dhcpdb is continuously updated by the daemon. DHCP Troubleshooting Tools The DHCP server provides tools to debug problems and make adjustments while the server is running. When building the files /etc/bootptab and /etc/dhcptab, you need a tool that will automatically discover illegal entries and typographical errors. The command-line tool dhcptools is available to provide access to DHCP-related options for the bootpd server. The options provide control for dumping internal data structures, generating a host file, previewing client address assignment, reclaiming unused addresses, tracing packets, and validating configuration files. For more information, type man 1M dhcptools at the HP-UX prompt. After configuring the files /etc/bootptab and /etc/dhcptab, you must use the -v option to check for any detectable errors in the configuration files. If communication problems exist between the server and the client at a protocol level, and you have verified that no errors exist in the configuration files, you can use the -t option of the dhcptools command. This option performs packet tracing. You can use this option in conjunction with the -d option of the bootpd(1m) command. For more information, type man 1M bootpd at the HP-UX prompt. Here are some of the tools available and the appropriate reason for using them. dhcptools -v dhcptools -p dhcptools -r dhcptools -R dhcptools -d Automatically discovers illegal entries and typographical errors in the files /etc/bootptab and /etc/dhcptab. /usr/sbin/dhcptools -v Allows you to review a lease for a particular client. You can use it to ensure that the client is responding correctly. /usdhcptools -p ht=hardware_type ha=hardware_address\ sn=subnet_identifier [lt=lease_time][rip=requested_ip_address] Allows you to reclaim an individual lease address, making it available for a new client. dhcptools -r ip=ip_address ht=hardware_type ha=hardware\ _address dhcptools -R ip=ip_address ci=client_identifier Dumps the complete internal state of the server into files the dump files /tmp/dhcp.dump.*. /usr/sbin/dhcptools -d 128 Configuring DHCP

Callbacks 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. 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. These callbacks are defined in the /etc/dhcptab file as follows: DHCP_SERVER_SETTINGS:\ call-on-unrequited= /etc/script.unrequited :\ callback_style= NEW : call-on-unrequited= /etc/script.unrequited :\ call-on-assignment=/etc/script.assignment:\ call-on-decline=/etc/script.decline:\ call-on-release=/etc/script.release:\ call-on-lease-extend=/etc/script.extend:\ call-on-discard=/etc/script.discard: Each callback passes some command-line parameters (such as client hardware address, client IP address, class-id) to the executable file named in the /etc/dhcptab file. The executable is typically a shell script, but it can be any executable file. This is commonly used to send mail to the network administrator or to store data in a file about DHCP clients that have succeeded or failed in negotiating a lease. The following is an example callback script: Figure 4-5 Callback Script Example Monitoring and Troubleshooting DHCP Operations 129

130

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. It discusses the following topics: The dhcpv6d Server Daemon (page 131) Server Configuration File (page 132) Setting Up the DHCPv6 Server (page 132) Sample dhcpv6tab File (page 133) The dhcpv6d Server Daemon dhcpv6d is the IPv6 version of bootpd that runs as a standalone daemon. The dhcpv6d daemon supports the following features: Dynamic renumbering Relay preconfiguration with server addresses or use of multicast addresses Multiple IP addresses for an interface You can start dhcpv6d by one of the following methods: Invoking dhcpv6d from the command line. Editing the /etc/rc.config.d/netdaemons file to invoke dhcpv6d upon each reboot. Invoking dhcpv6d To invoke dhcpv6d, run the following command on the command line: /usr/sbin/dhcpv6d [-d] [-c config_file] [-k] [-h] [-r] [-u] [-C] [-R] where, -d Enables debugging. -c config_file Specifies the alternate configuration file to be read by the DHCPv6 server. The default file is /etc/dhcpv6tab. -k Kills the server gracefully. h max_hop_count Specifies the maximum number of hops allowed for a DHCPv6 packet after which the server drops the DHCPv6 packet. -r Rereads the configuration file and triggers the server to send a reconfig-init message to the clients when the configuration file has any new or updated information. u Enables the unicast option. C Enables the rapid commit option. R Runs the DHCPv6 server as a relay agent. Configuring the Server 131

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: system. You can use the -k and -r options only if a DHCPv6 server is already running on the 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. The dhcpv6tab contains the following sections: DHCPv6 client default settings (DHCP_CLIENT_DEFAULT_SETTINGS) This section specifies the tags for the DHCPv6 client default settings. These tags are applicable to all the addresses that the server assigns to the DHCPv6 client. DHCPv6 pool group settings (DHCP_POOL_GROUP) This section specifies the tags for an individual DHCPv6 pool groups. DHCPv6 relays settings ((DHCP_RELAY_SETTINGS) This section contains the relay-specific tags. DHCPv6 device group settings (DHCP_DEVICE_GROUP) This section specifies the tags for a DHCPv6 device group. DHCPv6 address pool settings (DHCP_ADDRESS_POOL) This section specifies the tags for an individual address pool. DHCPv6 relay interface mapping settings (RELAY_INTERFACE_MAPPINGS) This section specifies the tags for the relay interface mappings. DHCPv6 client duid (DHCP unique identifier) group settings (DHCP_CLIENT_DUID_GROUP) This section specifies the tags for a DHCPv6 client duid group. dhcpv6tab ignores blank lines and lines that begin with a pound sign (#). A semicolon (;) separates each entry in the configuration file. You can extend multiple entries of a group over multiple lines by ending the lines with a backslash (\). A final semicolon (;) followed by a new line indicates the end of a group. For more information on the tags included in the various sections of the dhcpv6tab file, type man 1m dhcpv6d at the HP-UX prompt. Setting Up the DHCPv6 Server You can use the following methods to set up the DHCPv6 server: Run the following command on the command line to start the DHCPv6 server: /sbin/init.d/dhcpv6d.server start Alternatively, if you want the DHCPv6 server to start automatically upon each reboot, set the DHCPV6D variable in the /etc/rc.config.d/netdaemons file as: DHCPV6D=1 To start the DHCPv6 server automatically, with the -d and -c arguments upon each reboot, set the DHCPV6SRVRD_ARGS variable in the /etc/rc.config.d/netdaemons file as follows: DHCPv6SRVRD_ARGS=-d -c <configuration file> 132 Configuring DHCPv6

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. ## ## # DHCP Client Default Settings ## DHCP_CLIENT_DEFAULT_SETTINGS;\ client-settings-name = VENUS;\ DNS-server-address = 5ffe:1234::1234:1 5ffe:1234::5678:2;\ DNS-server-domain-list = hp.com;\ SIP-server-address = 5ffe:1234::1234:3;\ SIP-server-domain-list = hp.com; ## # DHCP Pool Group : YELLOW group ## DHCP_POOL_GROUP;\ pool-group-name = YELLOW;\ default-settings = VENUS;\ address-pool-names = APPLE;\ elapsed-time = 100;\ # in 1/100 of the second preference = 255;\ T1 = 5000;\ T2 = 8000;\ preferred-life-time = 10000;\ valid-life-time = 12000;\ reconf-grace-period = 10000;\ DNS-server-address = 5ffe:1234::5678:1;\ renumber-complete-time = Mon Mar 8 17:01:55 IST 2004; ## # DHCP Address Pool : APPLE pool ## DHCP_ADDRESS_POOL;\ address-pool-name = APPLE;\ subnet-prefix = 5ffe:1234::34/64;\ address-pool = 5ffe:1234::4321:1000-5ffe:1234::4321:1999;\ reserved-addresses = 5ffe:1234::4321:1222; ## # DHCP Address Pool : GRAPE pool ## DHCP_ADDRESS_POOL;\ address-pool-name = GRAPE;\ subnet-prefix = 5ffe:1233::34/64;\ address-pool = 5ffe:1233::4321:2000-5ffe:1233::4321:2999;\ reserved-addresses = 5ffe:1233::4321:2345; ## # DHCP Relay Settings : BLUE group ## DHCP_RELAY_SETTINGS;\ pool-group-name = BLUE;\ subnet-prefix = 4ffe:1234::34/64;\ Configuring the Server 133

dest-dhcp-server-address = 7ffe:1234::34; ## # DHCP Device specific settings ## DHCP_DEVICE_GROUP;\ vendor-class-id = 1234 "OS = HP-UX B.11.11 U 9000/800" "Mem = 512 kb";\ V100 = "/depot/install";\ address-pool-names = GRAPE;\ preference = 255; ## # Interface mappings ## RELAY_INTERFACE_MAPPINGS;\ # <Interface ID1> -> <Subnet address> 10:24:ab:1d -> 3ffe::/64;\ ac:12:23 -> 3000::/64; ## # Client duid settings ## DHCP_CLIENT_DUID_GROUP;\ client-duid = 41:42:43:44:f2:ec:45:9f;\ pool-group-name = RED;\ addresses = 5ffe::90f 4000::209;\ DNS-server-address = 4000::100; NOTE: The dhcpv6tab file discards the DHCP_POOL_GROUP section because it starts with a pound sign (#). Configuring the Client This section describes how to configure the DHCPv6 client. It discusses the following topics: The dhcpv6client.data File (page 134) The dhcpv6clientd Client Daemon (page 135) Setting Up the DHCPv6 Client (page 135) The dhcpv6client_ui Interface (page 136) The dhcpv6config Script (page 137) The dhcpv6db2conf Utility (page 138) The dhcpv6client.data File The client database file /etc/dhcpv6client.data contains a series of records to represent various configuration parameters, such as DNS server address, DHCPv6 server address, DNS domain name list, and others. Each record is of the following format: <opcode> <length> <data> where <opcode> is the option code for the parameter or identifier, followed by a space. <length> is the length of the information, followed by a space. <data> 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. 134 Configuring DHCPv6

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. Invoking dhcpv6clientd To invoke dhcpv6clientd, run the following command on the command line: # dhcpv6clientd [-d config_options] [-e number] [-l] [-u list_of_user_classes] [-v list_of_vendor_classes] -d Specifies the list of configuration parameters that the client daemon must request from the server daemon. -l Enables the logging of all messages by dhcpv6clientd to the /var/adm/syslog/syslog.log file. -e Specifies the vendor s registered enterprise number as registered with IANA. You can use this number in the vendor-class and vendor-specific options while communicating with the server. u Specifies the user-class data used to represent the client in its communication with the server. This option can have a maximum length of 16 characters. You can use multiple -u options to specify multiple values for the user-class data. Depending on the classes identified by this option, the server selects the configuration information for the client. The user-class option is used to identify the type or category of the client. v Specifies the vendor-class data that you must use in the client s communication with a server. The vendor-class data contains a series of distinct items, each of which describes the client s hardware configuration. For more information on setting the DHCPV6_ENABLE variable in the netconf-ipv6 file, see The dhcpv6config Script (page 137). For more information about configuration parameters, type man 1m dhcpv6clientd at the HP-UX prompt. For more information on log message types, type man 3c syslog at the HP-UX prompt. Alternatively, you can use the /sbin/dhcpv6config script to invoke dhcpv6clientd. To start dhcpv6clientd automatically with the -d and -l arguments upon each reboot, edit the /etc/rc.config.d/netdaemons file. See The dhcpv6config Script (page 137) for more information. Setting Up the DHCPv6 Client You can use either of the following methods to set up the DHCPv6 client: To configure a new interface for IPv6, run the dhcpv6config script on the command line as follows: $ /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. Configuring the Client 135

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. Obtain multiple IP addresses for an interface. Obtain IP addresses with other configuration parameters. Release unused IP addresses obtained from the server. To invoke dhcpv6client_ui, run the following command on the command line: # /usr/bin/dhcpv6client_ui [-m interface_name] [-[t T]] [-o config_options] [-I] [-s vendor_specific_options] [-R] [-r interface_name [-v] where, -m Specifies the interface for which you must obtain IPv6 addresses and other configuration parameters. -o Specifies the list of configuration parameters. -s Specifies the list of vendor-specific options that the client daemon must request from the server daemon. You must use this option in conjunction with the -m option. -R Notifies the client to use the unused IP addresses stored in the /etc/dhcpv6client.data file instead of requesting new IP addresses from the server. -r Specifies the interface that receives the released IP addresses. -v Prints the version information of the client daemon. -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. 136 Configuring DHCPv6

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. The default parameters are set during the invocation of dhcpv6clientd, the DHCPv6 client daemon. NOTE: The client daemon must be running, when you execute the dhcpv6client_ui interface. For more information, type man 1 dhcpv6client_ui at the HP-UX prompt. The dhcpv6config Script /sbin/dhcpv6config is a screen-oriented shell script that allows you to configure an interface. You need to invoke dhcpv6config only once, when you are installing DHCPv6 software. Run the following command on the command line to invoke dhcpv6config in the interactive mode: $ /sbin/dhcpv6config [interactive -i] Upon startup, the script checks the /etc/rc.config.d/netconf-ipv6 file to check if the DHCPV6_ENABLE flag is set to any non-zero value for any interface. If the netconf-ipv6 file does not contain any such interfaces, the dhcpv6config script prompts you to answer the following questions: 1. Do you wish to use DHCPv6 to obtain networking information? If you wish to use DHCPv6, a list of all the network interface cards displays. 2. Enter the name of the lan interface you would like to configure followed by [Enter] or just press [Enter] to select the default interface, for example, lan4. Select the name of the lan interface and press [Enter]. You can select any other interface that needs to be configured. 3. Do you wish to configure any other interface? Press [y] to configure any other interface or [n] to quit. The information about the interface that is configured is written to the /etc/rc.config.d/netconf-ipv6 file. The /sbin/dhspc6config script also checks whether dhcpv6clientd is already running on the system. If it is not running, the script invokes the client daemon. 4. The following message is displayed while the script invokes the client daemon: Starting dhcpv6clientd... 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.d/netconf-ipv6 file as follows: IPV6_SECONDARY_INTERFACE_NAME[0]=lan4:1 DHCPV6_ENABLE[0]=1 Configuring the Client 137

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. The dhcpv6config script invokes dhcpv6db2conf when the dhcpv6client.data file has new or updated information. Alternatively, run the following command on the command line to invoke dhcpv6db2conf and to specify a list of interfaces: # dhcpv6db2conf [-a -c -p] [-d] [-i] [-n] [-s] [-v] [lan_interfaces] where, -a Using the results of the specified filter, directly apply the variable definitions to the existing configuration files (for example, /etc/rc.config.d/netconf-ipv6). c Create a set of staging files using the results of the selected filters. d Process the DNS variable set: [domain, nameserver]. i Process the INTERFACE variable set: [IPV6_SECONDARY_INTERFACE_NAME, IPV6_ADDRESS, IPV6_PREFIXLEN, DHCPV6_ENABLE]. p Print results to the screen (stdout), this is the default action if neither -c nor -a are specified. n Process the SIP server address and SIP domain name information. s Process the NIS variable set [NIS_DOMAIN, YPSET_ADDR]. v Process the vendor-specific information. lan_interfaces Specifies LAN interfaces such as lan0, lan1, whose data must be translated to a readable format. If you do not specify the LAN interface, dhcpv6db2conf processes the entries of all interfaces which are UP. When you invoke dhcpv6db2conf with the -a option, dhcpv6db2conf updates the /etc/resolv.conf, /etc/rc.config.d/netdaemons/, /etc/rc.config.d/netconf-ipv6, and /etc/rc.config.d/namesvrsfiles. For more information, type man 1 dhcpv6db2conf at the HP-UX prompt. 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. 138 Configuring DHCPv6

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. It discusses different dhcpv6d error messages displayed and also the respective troubleshooting methods. It also discusses crash recovery for a DHCPv6 server and client. The syslog.log File The /var/adm/syslog/syslog.log is a log file that contains the log messages for all subsystems. You can use these log messages to characterize a particular problem. The DHCPv6 client and the server log messages to the syslog.log file. The client and the server check this log file for the validity of server requests and client requests, respectively. Error Messages The dhcpv6d daemon validates the configuration file and logs the error messages into the syslog file. Table 5-1 describes the error messages that dhcpv6d logs in the syslog file and also the cause and method to rectify the problem. Table 5-1 dhcpv6d Error Messages Error Message No Address Pool Name Cause When you do not specify the address pool name under the DHCP_ADDRESS_POOL section. Troubleshooting Tip Specify the address pool name in the DHCP_ADDRESS_POOL section and restart the dhcpv6d server. process_msg: not a valid option <20> in <9> message When the DHCPv6 client sends a message with an option that is not supposed to be part of that message. For example, this error message is logged when the OPTION_RECONF_ACCEPT( 20) option exists in the DECLINE(9) message. You must configure your client in conformance to RFC 3315 (Dynamic Host Configuration Protocol for IPv6 (DHCPv6)). 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. Troubleshooting DHCPv6 139

140

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.conf file: Role of slpd as a Directory Agent (DA) or Service Agent (SA) server Static scope configuration Serialized proxy registrations UA configuration Network interaction Timing of multicast messages Enablement of tracing and logging for SLP This section discusses the following topics: Directory Agent Configuration Properties (page 141) Static Scope Configuration Properties (page 141) Tracing and Logging Configuration Properties (page 142) Network Configuration Properties (page 142) Service Agent Configuration Properties (page 143) User Agent Configuration Properties (page 143) Sample slp.conf File (page 144) Directory Agent Configuration Properties Table 6-1 describes the configuration properties for the Directory Agent (DA). Table 6-1 DA Configuration Properties Property net.slp.isda=true net.slp.daheartbeat net.slp.daattributes Description A Boolean value that indicates whether the SLP server acts as a DA. If it is false, slpd runs as an SA server. Default is false. A 32-bit integer that represents the DAheartbeat in seconds. Default is 3 hours (10800 seconds). This value is ignored if isda is false. A comma-separated list of parenthesized attribute or value list pairs that the DA must advertise in DAAdverts. The property must be in the SLP attribute list wire format, including escapes for reserved characters. This property is currently ignored. Static Scope Configuration Properties Table 6-2 describes the properties you can use to configure the various aspects of scope handling. Directory Agent Configuration Properties 141

Table 6-2 Static Scope Configuration Properties Property net.slp.usescopes net.slp.daaddresses Description 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. If you do not specify this parameter in the UA or when scope information is not available from DHCP, then SLP uses the user scoping model. The UA can provide available information on all the scopes to be used through active or passive DA or SA discovery. If this information is not discovered here, then the scope DEFAULT is used. Unlike the other properties, this property is read-only. Hence, SLP ignores any attempt to change this setting after reading the configuration file. A value list of IP addresses or DNS resolvable host names of DAs that the statically configured UAs and SAs use for sending queries and registrations. DAs ignore this value-list unless the DA is also an SA server. The default value is none. Unlike the other properties, this property is read-only. Hence, SLP ignores any attempt to change it after reading the configuration file. Tracing and Logging Configuration Properties Table 6-3 describes the properties that you can use to configure the tracing and logging information for the various SLP agents. Table 6-3 Tracing and Logging Properties Property net.slp.tracedatraffic net.slp.tracemsg net.slp.tracereg net.slp.tracedrop Description Controls the printing of messages about traffic with DAs. The default value is false. Controls the printing of details on SLP messages. The default value is false. Controls the printing of dumps of all registered services upon registration and deregistration. The default value is false. Controls the printing details when a SLP message is dropped. The default value is false. The SLP API specifies the following properties for reporting the internal functioning of an SLP agent: net.slp.tracedatraffic net.slp.tracemsg net.slp.tracedrop net.slp.tracereg Network Configuration Properties You can configure the network properties described in Table 6-4 by using the /etc/slp.conffile. 142 Configuring SLP

Table 6-4 Network Configuration Properties Property net.slp.isbroadcastonly net.slp.passivedadetection net.slp.multicastttl net.slp.daactivediscoveryinterval net.slp.multicastmaximumwait net.slp.multicasttimeouts net.slp.dadiscoverytimeouts net.slp.datagramtimeouts net.slp.randomwaitbound net.slp.mtu net.slp.interfaces Description 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. A Boolean value that indicates if passive DA detection needs to be used. Default is true. A positive integer less than or equal to 255 that represents the multicast TTL. Default is 255. A 16-bit positive integer that represents the time difference between DA active discovery queries. Default is 900 seconds (15 minutes).to turn off active discovery, set this property to zero. SLP uses this property when the DAs available are explicitly restricted to those obtained from DHCP or the net.slp.daaddresses property. A 32-bit integer that represents the maximum time to perform multicast, in milliseconds. Default is 15000 ms. (15 seconds). This parameter value is not being used currently. Instead, SLP generates multicast timeouts internally based on the net.slp.multicastmaximumwait parameter. This parameter value is not being used currently. Instead, SLP generates multicast timeouts internally based on the net.slp.unicastmaximumwait parameter. A 32-bit integer that specifies the maximum value for all random wait parameters, in milliseconds. Default is 1000 ms. (1 second). A 16-bit integer that specifies the network packet MTU, in bytes. This is the maximum size of any datagram to send, but the implementation might receive a larger datagram. The maximum size includes IP, and UDP or TCP headers. Default is 1400 bytes. A value list of strings that specifies the IP addresses of network interfaces on which the DA or SA should listen on port 427 for multicast, unicast UDP, and TCP messages. The default is to use all the network interfaces. Service Agent Configuration Properties This section describes the properties for the Service Agent (SA). Typically, these properties are set programmatically because they are specific to each SA. net.slp.saattributes is a comma-separated list of parenthesized attribute or value list pairs that the SA must advertise in SAAdverts. The property must be in the SLP attribute list wire format, including escapes for reserved characters. Currently, this property is not supported. User Agent Configuration Properties Table 6-5 describes the configuration properties for the User Agent (UA). You can set these properties either programmatically or through the /etc/slp.conf file. Service Agent Configuration Properties 143

Table 6-5 UA Configuration Properties Property net.slp.locale net.slp.maxresults net.slp.typehint Description 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. A 32-bit integer that specifies the maximum number of results to accumulate and return for a synchronous request before the timeout, or the maximum number of results to return through a callback if the request results are reported asynchronously. DAs and SAs always return all results that match the request. This configuration value applies only to UAs that filter incoming results and only return as many values as net.slp.maxresults indicates. A value list of service type names. In the absence of any DAs, UAs perform SA discovery for finding scopes. These SA discovery requests may contain a request for service types as an attribute. Static Registration The SLP implementation allows legacy service applications that are not SLP enabled (that is, applications that were not compiled to use the SLP library) to participate in the SLP framework, allowing UAs to dynamically discover these legacy services. The SLP software contains a default file, /etc/slp.reg, to provide the service information of these non-slp-enabled applications. The SLP daemon, slpd, reads this default file during startup, and it rereads this file whenever a SIGHUP signal is received. You can specify a different file using the -r option of the slpd command. As an example, to register the SSH service, add the following line in the /etc/slp.reg file: ## Register ssh service service:ssh.openslp://192.168.10.1, en, 65535 Sample slp.conf File A sample slp.conf file is as follows: #-------------------------------------------------------- # Static Scope and DA Configuration #-------------------------------------------------------- # A value list of strings indicating the scopes that a UA or # SA is allowed to use while making requests or # registrations, or the scopes that a DA must support. The # default value is DEFAULT ;net.slp.usescopes = myscope1, myscope2, myscope3 # Allows administrator to force UA and SA agents to use # specific DAs. If this setting is not used, dynamic DA # specific DAs. If this setting is not used, dynamic DA # (Default is to use dynamic DA discovery) ;net.slp.daaddresses = myda1,myda2,myda3 #-------------------------------------------------------- # Network Configuration Properties #-------------------------------------------------------- # Force broadcasts to be used instead of multicast. This # setting is seldom necessary because SLP automatically uses # broadcast if multicast is unavailable. (Default is false) ;net.slp.isbroadcastonly = true # A Boolean value indicating whether passive DA detection 144 Configuring SLP

# should be used. (Default is true) ;net.slp.passivedadetection = false Sample slp.conf File 145

146

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 creating subdomain, 64, 86 debugging, 98 hostname resolution, 19, 20 name server caching-only server, 64 forwarding server, 64 master server, 64 slave server, 64 name space, 16 resolver, 19 statistics, 100 troubleshooting, 92 with HP VUE, 82 boot file configuring location, 106 configuring name, 105 configuring size, 106 in bootptab file, 105, 106 on caching-only server, 80 on master server, 68 on slave server, 77, 78 pathname, 116 transfer timed out, 115 transferring with TFTP, 46 boot servers in bootptab file, 107 boot.cacheonly file, 80 boot.sec file, 77 boot.sec.save file, 77 BOOTP adding clients, 104 boot servers for relayed packets, 105 configuration example, 107 configuration file syntax, 106 configuring, 103, 104 determing address, 44 logging, 104, 112, 117 phases of operation, 44 relay option tag description, 106 selecting bootfile, 44 tag description, 106 testing, 104 troubleshooting, 112 unsupported products, 103 BOOTP relay agent, 45 adding clients, 104 configuration example, 108 configuring boot servers, 105, 107 example, 45 for DHCP, 125 BOOTP Relay Agents, 125 bootpd server, accessing DHCP options for, 128 bootpd daemon killing, 112 bootpquery command, 104, 113 example, 109 bootpquery program, 106 bootptab file, 105 client option tag description, 106 description for relay option tag, 106 template for defaults, 106 bootreply, 44 bootrequest gateway address, 45 giaddr value, 45 hardware address, 45 hops value, 44 packet, 44 seconds value, 45 threshold value, 45 bootrequest packet, 44 Bootstrap Protocol (see BOOTPD) bp tag in bootptab file, 107 broadcast address for testing BOOTP, 106 bs tag 147

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 slave name server, 77 timeout values, 83 configuration statement sortlist statement, 41 configuration statement in BIND acl statement, 26 include statement, 26 key statement, 27 logging statement, 27 options statement, 30 server statement, 41 zone statement, 42 configuring dynamic DNS, 122 configuring BOOTP, 103 Configuring device groups, 122, 123 Configuring pool groups, 122 convert_rhosts script, 86 current origin, 72, 75 customizing DHCP servers, 129 D DAAdvert message, 60 db.127.0.0 file, 72 db.cache file, 67, 70, 77 db.domain file, 73, 87 db.net file, 75 db.root file, 87 DHCP, 46, 49 accessing options for bootpd server, 128 benefits, 46 BOOTP relay agent, 125 clients, 47 device groups, 122, 123 DHCPACK packet, 48 DISCOVER packet, 48 fixed-address devices, 125 leases, 47 monitoring, 126 OFFER packet, 48 pool groups, 122 REQUEST packet, 48 servers, 46 troubleshooting, 126 troubleshooting techniques, 127 troubleshooting tools, 128 DHCP Configuration Overview, 122 DHCP servers callbacks, 129 dhcptools, 128 DHCPv6, 49 client/server communication, 50 components, 49 message types, 52 UDP ports, 50 DNS, 16 change notification, 17 contact address for setting up a new domain, 63 creating subdomain, 64 dynamic, 121 name space, 16 naming convention, 64 registering a new domain, 63 server, 121, 122 setting default domain name, 68 DNS domain creating subdomain, 86 setting default DNS domain name, 82 setting default domain name, 80, 81 Domain Name System (see DNS) domain option in /etc/resolv.conf file, 21, 82 dynamic DNS configuring, 122 Dynamic Host Configuration Protocol (see DHCP) Dynamic Host Configuration Protocol, see DHCP, 46 dynamic update enabling, 18 usage, 18 dynamic updates pre-requisites, 121 E /etc/resolv.conf file, 19, 20, 82 example, 144 error messages in bootpd, 114 /etc/hosts file, 67, 86 148 Index

Expire value in SOA record, 73 F file transfer timed out, 115 with TFTP, 46, 111 fixed IP addresses, 125 G 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 H $HOME/.rhosts file with BIND, 86 ha tag in bootptab file, 105, 106, 107 hardware address from diskless client, 106 in bootptab file, 105, 106 in bootrequest, 45 mask, 107 hardware mask in bootptab file, 107 example, 108 hardware type in bootptab file, 105, 106 hd tag in bootptab file, 106 HINFO record, 74, 76 hm tag in bootptab file, 107 hn tag in bootptab file, 106 hops value in bootptab file, 107 in bootrequest, 44 host information record (see HINFO record) host name aliases, 20 for diskless clients, 106 in bootptab file, 105, 106 translating to Internet address, 19, 20 when to end with a dot, 20 host name resolution, 19, 20 HOSTALIASES variable, 20 hostname fallback, 64 hosts.equiv file 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 I IA, 52 Identify Associations (see IA) IN class (see Internet address) IN-ADDR.ARPA domain, 72, 75 include statement, 26 Incremental Zone Transfer Protocol (see IXFR) inetd connection logging, 115 inetd.conf file BOOTP entry, 112 TFTP entry, 103, 115 inetd.sec file with BIND, 86 interface type in bootptab file, 105, 106 Internet address for diskless clients, 106 in BIND data file, 72 in bootptab file, 105, 106 in bootreply, 45 translating to host name, 19, 20, 75 ip tag in bootptab file, 105, 106 IXFR advantages, 18 enabling and disabling, 18 K key statement, 27 L lightweight resolver protocol, 21 link level address from diskless client, 106 in bootptab file, 105, 106 in bootrequest, 45 mask, 107 LOCALDOMAIN variable, 21 localhost address in BIND data files, 72, 80 log file specifying number of backup versions, 28 logging BOOTP, 117 in BIND, 88 logging statement, 27 149

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.netrc file with BIND, 86 name server configuring caching-only server, 80 root name server, 87 slave server, 77 debugging, 98 for root domain, 19, 87 in BIND choosing a host, 65 configuring, 67 slave server, 64 restarting, 76, 87 running on remote host, 82 starting, 84 statistics, 100 testing, 86 name server record (see NS record) name service choosing, 64 Name Service Switch, 64 name space, DNS, 16 named starting, 84 startup script, 85 NAMED variable, 85 named.boot file, 67 on caching-only server, 80 on master server, 68 on slave server, 77, 78 named.stats file, 100 nameserver option in /etc/resolv.conf file, 82 ndots option in /etc/resolv.conf file, 20 net.slp.daattributes boolean value, 141 net.slp.daheartbeat boolean value, 141 net.slp.isda boolean value, 141 Network Information Center (see NIC) network interface type in bootptab file, 105, 106 Network Time Protocol, 49 NIC, 63, 67 NS record, 71, 72, 74, 75, 87 nslookup command, 85 nsquery command, 93 NTP, 49 O options statement, 30 P passwd file configuring tftp entry, 114 pathname for boot file, 106 ping command, 92 PPL with BOOTP and TFTP, 103 primary server, 64 PTR record, 72, 75, 76 put command in TFTP, 112 R rcp failure after BIND startup, 92 Refresh value in SOA record, 73 remote daemon control utility (see rndc utility) Remote Maintainance Protocol (see RMP) remote name daemon control utility commands, 22 configuration file example, 23 format, 21 remsh failure after BIND startup, 92 RES_TRANS environment variable, 83 RES_TRY environment variable, 83 resend lines in named.run, 96 resolver configuring, 82 resolver daemon lwresd daemon, 21 resolver in BIND, 19 Retry value in SOA record, 73 RFC 1035, 94 RFC 1048, 106, 115 RFC 1535, 82 RFC 1766, 144 RFC 2136, 18 RFC 2535, 90 RFC 952, 24 150 Index

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.conf file, 21, 82 secondary server, 64 seconds value in bootrequest, 45 Serial value in SOA record, 73 server dynamic DNS updates, 121 server statement, 41 services file BOOTP entry, 103 sig_named command, 76, 87, 100 slave server configuring, 77 SLIP with BOOTP and TFTP, 103 slpd daemon, 61 SLPDeReg() API, 61 SLPError error code, 59 SLPFindAddrs() API, 61 SLPFindSrvs() API, 61 SLPFindSrvTypes() API, 61 SLPReg() API, 61 sm tag in bootptab file, 105, 106 SOA (see start of authority) SOA record, 75, 76 Serial value, 76 SOA records, 73, 72 (see start of authority record) SrvAck message, 60 SrvDeReg message, 60 SrvReg message, 60 SrvTypeRply message, 59 SrvTypeRqst message, 59 start of authority record, 17, 72 statement in BIND acl, 26 include, 26 key, 27 logging, 27 options, 30 server, 41 sortlist, 41 zone, 42 static scope configuration property net.slp.daaddresses, 142 net.slp.usescopes, 142 station address from diskless client, 106 in bootptab file, 105, 106 in bootrequest, 45 mask, 107 stealth servers, 17 subdomain, 86 in DNS, 64 subnet mask for diskless clients, 106 in bootptab file, 105, 106 syslog errors found, 127 syslogd daemon, 85, 86, 112, 117 System Management Homepage (see HP SMH) T tc tag in bootptab file, 106 example, 108 template for defaults, in bootptab file, 106 TFTP, 44 common problems, 115 example, 111 file transfer option, 111 home directory, 111, 114 logging, 112 testing, 111 troubleshooting, 112 unsupported products, 103 tftp error message, 118 TFTP Error Code 2 message, 116 tftpd, the TFTP server, 44 threshold value in bootrequest, 45 time to live field (see ttl field) timeout values, 83 tracing and logging configuration property net.slp.tracedatraffic, 142 net.slp.tracedrop, 142 net.slp.tracemsg, 142 net.slp.tracereg, 142 Trivial File Transfer Protocol (see TFTP) troubleshooting BIND, 92 BOOTP, 112 DHCP, 127 dumps, 128 name server, 95 syslog, 127 TFTP, 112 151

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.25 with BOOTP and TFTP, 103 Z zone statement, 42 152 Index